ON THIS PAGE:
Where an entity defines a real world or conceptual object, it is the attributes of an entity that describe the characteristics of that object. It’s these characteristics, or attributes, that are associated with data that we generally want to model.
For example, an organisation may have a number of wells. Each well has a number of characteristics, such as THP and Choke. These characteristics are called attributes, and they are generally the thing that we are interested in finding detailed information about so that we can optimise production.
We can then break these attributes down even further to gain an insight into different aspects of that type of data.
For example, if we look at an attribute such as Flow Rate, we may have a number of different sources of this same data, such as Actual Value (from a historian), Theoretical Value (from a simulation), and Planned Value (from a forecasting system). Each of these attribute values can be associated with that attribute, creating a much more diverse view of your data.
The most common use of attribute values is to assign historian tags to the values. This allows us to create an asset model, where the users no longer need to remember long and complicated tag names. We can also store things like calculations, strings, and numbers to attribute values.
Let’s go up a level and look at how a list of attributes can be organised.
A well will have many attributes, and trying to find your data item in a list of 100 items is a difficult thing. We can now group these attributes in a way that makes sense so that we have an organised list. This grouping is known as attribute groups in IFS OI Server. We use attribute groups for asset modelling, so that attributes related to, say, Operating Data, can be grouped together. This presents a more organised display in applications such as IFS OI Explorer.
This is what an asset model looks like in a trend in IFS OI Explorer:
Note that in common usage the meaning of attribute may change, depending on our frame of reference:
- When we are generally talking about an attribute, then we are normally referring to the attribute definition.
- When we talk about an attribute in reference to a value it may display, then we are normally referring to the attribute value.
Now let’s get a bit more technical and look in more detail at how attributes are actually structured within the system.
Setting up an attribute consists of 4 parts, and it is assumed that at this point you have already created the Template Definition.
Attribute Group
Attributes are grouped into attribute groups. This is the recommended way of grouping attributes, instead of grouping them by defining multiple templates as was done in the past.
Here is an example of a set of attribute groups:
| Name | Description |
| Operating Data | The entity’s Operational Data attributes |
| Operating Status | The entity’s Status attributes |
| Production Data | The entity’s Production data |
| Lab Test Results | The entity’s Lab testing results |
This grouping allows us to take a very long list of attributes of a single template, and split them up into different, logical sections that allow users to more easily find the data items that they are looking for.
When setting up the system, we define a global set of names for the attribute groups, which can then be used in different templates. At this stage, we do not define what attributes belong to the group, we only define the common list of group names.
Attribute Definition
The attribute definition defines which attributes are connected to each template. At this point, we are not assigning any data to the attributes, we are just setting up what will be available on a template, and which attribute group the attribute will be under.
When defining the attribute, we are telling the system what type of data will be connected to it (time series or tabular), as well as what template and template group it will belong to.
Here is an example of an attribute definition, with the name of the associated attribute groups and templates:
| Attribute Definition Name | Data Type | Template Definition | Attribute Group | Description |
| THP | TimeSeries | Oil Producing Well | Operating Data | Tubing Head Pressure of an oil well |
| Oil Flowrate | TimeSeries | Oil Producing Well | Production Data | The flow rate of oil from the well |
| THP | TimeSeries | Gas Producing Well | Operating Data | Tubing Head Pressure of a gas well |
| Gas Flowrate | TimeSeries | Gas Producing Well | Production Data | The flow rate of gas from the well |
Attribute Value Definition
In version 4, we have the ability to have another level of structure underneath an attribute. These are known as attribute values.
The attribute value definition defines this sub structure underneath an attribute, and there are 2 important things to know when setting these up.
- We must set one of these attribute values to be the default value. If a data fetch is requested for the Entity:Attribute, and no attribute value has been supplied, then the system will use the default value. This allows the system to run in the same way as it did in previous versions, where attribute values were not available.
- The second important thing to note is how to reference an attribute value, in calculations and the like.
An attribute value is preceded by a ! symbol, so it would be seen like Entity:Attribute!AttributeValue. A real world example would be Well1:Flowrate!Estimated.
Here is an example of an attribute value definition:
| Attribute Definition Name | Attribute Value Definition Name | Description | Is Default |
| THP | Actual | The actual THP Value from the well | TRUE |
| THP | Planned | The planned THP for the well, obtained from the forecasting system | FALSE |
| THP | Theoretical Max | The maximum acceptable THP from the well as obtained from a simulation | FALSE |
| Oil Flowrate | Current Flowrate | The current flow rate of oil from the well | TRUE |
| Oil Flowrate | Daily Avg Flowrate | The daily average flow rate of oil from the well | FALSE |
We are now at a stage where the base data has been set up, and we have defined our structures. The next step in the process it to create a real entity, like a well, and define the real data items that are associated with this well.
Attribute Value
The previous parts of this article have been about setting up the structure that we will be reusing over and over, whereas now we are going to define a real world object.
We have a couple of important things to note here.
- At any point in time, not all attributes on a template need to have values. The most common time that this is seen is when you have a particular object, say a well, that does not have any telemetry for a particular attribute and therefore it can’t be measured, but all of the other wells in your business do. We do not want to create a new template just because this one well has a tiny difference to all of the others, so we can reuse our well template, and just not configure one of the attribute values. Any attributes values that are not configured will not show in applications such as IFS OI Explorer.
- Attribute values are time aware, in that you can define one to be valid for all of time, or only for a specific point in time. The main use of this is when you decided to change the tag that is supplying the value.
Let’s use an example: THP!Actual is assigned to a PI tag, Well1THP. At some point in time, we create a new tag in PI, that has a more accurate calculation and we now want to use this new tag, Well1THP-New from this point forward. We would define that like this:
| Entity | Template Definition | Attribute Definition | Attribute Value Definition | Start Time | End Time | Data Type | Value |
| Hunter | Oil Producing Well | THP | Actual | NULL | 6-Aug-2015 00:00:00 | Tag | Well1THP |
| Hunter | Oil Producing Well | THP | Actual | 6-Aug-2015 00:00:01 | NULL | Tag | Well1THP-New |
Note that a Start Time or End Time of NULL indicates that the attribute applies for all of time for that template instance. This is the most common start and end time for attributes.
Here is another example with multiple attribute values for a single entity:
| Entity | Template Definition | Attribute Definition | Attribute Value Definition | Start Time | End Time | Data Type | Value |
| Wilga | Gas Producing Well | THP | Actual | NULL | NULL | Tag | 10TI120.PV |
| Wilga | Gas Producing Well | THP | Min | NULL | NULL | Tag | 04PC736.PV |
| Wilga | Gas Producing Well | THP | Max | NULL | NULL | Decimal | 100 |
| Wilga | Gas Producing Well | Well Params | Initial Date | NULL | NULL | DateTime | 1-Aug-2015 |
| Wilga | Gas Producing Well | Well Params | Well Code | NULL | NULL | String | API32235 |
Attributes are displayed in consuming applications such as IFS OI Explorer, for use in pages and trends.
Asset Modelling: Pulling It All Together
Asset modelling makes use of hierarchies, entities, templates, and attributes to give you a relevant “big picture” of your entire system.
Here is an example of bringing all of this together to model an asset:
| Entity Name | Template | Attribute Group | Attributes | Attribute Values |
| Derby | ||||
| Water Injection Well (Primary) | ||||
| Production Data | ||||
| Water Consumption | ||||
| Daily Plan (Default) | ||||
| Daily Production | ||||
| Operating Data | ||||
| Choke | ||||
| Current Position (Default) | ||||
| Differential Pressure | ||||
| Inlet Pressure | ||||
| THP | ||||
| Actual (Default) | ||||
| Theoretical Max | ||||
| Planned | ||||
| Operating Status | ||||
| Hrs Online | ||||
| Day (Default) | ||||
| Week |
What this asset model looks like in a trend in IFS OI Explorer:
What the asset model looks like when configuring a tag (time series) dataset in IFS OI Explorer:
