Multiple event types for WITSML sources
Last updated
Was this helpful?
Last updated
Was this helpful?
For WITSML protocol sources, there is an option to add tags in the Event Type field to parameterize the output event type generated by the LiveRig Collector data flow.
In a common scenario, a LiveRig Collector source (for any protocol) will produce only one event type in INTELIE Live. But WITSML protocol has a built-in data structure for well, wellbores, object type and index type. Then, LiveRig Collector enables the user to mark how to build the effective event type name based on such structure.
\
In this way, the user can dynamically filter through information using the Event Type field so that the same data source can be automatically partitioned into different collections. That is also a simple way to split the origin data flow in multiple storage datasets.
NOTE: the word Tag is still used to avoid breaking the compatibility with previous versions but we understand it is not the best match to the feature semantics. To make it clear: this is not related in any sense to OPC tags.
Adding tags in the event type field of an existing source.
Available tags
In this example we will add the following tags: {well-uid}, {object-type} and {object-uid}, in the image below, the result of the event type field.
It’s important to note that only the tags described in this guide exist. It’s not possible to create new tags, so, creating a name within {} will be just another textual information and not a tag.
After saving the new source settings in the LiveRig Collector application, we can see the changes in Live application.
When selecting the modified source in the collectors window, the following result will be displayed.
In this step, we will use the Live console to filter some events using the tags.
We can see in the image above that the __types bring in their value the translation of the tags, example:
NS01{well-uid}{object-type}{object-uid}
raw_ns01 well_uid_1 log log_uid_1
raw_ns01 well_uid_1 log log_uid_2
We can add a specific filter for each event, for example:
In the LIVERIG_METADATA field, when we add tags to the event type of a collector, a new field is added, parsed_event_type, which has the name translated from the tags with the event values, whereas the rig_name field has the original name, that is, with the tags added.
Using an event type with tags, we can create filters for an asset, generalizing or specifying a pipe filter, example: ****In the image below, was created a RIG, the RT13, with a specific filter: raw_ns01well_uid_1loglog_uid_1
We can see the data coming through the channels not configured with the information from the tags:
This guide demonstrates the new functionality of adding tags to the Rig Collector event type field. We see that this way we can create filters more dynamically, below some examples of use.
NS01{well-uid}{object-type}{object-uid} -> Distinct information **** NS01{well-uid}{well-uid}{object-uid} -> Repeated information **** NS01{well-uid}trajectory{object-uid} -> Fixed information **** NS01_{well-uid}_{object-type}_{object-uid} -> Distinct information separating by underline
