Version 9 (modified by gordonrachar, 13 years ago)


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. ISO 15926 Implementation
  6. 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 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).
    • STEP contains the necessary information and relationships to create a usable database for plant information.
    • By standardizing the new database against STEP, the owner was gauranteeing a measure of quality.
    • The owner's standard practice was to store plant information in a STEP-compliant database.
  • 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

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.

In addition, with the database, it would be easier for the owner to determine if the contractors had turned over all the information required to comission 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 maintenace.

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

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

ISO 15926 Implementation

STEP was the information standard at the begining 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 proejct 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 a language called 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.

The database that was 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. About two dozen attributes of plant objects were tracked. For further information, references were made to data sheets and vendor information.

The database that was eventually handed over was built in Microsoft Access.

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.
  • Development of the concept of Templates to make it easier to use Part 2 data types.


You have no rights to see this discussion.

About PCA
Reference Data Services