UNDER CONSTRUCTION

This tutorial extends on the tutorial of ISO 15926 part 4

The ISO 15926 part 2 model is defined in the language Express This data model is highly generic. It is able to define any kind of ontology.

Read here for ISO 15926 modeling examples.

Here is a diagram of a Short Hand template (base template) for Indirect Property of Individual called ST3401P. This template is used generically to define a property to an individual object. In this case the property is an "Indirect Property" in the sense of ISO 15926. Examples of Indirect Properties are:

• maximum allowable working pressure
• total filled weight
• rating

They are called "Indirect" because they are properties that are normally not measured like that; they can be actual, but usually not. In that effect in the engineering specification world most properties are "Indirect".

In the diagram the template ST3401P has a relation called "equivalentClass". This relation points at the Long Hand template, which has the same meaning, but it contains the inner typical ISO-15926-part-2-based data model for an Indirect property of Individual. Another relation is the "subClassOf" which points to ST3401C. This is the class instance of this base template in the ISO 15926 RDL. That contains the template's definition. The class is on itself subClassOf the template of template ST0001.

Making diagrams like this is only meant to be explanatory, not very practical. It is easier to present this Short Hand template like this:

ST3401 Indirect Property of Individual

appliesTo	PossibleIndividual	Temporal part of an individual object
propertyType	ClassOfIndirectProperty	Property class defining this property
basePropertyType	SinglePropertyDimension	Property of which this property must be a specialization
numericalValue	XmlSchemaFloat	value of property
unitOfMeasure	Scale	Unit of measurement

Looking at for example the variable for PropertyType, the template specification above says the Entity Data Type should be ClassOfIndirectProperty or any of its subclasses. When assigning a value for PropertyType, like for instance a pointer to the class in the ISO 15926 RDL for "maximum allowable working pressure", this Entity data Type designation limits the lookup list. An application or verification program will only select members of ClassOfIndirectProperty (or subclass). It is important to realize how this works; it shows why Entity Data Types must always be assigned in the ISO 15926 RDL or any other library. If that wasn't available, application building, like an Ontology Browser or verification program for legacy data mapping, would be impossible. Think about the core library of 10,000 classes; no engineer should have to go through all of them when configuring the name of the property for a certain mapping.

Next, a data example:

ID="PRS01-347621"
type	Vessel
type	FunctionalPhysicalObject
tag number	V-6060		UTC: 24-Jan-2006 10:18
maximum allowable working pressure	100	barg	UTC: 24-Jan-2006 16:45	data terminated UTC: 17-Mar-2006 10:26
maximum allowable working pressure	120	barg	UTC: 17-Mar-2006 10:26
minimum allowable working temperature	-10	degrees centigrade	UTC: 24-Jan-2006 16:50

This example can be seen in OWL here: ISO 15926 part 7 examples

Explanation:

This is an example about a few vessels (above only one is shown).

ID="PRS01-347621"

Each vessel has (to have) a unique persistent ID. It is required that this ID is stored also in the legacy system where this data came from, so that all data changes can be properly mapped, even when that change is the tag number.

Here the object's ID is "PRS01-347621". What is not shown here, but can be seen in the OWL script, is that the ID falls under a globally unique namespace, which only makes it necessary that the ID is unique within the namespace, so within the owning Facade.

type	Vessel
type	FunctionalPhysicalObject

The object has as type "Vessel" and "FunctionalPhysicalObject".

The string "Vessel" is the short name, in English, for the pointer to the VESSEL class in the RDL. The example data is resident in a project Facade, and the VESSEL class in the ISO 15926 RDL Facade. The application showing this data has to follow the pointer into the RDL Facade, and retrieve the short name in the language of choice, here English.

The string "FunctionalPhysicalObject" is the Entity Data Type of the object. "FunctionalPhysicalObject" objects store the design data (example: tag number). "MaterializedPhysicalObject" objects store the physical data (example: serial number). The third type is the installed object, which is connected with TemperalWholePart relations to these former two, and which stores the data belong to the installed object (example: DCS historian data for maintenance purposes)

The triangle "Functional data" - "Materialized data" - "Installation place" comes from the plant data warehouse world. The benefit of such data construction is that when for instance a pump is replaced, the materialized data (vendor name, serial number, actual rating, npsh etc) is updated, but the design data remains the same.

tag number

V-6060

UTC: 24-Jan-2006 10:18

TO BE CONTINUED - UNDER CONSTRUCTION

Handover data according to the Capital Facilities Information Handover Guide

ISO 15926 part 7 examples

Façades

Combining data from different Façades in a query

Handover data from an engineering database to a Facade

Moving data from one Facade to another

Demonstration export RDS Demo of export of Part7-compliant OWL instance data from RDS. This must be regarded as a prototype. For speed purpose the RDS content was first copied from the Express EDM database to SQL-Server, and the aspx program runs on that. The used templates are only those of Identification and Definition, and they are hard-coded, not derived from an Part7 triple store. This demonstration has been made by DNV, author is Martin G. Skjæveland, contact Johan W. Kluewer.