CAESAR

ERDL working format

A specification for the publication of the EPISTLE Reference Data Library

This Version:
http://www.cedarlon.demon.co.uk/epistle/erdl_working_format-2001-07-10.html
Author:
David Leal, CAESAR Systems Limited

Foreword

Following an extensive e-mail discussion, consensus on the approach to the definition of a working format for development and publication of the EPISTLE Reference Data Library (ERDL) has been reached.

Following this consensus, a standard view table has been defined for:

There are two natural extensions to this document, which have not yet been completed:

Acknowledgements

Contributions to this document have been received from Ian Glendinning, Roel Murris, Chris Angus, Andries van Renssen, Hans Teijgeler, Matthew West and Onno Paap.

Document log

1.0 5th May 2001 Initial draft following the PISTEP meeting in Billingham
2.0 11th May 2001 Revision following contributions and discussion from Chris Angus, Andries van Renssen, and Ian Glendinning
3.0 15th May 2001 Addition of summary and placeholders for the technical content
4.0 4th July 2001 Addition of the standard view table
4.1 10th July 2001 Misprint spotted by Magne corrected

Table of Contents


1. Introduction

1.1 Background

Collaborative work on the ERDL requires one or more publication formats, which:

The obvious way to meet these criteria is to relate the publication formats directly to ECMv4.

NOTE - ECMv4 contains a useful set of generic concepts which have been agreed by the participating organisations in EPISTLE. If any other set of generic concepts were adopted as the basis for ERDL publication, this would be equivalent to reopening discussion on ECMv4.

Possible publication formats, which can be related to ECMv4, are:

ACCESS:
This is a useful format because it is based upon widely available software;
STEP part 21:
This is an important format because it is a standard, but does not have such broad software support.
EXCEL:
This is very simple and convenient for browsing and editing. However, the format is less sophisticated than ACCESS, and may be cumbersome when full source and approval meta-data is added.
XML:
This is very important for the long term, but at present no DTD corresponding to ECMv4 has been published.

At the PISTEP meeting on 2001-05-01, it was suggested that ACCESS was one of the most useful publication formats.

1.2 Objectives

The objectives of this document are as follows:

1.3 Summary of approach

The approach to ERDL publication is summarised as follows:

  1. An implementation shall enable a standard view table to be downloaded for browsing and updating.

  2. A standard view table shall specify the necessary minimum of identification, description, source and approval data for the ERDL content.

  3. An implementation shall support downloading in ACCESS or EXCEL format (because these software packages are widely available, although the definition of the standard view table itself will be independent of format)

  4. The precise semantics of a standard view table will be defined by a mapping to ECMv4 (because there is no other choice).

    NOTE - This shall not prevent entry of library content that has no agreed mapping to ECMv4. If such content is required, then this is an issue against ECMv4. Any extensions to ECMv4 shall be made using the ERDL itself as far as possible.

  5. The mapping to ECMv4 will be defined informally using English and a worked example (because there is no other choice).

  6. Exchange of information between different ERDL implementations shall be carried out using either standard view tables or ECMv4 and STEP part 21 (if we can't use ECMv4 for this, then what can we us it for?).

2. Publication architecture

2.1 Database and views

ECMv4 is not a convenient format for browsing or editing. Hence views will be required to support these activities. An outline of a possible network of formats is shown in Figure 1.

ERDL formats
Figure 1: ERDL formats

2.2 ACCESS or EXCEL download

It shall be possible to download a standard view table from an ERDL application. The format of a standard view table is defined independently of any software in section 3 below.

It shall be possible to download a table in ACCESS or EXCEL format.

NOTE 1 - These formats are convenient for browsing and editing. The software to handle them is widely available.

The internal database format used by an ERDL application is not specified.

NOTE 2 - An internal database format with a defined mapping to ECMv4 is recommended.

NOTE 3 - Chris Angus has proposed a single table schema suitable as an internal database format, which is described in annex A. This single table schema is flexible and can support ECMv4.

3 Standard view table

3.1 'One table, one row per object' approach

The standard view format for the ERDL consists of one table, with one row per object. This table is not normalised and has many columns.

NOTE - The structure of this table is similar to, but not identical to, that used for the STEPLIB library.

Different ERDL browsing and editing activities require different subsets of the columns, or 'subviews', as shown in Figure 2.

ERDL subviews
Figure 2: Extract subviews from a single table

A set of useful subviews is suggested in annex B. These are not standardised in any way.

3.2 Engineering dictionary and reference library

The ERDL has two levels:

engineering dictionary:
This is a set of engineering concepts, which are informally defined. The definitions may be understood only in a particular 'context', such as an engineering discipline, country, or company.
reference library:
This is a set of concepts that have a single precise definition, which is independent of context.

Both engineering dictionary and reference library objects have audit trail information, such as source and approval.

A reference library object may have one or more corresponding engineering dictionary objects.

NOTE 1 - Most 'concepts' or 'objects' in the engineering dictionary and in the reference data library are classes. 'Correspondence' between a dictionary class and a library class means that they have the same members. They have merely been identified and described differently in the two places.

NOTE 2 - The relationship between the engineering dictionary and the reference library is similar to that between the ARM (Application Reference Model) and the AIM (Application Interpreted Model) in a STEP AP.

NOTE 3 - A reference library object can be defined even if there are no corresponding engineering dictionary objects.

In the standard view table, a row may correspond to either an engineering dictionary object or a class library object.

3.3 Multiple data items for an object

Not all data fits easily into a one table, one row per object approach.

NOTE - This is why we have a flexible EXPRESS schema for the ECM, rather than a hierarchical document format.

There must be multiple columns to support:

These multiple columns shall be created explicitly, giving column headings such as 'dictionary object name 1', 'dictionary object name 2', etc..

If a column contains a name or description in a language other than English, then the language shall be indicated as follows:

'Français: pompe'
'Cymraeg: pwmp'

3.4 Standard view table columns

The standard view table columns are defined in Figure 3.

standard table column D L repeat definition
object UID ü ü unique object ID
dictionary context UID ü dictionary context - UID
dictionary context name ü dictionary context - name
dictionary object UID ü * dictionary object for library object - UID
dictionary object name ü dictionary object for library object - name
object name ü ü * object name
superclass UID ü * superclass for a library class - UID
superclass name ü superclass for a library class - name
formal definition ü see note 3
working definition ü ü * an informal definition which is used if a formal definition is not available
entity type name ü * entity type of which the object is an instance - see note 4
schema name ü the schema that contains the entity type
classification UID ü * class containing library object - UID
classification name ü class containing library object - name
creation date ü ü creation date of the object record - see note 8
source ü ü source of the object record
latest change date ü ü latest change date for the object record
author of latest change ü ü author of the latest change to an object record
approval status ü ü object record approval status
approval date ü ü object record approval date
approver ü ü object record approver
approver's remark ü ü object record approver's remark
first role ü first role for a class of relation
first related class UID ü first related class - UID
first related class name ü first related class - name
first cardinality ü first cardinality - see note 5
second role ü second role for a class of relation
second related class UID ü second related class - UID
second related class name ü second related class - name
second cardinality ü second cardinality - see note 5
property criterion UID ü * class of property for property criterion - UID
property criterion name ü class of property for property criterion - name
property criterion numeric value ü numeric identification of the property - see note 6
property criterion unit of measure ü unit of measure for property criterion value - see note 7
valid property UID ü * valid class of property - UID
valid property name ü valid class of property - name

Figure 3: Standard view table columns

NOTES:

  1. Column 'D' indicates the columns that may be instantiated for an engineering dictionary object. Column 'L' indicates the columns that may be instantiated for a reference library object.

  2. Column 'repeat' indicates the columns that can be repeated, singly or in groups.

  3. The formal definition takes the form of English language text that can be used in a sentence of the form:

    'A <class name> is a <superclass name> that <definition>.'
  4. The entity type name indicates the entity type in a schema that can be instantiated to hold the reference library object.

    EXAMPLE - If the object is 'check motor sump oil level', then the entity in ECMv4 is class_of_activity.

    The ERDL may include objects within ECMv4., such as 'activity'. It is possible to record separately that 'check motor sump oil level' is a specialisation of 'activity'.

  5. The cardinality for composition and connection of an equipment item is for the running state. Any equipment item may violate this cardinality when being serviced or when partially manufactured.

    The cardinality may be specified by:

  6. The numeric value or range may be specified by:

  7. The unit of measure is specified by text. SI units shall be specified according to ISO 31, e.g. m, Kg, kN, W.

  8. Dates shall be in YYYY-MM-DD format according to UTC.


A. Single table database schema

The single table schema shown in Figure 4, has been proposed by Chris Angus as an internal database format. This is a highly normalised format which can cope with any ECMv4 defined data. This is not a view format suitable for browsing and editing.

Column Domain Type M/O Description
OID OID 32-bit I M Unique identifier (primary key)
TYP OID   M Physical type
CE OID   M Creation event
TE OID   O Termination event
CTM TM Time M Creation date/time
TTM TM   O Termination date/time
A OID   O Involved thing
B OID   O Involved thing
LOG_TYP OID   O Logical type
ACR OID   O Access control record
DT DT 1-byte O Data type of VAL
S - String
T - Time (date/time)
N - Number
O - OID
P - Enumerated Property
etc.
VAL VAL String O Value or label

Figure 4: A single table database format

NOTES:

  1. 'M' or 'O' indicates whether or not the data is mandatory or optional.


B. Some useful subviews

Some useful subviews of the table defined in Figure 3, are as follows:

object source and approval:

this subview contains the source, and approval information for any engineering dictionary or reference data library class;

reference data library class of object:

this subview contains the definition of a reference data library class, which is not a class of relation;

A class of object is distinguished from the intersection of its superclasses by a text definition.

reference data library class of relation:

this subview contains the definition of a class of relation;

A class of relation has all information for a class of object, with information about the related classes and the cardinalities.

reference data library class of object criteria:

this subview shows intersecting superclasses, including property range criteria;

reference data library class of object valid classes of property:

this subview contains the classes of property that are valid for a class of object.

These views have the columns shown in Figure 5.

standard table column source and approval class of object class of relation class criteria valid properties
object UID          
dictionary context UID          
dictionary context name          
dictionary object UID          
dictionary object name          
object name ü ü ü ü ü
superclass UID          
superclass name   ü ü ü  
formal definition   ü ü    
working definition ü        
entity type name          
schema name          
classification UID          
classification name   ü ü    
creation date ü        
source ü        
latest change date ü        
author of latest change ü        
approval status ü        
approval date ü        
approver ü        
approver's remark ü        
first role     ü    
first related class UID          
first related class name     ü    
first cardinality     ü    
second role     ü    
second related class UID          
second related class name     ü    
second cardinality     ü    
property criterion UID          
property criterion name       ü  
property criterion numeric value       ü  
property criterion unit of measure       ü  
valid property UID          
valid property name         ü

Figure 5: Some useful subviews

The 'source and approval', 'class of object', and 'class of relation' subviews are illustrated in figures 6, 7 and 8.

object

creation date

source

latest change date

author of latest change

approval status

approval date

approver

approver's remark

individual

2001-03-07

ECMv4 team

           

mechanical equipment

       

proposed

     

heat transfer equipment

1995-01-01

Fred Vonk

   

approved

1999-07-01

ERDL merger team

 

heat exchanger

1995-01-01

heat transfer peer group

1997-11-21

Andries van Renssen

approved

1999-07-01

ERDL merger team

 

unfired heat exchanger

1995-01-01

Andries van Renssen

   

approved

1999-07-01

ERDL merger team

 

shell and tube heat exchanger

1995-01-01

heat transfer peer group

1997-11-20

Andries van Renssen

approved

1999-07-01

ERDL merger team

 

fixed tube sheet heat exchanger

1995-01-01

heat transfer peer group

1997-11-19

Andries van Renssen

approved

1999-07-01

ERDL merger team

 

floating head heat exchanger

1995-01-01

heat transfer peer group

   

approved

1999-07-01

ERDL merger team

 

Figure 6: Reference data library source and approval

class

superclass

classification

formal definition

individual

thing

ECMv4 class

exists in space and time

mechanical equipment

individual

mechanical equipment class

is a machine or a component of a machine

heat transfer equipment

mechanical equipment

heat transfer equipment class

has the exchange of heat as the principal function

heat exchanger

heat transfer equipment

heat transfer equipment class

exchanges heat between two fluids

unfired heat exchange

heat exchanger

heat transfer equipment class

does not use combustion energy

shell and tube heat exchanger

unfired heat exchanger

heat transfer equipment class

has a tube bundle inside the shell to create sufficient heat transfer area

fixed tube sheet heat exchanger

shell and tube heat exchanger

heat transfer equipment class

has both tube sheets fixed to the shell

floating head heat exchanger

shell and tube heat exchanger

heat transfer equipment class

has one tube sheet fixed and the other floating

Figure 7: Reference library class of object

class

superclass

classification

formal definition

first role

first related class

first cardinality

second role

second related class

second cardinality

composition of individual

relation

ECMv4 class

specifies the part individual is within the whole individual

whole

individual

any

part

individual

any

tube sheet of shell and tube heat exchanger

composition of individual

heat transfer equipment class

specifies the part tube sheet is installed within the whole shell and tube heat exchanger

whole

shell and tube heat exchanger

1, 2

part

tube sheet

0, 1

floating tube sheet of floating head heat exchanger

tube sheet of shell and tube heat exchanger

heat transfer equipment class

specifies the part tube sheet is installed as the floating tube sheet within the floating head heat exchanger

whole

floating head heat exchanger

1

part

tube sheet

0, 1

Figure 8: Reference library class of relation