Intersection of elementary requirement classes

The Asset Requirements Class usually is defined with a Specification a.k.a. Datasheet. So, in principle you could be satisfied with that and not map the data elements in that Specification to ISO 15926. But then you miss the advantages of ISO 15926 i.e. re-use, without rekeying, of data further down the life cycle.

Not all data are required as input to any software further down the life cycle, so it is wise just to rely on their recording in the Specification.
Als read the topic Mixing data and documents

Rationale

Why is it not OK to attribute all data of an Asset Requirements Class to the (individual) TAG?
Because in most cases these data are ranges or single values that in fact are the lower or upper boundary of a range, or a member of an undefined range such as a material of construction. Alternative materials are possible but often more expensive than normally justified.

An individual cannot have a range property, individuals have point properties. John Doe weighs 87.5 kg, not 85 - 90 kg. If you would state that the requirement for the dry weight of P101 is 200 kg, no supplier could possibly comply with that, unless by a chance in a million his pump weighs exactly that. So requirements need a certain leeway with defined boundaries. By the way, don't confuse property range with accuracy, where the latter refers to how close a measurement is to the true value.

And what if you need more than one occurrence of a pump design on different places in your plant design? Are all data repeated for all such occurrences?

Returning to our Asset Requirements Class, the first line of the chapter 'Construction' of the API 610 Centrifugal Pump Data Sheet states:

API 610 defines 18 pump types, such as API 610 MODEL OH2 CENTRIFUGAL PUMP , and by defining OH2 in that yellow cell everything else in that specification is in fact defining a subclass of that OH2 class.

Tag Properties

There are some valid tag properties. These are defining the function of the tag in the context of the plant it is a component of. So topological properties like its:

• tag number
• type (e.g. CENTRIFUGAL PUMP)
• connections to other plant items
• physical location (from the 3D model)
• contained stream

In principle those data could be defined at class level, but the CAE software suppliers don't do that.
All other properties are to be defined at class level in an Asset Requirements Class.

Templates or relations?

Templates are used to store information that changes during the life cycle of the plant.
In the context of a revision of a Specification nothing changes, so if so wished the information in a Specification could be modeled in a simpler manner. This could be done using RDF triples that can be predefined at the level of a Tag Class. The life cycle aspect of the Specification itself is then covered by a Template that relates the OOI - Object Of Interest with a temporal part of its Specification (as is standard, see excerpt from LSN below)


For this approach it is required to define Object Models as a meronomy for the OOI. The whole and its parts are the rdfs:subject of the RDF triples and the data values are the rdfs:object, as Literal or as URI. In fact the Specification is a kind of super template then.

This approach has the disadvantage that the contents of a Specification is one of a kind. Added to this is the necessity to make a selection of data that must be stored. For example, the specification S-710D - Data Sheet for Air-cooled Heat Exchangers of IOGP JIP33 has 252 data. Which ones to store as data? As a minimum the functional data. Also read the topic Mixing data and documents.

Given a standardization of Object Models this is a manageable price to pay for rapid exchange of design & engineering data without mapping, whilst the Specifications remain integratable in the integrated life-cycle information.

Comments are welcome.