Mixing data and documents

Introduction

Mapping all data presented on documents is not required for lifecycle information integration. Besides that it is a mission impossible.

This topic gives, at a conceptual level, a solution for the integration of data, that are being mapped, and documents.

Document storage

In most cases the software, that has been used for the creation of documents, will not be used throughout the life time of a facility. Then the documents are stored in, for the most, PDF format in an EDMS (Electronic Document Management System). An EDMS provides a solution for managing the creation, capture, indexing, storage, retrieval, and disposition of records and information assets of the organization.

Essential is, in this context, that each version (revision) of each document has its own URI and a user-extendable set of meta data.

Set-up

A sketch of a set-up is:

Example

Have a look at an ISA Contol Valve specification:

Mapping all 113 data elements on this document does not really make much sense. So which ones do make sense? The listing below represents the opinion of the author only:

Top center block - these data are already available in the Project Triple Store
Top righthand block - these meta data shall be mapped
Service Conditions - shall be mapped, although these data come predominantly from Process Engineering, and it would be better to map at the source rather than in a derived document like this one.
Line - already available in the Project Triple Store in relation with this valve
Valve body/bonnet - should not be mapped, can be re-established from the Service Conditions; Besides, vendor data do in fact not belong in a specification, because specifications are made to define requirements from an engineering point of view; This type of specifications are a relic from the pre-computer days, where documents were in fact a kind of record. So, only map what is a requirement, not what is vendor data. These come in the Lifecycle Activity "Procurement".
All other data - See above, only map what is a requirement, not what is vendor data.

Defining which data shall be mapped is up to the plant owner/operator, and is based on business requirements.

Note that the above should be read in the context of lifecycle information integration. For system-to-system interfacing other considerations may apply.

Considering the above one may draw the conclusion that only the meta data should be mapped, and data that have been created when engineering a control valve (provided it is important enough for lifecycle information integration). An example of the latter is the required Cv value (the selected valve has a Cv that is equal or slightly higher). Again, that value may come from some calculation program and, if so, should be mapped there at the source.

Some code

Assume a control valve with tag number FCV-101, defined on specification sheet IN-V-142 rev. 1. It has a Cv = 22.5. This leads to a mapping, in the ISO 15926 Adapter of the EDMS, to an instance of template

ReferenceToClassOfIndividualOnDocument - providing the cross-reference between document and control valve;
DocumentRevision - providing the relationship with the "Ur"-document, the revisioning activity, and the revision date;
DocumentPublication - providing the publishing activity and the publication status anddate.

and in the ISO 15926 Plant Archive:

ClassOfIndividualHasPropertyWithValue - for the required Cv-value at the dateTime mentioned in above DocumentPublication template instance.

Below these four templates are represented in ISO 15926-8 format, in Turtle. Note that the control valve is here considered to be an instance of ClassOfInanimatePhysicalObject, because it is the "requirements class" of which the instance of PhysicalObject, that is represented on the P&ID, is a member. That class is tagged CO_FCV-101 (CO = ClassOf).

This code, generated in the ISO 15926 Adapter of the EDMS, has the namespace of the Plant Archive and is sent to and integrated in the latter.

:78a2ae99-7bec-4a26-a0c5-1072d5ff7e2c rdf:type tpl:ReferenceToClassOfIndividualOnDocument ;
    tpl:hasReferred :CO_FCV-101 ;
    tpl:hasDocument :64c8cdb5-7a37-4e57-b678-1f031211a9e6 ; # the GUID of IN-V-142 rev.1
    meta:valEffectiveDate "2019-06-22T00:00:00Z"^^xsd:dateTime .

:28ba21e7-f68e-45a4-968e-b3e47b14d536 rdf:type tpl:DocumentRevision ;
    tpl:hasRevisedDocument :64c8cdb5-7a37-4e57-b678-1f031211a9e6 ; # the GUID of IN-V-142 rev.1
    tpl:hasMember :4019efad-a8dc-441f-8ad2-cff79a837dee ; # the physical file at revision date
    tpl:hasActivity :10e9ba65-623e-40bc-b016-6c28514edb14 ; # auto-generated, for later use
    tpl:valRevisionDate "2014-06-22T00:00:00Z"^^xsd:dateTime ;
    meta:valEffectiveDate "2019-06-22T00:00:00Z"^^xsd:dateTime .

:960dcd59-e39e-4ce4-be44-78fb03b93cf2 rdf:type tpl:DocumentPublication ;
    tpl:hasPublishedDocument :64c8cdb5-7a37-4e57-b678-1f031211a9e6 ; # the GUID of IN-V-142 rev.1
    tpl:hasMember :fb1a5ccb-808f-409e-9afa-3c143506ba8e ; # the physical file at publication date
    tpl:hasStatus rdl:RDS2229161 ; # Approved for Procurement
    tpl:hasActivity :5e5c6658-3be0-46d7-862c-b4586ce8f5fe ; # auto-generated, for later use
    tpl:valPublicationDate "2019-06-22T00:00:00Z"^^xsd:dateTime ;
    meta:valEffectiveDate "2019-06-22T00:00:00Z"^^xsd:dateTime .

# and already stored in the Plant Archive:

:c02b49cd-a1a8-4744-97ce-d92a52a264b1 rdf:type tpl:ClassOfIndividualHasPropertyWithValue ;
    tpl:hasPossessorType :CO_FCV-101 ;
    tpl:hasPropertyType rdl:RDS6549840 ; # Cv-value (fake ID)
    tpl:valPropertyValue "22.5"^^xsd:decimal ;
    tpl:hasScale rdl:RDS1059740901 ; # DIMENSIONLESS SCALE
    meta:valEffectiveDate "2019-06-22T00:00:00Z"^^xsd:dateTime .