Default Class and Attribute model

Many of the design deliverables, such as American Petroleum Institute (API) datasheets and Piping and Instrumentation Diagrams (P&IDs), define the physical asset. It is natural to group and characterize the model by a physical hierarchy for design.

Common physical characteristics, such as parts and attributes, inherit down the tree with specialized characteristics and enrich common ones further up the tree.

The ontology can be seen as three-dimensional in nature:

1. Conceptual physical characteristics are grouped at each level in the tree (1D).

2. The characteristics becoming more specialized as you go down the tree (2D).

3. Relationships across classes traverse across the tree (3D).

The gradient goes from abstract collections, type categories, functional collections (Process Flow Diagram type classes) and finally to specialized physical classes (P&ID type classes).

The basic physical ontology is based on International Organization for Standardization (ISO) 15926, with mappings to the Capital Facilities Information Hand Over Specification (CFIHOS), POSC/Caesar Association (PCA), StepLib, ISO 14224, and others that can be added. No single standard is totally suited to a real usage in a design tool and modifications are needed to suit the real world. The base model needs to be supplemented with attributes from deliverables, such as API or International Society of Automation (ISA) datasheets, as well as symbology from the various symbols’ standards.

The design was scoped for multi-disciplinary workflows, which includes the following:

• Simulation import

• Process Flow Diagrams (PFDs) and P&IDs

• Datasheets

• Hook-ups

• Loop schematics

For these deliverables, ISO 15926 gave the required granularity and decomposition as seen on an API datasheet. If we want to use this design in the digital twin in a different context, it needs to be componentized. This approach being used as the physical categorization is the only one that can be applied easily to other categorization contexts that are not physical, but context based. For example, CFIHOS and ISO 14224.

The model can be extended, but it is important to continue to maintain standards. This ensures that additional content and functionality can be integrated into the AVEVA Unified Engineering Default Configuration. Retaining inheritance from the upper ontology is essential to preserving functionality and business logic.