Mapping - introduction

latest update: 2018-05-08   

Introduction

Data that reside in an application program or data base can be added to the integrated plant lifecycle information. To that end that data shall be mapped to the format as defined in ISO 15926-8. This paper describes the process.

Limitation

Since no two applications are the same, the hints for the source side can only be generic.

Implicit and explicit information

All customary data stores contain "implicit" data. This means that much contextual information is left out, because the software and the user "know" (or at least think they do). But others don't necessarily.

"Explicit" information includes, but is not limited to, information about:

  • equipment and piping that contain a stream, where that stream possesses most of the  properties often attributed to that equipment or piping;
  • compositional information, such as:
    • assembly of piping systems;
    • assembly of equipment systems (e.g. a pump system has pump, drive, transmission, motor controls, etc;
    • relationship between piping or equipment and their insulation and heat tracing;
    • relationship between piping or equipment and in-line/on-line instrumentation items;
    • etc.
  • activity-based information (e.g. stress testing, hydrostatic testing, etc);
  • etc

In order to build a completely integrated lifecycle data base, all information must be explicit to the maximum extent, inasmuch that is required by the business needs. An example can be found in the publication Mapping a Line List.

Declaring objects

All objects shall be declared, as described in the publication "Declaring an object". It is advisable to store all such declarations in the Project Façade (see here), so that they can be looked up by all project parties. The responsibility for assigning equipment numbers, line numbers, instrument tag numbers, etc usually is well organized in a project, and doesn't have to change.

Mapping

Mapping involves outgoing mapping and incoming mapping. Outgoing involves data for which one is responsible, incoming for which one is not responsible, but one needs those data for the particular application.

What incoming data shall be mapped?

Incoming data always originates from SPARQL queries, typically in JSON format. What exactly is required is different for each application.

What outgoing data shall be mapped?

Only the data for which the user of the application is responsible shall be mapped. Responsibility means that the user has read/write access to those data, and that it is expected that he/she is the sole person that creates those data and that the data will be of use for others. Obviously this requires some planning.

Process

The target for outgoing mapping is a file in Turtle format, as defined in ISO 15926-8.

The diagram below gives an overview of the mapping process.

Data from the applications are, by means of a data acquisition software, dumped in a Data Lake in their native format.

Mapping software is selecting one or more data and maps those to variables in the applicable TIP. This is described in the topic TIPs - Templates of Information Pattern .

Using the completed TIP signature the underlying generic code is completed and turned into an ISO 15926-8 compliant code.

This is validated using W3C SHACL and stored in an Application Façade. This façade contains all data that were acquired from the application, thus including data that are not good enough for sharing with others. The owner of the data can decide which data shall be handed over to the Project Façade. From then onwards he/she is no longer owner of those data, although changes can be initiated if permitted by Project Management. This will be detailed in a topic about Part 9 - Façades.