This work investigates semantic and syntactic interoperability capabilities on a Piping and Instrumentation Diagram (P&ID) model of engineering plants. Our analysis extends to a case study involving the Data Exchange in the Process Industry (DEXPI) specification, emphasizing the need for well-founded ontological relationships. By mapping P&ID classes of the DEXPI representation model to the Ofshore Petroleum Production Plant Ontology (O3PO), we aim to clarify and regulate the semantics of P&ID entities and structuring relations. While technical interoperability between DEXPI P&IDs and BFO-based domain ontologies is achievable, we identify challenges in semantic interoperability of the standard, including issues related to clarity, conciseness, extensibility, consistency, and essence. These challenges could bottleneck seamless system integration and pose adoption barriers for the DEXPI P&ID specification beyond the information handover use case.
Piping and Instrumentation Diagrams (P&IDs) are documents employed to exchange information
concerning installations, equipment, and related elements [
P&IDs have a long and evolving technical history, initially as physical drawings and later in digital formats, for Computer-Aided Design (CAD) and Computer-Aided Engineering (CAE) applications. In complex installations, such as petroleum plants, several companies may be involved in the refinement and upgrades of the diagrams, struggling to exchange data between diferent pieces of software from diferent vendors. Indeed, one important related problem is interoperability. Interoperability refers to the efective exchange of information and understanding to collectively pursue common objectives.
A remarkable initiative of the industry to provide homogeneous data interchange between P&ID projects from diverse vendors refers to the Data EXchange in the Process Industry (DEXPI) Association, which develops and promotes a common data exchange standard for the process industry, covering all phases of the process-plant lifecycle. The DEXPI solution includes: a conceptual model (the P&ID specification), an exchange format (the ProteusXML schema) and links to the Posc Caesar ontology (based on the ISO 15926). The conceptual model intends to organize and represent the entities that build industrial plants, while ProteusXML is the language that allows the formal description of the diagrams, and the links to the ontology provide useful definitions. Many important P&ID CAD/CAE software vendors are currently ofering an option to import or export their data following the DEXPI standard and it is still an ongoing work.
Even if it contains some semantic capabilities, the DEXPI solution is basically a technical interoperability resource, focused on format data exchanging between commercial software. We recognize that the DEXPI solution conceptual model can be thought as a kind of weak ontology, but this is diferent from a well-founded ontology. The DEXPI solution also provides some linking for a third-party ontology, but only to provide some definitions. The DEXPI solution does not organically derive from this third-party ontology.
We have explored the DEXPI solution in the context of a Research and Development (R&D) project for a petroleum production digital twin1. More specifically, we have invested in trying to couple the DEXPI solution to a well-founded ontology developed in the project, named O3PO. After all, in our digital twin context, we had to be more ambitious about semantic interoperability.
We have mapped the DEXPI conceptual model classes to the ontological entities of the Ofshore Petroleum Production Plant Ontology (O3PO), necessitating a thorough semantic analysis of the DEXPI model. Our primary objective is to present the findings of this analysis. This means to make explicit the gap between a mostly technical interoperability tool, good for some purposes, and a more complete semantic interoperability perspective, required for more advanced uses. We observed some good matches but also some challenges, like some vague, missing, and overlapping definitions in the DEXPI model.
This section introduces the problem of the data exchange in engineering planning and the technologies that this work adopted to express and verify the semantics of the entities that build an instrumentation diagram.
Interoperability is multidimensional, encompassing diverse perspectives and approaches across various
application domains [
Interoperability is also separated into diferent levels, distinguishing syntactic, technical and semantic
interoperability:
• Syntactic interoperability refers to describing the exact representation of the information to be
exchanged in terms of grammar and format [
The DEXPI initiative seeks to address interoperability challenges within the process industry by
establishing standardized digital communication norms, facilitating seamless data exchange across the
industry’s life cycle, from development to maintenance [
The design approach of separating specification (DEXPI) from implementation (ProteusXML) requires aligning P&ID files, initially in the ProteusXML format, with the DEXPI conceptual model. To efectively handle Proteus files within this framework, the P&ID Toolbox provides a comprehensive implementation of the DEXPI information model. Additionally, this toolbox streamlines the processes of importing, exporting, and visualizing DEXPI P&IDs as images. Figure 1 shows an example of a P&ID.
The Ofshore Petroleum Production Plant Ontology (O3PO) 2 is a public reference domain ontology of
petroleum plants that uses BFO[
There are three main uses for O3PO: (1) to define what are the main types of entities between the
subsurface reservoir and the surface platform; (2) to determine the main properties that inhere on those
entities; and (3) to follow the fluid path from the reservoir to the platform[
In this section, we will present how the diferent subdivisions of interoperability (i.e., syntactic, technical, and semantic interoperability) manifest themselves in the DEXPI P&ID specification. Showcasing the tools, descriptions, and situations in which the specification achieves diferent interoperability and has room for improvement.
Syntactic interoperability requires an exact and well-defined representation format for information
to be properly exchanged. The DEXPI P&ID standard currently adopts the ProteusXML4 schema
as its exchange format. The standard’s documentation also points direct mappings from the DEXPI
Information Model to ProteusXML patterns [
Technical interoperability, on the other hand, is associated with data integration services and data exchange activities. On that matter, many CAE systems provide automated services to import/export P&IDs using the DEXPI P&ID standard6. This allows third-party applications to exchange P&ID data with such CAE systems without the need for vendor-specific integration.
Semantic interoperability requires that the parties involved have a shared understanding on the meaning of the exchanged data. The DEXPI P&ID specification presents several definitions to contextualize the elements in a process plant, and many of them are based on definitions from POSC Caesar 7. Despite that, there are flaws in the definitions of many other terms that compose the specification, which hinders its semantic interoperability capabilities. We analyze some of these issues below.
Vague definitions Certain elements within the DEXPI standard exhibit vague definitions and require a comprehensive grasp of the standard’s structure and access to industry-specific glossaries for proper comprehension. Examples of this issue include the definitions of DEXPI:Piping Component as “A piping component”, and DEXPI:ColumnSection, defined as “A column section”, lacking contextualization or specific and explicit identity criteria for the identification of its instances.
With vague definitions, the interpretation is left to the reader of the model, which can lead to issues if the recipient of the information has a conceptualization diferent from the sender’s. For instance, a pump is classified as “equipment” in the DEXPI standard and is likely distinct from “piping components”, yet some consider it as a piping component. This raises questions about what exactly constitutes a piping component. If the definition is limited to only tubes, then valves would not be considered piping components; however, if it includes any item through which a fluid passes, then valves, tubes, and even the insulation of tubes would be classified as components. Conversely, thermal insulation would not qualify as a component if the definition restricts it to items where the fluid directly contacts their walls. This ambiguity in classification highlights the need for precise definitions to ensure uniform understanding and application across diferent contexts. 4Available at: https://github.com/ProteusXML 5Available at: https://www.plants-and-bytes.de/en/p-id-and-dexpi 6Available at: https://dexpi.org/software/ 7Available at: https://data.posccaesar.org/rdl/ Missing definitions Despite the large number of classes in the DEXPI specification, such as DEXPI:
terms of being part of a piping, the standard lacks a clear definition of what constitutes a “piping”. This absence of definition poses challenges when attempting to state, for instance, that DEXPI:PipingComponent is a piping component, as the concept of a piping system is not explicitly defined.
Consequently, one must resort to terms like O3PO:Pipeline as an approximation to the implicit DEXPI notion of what a piping system entails.
Another case of missing definitions seems to be the DEXPI:PipeFitting, defined as “A pipe fitting”, without resorting to any external definition. By analyzing its subclasses, the class seems to refer to passive elements assembled between two pipes, like strainers, fittings, and line blinds, that we could categorize as valves.
Collapsed definitions An illustrative example of a lack of definition and collapsed terms is DEXPI:SafetyValveOrFitting, denoted in the specification as “A safety valve or fitting”. From an ontological viewpoint, this definition muddies the distinction between diferent types of entities: pipe fittings and valves, both serving the role of ensuring safety. Within the O3PO model, the sole common class encompassing pipe fittings and valves is IOF:MaterialArtifact. Had the standard implemented separate classes for each, it would have enabled the diferentiation between the elements that define their identity and those that specify their utility. The absence of a valve class raises further questions, particularly regarding how one might quantify the number of valves within a plant. Despite the seemingly straightforward nature of this query, it necessitates a manual count of instances, encompassing DEXPI:OperatedValves, DEXPI:Check Valve, and non-safety fitting instances of DEXPI:SafetyValveOrFitting. Given that these instances are distributed among various subclasses of DEXPI:PipingComponent and no clear criteria exist within the DEXPI:CustomSafetyValveOrFitting class to diferentiate between valves and fittings, this tallying process necessitates human intervention.
Contradictory definitions In DEXPI specification, a Piping Network Segment is defined in POSC Caesar as something composed of inanimate physical objects. In DEXPI, a Piping Network Segment Item is defined as something that can be part of a Piping Network Segment. However, in DEXPI, Piping Network Segment Item is subclassed as PipeOfPageConnector, which is an “Abstract Class” defined as “A connector that indicates that a piping network segment is continued elsewhere, either on the same PID or on another PID. Graphically, it is usually represented as an arrow”.
Custom Object Role One parent class present across the DEXPI specification is the DEXPI: CustomObject (defined as “The abstract base class of all custom classes”), which diferentiates classes initially defined in the standard from user-defined ones. The standard currently counts 57 custom classes, all sharing the same pattern.
The issue with custom classes is that instead of relying on the entity responsible for defining a class like “this class is defined in DEXPI 1.3” or “this class was defined by organization X,” its members are defined in a case-by-case manner, using the same pattern of “a DEXPI:CustomY is a Y and is not covered by any of the other subclasses of Y.” This means that to support the representation of any of the custom classes in DEXPI, one needs to be able to represent and diferentiate all other subclasses of the parent class.
Diferentiability of equipment As far as redundancy goes, there are also classes like DEXPI:TaggedColumnSection that exist to convey that an item is a DEXPI:ColumnSection and is tagged. In the same way, as in previous examples, it is quite interesting to note that a column section is still the same whether it is tagged or not, and the only diference is this relation with a tag that does not afect the identity of the column. The precision and clarity of a model presuppose that the entity has a single representation and that non-specialization properties, like “having a tag,” should not define new entities but be inserted as dependent properties of the entity.
linePrimaryElement (defined as “An inline primary element”) encompasses ten distinct subclasses. Two of these subclasses stand out: the DEXPI:FlowMeasuringElement and the DEXPI: ElectromagneticFlowMeter. The former is defined as “A FLOW MEASURING ELEMENT is a MEASURING ELEMENT that measures a FLOW RATE”. In contrast, the latter is “A velocity flow meter that measures the flow rate of a conductive fluid running through a magnetic field by measuring the charge created when fluid interacts with the field”.
This scenario perfectly illustrates a case where an electromagnetic flow meter inherently functions as a flow-measuring element due to its ability to measure flow. However, in the DEXPI specification, both classes are categorized as direct subclasses of DEXPI:InlinePrimaryElement, thus implying that we can not classify one entity under both classes.
A similar scenario arises when considering DEXPI:HeatExchanger and DEXPI:CoolingTower. The former is “An apparatus or machine that has the capability of heat exchanging”. In contrast, the latter is defined as “A cooler and an air-cooled heat exchanger that is a tall structure through which air circulates by convection”. Notably, the definition of DEXPI:CoolingTower explicitly states that it is an “air-cooled heat exchanger”. Despite this clear relationship, the DEXPI standard does not classify DEXPI:CoolingTower as a subclass of DEXPI:HeatExchanger, showcasing a discrepancy between the definitions and the classification within the standard.
As demonstrated, DEXPI facilitates syntactic and technical interoperability but falls short of providing semantic interoperability. To address this gap, an experiment was conducted to showcase potential solutions. The experiment utilized the O3PO ontology alongside a subset of DEXPI packages, specifically those whose terms overlap with O3PO categories. This approach allowed for a deeper integration of data and systems by aligning terms from diferent standards under a unified semantic framework.
One of our goals is assessing to which degree one can achieve semantic interoperability between process plant descriptions adhering to DEXPI and O3PO. In the context of ofshore oil and gas production, both models depict some aspects of reality in common. Also, the capacity to convert elements described in the DEXPI standard to an ontological model provides us access to tools such as query languages and tools common to the ontology community, such as graph databases and query languages, reasoning, fact-checking, and so on.
Both the standard data model and O3PO cover, to some degree, physical quantities, component types, and connection topology. If these data could be seamlessly integrated, one could easily make a query for pressure data (with the aid of the Information Artifact Ontology (IAO) alongside O3PO) of all elements along the piping (piping and connections represented in DEXPI).
Within the framework of the DEXPI standard, distinct packages focus on various facets of a production plant integration possibilities within specific packages. Package Piping stands out for its depiction of connection topology, while both Package Equipment and Package Piping contribute by outlining diverse equipment types within the plant. Additionally, Package PhysicalQuantities proves valuable in elucidating the array of physical quantities associated with production elements, such as surface areas of frequencies.
To assess the overlap of intended models between the conceptualizations of DEXPI and O3PO, a classification process is proposed to establish a depiction of DEXPI classes with O3PO classes and relationships, using elements from its imported ontologies when necessary. We selected the DEXPI P&ID specification packages based on their apparent overlap with represented elements in O3PO. Package piping and equipment were chosen for this study, aligning with the component types and relations in O3PO.
After a more in-depth analysis of the selected DEXPI packages, the most representative classes identified were PipingComponent and Equipment. From there, their subclasses were analyzed down the taxonomy, stopping whenever new terms brought out the same meaning as their parent classes. In addition, other classes help to explain dependent concepts. While some of the established correspondences rely on concepts directly defined in O3PO, many require definitions from O3PO’s imported ontologies, such as IOF-Core for more general terms like assemblies and systems or BFO for capabilities and functions. It is essential to note that we considered only classes and relations defined in these important ontologies and imported by O3PO for the analysis.
By applying this methodology, we have formulated O3PO classifications for some DEXPI piping and equipment classes (exemplified by Table 1), while simultaneously pinpointing the specific challenges for the cases that render the classification unfeasible.
Consider the case of the DEXPI:PipingComponent, as outlined in the DEXPI specification as “A piping component”. Given the vague nature of its definition, by taking into consideration its subtypes and the understanding that P&IDs primarily illustrate assemblies rather than individual components, one can classify DEXPI:PipingComponent as a BFO:MaterialEntity and BFO:bearer_of some BFO:Function, and IOF:prescribedBy some IOF:DesignSpecification and O3PO:component_of some O3PO:Pipeline.
Based on that, we can also specify DEXPI:InlinePrimaryElement, defined in the DEXPI specification as “An inline primary element”. Since the definition is also lacking specificity, the fact that it is a subclass of DEXPI:PipingComponent and all its subclasses are used to perform some measurement, we can say that a DEXPI:InlinePrimaryElement is a BFO:MaterialEntity, and a BFO:bearer_of some BFO:Function, and is IOF:prescribedBy some IOF:DesignSpecification, and a O3PO:component_of some O3PO:Pipeline, and IOF:hasCapability some IOF:MeasurementCapability.
Even though all the elements represented in a P&ID diagram are part of piping, that seems to be the only diference between DEXPI:Equipment, defined as “An apparatus or machine”, and DEXPI:
Through this classification, we clarified the semantics of the entities represented in a P&ID and provided support for the operator to understand the meaning and intrinsic restriction of the modeled entities. Also, O3PO supports a description of the DEXPI entities while utilizing domain-specific vocabulary tailored to the Oil and Gas industry. Moreover, this approach equips us with a foundational framework built upon ontological principles, fostering open accessibility, collaborative development, and enhanced interoperability.
Further possibilities remain open for mapping the two models, such as establishing a correspondence between DEXPI and O3PO topology models. DEXPI’s topology is structured around nodes associated with elements and their interconnections, whereas O3PO presents its topology through connections and fluid supply properties.
Another possibility is the use of O3PO for the creation of a Comprehensive Information Base (CIB), integrating data from various sources, including DEXPI P&IDs. By allowing the complementing of the data in the P&ID with other information sources, we could bridge the gap between classifications. This enhancement could help accurately categorize valve types such as GasLiftValve, ChokeValve, or InflowControlValve.
Integrating the DEXPI standard with the O3PO presented several challenges, including imprecise term definitions, potentially redundant or overly vague definitions that rely on previous understanding of those familiar with the subject matter, the absence of a superclass in definitions, the complexities of multiple inheritances and collapsed entities or relations. These limitations lead us to search the correspondence between the entities primarily based on the entity name, a common practice for mapping models that results in false agreements. This section will elaborate on these challenges to ofer a more comprehensive understanding.
Representing elements from the DEXPI standard in OWL using the O3PO domain ontology afords a dual advantage. From the technical interoperability perspective, it enables the execution of queries leveraging languages such as SPARQL, facilitating information retrieval from process plants structured in alignment with the DEXPI standard. Simultaneously, from a semantic standpoint, it empowers the utilization of a domain-specific vocabulary and conceptual framework to encapsulate plant-related data. Beyond these advantages, it facilitates seamless integration and aggregation of information from diverse sources and supports fact-checking and reasoning for instances within the O3PO context. Figure 3 portrays the diverse information transitioned from the initial P&ID to the final O3PO instances, showcasing the potential outcomes achievable by mapping topological correlations and equipment between O3PO and DEXPI.
To address the translation of data from the DEXPI file format (ProteusXML) to a conceptual model the pnb Toolbox Library, ofered by pnb plants & bytes 8, was used, simplifying the complexities of the format. This data was then converted into an N-Triples file using specific mapping rules, focusing on elements from the DEXPI equipment and piping specifications. Using the Hermit reasoner, we processed this data to identify inconsistencies and generate new information.
An application was developed to validate this process, taking a ProteusXML file and converting
it into triples that were further mapped to the O3PO model using the parser. The conversion and
reasoning capabilities were enhanced with a custom module developed using the Owlready2 Python
library9, which supports sophisticated ontology-based applications [
Upon receiving a ProteusXML file adhering to the DEXPI specification that delineates a plant featuring components like pipes, valves, separators, and nozzles, the application undertakes the task of mapping these elements to the O3PO model and subsequently infers their inherent attributes. Subsequently, following the described procedures, the process of categorizing DEXPI classes into corresponding O3PO classes is executed, followed by reasoning to extract comprehensive information associated with the identified elements.
This study approaches interoperability from multiple perspectives by facilitating technical interoperability between the P&ID representation standard (DEXPI) utilized by diverse software vendors and domain ontologies like O3PO tailored to represent the oil and gas production plant environment. Additionally, the study highlights instances where semantic interoperability between DEXPI and O3PO conceptualizations is feasible and instances where it is not.
While various tools are available to handle standards and technologies, the practical feasibility of achieving technical interoperability between DEXPI P&IDs and ontologies represented in OWL becomes evident. However, the predominant challenges remain within the realm of semantic interoperability. The presence of ambiguous and often vague definitions poses a significant hurdle to seamless systems integration.
As a potential avenue for further contribution, future work could extend this approach of categorizing instances into well-founded ontologies to cover the entire DEXPI standard by taking advantage of diferent ontologies to represent various aspects of the standard, thus serving as a valuable guide for future standards development and patching. Although the primary focus of the DEXPI revolves around enhancing interoperability between CAE tools, it is increasingly observed in the literature that various other applications adopt the description as a standard. These applications leverage the available tooling and the standard’s publicly available documentation. However, if the DEXPI standard were to evolve into a de facto standard for representing P&IDs, the highlighted issues could potentially bottleneck its adoption and hinder the ease of integration into diferent systems.
The authors acknowledge CAPES-Brazil Finance Code 001, the Brazilian Agency CNPq, and the Petwin Project, supported by FINEP, Libra Consortium (Petrobras, Shell Brasil, Total Energies, CNOOC, CNPC).