Every software application, from word processors to banking systems, has a data model which is simply a definition of the structure of the data used in the program and how it is stored. Formal data models are defined in a standard languages such as Structured Query language (SQL) or rather in the Data Definition Language (DDL) component of SQL. A real-world database consists of a database management system (e.g. Oracle), a data model, user interface components, the actual data held in the database, and a set of procedures for managing the data.

Early on in POSC’s existence it was realized that in order to produce a coherent industry standard data model, an overall framework was required. This framework would make up the foundation of the detailed data model. A ‘high level model’, was first produced which defined basic concepts such as ‘activity’, ‘property’, and ‘object of interest’. The remainder of the model was then derived with more and more detailed specialization of these basic concepts.

At about the same time as POSC started out, the Epistle (www.stepcom.ncl.ac.uk) group was formed, to aid technical collaboration between projects working on an ISO standard for data models for the process industry. One focus of Epistle was the requirements of data models for data sharing as well as for data exchange. Epistle itself made extensive use of on-going work at Shell which defines principles and guidelines for how to produce a ‘good’ data model. POSC, through its London office, was a regular attendee at Epistle meetings from the start. A criteria used by Shell and Epistle for a good data model was flexibility. A good model should cater for changing business practices and environments. It was recognized that while hardware and software comes and goes, data, and the structure in which data is held, can have a lifetime of many decades.

The principle guideline that aimed at ensuring a good data model was that entity types - the building bricks of the data model - should represent the essence of things, rather than how they relate to other things. As an example, an entity type ‘father’ is generally not good data modeling practice – instead, there should be an entity type ‘person’, and through relationships with other entity types we can model the role of ‘father’. Epistle, in close liaison with Shell, produced their own ‘high level model’ implementing such techniques. In 1992 POSC produced version 1 of Epicentre which generally encompassed the subsurface domain, but also impinged on the facilities arena. During review of Version, it became clear that there were some problems with the way equipment and materials were modeled. A liaison was established with Epistle specialists to see how Epicentre might benefit from Epistle. The first realization was that, although the two data model groups had had almost no prior contact, the high level models were remarkably similar. Indeed, Philippe Chalon, the POSC data model project leader at the time, said that had he known of the existence of the Shell/Epistle high level model, he would have used it and saved a lot of time.

This liaison between POSC and Epistle resulted in a rework of the equipment and materials area in Epicentre. The principle changes were the distinction between physical objects and the logical, functional requirements for those physical objects as well as a more flexible way of modeling equipment classification schemes, as standard data rather than entity types. Soon after this collaboration, the joint project POSC/Caesar was set up. Caesar had already been in existence for some years, and was a regular attendee at Epistle meetings. It seemed a natural choice that there be a formal agreement between POSC and Caesar so that redundancies could be eliminated and there be a greater weight behind a common industry data model which represented the complete lifecycle of an oil and gas field.

However, it was not completely plain sailing. Some of the hurdles in setting up the venture were

the relative priority between an ISO standard and an oil and gas/POSC standard

object technology, whatever that meant

the business need for data integration between surface/facility information and subsurface/geological information and diversion of POSC resources.

In particular, the pursuit of an ISO standard imposes constraints on the technical contents of the standard, and on the process for defining the standard. However, particularly for the large engineering companies, ISO standardization was seen as a priority. POSC, in contrast, had explicitly decided to avoid being ‘sucked into’ the world of ISO.

The POSC/Caesar specification (http://www.posccaesar.com), as Epicentre, consists of a data model and a reference library. The data model is defined in Express, although a slightly different version from Epicentre. In terms of business value, the reference library is the primary means of achieving data sharing and exchange. The reference library allows different organizations to standardize on natural language such as ‘centrifugal pump’, and allows industry-wide selection based on this standard language. The data model is somewhat secondary – it is a convenient mechanism for storing the data in a flexible manner. Although POSC/Caesar publish a data model, they have in the past delivered the reference data library using an alternative data model, and current implementations of POSC/Caesar use a variety of data models and application programming interfaces, although the data models all share a very similar style. It is possible to adapt the POSC/Caesar data model to create implementations based on anything from MS Access to the latest object oriented DBMS. POSC/Caesar do not currently publish an API, nor any rules for conformance of implementations, although there is some push by members for a definition of a standard API – which would almost certainly be based on one of the current API standards.

Although the POSC/Caesar reference library can be implemented using old versions of Oracle, or relational databases such as MS Access, this puts some extra burden on the application developer. In addition, the facilities industry makes extensive use of on-line and off-line documentation. Older technology can be successfully used as a catalogue, and as pointers to document files, but it is less successful at storing documents within the DBMS, or in storing graphical elements of documents, which might have links to the raw data. Some specialized engineering databases - which may be layered on top of Oracle or object orientated DBMS’s - are designed to remove the burden from application developers of aspects such as handling units of measure, and dealing with inheritance.