Groundwork: Layering OO & GIS on the PPDM

Groundwork: Layering OO & GIS on the PPDM

Wesley Baird
Cquay Inc.
Suite 300, 405-5 th Ave. SW
Calgary Alberta
T2P 0T9

Overview
The emergence of a common data model for the oil and gas industry has been accomplished through the adaptation of the Public Petroleum Data Model (PPDM). This relational data model has been in existence for over 10 years has been successfully implemented in Oil and Gas companies worldwide. Covering many disciplines, ranging from Business Associates, Wells to Land/Contracts. It is a continually evolving model that bases its success on the active participation of its members and adaptation of the model by said members. With the rapid advancement of the Internet and its continuing drive to change the face of businesses, efforts have been made to add the ability to ‘locate’ oil and gas data. We are actively pursuing this ability to add GIS functionality effectively and inexpensively to our existing data stores. This paper explores the possibility of how to add GIS and Object capabilities to existing relational data models, extending the life of these systems.

Introduction
Object databases; OO programming; Object-Relational systems; and RAD methodologies. We hear about them, we wonder how or even if they will benefit us; and furthermore what these tangible benefits for us are. Lower operating costs? Increased productivity? Are they necessary or even beneficial to our industry? Where and how can we reap those benefits? The common view is that object technology allows the creation of a more accurate business model. This is certainly true because of the re-usability of defined objects, the inheritance and the methods associated with these objects. A major roadblock or hesitation that companies have in developing in object technology is the invested time and effort that resides in existing legacy systems. Companies are looking to maximise the return on investment (ROI) over the longest period of time, redeveloping systems can at a cursory glance look less than a sound investment. What is needed is to find a methodology that can marry our existing data sets / applications with the new technologies emerging today. For this purpose, Oracle provides a technology called object views. These views have been designed to allow the introduction of an object layer (model and methods) into a company’s information systems with minimal impact; this is accomplished through initially replacing only the application layer. Thus when a workflow review is done and changes are anticipated, the impact of these changes can be minimised. Most systems are designed to present data in a tabular format, such as reports. Requiring the geoscientist to make the mental translation from a data report to a map view when working with the information. Certainly it would be better to present these data sets, (all of them) in a visual context first (maps-on-the-fly), and secondly create text based reports at the users request. This is a natural progression of computer systems, to displaying information graphically, on-demand.

System Review
Most companies have put in a system architecture that is similar to the following diagram:

Unfortunately, this architecture is often repeated within each department/discipline in a company, meaning that a company has the extra expenditure of maintaining these separate data streams. Consolidation has been done by migrating to common hardware (Unix / NT) platforms and software (Oracle / Microsoft) applications. Currently most companies have relational-based systems supporting the business and most of these are based on Unix / NT hardware. There are functioning applications that work on top of these systems and access can be made from anywhere (inside / outside the office). What does become clear from this “typical architectural picture” is that any additional integration will be an advantage.

Integration Review
Basic integration in most Oil and Gas companies has not been done. There are two stumbling blocks that are in everyone’s road: departmental dysfunction and natural key selection. We all know about departmental dysfunction (the ability of a department to put its agenda first) and most of us manage around it. It has become easier to break down these departmental barriers, in part due to the downward cost pressure that new technologies (internet-related) bring. The other roadblock, natural key selection, is tougher to deal with. All systems, relational or otherwise have a natural key identifier. This key is not a primary key, but rather a representation of a unique time-based (more likely than not) element that is naturally understood within the business discipline. We humans think in complex patterns and have the ability to associate and disassociate relationships ‘on-the-fly’. The best industry illustration of this is a well location in Canada. The well was originally licensed and drilled as 11-31-66-11w6 (the actual name/location has been changed to protect the stupid) but was actually found to be located at 1-1-67-12w6. This well was incorrectly surveyed and thus recorded with the government authority as the incorrect location. Geoscientists working the area know it by both locations. More importantly, the incorrect well location will just not go away.

Production volumes are associated with 11-31, routinely and the working interest for 1-1 is almost always incorrectly adjusted for, because of missing production. This is a simple integration problem between business disciplines (and their systems). Humans quickly learned and remembered that these wells are in-fact the same well and can deal with it, but our systems cannot. There is nothing that relates 11-31 to 1-1. This illustrates complex reasoning and the related business rules contributing to why system integration is so difficult. If we can move toward defining objects that are able to better reflect these and other business rules, we will be able to create systems that accurately reflect the manner in which our company does business.

Technical Review
There is a common data model in the oil and gas sector called the PPDM. The PPDM is a relational based model; that is very mature in the following subject areas: Wells, Stratigraphy, Land, Business Associates, Contracts and Seismic. The PPDM has created a model that has followed a strict naming convention standard. This has created a model that is consistent in the entity and attribute naming as well as the attribute typing. Later we will see how we can take advantage of this in the implementation of objects based on this oil and gas data model. The PPDM is starting to add spatial components to the model with a complete spatial hierarchy in each subject area. This additional layer of complexity could delay implementation at companies for two reasons: 1) the implementing company will have to load, store and maintain this information; adding to the existing infrastructure costs. 2) The implementing company will have to get software vendors (or their own internal I.S. departments) to adopt their software to read in this new spatial structure. Most software vendors have already formed alliances with ESRI or MapInfo to display data in a spatial format or have their own proprietary methods of displaying maps. Why would they want to add in another display mechanism and have to support it? Both above considerations will contribute to an expensive and time-consuming task. In today’s Internet economy, is this a reality?

Objective
Let review the objective at the Oil and Gas Company that we work at. It is probably to enable our geoscientific user community with the ability to view data in a map view and to be confident that all information is available within a specified geographical area. This means that our systems must: 1) have a systems with architectures that are compatible with each other. 2) have disciplines must be aware of what other data is available and be linked together. 3) allow separate subject areas to be displayed on the same map. This will require a significant change in systems across the entire enterprise or will it? Using a standard model and methodology will be fundamental to enabling seamless communication between; departments within a company, applications from different vendors, company offices and even between oil companies. What could this standard be? How much will it cost to pull all of this information together and display it in a coherent manner?

Methodology
There is a standard available to oil and gas application vendors and oil and gas companies. This standard is the PPDM. Not all vendors have implemented a version of the PPDM in their proprietary data model, but most have implemented their model in Oracle. With the recent moves by relational database vendors (Oracle, IBM and others) to wrap objects around their relational technology, research has been done to see how this could be implemented in a production environment. Oracle’s implementation of object views has been designed to facilitate the move from relational based systems to object technology based ones. These object views are a half step or migratory step between relational and object systems. They allow existing systems/data structures/work practices to continue to be used; while the new object based application is being designed, written and tested. Business practices can be reviewed and improved upon with this system re-design using object technology. As with any system re-work, an effort is made to ensure that item(s) previously missed are included. In most systems, that item is the ‘where’ component. Many systems have business objects that have attributes that describe a location; however, these attributes are not capable of understanding where they are relative to each other. This must be done in a GIS engine and standard convention has all data about the business object being moved into this GIS repository before these business objects understand ‘where’ they are in relation to each other. This is a costly endeavour, as mentioned earlier. The problem remains about how to accomplish this in a timely, cost-effective manner. What is needed is a single land-base for North America, available on-line 7x24, with published application programming interfaces (API’s) that would tag a business object with a unique spatial location (USL)[1] key. With this database available, development effort could be focused on adding value to existing data sets, rather than expending the time and money required building and maintaining a GIS repository. We can now integrate all of our disparate disciplines, while retaining natural key identifiers within the disciplines and still be able to satisfy the requirements of the company by providing data as an integrated solution, utilizing this single land based repository

The steps necessary to spatially enable a PPDM database are:

define the oil and gas objects using the PPDM as a starting point
add in the spatial attribute (USL) to the existing model
create object views that reflect the objects defined earlier but are based on the relational implementation of the PPDM
link the company data set to the on-line 7x24 land-base
create the necessary applications changes that would be able to deliver data via ‘maps-on-the-fly’ and be designed to answer spatial questions, such as how far is this well location from the nearest pipeline or how many farms/families are within the 5 mile radius from the potential sour gas well.

Details of the actual object definitions and the object views will be presented and reviewed in the slide presentation of this talk. So now that you have these neat, new objects and the ability to access your old data structures with them, how can it be done and how will this new technology help system development? Here are some examples of the SQL that would be written. This example shows how to get a list of wells that have a status of 'STANDING'.

SELECT W.UWI, W.SPUD, S.STATUS, S.STATUS_DATE
FROM WELL_OV W, TABLE (W.WELL_STAT) S
WHERE S.STATUS = 'STANDING';

This next SQL shows how to get the same information, but from the relational tables.

SELECT W.UWI, SPUD_DATE, S.STATUS, S.STATUS_DATE
FROM WELL W, WELL_STATUS S
WHERE W.UWI=S.UWI AND S.SOURCE=W.SOURCE AND W.SOURCE = 'IPL'
AND S.STATUS = 'STANDING';

As you can see, the first SQL statement is a lot easier to write because the joins have been eliminated. They are still being done, but are encapsulated in the object layer. Initial timing tests show that both the object view and the relational table query have the same performance. It should be noted that the relational query is more likely to have performance issues, as the developer must know what is the correct execution path to choose. Developers unfamiliar with the business process, the data model and more importantly its accompanying indexes, stand a greater chance of writing bad or non-performance SQL. For this reason, when an object view is created, you are writing a large portion of the SQL for the developer. By doing this, you control the access paths to the data, so your performance of queries can be pre-tuned.

Conclusion
Working with existing data sets and existing mindsets lead to the similar answers to the old problems of integration. The advent of the web with its networks of ever-increasing bandwidth and the available n-tier architectures are providing the chance to significantly change the way we view data and interact with information. Within the context of information management, data and information are often used interchangeably, but have very different meanings. Data is defined as “streams of raw facts representing events occurring in organizations or the physical environment before they have been organized and arranged into a form that people can understand and use”.[2] Information is data that has “been shaped into a form that is meaning and useful”.[3] It is in the presentation of information that we are able to add value to our companies. By embracing object technology, specifically Oracle’s object views, we are advantaging our company with the ability to migrate to new technology while maximising their ROI in existing applications.

If we can now add in the ability to make data sets spatially aware of where they are as well as where they are in-relation to each other, we are truly starting to represent our physical world in our computer world. There still remains the problem of the delivery mechanism. As surprised as some people might be, the tool is already available that will allow us to take the first steps. That tool is the web browser, a spatially enabled web browser to be specific. A web browser can run on many, if not all, computer system; thus satisfying our first requirement of system architecture. Using a single on-line land-base, we can spatially integrate all of our disparate data sets. Allowing the location of the object to be the integrating factor, not a natural key. In our example of the 11-31 or 1-1 well, we would see that these well(s) have the same location, thus we could assign them the same spatial attribute and they would, in fact, be one. This satisfies our second requirement. Being able to present all of this data in a spatially enabled web browser, the data viewed in a spatial context first and then reports second. People think spatially and delivering the data in this manner will further enable their ability to add value to the company.

References

Warren, D., 2000, “URL to USL or Web enabled GIS.”, GITA Spring Conference, 2000
Laudon, K.J. & J.P., 1997, “Essentials of Information Systems: Organization and Technology” 2 nd ed. Pg 513
Laudon, K.J. & J.P., 1997, “Essentials of Information Systems: Organization and Technology” 2 nd ed. Pg 513