|
 |
 |
 |
 |
 |
 |
 |
Implementation of API & Other Standards and Trends in Tertiary Measurement Devices |
|
By
Alan L.McCartney, President, Omni Flow Computers, Inc Kenneth D Elliott, Executive Vice President, Omni Flow Computers, Inc |
As the energy industry continues to re-engineer itself through "downsizing", "rightsizing", and mergers, standardization of product selection and outsourcing elements of engineering, operations and maintenance is much in evidence. This does not relieve the user of the responsibility of being knowledgeable of his own processes and the underlying technologies employed
There is collateral consolidation in vendor groupings, too. This is resulting in product rationalization and the emergence of only a few expert companies in various custody measurement specialties with sufficient commitment to maintain product excellence and integrity. A lack of commitment can lead to a loss of quality control which, in turn, impacts on customer relationships. One can be easily persuaded that changes in our perception will continue to occur in what constitutes a typical tertiary device e.g. flow computers. It has already been established that they are capable of multiple uses. Current and emerging technologies will have a profound effect on their ultimate role in the future of measurement, control, and data acquisition systems.
In this microprocessor age, software is a key ingredient in virtually every aspect of our environment. In custody transfer, software implementation and certification of API Standards in several generations of microprocessor-based devices has always been a subject of debate by a number of users. The expert knowledge required both by the manufacturers and users, contrary to expectation, is less in evidence today than a decade ago due to cyclical and structural changes in the energy industry. One cannot consider the software development independently of hardware architecture design.
It is estimated that the leading manufacturer of panel-mount flow computers may have as much as 70% of 32-bit flow computer installations over the past four years. This would suggest that only manufacturers that have achieved critical mass in field-proven custody applications with 32-bit based units worldwide have the breadth of experience and resource to effectively use these faster microprocessors. For example, a flow computer which uses a 32-bit processor not only can perform calculation-intensive tasks in 200 msecs but can also undertake concurrently a variety of related control and communication functions with minimal processing impact if properly programmed by the manufacturer. Only one manufacturer has successfully achieved that to date.
There also remains a significant difference in requirements of realtime, continuously calculating 110/220AC/24VDC powered systems vs. interval processing for 6VDC low-voltage systems e.g. continuous sampling, say every 1 sec. but with a 1 minute calculation cycle. These low voltage flow computers, particularly solar powered systems in gas measurement are the norm because of the absence of continuous power cf. chart recorders! The processor, to conserve power, is maintained in a 'sleep' mode with minimal activity occurring until such time as a calculation routine needs to be activated. Heat dissipation of the processor is also a major concern for many applications and impacts on the reliability and longevity of the electronics.
There are distinct differences between third party 32-bit PC chipset modules for industrial applications and embedded processor hardware designed entirely from the fundamentals by the manufacturer with a tight coupling between hardware and software being achieved. The latter approach is used in the majority of industrial applications including DCS systems. Memory addressing capability of processors can differ significantly. Compare Intel's 64K segmented architecture addressing constraints to Motorola's 16 Mb linear addressing capability. This can have a major impact on the programmer's ability to write efficient code.
Programming language selection has a direct impact on memory requirements for firmware code. Optimized code written in assembler language operates more efficiently than higher level languages using compilers. Memory requirements will increase as a result. The principal task of the flow computer can be lost in the "shuffle"
The primary function of a flow computer is still to undertake "number crunching". Consequently, a math co-processor chip can speed up math processing significantly. Because 'same chip family' parts are used, there is usually a tight integration between the CPU and the math co-processor chip or it is already an integrated chip function as is found in Intel 486 PC and later chip architectures. Major improvement in performance with little added programming complexity can be obtained.
The math co-processor supports single precision (32 bits), double precision (64 bits) and extended precision (80 bits) floating point formats. Floating point calculations can make use of the 80-bit extended precision format by keeping intermediate results in floating point registers thus increasing the precision of the total calculation.
Dedicated floating-point math hardware chips will always outperform comparable software solutions. This does not mean that the hardware and software math methods will produce differing results, it simply means that more processor time will be available for other tasks.
In a realtime, multitasking system, time-dependent functions have their own processing allotment. Software tasks are divided into time intervals based on their priority. They are managed by an interrupt driven scheduler which executes the task during the appropriate time interval. Execution times for each interval is maintained and recorded for system evaluation. Tasks may run every 10msec, 50 msec, 100 msec, 200 msec or 500 msec. Lower priority tasks can be preempted by higher priority tasks. Very low priority tasks, such as formatting a report for printing, are handled in "background" and are given CPU time when other tasks are not running. Asynchronous events such as serial communications are interrupt driven and are given a priority based upon their individual interrupt levels.
Other ways of increasing processing throughput is to operate with multiple processors with assigned tasks. Using a separate microprocessor as a communications controller or I/O controller, for example, requires the programmer to write two separate programs, which must be able to access the same database without data synchronization concerns. This can be a source of continuing problems when designing and testing the application code. Consider also the challenge of system-oriented vendors who must meet the burden of project custom specifications and require staff or contract programmers writing the necessary code on a one-off project basis including testing and documentation. This goes a long way to explaining why there is increased standardization and configuration flexibility, a trend that has been led by this vendor.
There is a lot more that goes into the development of a flow computer than the calculations. In fact, that is the easiest part of the development. Other auxiliary functions such as PID control, meter proving, valve and sampler control, archiving, batch processing and data communications, just to name a few, are the challenging parts. Most of these can be logically broken into tasks based on their function. These tasks are broken into modules for easier maintenance (Omni's Software Coding Standard limits modules to below 1000 source code lines).
How these sections of code are put in memory is important if they are to work seamlessly together. Shared data and entry points must be automatically resolved at build time to eliminate human error. Separate executable sections ease debugging and allows code to be upgraded a section at a time. Multiple programmers must be able to work on sections of a product's code without interfering with another's memory space.
Moving memory allocation and usage around because of poor planning can cause unnecessary delays in the programming cycle. Stack space must be allocated for worst case conditions and be monitored for overflow. Interrupt routines must be able to locate buffers and variables regardless of where the CPU was when interrupted (this can be difficult in segmented architectures). Getting the most out of memory requires a well-considered design and careful coding. "Wasting" memory because there seems to be plenty available can have consequences down the road. Software engineers not only need to think about what goes into the product now but also to consider how enhancements will be added in the future.
The database holds information for configuration and real-time results as well as intermediate results and raw data. Two goals of creating this ram area is to keep related information together so every module can access it efficiently and ensure that variable locations do not change between software upgrades.
The above discipline and experience distinguishes and elevates product acceptance and performance in the marketplace and goes some way towards explaining why there are fewer suitable flow computer products available to the custody market today.
The minimum one should expect when assessing capabilities of flow computers in meeting the requirements of current and emerging standards:
So how does a flow computer implement the current API Volume Correction Standards for Crudes & Refined Products? See APPENDIX A CTL/CPL Flow Chart. There are actually six steps.
Step 1: With observed product density at flowing conditions 
density at standard temperature, 60oF or 15oC, and flowing pressure i.e. elevated pressure is calculated, using API MPMS Chapter 11.1, Table 23 A /B or 53 A/B algorithm
Step 2: With calculated reference density from Step1 and flowing temperature, the initial compressibility factor 'F' is calculated using API MPMS Chapter 11.2.1 algorithm.
Step 3: Using initial 'F' from Step 2, equilibrium and flowing pressures, the initial pressure correction factor 'Cpl' is calculated using API MPMS Chapter 12.2 rounding and truncating rules.
Step 4: The product density at standard temperature and equilibrium pressure is calculated by adjusting the density at standard temperature and flowing pressure obtained at Step 1 by the 'Cpl' factor calculated at Step 3.
Step 5: Iterate Steps 2,3 & 4 until the change in Cpl factor obtained is less than 0.00005.
Step 6: Using flowing temperature and product density at standard temperature 
and equilibrium or base pressure 
the volume correction factor, Ctl, is calculated using Table 24 A/B or 54 A/B, depending on whether U.S. customary or metric measurement units are in use.
64-bit floating-point operations capability from currently available PC processors and flow computers which already incorporate math coprocessing capability has encouraged the API into developing more complex algorithms and simplification of arithmetic operations in the revised API MPMS Ch. 11.1 currently being balloted. Using increased decimal precision and floating-point math routines in place of the less rigorous implementation procedures using integer math and low processing capabilities existing in the 1970s and 1980s, discrepancies between the 60°F, 15°C and 20°C Tables have surfaced. These differences were not identified due to the rounding and truncation procedures required to implement the algorithms. These were devised to ensure reproducibility of results from different devices. In practice, the new routines will result in approximately 16 or more decimal places for all calculations.
The procedures by which volume correction factors are calculated to a consistent five decimal places for all VCF factors are also being revised. Due to the widespread use of realtime density measurement, temperature and pressure corrections will be performed as one procedure. It will now be possible to improve the convergence methodology for the correction of observed density to base density. API is adopting a more advanced convergence methodology than was previously possible to do the calculations. The procedures have been written without rounding because they can be part of an iterative loop and rounding of factors could mean slow or non-convergence of iterative calculations. Older flow computer technology embodying 16-bit technology may not reproduce factors exactly to a 5 decimal place resolution. The standard requires that all calculations must also be executed using double-precision calculations and that all constants are carried to the exact number of digits as required by the standard.
Underlying data, equations and associated constants have not been changed but there are increased density and temperature ranges that accommodates lower temperatures and higher densities. None of the above applies to the 1952 Tables which were derived from empirical data developed during the 1930s and 40s.
The API Standard dealing with Electronic Liquid Measurement, MPMS Ch. 21.2 was published in 1998. The Standard builds on the foundation of MPMS Ch. 21.1, but goes into considerably more detail on calculations, security, calibration and configuration issues. Topics covered are:
Guidelines for selection and use of system components:
Primary, Secondary and Tertiary
Installation and Wiring
Instrument Calibration Periods and Procedures
Total System Uncertainty
Algorithms:
Frequency of Calculation
Averaging Methods
Verification of Calculated Results
Integration Methods
References to Physical Properties Standards
Auditing and Reporting Requirements:
The Configuration Log
The Quantity Transaction Record (Batch Ticket)
Alarm and Error Logs
Calibration versus Verification Issues
Security:
Restricting Access
Integrity of Logged Data
Protecting the Algorithms
Memory Protection
Computer 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
The electronic liquid measurement standard explains, for example, how performing a single calculation for a custody transfer transaction compared to multiple real-time calculations in a flow computer will yield different quantities. Rounding and truncating rules were designed for reproducibility using a one-time calculation, regardless of equipment used. Unfortunately the ability to compare a 'one time' result versus 'real time' results is impaired when many thousands of calculations are performed each hour using the existing rounding rules.
Users can refer to API MPMS Chapter 21.2, Section 9.2.12 and Appendix A for a fuller appreciation of verification of quantities calculated by realtime flow computation devices.
Any 32-bit flow computer today is capable of providing the necessary security access and algorithm protection that prevents alteration of measurement or calculation parameters. Although not specified in API MPMS 21.2, Institute of Petroleum's Petroleum Measurement Manual Part XII, Section 3 also recognizes the need for special diagnostic and self test routines. Custody transfer totals, meter factors and other data and constants can be stored in a redundant RAM area as a single register containing a checksum. This allows for alarm detection of suspect data and permits automatic correction of custody totals when RAM bits are found to be faulty e.g. corruption due to constant power fluctuations interrupting processing activity.
There is increasing consolidation of functions into the tertiary device. PID control of flow, back pressure and delivery pressure is becoming more common. Single stream gas flow totalizers are also being replaced by multistream flow computers which interface directly to gas chromatographs, provide direct serial interface to multiple ultrasonic meter types and also provide master meter proving capability using precision gas turbine meters. British Gas in U.K. recently upgraded its entire transmission system with over 200 flow computers with capability to meter any combination of orifice and turbine meters as well as direct interface to gas analyzers. These multifunction multistream flow computers also operate as their own station controller and database.
There is an emerging trend by some process system builders to make use of PC-based third-party Realtime operating system (RTOS) software as the backbone to their new instrumentation software designs. This trend has occurred due to the need to shorten development cycles and reduce investment cost - and no doubt accelerated by the unavailability of embedded processor programmers and company reengineering:
As a consequence, many manufacturers are now reliant on PC-oriented programmers who make extensive use of high-level third party software code. To make modifications to achieve an optimum coupling with application code requires expert staff. These issues are not immediately apparent to the unsuspecting user until the system goes wrong, with a resultant cost spiral.
It is important to note the differences between the preceding approach and the established use of embedded processor software design. It remains as the leading methodology to achieve a secure, efficient processing environment.
Field-Mounted Flow ComputersThere is much interest in skid-mounted flow computers today. Such computers can provide the dual benefits of reducing system capital costs and more easily guaranteeing system performance by performing FATs (factory acceptance testing) with all instrumentation wired in place. Systems requiring separate control room fa-cilities to house flow computers usually have to be disconnected from the meter-ing skid after the FAT ready for shipment to the customer. This introduces an added un-certainty… 'Will the equipment be correctly re-connected at the customer's site?' Field mounted flow computers because of their small size, are usually limited in I/O and meter run capability. With the advent of serial-based meters such as ultrasonic and mass meters, skid-mounted flow computers adjacent to the meter's secondary electronics on the same spool piece provide for simplified connectivity and minimal wiring being required between the metering skid and the host supervisory system. |
 |
Serial data link connectivity between field mounted computers will be needed to transfer data and commands needed to provide an integrated station function on larger multi-run metering systems. It is now possible to network field-mounted flow computers and provide remote wireless access. A remote display may be needed when a field-mounted computer is mounted in an inaccessible location.
Another challenge for field-installed flow computers being used in custody measurement is their stability under a wide range of temperature conditions and tolerance to extreme electrical effects. For this reason OIML (International Organization for Legal Metrology) and European Norms are currently the best guideline that users have for ensuring that products are certified to acceptable levels of performance in the absence of extensive tests conducted by knowledgeable, accredited users.
Major pipeline systems in the U.S. are now looking at the Internet for connectivity solutions that can simplify the hierarchy of MIS/ SCADA/ Leak Detection/ Tank farm/ Metering systems and minimize their exposure to obsolescence. TCP/IP connectivity is fast becoming accepted and products now exist which preserve Modbus-based communications wrapped in TCP/IP high-speed connections.
Configuration programs have proliferated as notebook computers have emerged as a standard field technician tool. The key to successful field configuration remains the core firmware. This is where flexibility must be built-in. Industry expectations are that only Windows-based programs are acceptable. This is both an advantage and disadvantage and depends on the PC literacy of the user.
Programs now exist to retrieve archive data and export to a Windows-based spreadsheet, auditing and calculation checking software incorporating the multiple measurement calculation standards, metric or customary US units. The need for extensive training of measurement technicians to ensure proficiency in these new disciplines is self-evident.
This is best exemplified by the Windows-based control system supervisory software much in vogue in both process control and metering systems. Although graphically-appealing and seemingly user-friendly, there are considerable uncertainties due to the programming and configuration skills of integrators who promote sophisticated software. They frequently lack in-depth knowledge of the application and the communications and data handling capabilities required for metering systems. Consequently many metering systems languish in semi-working order and some remain uncommissioned worldwide due to users' unfulfilled or unrealistic expectations of "realtime" systems.
The average user can expect to confront new meter devices using serial digital/numeric data streams with relatively little technical guidance. Not only must a testing engineer be a knowledgeable electrical and instrument professional, today he should also be an experienced electronic engineer and intimately knowledgeable in processor architecture and technical specifications from individual manufacturers' sources in the absence of functional electrical/microprocessor standards. Anything less makes a mockery of many company approvals processes and leads to second-rate process performance.
In respect of serial a.k.a. digital, periodic numeric communication as distinct from conventional instant pulse-based data acquisition , issues such as "band width", "baud rate", "cross-talk", signal integrity principles including transmission line properties and connections etc, should give any metrology-based user significant concern until the uncertainties of the technology have been determined and/or by practical use as a system component.
This is not to reject the technologies involved. Users should stay abreast of technology developments, experiment where possible, and adopt when the results, as with well-established technologies, will drive the value decision. It is obvious, however, that use of these communications-based technologies should be validated under a range of controlled parameters that best represent typical field conditions so as to benefit the end users. The main objective must be to maintain the integrity of the custody measurement data received from the primary measurement device. The old technologies still have value.
Error checking, as originally envisioned by API MPMS Chapter 5.5 and in widespread use worldwide, risks being relegated to a reliance on secondary devices which, in a variety of operating conditions and electrical influences, may not accurately represent the primary signal. At a secondary level, numeric representatations of the measurement value could impact the measured results in readouts. However, flow computers implement CRC (Cyclic Redundancy Check) error checking and other checking methods to ensure that data messages to and from other connected devices are not corrupted. Security, configuration settings, alarming, data logging and audit issues are central to Weights & Measures/Excise approvals and sometimes take their cue from API & IP Standards.
It remains best practice for the tertiary device to use the instantaneous flow rate value to calculate and totalize the flow. This forms the basis for the totalizer integration within the electronics of these new metering systems. Data transfer is preferably accomplished through serial data transmission. This is particularly relevant 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 to a turbine or densitometer-generated pulse train, the user can obtain some pseudo- compliance with the data security issues commonly associated with API Manual of Petroleum Measurement Standards (MPMS) Chapter 5.5 regarding signal security, and API MPMS Chapters 21.1 and 21.2, respectively, regarding gas and liquid electronic metering systems.
Some of the new electronic meters provide totalizers, but be warned - these can be difficult to use unless they are provided in a numeric format which increments and rolls over predictably. Floating point variables, for example, normally keep increasing in value and do not roll over to zero at any point. This causes a problem because as the totalizer increases in size, a point is reached when the bit resolution of the mantissa portion of the number is exceeded, and the totalizer begins to increment using larger and larger steps.
The tertiary computing device can compare the totalizer values received between successive serial transmissions, but even this can prove to be difficult because of totalizer rollover and resolution problems in some digital flow meters, and the inpracticability with any degree of certitude of synchronizing the reading of successive totalizer readings with the calculation cycle of the tertiary host calculating device.
A majority of U.S.-source measurement products are not exposed to international metrological norms, a number of which are European-inspired such as OIML R117 or EN 50081/2, unless it is intended to obtain a significant installed base overseas or compete with European-based competitors. Appendix B shows how there is considerable similarity in some areas of testing, many of which are derived from IEC Standards.
It has been the experience of the authors that significant benefit is derived from considering such standards in the design and testing of instrumentation. They provide a safeguard for users by establishing minimum requirements of performance and indicate a commitment to quality by the manufacturer. For example, how many integrators and users alike invest in quality equipment such as a Hewlett Packard 8904A Multifunction Synthesizer DC-600KHz. There are numerous other test instruments that users should acquire if they want to be in the business of obtaining believable, traceable results.
Selecting suitable electronic instruments with good EMI/EMC performance can be a challenge. Appendix B can again be referenced for testing procedures for CE approvals. But bringing them all together in a measurement and control 'system' which has good EMI/EMC performance is even more difficult for many engineers. Questions such as "Why does my totalizer increment a couple of barrels when the pump starts up?" or "Why does the displayed flowing temperature change when I talk on my handheld radio?" should cause the system designer to re-evaluate the EMI/EMC performance of the total system, including components, wiring and shielding and set proper operating procedures for the metering system.
Manufacturers of electronic equipment can take reasonable steps to minimize but cannot eliminate the exposure of the system to disturbances, such as lightning events and switching surges, or to operational practices such as permitting high-wattage radios generating RF interference in close proximity to critical measurement devices. A CE certification is the minimum that manufacturers should provide.
It is assumed that system integration engineers are sufficiently knowledgeable in the system grounding and shielding techniques required to correctly link the components together. By the appropriate use of grounding and shielding planes, separation of analog and digital signals, and modular circuitry where possible, an instrument manufacturer can provide a number of extra benefits to the user. Users' instrument engineers are encouraged to review their design and testing associated with EMI/EMC. In older measurement systems, scant attention was paid to EMI/EMC. Consequently operational difficulties were frequently experienced.
Industry consolidations will continue to impact on the world of measurement. There will be less choice available to users, despite user preferences. Technological challenges will confront the average measurement instrumentation user given the quantum leaps in electronic technologies and pace of meter developments that have occurred since the original API MPMS Chapter 5.5 was published.
Technical training will be at a premium. Energy companies are mistaken if they believe that system vendors alone can bear responsibility in a "low-bid wins" environment. There is no evidence that adequate training budgets are included to ensure vendor and user proficiencies in the latest technologies. Developments will continue to occur in signal processing, micro-processor, memory and communication technology during the next 5 years i.e. serial baud rates, ultrasonic meters, digital signal processing, Internet, cellular, and satellite means. The expertise is already limited so when will management again support the "value" of measurement?
The petroleum industry has yet to fully come to terms with existing serial digital technology much less account for any device that could ultimately communicate at up to 100 Mbps (cf. IEEE 1394). It is certain that field devices implementing the Fieldbus communication standard will enter into widespread use. But it will be ill-advised for any user to endorse products, technologies and methodologies for acquiring meter data for no other reason than that they exist until and unless they 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 well emerge as a network node, processing all metering and valve data and diagnostics and passing on to central host systems. This will drive more products to a field environment. It will therefore be essential that proper metrological and electrical certification is obtained before a product is permitted into field use beyond user trials.
This same potential exists for transferring to entirely mass-based systems using flow computers and proving systems. Currently, this is more in evidence in process than in custody transfer. Until then, the continuing efforts to improve accuracy and reduce uncertainties in volumetric systems, the mainstay of custody transfer transactions for both static and dynamic transfer systems, will continue.
Metrological data can still only be deduced, defined and proven at a metering system level that incorporates proposed combinations of primary, secondary and tertiary devices. The probability will be for complex simulation equipment being made available by typical users to emulate real-life electrical disturbances when using electronic-based systems. Testing methodologies employed to validate the metrological results is a currently debated issue, as well as what uncertainty limits should be established. These are the continuing challenges for designers and users of metering instrumentation.
1999,98 Net-Step Media, LLC. All rights
reserved.
Web Design by Net-Step
Media, LLC.
Web Administrator Kirk Harrison
E-mail us your thoughts or suggestions.
Last Update 2-23-00.