Page - 1

Implementation of API & Other Standards and Trends in Tertiary Measurement Devices

Presented by: Alan L.McCartney, President, Omni Flow Computers, Inc Kenneth D Elliott, Executive Vice President, Omni Flow Computers, Inc

Introduction As the energy industry continues to re-engineer itself through "downsizing", "rightsizing", andmergers, standardization of product selection andoutsourcing elements of engineering, operations andmaintenance is much in evidence. This does not relievethe user of the responsibility of being knowledgeable ofhis own processes and the underlying technologiesemployed.

There is collateral consolidation in vendor groupings,too. This is resulting in product rationalization and theemergence of only a few expert companies in variouscustody measurement specialties with sufficientcommitment to maintain product excellence andintegrity. A lack of commitment can lead to a loss ofquality control which, in turn, impacts on customerrelationships. One can be easily persuaded that changesin our perception will continue to occur in whatconstitutes a typical tertiary device e.g. flowcomputers. It has already been established that they arecapable of multiple uses. Current and emergingtechnologies will have a profound effect on theirultimate role in the future of measurement, control, anddata acquisition systems.

Part 1: Software & Hardware architecture ofcomputational devices

In this microprocessor age, software is a key ingredientin virtually every aspect of our environment. In custodytransfer, software implementation and certification ofAPI Standards in several generations ofmicroprocessor-based devices has always been asubject of debate by a number of users. The expertknowledge required both by the manufacturers andusers, contrary to expectation, is less in evidence todaythan a decade ago due to cyclical and structuralchanges in the energy industry. One cannot consider thesoftware development independently of hardwarearchitecture design.

32-bit Processors & Memory Requirements It isestimated that the leading manufacturer of panel-mount flow computers may have as much as 70% of32-bit flow computer installations over the past fouryears. This would suggest that only manufacturersthat have achieved critical mass in field-provencustody applications with 32-bit based unitsworldwide have the breadth of experience andresource to effectively use these fastermicroprocessors. For example, a flow computerwhich uses a 32-bit processor not only can performcalculation-intensive tasks in 200 msecs but can alsoundertake concurrently a variety of related controland communication functions with minimalprocessing impact if properly programmed by themanufacturer. Only one manufacturer hassuccessfully achieved that to date.

There also remains a significant difference inrequirements of realtime, continuously calculating110/220AC/24VDC powered systems vs. intervalprocessing for 6VDC low-voltage systems e.g.continuous sampling, say every 1 sec. but with a 1minute calculation cycle. These low voltage flowcomputers, particularly solar powered systems in gasmeasurement are the norm because of the absence ofcontinuous power cf. chart recorders! The processor,to conserve power, is maintained in a 'sleep' modewith minimal activity occurring until such time as acalculation routine needs to be activated. Heatdissipation of the processor is also a major concernfor many applications and impacts on the reliabilityand longevity of the electronics.

There are distinct differences between third party 32-bit PC chipset modules for industrial applications andembedded processor hardware designed entirely fromthe fundamentals by the manufacturer with a tightcoupling between hardware and software beingachieved. The latter

Page - 2

approach is used in the majority of industrialapplications including DCS systems. Memoryaddressing capability of processors can differsignificantly. Compare Intel's 64K segmentedarchitecture addressing constraints to Motorola's 16 Mblinear addressing capability. This can have a majorimpact on the programmer's ability to write efficientcode.

Programming language selection has a direct impact onmemory requirements for firmware code. Optimizedcode written in assembler language operates moreefficiently than higher level languages using compilers.Memory requirements will increase as a result. Theprincipal task of the flow computer can be lost in the"shuffle"

Microprocessors and Math Coprocessors Theprimary function of a flow computer is still to undertake“number crunching”. Consequently, a math co-processor chip can speed up math processingsignificantly. Because ‘same chip family’ parts areused, there is usually a tight integration between theCPU and the math co-processor chip or it is already anintegrated chip function as is found in Intel 486 PC andlater chip architectures. Major improvement inperformance with little added programming complexitycan be obtained.

The math co-processor supports single precision (32bits), double precision (64 bits) and extended precision(80 bits) floating point formats. Floating pointcalculations can make use of the 80-bit extendedprecision format by keeping intermediate results infloating point registers thus increasing the precision ofthe total calculation.

Dedicated floating-point math hardware chips willalways outperform comparable software solutions.This does not mean that the hardware and softwaremath methods will produce differing results, it simplymeans that more processor time will be available forother tasks.

In a realtime, multitasking system, time-dependentfunctions have their own processing allotment. Softwaretasks are divided into time intervals based on theirpriority. They are managed by an interrupt drivenscheduler which executes the task during theappropriate time interval. Execution times for eachinterval is maintained and recorded for system

evaluation. Tasks may run every 10msec, 50 msec,100 msec, 200 msec or 500 msec. Lower prioritytasks can be preempted by higher priority tasks.Very low priority tasks, such as formatting a reportfor printing, are handled in “background” and aregiven CPU time when other tasks are not running.Asynchronous events such as serial communicationsare interrupt driven and are given a priority basedupon their individual interrupt levels.

Other ways of increasing processing throughput is tooperate with multiple processors with assigned tasks.Using a separate microprocessor as acommunications controller or I/O controller, forexample, requires the programmer to write twoseparate programs, which must be able to access thesame database without data synchronizationconcerns. This can be a source of continuingproblems when designing and testing the applicationcode. Consider also the challenge of system-orientedvendors who must meet the burden of project customspecifications and require staff or contractprogrammers writing the necessary code on a one-offproject basis including testing and documentation.This goes a long way to explaining why there isincreased standardization and configurationflexibility, a trend that has been led by this vendor.

Software Mapping There is a lot more that goesinto the development of a flow computer than thecalculations. In fact, that is the easiest part of thedevelopment. Other auxiliary functions such as PIDcontrol, meter proving, valve and sampler control,archiving, batch processing and datacommunications, just to name a few, are thechallenging parts. Most of these can be logicallybroken into tasks based on their function. Thesetasks are broken into modules for easier maintenance(Omni’s Software Coding Standard limits modules tobelow 1000 source code lines).

How these sections of code are put in memory isimportant if they are to work seamlessly together.Shared data and entry points must be automaticallyresolved at build time to eliminate human error.Separate executable sections ease debugging andallows code to be upgraded a section at a time.Multiple programmers must be able to work onsections of a product's code without interfering withanother's memory space.

Page - 3

Moving memory allocation and usage around becauseof poor planning can cause unnecessary delays in theprogramming cycle. Stack space must be allocated forworst case conditions and be monitored for overflow.Interrupt routines must be able to locate buffers andvariables regardless of where the CPU was wheninterrupted (this can be difficult in segmentedarchitectures). Getting the most out of memory requiresa well-considered design and careful coding. “Wasting”memory because there seems to be plenty available canhave consequences down the road. Software engineersnot only need to think about what goes into the productnow but also to consider how enhancements will beadded in the future.

The database holds information for configuration andreal-time results as well as intermediate results and rawdata. Two goals of creating this ram area is to keeprelated information together so every module can accessit efficiently and ensure that variable locations do notchange between software upgrades.

The above discipline and experience distinguishes andelevates product acceptance and performance in themarketplace and goes some way towards explainingwhy there are fewer suitable flow computer productsavailable to the custody market today.

Flow Computer Capabilities The minimum one shouldexpect when assessing capabilities of flow computersin meeting the requirements of current and emergingstandards:

♦ ‘Near’ Real Time computation: computationalcycles of 500 mS. or less, with continuous processsampling

♦ Concurrent computations involving multiple meterruns measuring different fluid products

♦ Resident algorithms and measurement tables able tocorrect flows of Crude Oils, Refined Products,LPGs, NGLs, Olefins, Chemicals and Aromatics

♦ Resident algorithms and tables to measure NaturalGas, Speciality Gases, Steam and WaterCondensate.

♦ Automatic control of a meter Prover with the abilityto provide API proving reports and meter factorcurve storage and maintenance

♦ New meter factor validation against flow /viscosity performance curve and againsthistorical meter factor data.

♦ Ability to Flow Weight Average all relevantmeasurement input data and computationalresults based on hourly intervals, daily and batchtransactions. FWA’s allow reasonableverification of real time computed results

♦ Automatic reporting and storage of data for:multiple batches, hours and days

♦ Handle all security issues: configuration access,totalizer tampering

♦ Provide diagnostic functions and displays to aidin certification of calculated results process,including viewing inputs from field devices

API Calculation Procedure So how does a flowcomputer implement the current API VolumeCorrection Standards for Crudes & RefinedProducts? See APPENDIX A CTL/CPL FlowChart. There are actually six steps.

Step 1: With observed product density at flowingconditions (RHOobs),density at standard temperature,60oF or 15oC, and flowing pressure i.e. elevatedpressure is calculated, using API MPMS Chapter11.1, Table 23 A /B or 53 A/B algorithm

Step 2: With calculated reference density from Step1and flowing temperature, the initial compressibilityfactor 'F' is calculated using API MPMS Chapter11.2.1 algorithm.

Step 3: Using initial 'F' from Step 2, equilibrium andflowing pressures, the initial pressure correctionfactor 'Cpl' is calculated using API MPMS Chapter12.2 rounding and truncating rules.

Step 4: The product density at standard temperatureand equilibrium pressure is calculated by adjustingthe density at standard temperature and flowingpressure obtained at Step 1 by the 'Cpl' factorcalculated at Step 3.

Step 5: Iterate Steps 2,3 & 4 until the change in Cplfactor obtained is less than 0.00005.

Page - 4

Step 6: Using flowing temperature and product densityat standard temperature (RHOb) and equilibrium orbase pressure (Pba), the volume correction factor, Ctl, iscalculated using Table 24 A/B or 54 A/B, depending onwhether U.S. customary or metric measurement unitsare in use.

Part 2: API Volume Correction Standards andAPI ELM Standard Development

API Physical Properties Changes 64-bit floating-point operations capability from currently available PCprocessors and flow computers which alreadyincorporate math coprocessing capability hasencouraged the API into developing more complexalgorithms and simplification of arithmetic operationsin the revised API MPMS Ch. 11.1 currently beingballoted. Using increased decimal precision andfloating-point math routines in place of the less rigorousimplementation procedures using integer math and lowprocessing capabilities existing in the 1970s and 1980s,discrepancies between the 60°F, 15°C and 20°C Tableshave surfaced. These differences were not identified dueto the rounding and truncation procedures required toimplement the algorithms. These were devised to ensurereproducibility of results from different devices. Inpractice, the new routines will result in approximately16 or more decimal places for all calculations.

The procedures by which volume correction factors arecalculated to a consistent five decimal places for allVCF factors are also being revised. Due to thewidespread use of realtime density measurement,temperature and pressure corrections will be performedas one procedure. It will now be possible to improve theconvergence methodology for the correction of observeddensity to base density. API is adopting a moreadvanced convergence methodology than waspreviously possible to do the calculations. Theprocedures have been written without rounding becausethey can be part of an iterative loop and rounding offactors could mean slow or non-convergence ofiterative calculations.Older flow computer technology embodying 16-bittechnology may not reproduce factors exactly to a 5decimal place resolution. The standard requires that allcalculations must also be executed using double-

precision calculations and that all constants arecarried to the exact number of digits as required bythe standard.

Underlying data, equations and associated constantshave not been changed but there are increased densityand temperature ranges that accommodates lowertemperatures and higher densities. None of the aboveapplies to the 1952 Tables which were derived fromempirical data developed during the 1930s and 40s.

ELM Standard The API Standard dealing withElectronic Liquid Measurement, MPMS Ch. 21.2was published in 1998. The Standard builds on thefoundation of MPMS Ch. 21.1, but goes intoconsiderably more detail on calculations, security,calibration and configuration issues. Topics coveredare:

Guidelines for selection and use of systemcomponents: Primary, Secondary and Tertiary Installation and Wiring Instrument Calibration Periods and Procedures Total System UncertaintyAlgorithms: Frequency of Calculation Averaging Methods Verification of Calculated Results Integration Methods References to Physical Properties StandardsAuditing and Reporting Requirements: The Configuration Log The Quantity Transaction Record (Batch Ticket) Alarm and Error Logs Calibration versus Verification IssuesSecurity: Restricting Access Integrity of Logged Data Protecting the Algorithms Memory ProtectionComputer Math Hardware and Software: Limitations Software versus Hardware Number Types and their Limitations Integers and Floating Point Numbers Integer Over and Under Flow Issues Floating Point Resolution Errors Integration Errors

Page - 5

The electronic liquid measurement standard explains,for example, how performing a single calculation for acustody transfer transaction compared to multiple real-time calculations in a flow computer will yield differentquantities. Rounding and truncating rules were designedfor reproducibility using a one-time calculation,regardless of equipment used. Unfortunately the abilityto compare a ‘one time’ result versus ‘real time’ resultsis impaired when many thousands of calculations areperformed each hour using the existing rounding rules.

Users can refer to API MPMS Chapter 21.2, Section9.2.12 and Appendix A for a fuller appreciation ofverification of quantities calculated by realtime flowcomputation devices.

Any 32-bit flow computer today is capable of providingthe necessary security access and algorithm protectionthat prevents alteration of measurement or calculationparameters. Although not specified in API MPMS 21.2,Institute of Petroleum's Petroleum MeasurementManual Part XII, Section 3 also recognizes the need forspecial diagnostic and self test routines. Custodytransfer totals, meter factors and other data andconstants can be stored in a redundant RAM area as asingle register containing a checksum. This allows foralarm detection of suspect data and permits automaticcorrection of custody totals when RAM bits are foundto be faulty e.g. corruption due to constant powerfluctuations interrupting processing activity.

Part 3: Software and hardware developmentsand trends

Multiple Functions There is increasing consolidation offunctions into the tertiary device. PID control of flow,back pressure and delivery pressure is becoming morecommon. Single stream gas flow totalizers are alsobeing replaced by multistream flow computers whichinterface directly to gas chromatographs, provide directserial interface to multiple ultrasonic meter types andalso provide master meter proving capability usingprecision gas turbine meters. British Gas in U.K.recently upgraded its entire transmission system withover 200 flow computers with capability to meter anycombination of orifice and turbine meters as well asdirect interface to gas analyzers. These multifunction

multistream flow computers also operate as their ownstation controller and database.

PC-based Realtime Operating Software There is anemerging trend by some process system builders tomake use of PC-based third-party Realtime operatingsystem (RTOS) software as the backbone to theirnew instrumentation software designs. This trend hasoccurred due to the need to shorten developmentcycles and reduce investment cost - and no doubtaccelerated by the unavailability of embeddedprocessor programmers and company reengineering:

Advantagesl Multitasking - separate tasks/programsl Oversees system resources- transparent toprogrammersl Program can be split into independently developedtasksl Speeds up product and software developmentl Improves maintainability Disadvantagesl Operating systems are third-party vendor-supplied- possible slow supportl Adds overhead switching tasksl Adds overhead servicing interruptsl Black box - difficult to troubleshoot RTOS-related problemsl Requires full understanding of system and taskscheduling to achieve good performance As a consequence, many manufacturers are nowreliant on PC-oriented programmers who makeextensive use of high-level third party software code.To make modifications to achieve an optimumcoupling with application code requires expert staff.These issues are not immediately apparent to theunsuspecting user until the system goes wrong, witha resultant cost spiral.

Page - 6

Embedded Processor Software It is important to notethe differences between the preceding approach and theestablished use of embedded processor software design.It remains as the leading methodology to achieve asecure, efficient processing environment. l Completely Interrupt-drivenl Code can be 100% company-generatedl No context switching times in software codel No Operating System “kernel” with interrupt

latency supplied by third partiesl Field-proven code can be usedl "Tight" hardware/software integration

Field-Mounted Flow Computers There is muchinterest in skid-mounted flow computers today. Suchcomputers can provide the dual benefits of reducingsystem capital costs and more easily guaranteeingsystem performance by performing FATs (factoryacceptance testing) with all instrumentation wired inplace.

Systems requiring separate control room facilities tohouse flow computers usually have to be disconnectedfrom the metering skid after the FAT ready forshipment to the customer. This introduces an added un-certainty… ‘Will the equipment be correctly re-connected at the customer’s site?’ Field mounted flowcomputers because of their small size, are usuallylimited in I/O and meter run capability.

With the advent of serial-based meters such asultrasonic and mass meters, skid-mounted flowcomputers adjacent to the meter's secondary electronicson the same spool piece provide for simplifiedconnectivity and minimal wiring being required betweenthe metering skid and the host supervisory system.

Serial data link connectivity between field mountedcomputers will be needed to transfer data andcommands needed to provide an integrated stationfunction on larger multi-run metering systems. It is nowpossible to network field-mounted flow computers andprovide remote wireless access. A remote display maybe needed when a field-mounted computer is mounted inan inaccessible location.

Another challenge for field-installed flow computersbeing used in custody measurement is their stability

under a wide range of temperature conditions andtolerance to extreme electrical effects. For this reasonOIML (International Organization for LegalMetrology) and European Norms are currently thebest guideline that users have for ensuring thatproducts are certified to acceptable levels ofperformance in the absence of extensive testsconducted by knowledgeable, accredited users.

Internet Applications Major pipeline systems in theU.S. are now looking at the Internet for connectivitysolutions that can simplify the hierarchy of MIS/SCADA/ Leak Detection/ Tank farm/ Meteringsystems and minimize their exposure to obsolescence.TCP/IP connectivity is fast becoming accepted and

FIELD MOUNTABLE FLOW COMPUTER WITH INTEGRATED

MULTIVARIABLE SENSOR

Page - 7

products now exist which preserve Modbus-basedcommunications wrapped in TCP/IP high-speedconnections.

Windows-based Interfaces Configuration programshave proliferated as notebook computers have emergedas a standard field technician tool. The key tosuccessful field configuration remains the corefirmware. This is where flexibility must be built-in.Industry expectations are that only Windows-basedprograms are acceptable. This is both an advantage anddisadvantage and depends on the PC literacy of theuser.

Programs now exist to retrieve archive data and exportto a Windows-based spreadsheet, auditing andcalculation checking software incorporating the multiplemeasurement calculation standards, metric orcustomary US units. The need for extensive training ofmeasurement technicians to ensure proficiency in thesenew disciplines is self-evident.

This is best exemplified by the Windows-based controlsystem supervisory software much in vogue in bothprocess control and metering systems. Althoughgraphically-appealing and seemingly user-friendly, thereare considerable uncertainties due to the programmingand configuration skills of integrators who promotesophisticated software. They frequently lack in-depthknowledge of the application and the communicationsand data handling capabilities required for meteringsystems. Consequently many metering systemslanguish in semi-working order and some remainuncommissioned worldwide due to users' unfulfilled orunrealistic expectations of "realtime" systems.

Part 4: New metering technologies,measurement fidelity and security

New Metering Technologies The average user canexpect to confront new meter devices using serialdigital/numeric data streams with relatively littletechnical guidance. Not only must a testing engineer bea knowledgeable electrical and instrument professional,today he should also be an experienced electronicengineer and intimately knowledgeable in processorarchitecture and technical specifications from

individual manufacturers’ sources in the absence offunctional electrical/microprocessor standards.Anything less makes a mockery of many companyapprovals processes and leads to second-rate processperformance.

In respect of serial a.k.a. digital, periodic numericcommunication as distinct from conventional instantpulse-based data acquisition , issues such as “bandwidth”, “baud rate”, “cross-talk”, signal integrityprinciples including transmission line properties andconnections etc, should give any metrology-baseduser significant concern until the uncertainties of thetechnology have been determined and/or by practicaluse as a system component.

This is not to reject the technologies involved. Usersshould stay abreast of technology developments,experiment where possible, and adopt when theresults, as with well-established technologies, willdrive the value decision. It is obvious, however, thatuse of these communications-based technologiesshould be validated under a range of controlledparameters that best represent typical field conditionsso as to benefit the end users. The main objectivemust be to maintain the integrity of the custodymeasurement data received from the primarymeasurement device. The old technologies still havevalue.

Measurement Fidelity Error checking, as originallyenvisioned by API MPMS Chapter 5.5 and inwidespread use worldwide, risks being relegated to areliance on secondary devices which, in a variety ofoperating conditions and electrical influences, maynot accurately represent the primary signal. At asecondary level, numeric representatations of themeasurement value could impact the measured resultsin readouts. However, flow computers implementCRC (Cyclic Redundancy Check) error checking andother checking methods to ensure that data messagesto and from other connected devices are notcorrupted. Security, configuration settings, alarming,data logging and audit issues are central to Weights& Measures/Excise approvals and sometimes taketheir cue from API & IP Standards.

It remains best practice for the tertiary device to usethe instantaneous flow rate value to calculate and

Page - 8

totalize the flow. This forms the basis for the totalizerintegration within the electronics of these new meteringsystems. Data transfer is preferably accomplishedthrough serial data transmission. This is particularlyrelevant in the case of gas ultrasonic meters.

By complementing the serial data with the use of the"manufactured" pulse output train - it is not identical toa turbine or densitometer-generated pulse train, the usercan obtain some pseudo- compliance with the datasecurity issues commonly associated with API Manualof Petroleum Measurement Standards (MPMS) Chapter5.5 regarding signal security, and API MPMS Chapters21.1 and 21.2, respectively, regarding gas and liquidelectronic metering systems.

Some of the new electronic meters provide totalizers,but be warned - these can be difficult to use unless theyare provided in a numeric format which increments androlls over predictably. Floating point variables, forexample, normally keep increasing in value and do notroll over to zero at any point. This causes a problembecause as the totalizer increases in size, a point isreached when the bit resolution of the mantissa portionof the number is exceeded, and the totalizer begins toincrement using larger and larger steps.

The tertiary computing device can compare the totalizervalues received between successive serial transmissions,but even this can prove to be difficult because oftotalizer rollover and resolution problems in somedigital flow meters, and the inpracticability with anydegree of certitude of synchronizing the reading ofsuccessive totalizer readings with the calculation cycleof the tertiary host calculating device.

Metrological Testing A majority of U.S.-sourcemeasurement products are not exposed to internationalmetrological norms, a number of which are European-inspired such as OIML R117 or EN 50081/2, unless itis intended to obtain a significant installed baseoverseas or compete with European-based competitors.Appendix B shows how there is considerable similarityin some areas of testing, many of which are derivedfrom IEC Standards.

It has been the experience of the authors that significantbenefit is derived from considering such standards in thedesign and testing of instrumentation. They provide a

safeguard for users by establishing minimumrequirements of performance and indicate acommitment to quality by the manufacturer. Forexample, how many integrators and users alike investin quality equipment such as a Hewlett Packard 8904AMultifunction Synthesizer DC-600KHz. There arenumerous other test instruments that users should acquireif they want to be in the business of obtaining believable,traceable results.

System Electromagnetic Immunity & Electro-magnetic Compatibility (EMI/EMC) Selectingsuitable electronic instruments with good EMI/EMCperformance can be a challenge. Appendix B canagain be referenced for testing procedures for CEapprovals. But bringing them all together in ameasurement and control ‘system’ which has goodEMI/EMC performance is even more difficult formany engineers. Questions such as “Why does mytotalizer increment a couple of barrels when the pumpstarts up?” or “Why does the displayed flowingtemperature change when I talk on my handheldradio?” should cause the system designer to re-evaluate the EMI/EMC performance of the totalsystem, including components, wiring and shieldingand set proper operating procedures for the meteringsystem.

Manufacturers of electronic equipment can takereasonable steps to minimize but cannot eliminate theexposure of the system to disturbances, such aslightning events and switching surges, or tooperational practices such as permitting high-wattageradios generating RF interference in close proximityto critical measurement devices. A CE certification isthe minimum that manufacturers should provide.

It is assumed that system integration engineers aresufficiently knowledgeable in the system groundingand shielding techniques required to correctly link thecomponents together. By the appropriate use ofgrounding and shielding planes, separation of analogand digital signals, and modular circuitry wherepossible, an instrument manufacturer can provide anumber of extra benefits to the user. Users’instrument engineers are encouraged to review theirdesign and testing associated with EMI/EMC.In older measurement systems, scant attention waspaid to EMI/EMC. Consequently operational

Page - 9

difficulties were frequently experienced.

Conclusion Industry consolidations will continue toimpact on the world of measurement. There will be lesschoice available to users, despite user preferences.Technological challenges will confront the averagemeasurement instrumentation user given the quantumleaps in electronic technologies and pace of meterdevelopments that have occurred since the original APIMPMS Chapter 5.5 was published.

Technical training will be at a premium. Energycompanies are mistaken if they believe that systemvendors alone can bear responsibility in a "low-bidwins" environment. There is no evidence that adequatetraining budgets are included to ensure vendor and userproficiencies in the latest technologies. Developmentswill continue to occur in signal processing, micro-processor, memory and communication technologyduring the next 5 years i.e. serial baud rates, ultrasonicmeters, digital signal processing, Internet, cellular, andsatellite means. The expertise is already limited sowhen will management again support the "value" ofmeasurement?

The petroleum industry has yet to fully come to termswith existing serial digital technology much less accountfor any device that could ultimately communicate at upto 100 Mbps (cf. IEEE 1394). It is certain that fielddevices implementing the Fieldbus communicationstandard will enter into widespread use. But it will beill-advised for any user to endorse products,technologies and methodologies for acquiring meter datafor no other reason than that they exist until and unlessthey are fully tested in operational conditions.

Fieldbus, and other technologies that may supercede it,appears to offer many benefits of network connectivity

in new projects such that the flow computer may wellemerge as a network node, processing all meteringand valve data and diagnostics and passing on tocentral host systems. This will drive more productsto a field environment. It will therefore be essentialthat proper metrological and electrical certification isobtained before a product is permitted into field usebeyond user trials.

This same potential exists for transferring to entirelymass-based systems using flow computers andproving systems. Currently, this is more in evidencein process than in custody transfer. Until then, thecontinuing efforts to improve accuracy and reduceuncertainties in volumetric systems, the mainstay ofcustody transfer transactions for both static anddynamic transfer systems, will continue.

Metrological data can still only be deduced, definedand proven at a metering system level thatincorporates proposed combinations of primary,secondary and tertiary devices. The probability willbe for complex simulation equipment being madeavailable by typical users to emulate real-lifeelectrical disturbances when using electronic-basedsystems. Testing methodologies employed to validatethe metrological results is a currently debated issue,as well as what uncertainty limits should beestablished. These are the continuing challenges fordesigners and users of metering instrumentation.

Copyright 1999 Omni Flow Computers, Inc.

Page - 10

Page - 11

Page - 12

Page - 13