The slides from Dr Esther Hayes (Operation Director, EnergySys) presentation on the implementation challenges associated with standardised production models at the recent EnergySys Hydrocarbon Allocation Forum.
This insights are taken from her new Whitepaper 'Challenges in Global Standardisation'. If you would like a copy of the whitepaper, please contact us via kirsty.armitage@energysys.com
Crypto Cloud Review - How To Earn Up To $500 Per DAY Of Bitcoin 100% On AutoP...
Challenges in Global Standardisation | EnergySys Hydrocarbon Allocation Forum
1. Challenges in Global
Standardisation
Hydrocarbon Allocation Forum
29 September 2014
2. Why standardise?
• Ease the integration of production data across multiple
assets;
• Minimise the cost and schedule of each new
implementation;
• Reduce the cost of maintenance and support;
• Ensure that user’s system knowledge is transferable
between assets;
• Lower lifetime cost of ownership.
3. What would be required?
A system that
• Supports the specific details of the asset and the
calculations to be performed;
• Provides sufficient flexibility that it can be easily adapted
to future business change;
• Offers an integrated presentation of total production
across the asset portfolio.
4. How has it gone so far?
Standardisation on a single Vendor has taken place,
providing:
• Standardisation of skill sets
• Similarity of look and feel of systems across assets
But all instances are different, reflecting the requirements of
the asset. Typically, it is difficult to upgrade the technology
once installed and changes must be applied, as necessary,
to each asset instance.
5. What’s the problem?
• Asset differences
• Continuous change
• Commercial/Statutory environment
• Exchange of data
• Allocation philosophy
• Data storage models
• Commercial pressures
6. Differences between Assets
• Onshore or Offshore;
• Type of products and their relative proportion;
• The type of processing;
• The statutory jurisdiction;
• Whether there is co-mingling of production fluids;
• Whether plant/asset is shared with another operator;
• How the well fluids are measured and/or tested;
• The type of export route;
• The type, quality and location of instrumentation.
7. Sources of Change
• Development of new wells or tie-backs
• Equipment/instrumentation failure/replacement
• Acquisition of new assets
• Engineering enhancements
• Modification of accounting philosophy or agreements with
Partners
• New staff
• Management demands
8. License/Lease/Ownership
• USA Onshore: Individuals own mineral rights, leading to
widespread development of small production facilities.
Production Companies operate individual leases on behalf of a
number of owners in return for royalties.
• UK: Government confers time-restricted rights for different
types of activities through Licenses related to “blocks” or
areas, for which rent is paid.
• Developing Countries: Typically use Production Sharing
Agreements in which “profit oil” is shared with the government.
9. Receipt of Data
• SCADA/Historian system in structured form via
automated interface
• Manually entered in the Field, in the form of Excel
workbooks, paper, CSV or other
• Third Party data from Partners, in any form they fancy.
10. Allocation Philosophy
• Different product streams: Production, Export, Flare or
Fuel;
• Mass, Volume, or Energy;
• By difference, proportional, or some other method;
• Stocks managed and allocated;
• Recognition of the different value of co-mingled products
(e.g. a quality bank).
11. Reconciliation and Reallocation
• Reconciliation and reallocation may be required for:
• Sales figures received on a monthly basis
• Product quality adjustments after receipt of lab analysis
• Improved accuracy production values received on a
longer period (eg monthly) basis
13. Commercial Preferences
• For Vendors whose consulting division is a key source of
revenue, product standardisation offers little appeal
• Off-the-shelf software applications and tools are available
to support a restricted set of requirements or part of the
process.
• For assets with relatively low complexity, software
products compete primarily with Excel
14. Conclusion
• A single global “out-of-the-box” standard for Production
Allocation and Reporting for all assets globally is not practical.
• The solution must instead provide flexibility to the end user to
modify and extend the system as needs change without
reliance on specialist or proprietary skills.
• The base technology must be independent of the
application/asset configuration.
• Pre-configured modules of functionality would aid their efforts.
15. Example: What is a Well?
Typical Well Name in Production
Reporting system:
• Initially, W01
• Then, W01-SS and W01-LS
16. Why does it matter?
• The Reservoir Engineer, as the manager of the
company’s assets, is a key client for the production data.
• He needs to be able to correlate production rates with
geographical location and sub-surface infrastructure
• A Well Name such as “W01-SS” needs string processing
to identify this as associated with “W01-LS”
17. PPDM Well Model
UWI
Well
Production String
UWI
Prod_String_ID
Well Test
UWI
Test_Type
Test_Num
Run_Num
Prod_String_ID
18. Implementation Issues
• The production string is optional, that is, a well may exist without any
associated production string.
• Therefore, no single table exists to provide the full list of well and
production string combinations.
• This means that related tables have to create the association with
Production String themselves.
• Finally, it is not possible to create a new Well or Production String
until the UWI is known and this is often issued by head-office.
19. An Alternative Model
Well_UWI
UWI
Well Test
Well_ID
Production_Date
…..
Well_ID
Well
UWI
Prod_String_ID
Notes de l'éditeur
Good afternoon everyone. Following on from Lawrence’s talk, I’d like to present a few thoughts on the implementation challenges of global standardisation, specifically in in hydrocarbon accounting.
There is a long-running discussion on whether it is possible to develop a global standard application for production allocation and reporting. Many people have said this is not feasible, and in this presentation we review what such as system would need to support and whether this might be possible.
A number of oil and gas producers have tried standardising in order to achieve perceived benefits of a single system across their entire portfolio of assets. They see this as being able to provide easy integration across their various assets, help minimise the cost of maintenance, and keep the number of skills required low. They are seeking lower lifetime cost of ownership, and increased operating efficiency.
At a minimum, a system suitable for all assets worldwide would have to support these three things:
The ability to represent the asset and define the calculations to be performed
Be able to adopt new assets or other changes easily in the future
Provide an integrated view of the total production for a collection of assets or the whole asset portfolio.
Large organisations have tried, but it has been an expensive experiment, and has resulted really in simply the selection of a preferred vendor. Asset systems share a common the look and feel, but each will have been configured for the asset and this usually means that the underlying version of the technology cannot easily be upgraded. So, either newer assets accept an old version, or they risk being incompatible with existing systems.
So what makes it so difficult? Well, there are a number of issues, which we’ll take a look at. In so doing, I am going to make some very broad assumptions and sweeping generalisations, in order not to bury the basic points in too much detail, which I hope you will forgive.
Oil and gas producing assets are incredibly diverse. While the objective – to allocate and report production – is the same in all cases, the assets themselves can be very different from each other. Typically, offshore assets are more expensive and more complex than onshore assets. That means they have more Partners involved, and products from different Producers co-mingling in shared assets. The products will be different and in different proportions, and these may be co-mingled – again, in differing proportions. The production from wells may be measured using well-head meters or local separators, or simply tested independently on a sporadic basis.
Export of product might be in discrete loads, as with a truck or vessel, or continuously though a pipeline. The metering available may be of good quality and well sited for allocation, or it may not, depending upon the quality of the plant design.
Not only are the assets very different, but they are continuously changing. New wells or tie-backs might be developed. Instrumentation might be changed and new equipment added. The company might acquire whole new assets, which they want to integrate into their reporting system, or the engineering team might add enhancements to existing processing. Negotiations with existing or new Partners might change the allocation philosophy. Probably the most frequent source of change is the reporting requirements of the Executive Management.
The United States is one of the few countries in the world where individual ownership of mineral rights is allowed. This has lead to widespread development of onshore reserves by, or on behalf, of individual landowners in small, often single-well, production facilities.
Oil and gas companies operating onshore in the USA typically do so by executing lease agreements with a number of individuals through which they manage the production, storage and transport of product from a collection of properties. As the Working Interest (WI) owner they become responsible for paying 100% of the exploration, development and production costs. They pay a royalty to the land owner, and retain the remaining revenue. Payment of royalties to a large number of leaseholders is a big part of the business process of these organisations.
Mineral rights to offshore acreage in the UK Continental Shelf and other Developed countries are licenced in relatively large blocks by the government. The licenses confer exclusive rights to ‘search and bore for and get’ petroleum. Each license confers such rights over a limited area and for a limited period and, in return, the licensee pays an annual rent.
In other parts of the world, the license is often associated with a Production Sharing Agreement. In such an arrangement, the oil company bears the risk, as before, but when successful it is permitted to use the money from produced oil to recover capital and operational expenditures. This is known as "cost oil". The remaining money is known as "profit oil", and is split between the government and the company in some agreed proportion.
Production data comes in many forms. In the sophisticated environment of the North Sea it is typically well-organised and managed in a data historian. But in many areas it is still received from the field in manually populated spreadsheets or hand-written notes.
Even in the North Sea, data from third party operators can be received in any form the operator selects.
Different assets will need different rules no how the streams are shared, depending upon the configuration of the asset. For example, if a shared production facility uses fuel taken from the production stream, this will need to be allocated to those assets that use the facility, probably in proportion to the production of each asset. The rules may be more complex if, for example, it can be argues that the product from one asset requires more fuel to process than the others.
Allocation of the export stream would normally be in proportion to the production of each production element, but what if these are not independently metered? Liquid stocks may also need to be allocated, typically using a first in-last out model, but this may depend, again, on the configuration of the asset.
Finally, if product from different Producers are co-mingled, there normally needs to be some recognition of the difference in quality or value of their relative products. This might be done with a Quality Bank or other similar mechanism.
In some cases the daily measurements are not of sufficient accuracy to perform commercial allocation and a final, commercial quality, allocation must wait until the sales figures are received. This might be well after the production day. There may need to be adjustments made for lab analysis results, which are received after the day or, indeed, mismeasurements. In some cases, the receipt of this more accurate or revised data will trigger a re-allocation of the daily figures. In other cases, a simple monthly comparison is all that is needed.
The models generally reflect the operations and issues faced by large operators and are excessively complex for, for example, the average small US operator. They also tend to reflect the preferences and requirements of the engineering discipline of those professionals that initiated the work. Thus a model might support the data required by reservoir engineering, but fail to provide a view familiar to production engineers.
The Professional Petroleum Data Management (PPDM) Association
PRODML (Production Markup Language) is a family of XML and Web Services based upstream oil and natural gas industry standards from Energistics
International Association of Oil and Gas Producers OPG is a global forum set up to share best practices in health, safety, environment, security, social responsibility, engineering and operations.
One final aspect to bear in mind is the commercial preferences of vendors and clients. Many vendors make most of their margin through the provision of consulting services configuring their systems to meet the needs of the specific asset.
There are, of course, off-the-self systems for specific classes of assets, such as USA onshore, or parts of the process, such as the Texas State Return. And for those clients who want to retain “flexibility”, there is Excel.
A fully pre-configured application that supports all assets “out of the box”, without either over-burdening the average user with too much complexity, or restricting the functionality to some unhappy middle ground, is not practical..
The solution must be one that provides sufficient flexibility to the end user that they can modify and extend the system as their needs change. Pre-configured modules of functionality might aid their efforts, but it must be possible to adapt these to meet individual needs. Change must be possible for the user without reliance on external consultants with proprietary or specialist knowledge, and without the associated expense. Then, in order that an individual asset does not fall back in technology, it must be possible to upgrade the underlying technology without impacting the configured application or asset data.
In the good old days, a well was a well. One hole in the ground out of which came a single stream of production fluids. This was connected to production manifold, and the stream could be tested (or measured) as a single production entity. Production Engineers and Reservoir Engineers were in agreement about the identity of a “well”. The well was often named after the slot it occuplied in the production manifold.
Then, someone discovered how to complete new zones and drill in new directions to create sidetracks, all from the same hole in the ground.
To the Reservoir Engineer, the example is a single well with two completions and two well-head streams, producing from different reservoir zones. To a Production Engineer, it is two different sources of production fluids, which might just as easily be from different geographical locations. They each require a slot in the production manifold, and can be measured or tested independently.
Traditionally, of course, both disciplines called the production entity a “well”. But the production engineer’s well is really a slot in the manifold, rather than the original hole in the ground.
This is a simplified diagram of the PPDM model. It shows a Well object (or Table), with a Unique Well Identifier naming it, and with an optional associated Production String. The Production String table provides the unique combination of well and string; this is the production entity. The model allows wells to be stored that have no production string – they are a single production entity. Data related to a Production String, such as its test, is associated with the Well, using a Unique key that does not include the Production String.
Because Production String is not required, the Well table is the only one that can be used to relate other data such as Well Tests and Well Readings. And, because Production String is optional, the user will have to identify those occasions when a Production String needs to be present to make the subject of the test identifiable. This relies on the user remembering to make this connection in each case. There is the possibility of choosing the wrong one, and yet we already know the correct the association. Uniqueness, for database purposes, is achieved using other entities such as test number.
This has all sorts of issues when it comes to providing searching on screens and reports, because the Production String is just any other piece of data about a well, it is not treated as if it was fundamental to the identification and naming of that well.
From an implementation point of view, it is much easier if there is a single table to which all other tables can refer, and in which all the important identification information is present.
This model allows the Well table to contain a user-defined code or name for the well, but includes (optionally) the UWI and Production String. It is equivalent to the Production String table in the PPDM model, and provides the same optionality, but ensures there is a single table to which all others can be related, and which contains all the important identification information. For the sake of the Production Engineer this main table is actually called “Well”, not “Production String”, so we have to find a name for the table which holds the Unique Well Identifiers. It could be Well Origin or, as here, Well UWI. For the Reservoir Engineer, this is the true “Well” table. We can now satisfy both the Reservoir Engineer and the Production Engineer.