Eficient access to relevant information is crucial for various data-driven operations within organizations. However, this process often involves significant time investment and the need for often manual and non-reusable mappings to utilize the available data properly. Ontologies ofer a solution by enabling upfront integration and contextualization of data, facilitating the access to integrated and semantically enriched information. In this paper, we report on the process of developing an ontology-based system for the domain of petroleum production. We present its conceptual structure, architecture, and implementation, discussing some of the decisions and trade-ofs imposed by the practical setting of the application.
Much like any other large and complex application domain, the oil and gas industry relies on many systems to manage and serve data efectively. From cataloging parts to organizing sensor series and present measurements, data systems serve from the most time-critical operational activities to research and analytic tasks. In particular, production surveillance requires many service companies to collect data on distinct parts and functions of the plant installation. Many systems are built to store and process these data without considering the original context and meaning or how it relates to other elements within the physical system. The delivered data demands a large efort in real-time human processing to become a uniform, indexed data collection organized to support production decisions, besides requiring highly specialized users to select data from the right source and combine them with correct semantics. To address this issue, engineers often assign semantics to data to provide context and facilitate retrieval. Whether categorizing data by geographical area, production plant, or administrative division, these semantic approaches aid humans in finding the information they need. However, when it comes to automated systems searching for data, a clear and definite method of organizing this data is essential. This is where ontologies come into play.
Ontologies serve as crucial tools in information system development, ofering standardized and semantically rich vocabularies for knowledge representation. Integrating ontology into system development enhances data consistency, interoperability, and eficient knowledge sharing and retrieval within a defined domain. Utilizing an existing domain ontology – in our case about ofshore petroleum production equipment – can facilitate data retrieval in information systems. Such systems enable stakeholders to access relevant data eficiently while ensuring consistency across diferent applications within cross functional domains of expertise.
In this paper, we report on the process of creating, from the ground up, an ontology-based system for the domain of petroleum production. We describe aspects of its conceptual structure, architecture, and implementation, discussing some of the decisions and trade-ofs imposed by the real-world nature of the application.
The remainder of the paper is structured as follows: section 2 provides some context about how data is used in the domain; section 3 exposes how we conceived a proposed semantic infrastructure to meet the needs discussed in section 2; section 4 describes how the proposed semantic structure was efectively implemented; section 5 place our work in the context of related ones; finally, section 6 brings our concluding remarks.
Recognizing the various aspects of the domain is the first step in creating a semantic definition capable of representing the data and assets involved in ontology-based systems. Thus, we need to understand how users interact with their daily tools.
During this discussion, we approach the decisions while considering the perspective of a petroleum
engineer, whose time is mostly consumed by tasks of data search and conversion [
In this context, the purpose of a semantic layer is to ease this process by incrementing a system with expert knowledge. Figure 2 shows a prototypical example of an interaction the application is intended to support. There, we have a user who wants a full description of the profile of a given petroleum well, consisting of the values for all the properties of all its components. From this scenario, we can identify some requirements that an ontology-based application for the petroleum production domain should fulfill.
Users have their own domain of expertise. Petroleum production is a multidisciplinary area involving professionals from a wide range of domains, such as reservoir engineers, production engineers, and maintenance engineers. As is usual in highly technical fields, these professionals rely on considerable amounts of data to carry out their duties. Still, data is just a tool for their work, not their object of inquiry – they are experts in petroleum, not in data. Therefore, demanding from them an accurate knowledge of where and how the data is stored is not reasonable. Instead, they should be able to rely on their domain knowledge to get the data they need. Given that, the application should shield professionals from data management details by ofering means to search data that reflect the semantics of the domain.
Pieces of data are useless in isolation. Typically, users do not access a system by chance simply to see what they can find. Instead, they resort to an information system to solve an issue or carry out some task. In petroleum production, this involves checking a single piece of data and analyzing it with respect to several other data items that characterize the broader context of the issue at hand. An example would be monitoring the behavior of a plant by checking a set of alarms designed to indicate the occurrence of anomalies. Usually, those alarms are rather simple, triggering when the value of some variable (e.g., the pressure of some pipeline section) crosses a given threshold. In this case, the task is not simply verifying whether the variable meets the alarm threshold. Instead, it would require analyzing a diverse set of equipment properties to determine whether the alarm went of due to a genuine anomalous behavior or if it is a false-positive. Therefore, an application for this domain should focus its semantic capabilities on gathering meaningful packages of contextualized information, releasing the user from the burden of having to figure out what pieces of information must be gathered to support a given activity.
ifeld, the problems that arise in petroleum production are not always well-structured or predictable. Sometimes, part of the job is first finding out the precise nature of the problem and determining what is needed to solve it. In such cases, having a fixed set of predetermined queries is insuficient. With that, the application should ofer means for the user to explore the data freely without being tied to any particular workflow.
Based on these requirements, the next section describes the semantic infrastructure we conceived to address this scenario. Also, we discuss some decisions we took during the process and some of the considered options to conform the solution to the constraints imposed by the practical setting.
In the context of a database storing historical property measurements, the concept of time is paramount. However, integrating such temporal notions into the ontology can introduce a significant complexity. To address this challenge, our approach focused on taking all time series data provided by sensor measurements in the plant, each represented by a unique identifier, and instantiating this identifier in the knowledge base as an Information Content Entity (ICE). For those ICEs, we set an annotation property with the identifier value, so that from an atemporal vision of the production plant (present time), one can find the data that describes all readings of a property of an element. The relation between the ontology, the physical entities, and the necessary infrastructure that will be explained in this section is illustrated by Figure 2.
Our solution needed a domain ontology to tie sensor data from the oil plant to the actual pieces of
equipment. We used the Ofshore Petroleum Production Plant Ontology (O3PO) [
The ontology besides formally defining the main entities in an oil plant, also enables accessing the properties of equipment, the components of the facilities, and following the oil path from the reservoir to the platform through fluid connections defined as object properties.
To efectively use the employed ontologies, it is necessary for the modeled ICEs, containing the reference to the data, material entities, and properties for which such information is about, to be instantiated in the model. When working with preexisting data, doing so requires some description of the data and relevant assets to enable the creation of the instances. Furthermore there is a choice to be made regarding how to represent the data in the model, by either assigning the value directly to a property or by representing an identifier to the "location" of a property’s respective data. The first option implies in inserting the values directly in the model, thus increasing the number of instances (consequentially increasing the complexity of the model) by an amount equal to the number of samples of data. This is not viable when working with time series, whose number of samples may surpass the thousands per data, as observed in our use case. As such, we determined that the best approach would be to utilize ICEs to represent the agglomeration of all samples of a piece of data (a time series) and utilize annotation properties to store the identifier of such data, enabling its retrieval from where it is stored.
The instantiation process can be done either manually or automatically, depending on how the necessary data is stored. Approaches for automatic instantiation start with the formalization of R2RML1 by the W3C2 as a language for describing how data in a relational database is related to entities in an ontological artifact. This and similar solutions require that the data is suficiently structured in a way 1https://www.w3.org/TR/r2rml/ 2https://www.w3.org/ compatible with the ontological definition of the domain, limiting its applicability to cases in which the schema of the data carries all the semantics related to the underlying taxonomy.
When working with the time-based information from historian systems, there is no guaranteed
manner for representing such semantics. This system can represent as little as just a time series and its
unique identifier and may provide some auxiliary description, as is the case with the OSI PI system.
The taxonomical relations are extracted from the PI Asset Framework, which represents the hierarchical
relations between the various involved assets but does so as a provider for a certain "target audience",
not creating a general, consistent model [
For the instantiation process, an ontology engineer who understands the domain will look at the available descriptions to determine to which asset the data is related, creating not only the instance of the ICE but also the instances of the related asset and its properties and all relevant relations between entities.
Reasoning is an important part of working with ontologies, being a tool during its formalization phase
for logical consistency checking and in its implementation phase for inferencing. For its importance,
we must choose carefully what reasoner to utilize for the domain ontology. In our implementation, we
have utilized the Hermit reasoner, mainly for its overall good performance when working with OBO
ontologies [
Another important choice in regards to reasoning is how to utilize the reasoner during the
implementation phase (that is when a system is utilizing the ontology) as inferencing can change drastically how
the information is presented after instantiation, after all "A reasoner is a program that infers logical
consequences from facts, assertions, and axioms" [
Ontology artifacts described in the RDF language (and derivated languages, like OWL) are represented by triples in the shape “subject-predicate-object”, such that entities are represented in subjects and objects, while predicates are relations between entities. This structural characteristic resulted in using purpose-built databases, namely triple-stores (extended to quad-stores for working with named graphs), to store ontological definitions. These purpose-built databases are not only for storage but also for the retrieval of triples through semantic queries, normally utilizing SPARQL3 as their query language.
Once the instances have been created and the reasoner’s inferences have been materialized, the ontology is ready to be used. Doing so requires retrieving the triples described in the ontological artifact, either using local files and APIs or through a semantic query language and an available endpoint.
One option is developing a specific API providing a list of methods for certain types of semantic queries (e.g., retrieving the class that a given individual instantiates, all individuals linked via a given relation). Based on that, other services would consume such methods when needing to retrieve information. This approach has the advantage of establishing a clear separation of concerns between the diferent services of the system. It shields a front-end service from the technological details of how the model is implemented and queried, thus preventing changes to the model (like changes to the IRIs of entities) from reflecting in changes to the front-end.
For applications that require simple queries on their knowledge base, an API with a small and easily learned set of methods for semantic query would be enough. However, this approach would lead to dificulties if the application requires numerous and complex queries. An API with a large list of methods covering all required semantic queries would result in a hard-to-maintain implementation. An alternative would be sticking with a small API with a simple, basic set of methods that could be algorithmically combined to retrieve data that would only be retrievable via more complex queries. The downside of this approach is that the meaning of the query would be implicit in the algorithms that combine the API’s methods. In addition, dynamic scenarios in which new functionalities are constantly being added would require constant expansion of the API, worsening the mentioned problems. With that, instead of a formal and standard method of expressing and processing queries, we would have ad hoc algorithmic solutions, which compromise their understandability, the evaluation of their correctness, and their overall maintainability.
In contrast, the direct use of SPARQL serves two purposes: being standardized enough to work on several possible storage implementations and being flexible enough to allow the service to choose how it wants the data to be presented. Furthermore, the abundance of reference material on SPARQL creates an easier environment for understanding and long-term service maintenance.
Even though triple-stores are very eficient databases that expose an endpoint for semantic querying, some environments may impose restrictions on their use, be it for enterprise norms or very strict architectural styles. In this situation it is still possible to create an architecture agnostic to the storage method of the ontological artifact by using SPARQL. This query language is supported by most triplestores and by many APIs, enabling the creation of a self-implemented endpoint (one such implementation is discussed in section 4).
When working with SPARQL, the service that needs the data must first know what it needs. The
service may always know this or may result from interaction with another service or the user. The
application Ontology Explorer described by [
By making a query with the knowledge known by the service, it is possible to present the asset information to the user, who, by navigating such information, will present to the system what information he/she needs, generating a new query. In terms of implementation, this means having some queries ready to retrieve the base amount of information the service knows it will need and various “template queries” with certain gaps to retrieve information the service might need when the gaps are filled.
The infrastructure we used to deploy the application prototype consists of a cluster of 16 computers, 9 of which are servers connected to the internal network of the UFRGS Informatics Institute. The prototype is a web application with a microservices architecture. This software design pattern structures an application as a collection of small, low-coupling, and independently deployable services. Each microservice is responsible for specific and well-defined functionality, with communication being carried out via lightweight protocols, usually HTTP or message queues like MQTT. This approach contrasts with monolithic architectures, where an application is created as a single, cohesive unit. Microservices ofer several advantages over monolithic architectures: • Scalability: Each microservice can be scaled independently, allowing more eficient use of resources and better management of variable workloads. • Flexibility: Teams can develop, deploy, and maintain each service independently, allowing faster development cycles and easier integration of new technologies. • Resilience: The failure of a microservice is less likely to afect the entire system, as the services are isolated from each other. • Reuse: Components can be shared and reused in diferent or similar applications, promoting modular design and reducing code duplication.
However, the microservices architecture presents some challenges, such as increased complexity, the need for eficient coordination of microservices, and the possibility of increased communication latency between them. Therefore, it is essential to evaluate the most appropriate way to implement this type of architecture according to the application’s requirements. We used the Docker Engine 4 containerization technology to deploy the application components, which is responsible for packaging software artifacts and their dependencies in containers, i.e., portable units that can run consistently in diferent computing environments. Unlike virtual machines, containers share the kernel and libraries of the host operating system, resulting in lower resource usage and faster start-up times. For this reason, using containers has become common practice in software development and distribution, especially in microservice architectures, where each service can be packaged and deployed as a separate container. This practice reduces the complexity of deploying the application and allows for a more appropriate sizing of the necessary resources.
The Kubernetes 5 platform is responsible for managing the execution of the deployed containers on the provisioned computing infrastructure. Kubernetes is an open-source container orchestration platform - maintained by the Cloud Native Computing Foundation (CNCF) - that automates container deployment, sizing, and management in distributed computing environments. The platform aims to make it more flexible to manage workloads distributed across several nodes, which can be physical or virtual machines in a cloud or on-premise environment. In Kubernetes, the smallest and most basic deployment unit is called a Pod, representing a single instance of a process running in the cluster. A Pod encapsulates one or more containers, storage resources, a unique IP address, and other configuration options.
The application’s front end consists of a single container that exposes a web application developed
in JavaScript with the React6 library. This component, called Data Explorer, allows users to access a
graphical interface for building and visualizing dashboards for analyzing production data (time series)
collected from the historian system, using a domain ontology as a guide for navigating through the
modeled physical plant. A more detailed front-end description is published at [
On the other hand, the Knowledge Base service is directly consumed only by the Data Hub. It creates an in-memory triplestore from the ontology’s OWL file retrieved from an external repository like Git. The prototype’s knowledge base is materialized as a knowledge graph, which includes the O3PO classes, other imported ontologies, and the instances corresponding to the domain entities. A reasoning tool generates this graph and performs logical inferences about the instances, then exported as a single RDF ifle. Finally, we use the RDFLib 10 package to import the RDF file, which allows access to the knowledge base via SPARQL queries on the graph, as can be seen in Figure 4.1. Consequently, the Knowledge Base service exposes a SPARQL endpoint to query the semantic structure of the knowledge base generated from the ontology and retrieve the material entities and the informational entities (tags) associated with the instances of the material entities included in the ontology.
Given the tags retrieved by SPARQL queries on the Knowledge Base, the time series data can be obtained through the data provider endpoints, as seen in Figure 4.1. In our deployment, these endpoints are from the WEB API, but they can be from other historian systems providing sensor data or even from more complex data platforms like the OSDU11. 4.1.3. Storage We used two services for data storage: MongoDB12 and Redis13. MongoDB is a document-oriented database that stores user profiles, configurations, and annotations associated with the dashboards built into the web application. Redis is a service that makes it possible to create in-memory databases. We 10https://rdflib.dev/ 11https://osduforum.org/ 12https://www.mongodb.com/ 13https://redis.io/ used Redis to cache the time series data retrieved by the data provider endpoints. The aim is to reduce latency in accessing previously retrieved data and reduce the load on the WEP API endpoint with redundant requests.
We used the open-source platform Istio14 to connect, protect, and manage the microservices in a unified way by including reverse proxies (Envoy) alongside the containers that implement the application’s microservices, namely the Data Explorer and the Data Hub and Knowledge Base services. Therefore, each Pod created in the Kubernetes cluster comprises two containers: one for deploying the microservice and the other for intercepting all the requests that arrive or leave the microservice.
The control layer ofered by Istio configures the reverse proxies to keep communication between microservices encrypted with the Transport Layer Security (TLS) security protocol, with Istio acting as the certificate authority for a data layer that uses mutual TLS. In this way, microservices are relieved of having to provide the security layer. They can focus solely on executing their functions. Moreover, Istio allows the implementation of a mesh of microservices with support for a range of features and functionalities to improve the observability, reliability, and security of container-based applications following the distributed computing model. Additionally, we used the Keycloak15 as the Identity And Access Management (IAM) tool to provide OAuth 2.0-based authentication for the application prototype.
In the context of oil and gas, where dealing with large ammounts of complex data is the norm, the idea
of leveraging ontology-based solutions for dealing with correctness and timelyness of data retrieval is
proeminent [
While these focus on the necessary semantic infrastructure, others concern with the diferent ways of
articulating query interfaces and presenting the data properly to user [
This paper discusses a case study on an ontology-based information system developed to provide coherent and contextualized data across various applications within an ofshore petroleum production plant. The system’s architecture is outlined through a description of the components employed in the application.
Future work will expand the description of events and experiment on the temporalization of the model. Additionally, support to real-time data will be added to the application which is a necessity in terms of an efective digital twin.
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).