Overview – Tags

In the OAS platform, a Tag is the fundamental representation of a unit of data. At the most basic level, a Tag consists of a TagName, a Value, a Timestamp and a Quality.

The TagName parameter stores the name of the tag, including the Tag Group (see the Tag Groups section).

The Value parameter holds the last known state – we’ll look at data types and sources shortly.

The Timestamp parameter holds the timestamp of when the Tag’s value parameter was last updated.

Finally, the Quality parameter tells us whether the last know value is available and valid. The quality parameter is important when dealing with issues like incompatible data types, unreliable network connections and invalid values. When such issues are detected and the quality is “bad” we can use different strategies to deal with such issues. For example, we could do nothing, or we could tell OAS to hold the last known value and hide the fact that the quality is bad, or we could fall back to a default value.

Tag Parameters

It is important to understand that a Tag is actually a structure consisting of hundreds of parameters relating to the unit of data being measured and the enabled features. We’ve just introduced four of those parameters, but there are literally hundreds of parameters that can be accessed for each tag. Tag parameters can be grouped into roughly the following categories:

  • Configuration
  • Data (such as Value, Timetsamp and Quality)
  • Counters
  • Alarms
    • DigitalAlarm
    • HighAlarm
    • HighHighAlarm
    • LowAlarm
    • LowLowAlarm
    • ROCAlarm

Some of the parameters are specific to certain features available in your license. For example, alarm parameters will not be used if you do not have any of the alarm features enabled in your license.

👉 For a full listing of tag parameters see: Tag Variables 🔗

Tag Groups

You can use Tag Groups to help organize your Tags into a hierarchical structure. You can think of Tag Groups like files and folders in your operating system, where the folders are the Tag Groups and the files are your Tags. This allows you to organize your Tags in a way that models your physical assets, devices and sensors. For example, you could group your Tags by site or location and then further group them by devices, sensors or function. It is really up to you how you want to model your data.

In a file system structure you would use file paths to refer to individual files – for example /home/user/my_file. OAS uses a similar approach – to reference a Tag you will use what is called a tag path. Below are some examples of tag paths based on the above diagram:

  • MyTag6.Value
  • TagGroup1.MyTag2.Value
  • TagGroup2.NestedTagGroup.MyTag3.Value

You can see that in the last part of the tag path we used the keyword Value. This is because simply referring to a tag path without a parameter at the end is not a valid tag path. A full tag path must contain the tag groups (if any), the tag name and the parameter that you wish to read/write.

Data Type

The Value parameter of a Tag is what holds the state of the unit of data that the Tag represents – this could be a measurements from a sensor, the state of a switch, a calculation or some other custom data points. How do we know what kind of data is supposed to be stored in the Tag value? How do we know it’s valid? To allow OAS to determine this, each Tag must also have a Data Type. Just like variables have a Type in most programming languages, Tags must also be configured with the correct data type.

Specifying the data type has two important functions – to validate the Tag value and to automatically convert values where possible. By setting the data type of a Tag you are telling OAS what your expectations are of what kinds of data are allowed to be stored in the Tag value. For example, a Boolean data type expects values to be True or False. However, what if the source is an integer? This is where the data type also provides data type conversion if required. For example, if the data type is Boolean and an integer value is written to the Tag, OAS will convert a zero (0) value to False and any non-zero value to True. It will do this automatically and the quality of the Tag will remain in a Good Quality state.

However, in other cases, if OAS can’t automatically convert a value, because it does not match the correct type, then OAS will set the quality of the Tag to Bad Quality. This is important because it allows you to take appropriate action (such as using the Source When Bad parameter to handle this case) or logic in your own custom application. For example, trying to write a floating point number to a Boolean type is not valid.

There are a number of supported data types in OAS including Boolean, Integral, Floating-point, Array, String, JSON and Object types. The following diagrams provides a visual summary of the data types.

Data Source

The most fundamental and powerful feature of the OAS Platform is the ability to source data from a wide range of data sources and make configuration very simple. Some data sources require you to first configure a driver before you can set the data types, whilst other data sources are built-in to the core OAS functionality, such as source data from another tag, creating calculations or creating a simulation.

Each Tag must have a data source configured using the Tag’s DataSource parameter. By default, this parameter is set to the Value data source. This is a standard internal data source that simply means: whatever value you manually write into my Value parameter will be my data source. As long as it does not fail validation based on the defined Data Type, the Tag’s quality will always be Good Quality. When a Tag’s data source is set to the Value data source the Tag will act like a variable that can be updated through any of the OAS clients or API calls.

The following diagram shows the available data types grouped into high level categories including OAS native data source types, drivers, protocols and cloud integrations.


More: