Owner/Operator Case Studies: 1996-01

Status of this document: Working Draft

This document is open for feedback, please post questions and comments in the forum at the bottom of this page. You will need a login to post in the forum.


  1. Project Description
  2. Owner Requirements
  3. Business Case
  4. Scope
  5. Developing the Information Asset
    1. Integration of Schematics
  6. Project Execution Summary
  7. Significance of this Project to ISO 15926

Project Description

  • 6.6 million metric tonne per annum (mmtpa) LNG plant.
  • Located in the Middle East.
  • Owned by a consortium of multinational oil companies and local government.
  • Detailed engineering started in 1996.
  • Data warehouse development (the Information Asset) started in 1997.

Owner Requirements

  • A data warehouse in which to store certain information about plant objects.
    • All information about a plant object would be in one location, or referenced from one location.
    • Plant information could be queried and located without using any plant design system.
    • Easier for plant personnel to find information.
  • The data warehouse was to be standardized against STEP (later, ISO 15926).
    • The owner's standard practice was to store plant information in a STEP-compliant database.
    • STEP contained the necessary information and relationships to create a usable database for plant information.
    • By standardizing the new database against STEP, the owner was guaranteeing a measure of quality.
  • The data warehouse was to be in a neutral format, not optimized for any vendor's software.
    • Data is easier to reuse between applications and between plants, if it is in a neutral, industry standard, format.
    • If the data is in an industry standard format, it would not be tied to a particular suite of software.

Business Case

Ease of finding plant information

  • Finding information quickly after handover has always been a problem on large, new projects. Simply finding which document to look for and where it is stored is often a major issue. The proposed database would store the most commonly used attributes about plant equipment, and links to data sheets and vendor documents that contained more detailed information.

Verify a complete information turnover

  • With the database, it would be easier for the owner to determine if the contractors had turned over all the information required to commission and operate the plant. For instance, if a certain document was normally required for a kind of equipment (say, a data sheet or maintenance manual) the database could be queried to verify that all such equipment had a link to that document.


Included in the data warehouse:

  • Engineering data about equipment attributes.
  • Schematic data including P&IDs, Line Lists, Wiring & Control Schematics, Cable Schedules.

Not included:

  • 3D data

The database would contain summary information about plant equipment. A good metaphor is a 4"x6" quick reference card containing the attributes most commonly used during operations and maintenance.

  • Data sheets and vendor documents would be linked to the summary information
  • All documents were to be electronic

The production database was a commercial database. The owner gave the engineering contractor an Access database with the required schema to validate the data.

Developing the Information Asset

Most of the effort developing the Information Asset was deciding what to model and how to model it. A significant focus was looking at all of the attribute values on all of the data sheets and creating a definition of those that should be mapped to STEP and ISO 15926 reference data.

The database that was eventually handed over did not, nor was it ever intended to, replicate all the information about all of the plant objects. A good metaphor is a 4"x6" card containing the most used information about each equipment. Only a couple dozen attributes were tracked for each plant object. For situations where more information was required, references were made to data sheets and vendor information.

STEP was the information standard at the beginning of the project, but by the end, ISO 15926 had come into being.

  • The data dictionary started out as the STEPlib library, which became ISO 15926 part 4.
  • The STEP AP221/EPISTLE model used at the beginning of the project became the basis of ISO 15926 part 2.
  • The idea that this all depended on extensible reference data was well established, so by the time the project was finished there was an initial RDS/WIP.

The first step was to figure out how to make the data warehouse understand the Part 2 data model. Part 2 requires a different kind of data model than a normal relational database.

ISO 15926 Part 2 data objects are very fine grained. They are definitions of atomic concepts that can be assembled together in various combinations to make pretty well anything. They are stored as simple statements:

  • This pump has this property
  • This vessel has this nozzle
  • This equipment has this part

To work with this sort of information, the project used what was initially called Step-on-one-page, which was later renamed General Engineering Language, or Gellish. Gellish takes the simple statements and stores them as triples which consist of two objects joined by a relationship.

So one major task for the information handover was mapping all of the plant data in this form. But understanding how to work with Part 2 objects directly, was, and still is, very specialized. What the project found was that whatever the fine grained Part 2 object was being represented, there was a more business-friendly view. This spawned the concept of a Business Object which was later called a Usage Factor, and today is called a Template.

Integration of Schematics

At about this time, the CAD software that was used on the project had the ability to create a hot spot to link an object on a drawing to a database entry. This project used that capability to link P&IDs, and some of the electrical and controls diagrams, to the plant information. This made it much more intuitive for users to make some queries.

Q. Ian. Please comment?

Project Execution Summary


  • People
    • one, two, three?
  • ...
  • Hardware
    • anything special?
  • Databases
    • Microsoft Access database to validate information handover.
    • Commercial database for data warehouse.


  • ?

Q. Ian. Is this correct?

Significance of this Project to ISO 15926

  • This project started at about the time people were talking about STEP AP221 (a.k.a. ISO 10303 Application Protocol 221), and were thinking there should be something more. It was out of these ideas, and on this project, that ISO 15926 was probably born.
  • Much of the learning on this project has been distilled into Part 7 and Part 8.
  • This project developed of the concept of Templates to make it easier to use Part 2 data types.
  • This project used Gellish for what now is powered by XML and OWL.

Back to Case Studies


You have no rights to see this discussion.

About PCA
Reference Data Services