Semantics of Real Time Signals
Click on the tabs below for more information or click here to return to all D-WIS Workstreams.
Drilling real-time signals are currently accessible through different real-time data sources, including WITS0, WITSML, OPC-DA, OPC-UA, API, etc. With such real-time data sources, the drilling real-time signals either are in predefined positions in records, e.g., WITS0, or are accessible through a mnemonic in a time-based log, e.g., WITSML, or other sort of tag reference, e.g., OPC-DA. To access the correct real-time data channel, one must know beforehand where to find the information, i.e., the mnemonic, tag or position in which record. Furthermore, there is very limited metadata associated with the signal. When metadata information is available, it is in a statically defined format.
In practice, drilling operations are evolving constantly, and the availability of drilling real-time signals changes almost on a daily basis. Therefore, personnel in maintaining support applications for signals, spend much time updating which signals are now available and where to find them. Also, as metadata is very limited, such applications cannot take full advantage of the actual qualities and uncertainties associated with the available signals. In addition, different applications exchange very few calculated signals, simply because it is already cumbersome to connect to measured signals. This in turn reduces the possibility of achieving synergies between the different systems that are monitoring and controlling the drilling process. Finally, it is difficult to create automatic quality control of available drilling real-time signals since connecting them requires a lot of work.
By defining a flexible and generic way to describe the semantic of real-time signal, it is possible address most of these issues – by making available facts about each available signal. These facts describe the meaning of the signal. A potential consumer of the signal can read those facts and determine whether the signal corresponds to its requirement or not. The consumer discovers real-time signals dynamically based on characteristics that are important for its application.
Various consumer applications may have different perspectives on what is a relevant signal for their own functionality, and they can choose dynamically the most relevant available drilling real-time signal. In addition, a consumer application can make available calculated signals that may be of interest for other applications. By providing the semantic of these additional signals, they provide an opportunity for other applications to discover them.
|Semantic RT Signal Requirement
|DWIS will enable the description of the semantics of drilling real-time signals.
|By exposing the semantic of each available signal, it is possible for any application to discover and choose which signal is of interest for its own functionality
|The description of the semantics of drilling real-time signals proposed by DWIS shall be flexible and generic.
|It is important that the solution chosen for describing the semantic of drilling real-time signal can support currently available signals and future signals that are not yet “invented”.
|The description of the semantics of drilling real-time signals shall rely on a very concise method.
|As there are tens of thousands of real-time signals at the rig site, and there can be even more signals that may be made available when calculated signals are also exchanged, it is important that the proposed solution to describe the semantics of real-time signals is not subject to combinatorial explosion.
|The chosen method to provide a semantic description of drilling real-time signals shall support multiple data sources.
|The drilling process involves many different service companies. The constellation of the service companies that are present during the drilling process evolves constantly. Therefore, it is important that the proposed solution is compatible with a very changing environment.
|The introduction of the description of the semantics of drilling real-time signals shall not affect refresh rates, delays, uncertainty, and quality of the actual signals.
|As there are already problems with latency, refresh rates, uncertainty and data quality in general, it is important that the introduction of semantical description does not exacerbate the current situation.
|The semantic description of drilling real-time signals shall be completely agnostic to which programming languages, operating systems or any other computer specificities is used by the data provider or the data consumer.
|The different service providers utilize many different software solutions, including, PLCs, IoT, Servers, handheld computers, etc., running many different types of OS like Windows, Linux, iOS, Android, Step7… and programmed in various languages, e.g., Python, Java, C, C++, C#, … Also, new computer solutions, new OS and new programming languages will arise in the future. It is important that the chosen solution does not block the access to the DWIS interoperability to any of those possibilities.
|The semantic description of drilling real-time signals shall be compatible with the access-control rules implemented in any drilling operations.
|Typically, the proposed solution shall contain an AAA (Authentication, Authorization and Accounting) strategy so that only authorized parties can access the information.
The current method of managing drilling signals across data suppliers and data consumers during drilling operations requires perfectly aligned tag names as well as communication protocols.
It is desirable to develop a plug and play methodology that does not require human interface to match tag names. Using a semantic process, each machine/sensor or other element describes itself (what it is and what it can do) and provides this as real time information. This allows adding and removing devices from a rig network without affecting existing devices.
Furthermore, when a component of the drilling process is measured in different ways, without metadata, it may be difficult to decide upon which of the available signals is the most appropriate for a certain data consumer. For instance, the hook-load may be measured at the dead-line, at the top of the top-drive and with an instrumented saver-sub connected to the top-drive. Each of these measurements have positive and negative aspects and depending on the use, one may be more suitable than the other.
So instead of a mapping of signal tags, it would be more convenient to query signals based on their characteristics or properties and make informed decisions for listening to one signal instead of another.
Also, nowadays, mostly measurements are made accessible to other parties. But as there are more and more external advisor systems that runs at the rig site, there is also a potential benefit for all parties that processed signals are made available for external systems. In that eventuality, there is quickly an inflation of number of real-time signals that are available at the rig site. Many of these signals may concern the same component of the drilling system, yet they may represent very different type of signals, e.g., one could be the max hook-load to detect an overpull, another could be an estimated hook-load based on the current mechanical friction and drilling parameters, etc. So without proper semantic description of the real-time signals, the manual mapping of signals tags and mnemonics can turn into a very difficult task also prone to errors.
Also, it is often interesting to know more about the relations between real-time signals. This type of information goes far beyond what is achievable with mnemonics and even metadata at the level of each signals. Returning to the hook-load example, the use of a hook-load measurement based on an instrumented saver-sub or iBOP is necessarily linked to another signal that indicates whether the top-drive is connected to the drill-string or not.
The primary objective of the workstream is to provide the industry a method that allows computer systems from different parties to exchange drilling real-time signals seamlessly without the need for human configuration or intervention.
A secondary objective is to define an industry accepted vocabulary for describing the meaning of drilling real-time signals by a software program. Associated with this vocabulary are validation rules that ensure the consistency of facts expressed with this vocabulary.
Another secondary objective is to provide to the industry example implementations of the seamless interoperability communication of real-time signals. This reference implementation utilizes different levels of complexity, from a simple method based on OPC UA, to more advanced method using semantic modelling technologies.
To address the problem of the inflation of signals made available at the rig site and the variable availability of those signals during a drilling operation, it is proposed to describe the meaning of real-time signals in a computer readable format.
The method chosen to describe the meaning of real-time signals is based on semantic networks. A semantic network is collection of facts that are true for a particular signal. A fact is expressed as a triplet [subject, relation, object]. The subject of one fact can be the subject of another fact or the object of yet another statement and similarly with objects. Therefore these facts can be assembled as directed graph. This is why the method is called "semantic network". Subjects and objects are vertices on the graph while relations are edges.
The description of the meaning of a signal is therefore simple: just collect all the known facts about that signal. Yet, it is necessary to define a vocabulary that can be used to expressed those facts. The vocabulary is composed of nouns that can be used as subjects or objects, depending on their position in a triplet, and verbs that represent the relations between subjects and objects. A specific vocabulary to describe drilling signals is being developed as part of D-WIS.
A semantic network can be supplemented with rules. Such rules may be used to put some semantic limits on facts as some combination of [subject, relation, object] may not make any sense even though they use valid nouns and verbs. These rules may be about restrictions for relations between types of subjects and objects. They can also be about the cardinality of relationships between subjects and objects and specific relations.
Logical inferencing can also be used to supplement with facts that have not been declared explicitly but which are be logically inferred from existing facts. A typical inference is the transitivity of relationships, e.g., If A R B and B R C then A R C where A, B and C are nouns and R is a relation.
Semantic networks can also support semantic queries, i.e., queries about the relations between different edges in the semantic graph. Semantic queries offer a powerful mechanism to retrieve information based on their meaning and not solely on their denomination. With semantic queries it is possible to discover what is available not having to know whether what we look for exists or not.
To be completed later.
To describe the meaning of a signal, we need to collect facts about that signal. Facts are expressed as triplets <Subject, Verb, Object> where Subject and Object are nouns. The verb relates the Subject to the Object. As a subject can be the object of another fact and vice versa an object can be the subject of yet another fact, these facts can be represented as a directed graph where the relations or verbs are the edges of the graph and the nouns are the vertices or nodes of the graph.
Nouns and verbs can be categorized, meaning that they can be organized in a specialization/generalization hierarchy. For instance, "physical quantity" is a generalization of "base physical quantity" and "derived physical quantity" is a specialization of "physical quantity". Furthermore, "Pressure quantity" is a specialization of "derived physical quantity". A specialization, or in other word a sub-class, has all the properties of its parent class but has in addition some supplementary or more restricted properties.
An instance of a class, is a specific object that belongs to this class. A relation between an instance and its class is typically denoted "a kind of". We can write for instance: <Signal #1, is a kind of, Signal> meaning that "Signal #1" is an instance of the class "Signal".
Similarly, relations can be categorized in generalization/specialization hierarchies. "Has a" is a fairly general relation while "Has physical quantity" is a much more specialized relation. An example of fact can therefore be: <Signal #4, Has physical quantity, Pressure quantity #1>.
The value of some measurement may be defined relatively to another measurement. This is the case of pressure as it can be defined relatively to for instance the atmospheric pressure. This fact can be described by the following triplet <Signal #4, Is referenced to, Atmospheric Pressure> and as "Atmospheric pressure" has a physical quantity "Pressure quantity", we obtain the following semantic graph:
With regards to pressure, it is important to know the vertical elevation of the measurement in order to relate to the hydrostatic component of pressure. In practice that means that pressure values depend on the vertical elevation of the sensor relative to the position by which pressure is atmospheric. This fact can be expressed by using a "depends on" relation.
A semantic graph is a collection of facts expressed as triplets <Subject, Verb, Object>, where Subject and Object are nouns. However, not all facts are acceptable. For instance, it may not make sense to relate with the relation "belongs to" two nouns like <Formation Rock #1, belongs to, Mud pump #1>. To avoid writing meaningless facts, validation rules can be added. Validation rules can be about restrictions about the subjects and objects of a relation. They can also be about the cardinality of some facts. For instance, it may be possible to state that if a relation is true then another relation cannot be true at the same time. An example could be <Trajectory #1, is the higher TVD bound, Wellbore position uncertainty #1>, then the fact <Trajectory#1, is the lowest TVD bound, Wellbore position uncertainty #1> cannot exist simultaneously. In many cases, validation rules may not be able to point directly which fact is erroneous but that a collection of fact cannot coexist at the same time without violating one or several validation rules.
A semantic graph contains the basic facts related to the signals that are intended to be described. A third party application that wants to discover the meaning of the available signals would need to download and parse a large portion of the overall semantic graph, which can be time and memory expansive as well as a source of possible inconsistencies as the semantic graph is continuously updated.
Alternatively, it is possible to ask the server-side that maintains the semantic graph to do the interpretation. This is done by posting semantic queries. A semantic query is a sentence formulated as a question that asks for nodes in the semantic graph that have particular properties.
By using semantic queries to access drilling real-time signals, it is possible to keep the access to signals to be indirect. In this way, the focus is on the characteristics of the signals not on their denominations.
But sometime semantic queries could return incomplete results if some facts are missing in the semantic network therefore prohibiting to find a logical path between for instance a signal and some characteristics. Typically, some relations have a symmetric relation like for instance "belongs to" and "contains" and if one of the two relations is present but the semantic query searches in the opposite direction, then some links between facts may be missed by the semantic query. To avoid this problem inferences are used. Logical inferences supplement missing facts that are logically deductible from the original set of facts. This can be symmetric relations as mentioned above or the transitivity of relations, e.g., A R B & B R C => A R C where A, B, C are nouns and R is a verb or relation. Also, the relation hierarchy can be utilized during inferences. If R1 is a specialization of R2, then if the fact A R1 B, then A R2 B is also true, where and A and B are nouns.
The work undertaken in this workstream consists in defining and expanding the vocabulary used to write the semantic of drilling real-time signals and to illustrate the use of this vocabulary by examples.
The vocabulary needs to be listed but also definitions need to be provided. Markdown files that contain the different words used in the semantic language are maintain on the D-WIS github repository found here.
It is also necessary to define semantic rules that restrain the use of the vocabulary to combinations that makes sense.
To facilitate learning the principles of semantic graphs and their usage, examples of semantic queries are also gathered.
Cayeux, Eric, Daireaux, Benoît, Saadallah, Nejm et al. 2019. "Toward Seamless Interoperability Between Real-Time Drilling Management and Control Applications." Proc., SPE/IADC International Drilling Conference and Exhibition. https://doi.org/10.2118/194110-MS.
Cayeux, Eric, Damski, Carlos, Macpherson, John, Laing, Moray, Annaiyappa, Pradeep, Harbidge, Philip, Edwards, Michael, and Jonathan Carney. "A Framework to Capture the Relationships in Drilling Data and the Propagation of Uncertainty." Paper presented at the IADC/SPE International Drilling Conference and Exhibition, Galveston, Texas, USA, March 2022. https://doi.org/10.2118/208754-MS
Cayeux, E., Damski, C., Macpherson, J., Laing, M., Annaiyappa, P., Harbidge, P., Edwards, M., and J. Carney. "Connecting Multilayer Semantic Networks to Data Lakes: The Representation of Data Uncertainty and Quality." SPE Drill & Compl (2022;): doi: https://doi.org/10.2118/208754-PA
This work is the result of the fruitful cooperation of many contributors including (in alphabetic order):
- Pradeep Annaiyappa, Nabors
- Jonathan Carney, Schlumberger
- Eric Cayeux, NORCE
- Benoît Daireaux, NORCE
- Dmitriy Dashevskiy, Baker Hughes
- Alberto Dellabianca, NOV
- Michael Edwards, Edwards Energy Innovation Consulting LLC
- Darryl Fett, TotalEnergies
- Fred Florence, RigOps
- Shane Hansen, NOV
- Mark Jenkins, Baker Hughes
- Patrick Johnston, Kongsberg Digital
- Moray Laing, Halliburton
- Ross Lowdon, Schlumberger
- John Macpherson, Baker Hughes
- Roger Marin, Halliburton
- Espen Solbu, NOV
- Shashi Talya, Halliburton
- Tim Wiemers, Shell
- Tim Williamson, NOV
- Nathan Zenero, TeraData