Virtual Views and Asset Models Primer (version 25)

The Views service allows the system administrator to add context to the Canary Historian archive. This additional level of insight can be created by supplementing the existing historical tag record with virtualized views of the tag names, tag structure, and by grouping tags by the assets they represent. Multiple versions of these virtualized views, aptly named Virtual Views within the Canary System, may be created and do not require additional tag licenses. As new tags are logged to DataSets, Virtual Views automatically rebuild and, in the process, discover the new tags integrating them into the Virtual View.

Why Use Virtual Views?

When clients query data from the Canary Historian, they do so by requesting data from the Views service. Since the Views service single-handedly determines which tags the client has access to, it can also be configured to adjust how the client sees those tags, both in structure, as well as in naming convention.

Avoid Control System or Device Tag Name Changes

Renaming tags at the device level will inheritably cause additional work within the control system. Renaming tags in a control system is risky and time consuming (expensive). Plus, it will likely cause additional work to link tags in reports to their new tag name.  

Aliasing Tag Names

This ability allows system administrators to alias tags within the Canary Historian multiple times, providing clients specific Virtual Views of the Historian archive that can be tailored to the needs of the client. 

For instance, as we study the table below, we may struggle to understand what each tag name references within an operation. 

However if we could alias those complex tag names with a more readable naming convention, it could be helpful for certain data consumers.

When tags are logged to the Canary Historian, tag structure and tag names should remain constant. Meaning, to preserve the historical record, a tag name should never change once logging has begun. Changing a tag name at logging would split the historical record between two tags and consume additional tag licensing. Virtual Views allows system administrators the option to alias tags in the Historian for the benefit of client interaction with the tags without effecting the tag name that is logged to the Historian.

The benefit of creating tag aliases is two fold:

1. Clients have better organized tag names and/or more meaningful tag names without permanently effecting either the historical record or the number of tag licenses consumed. 
2. Tags are massaged into a unified name space which lends itself to grouping tags into the assets they represent.

Creating Asset Models

To illustrate how tags can be broken into assets, consider our aliased tags and their new structure.  Notice that a period is used to section the tag name into three parts.  Asset models that are applied to Virtual Views rely on this artificial structure, or tag naming hierarchy. 

In this example, the first section of the tag name represents to which Line instance the tag belongs. The second section of the tag name affiliates it with either a Boiler, Filler, or WaterMain. Finally, the third section of the tag name describes the sensor or I/O that is being measured.

If two tags were named 'Line1.Production_YTD' and 'Line1.Alarm' these tags would be associated with a 'Line' asset type but would not be associated with an additional piece of equipment.

Parent Child Structure

Often it is necessary to link assets to other assets. For instance, in the previous example, Boilers, Fillers, and WaterMain assets are all linked based on the Line instance they are found in. Associating these child assets to the parent 'Line' instance is a common practice and is not limited to just a few branches. The following examples would potentially account for multiple levels of organizational structure:

YellowBirdCola.SouthWest.Austin.WestPlant.Line4.Boiler002.Pressure

This example links the pressure tag to six different nested asset types:

1. The second Boiler instance
2. On the fourth Line
3. In the western section of the Plant asset type
4. Located in Austin, asset type City
5. Within the southwest Region
6. Associated with the YellowBird Cola Company 'Business Unit'

Multiple Instances of an Asset Type

Additionally, if there were multiple lines, or multiple instances of boiler or filler, these could be easily identified by several methodologies. The simplest would be increasing the unique identifier numerically, by one. 

For example, as you can see below, the unified naming structure has continued to be applied with the duplicate instances of a boiler and filler each represented by the number 002. 

All tag names are still unique, and if an asset model were applied, two instances of the Boiler asset type would be discovered; one named Boiler001 and another named Boiler002. Both Boiler asset types would be comprised of three tags, [Pressure], [SteamOut], and [Temperature].

Likewise, two Filler asset types would also be present, one named Filler001 and the other Filler002. A Filler would be comprised of five different tags: [Power], [Flow], [Fault], [Out_BottleCount], and [Out_BottleRejected].

Problems Virtual Views Can Solve

Inconsistent or Cryptic Tag Naming

Tag naming conventions can be difficult to enforce and take large amounts of time to fix. Additionally, to be effective, most tag names contain a lot device information encoded into their naming structure.  Very few individuals within a large organization truly understand these naming conventions. Using a Virtual View to unify the name space and reduce tag names to layman's terms can be done in a matter of hours. Best of all, they can easily be modified as the needs of the operation change over time. 

Enterprise Level Reporting

Multiple operations or sites within a large organization often have unique tag naming conventions. This creates problems when enterprise level engineers want to compare tag values across multiple sites. Virtual Views can be deployed on an enterprise Historian and unify tag naming structure without impacting local site operations. Asset models also drastically cut time in building reports as you can format the report once then deploy it for all asset instances.

Restricting Data Access

Virtual Views can be created specifically for clients based on the DataSets and tags they need access to. With the ability to set security permissions on individual Virtual Views, specific users or groups can easily be given access to certain Virtual Views while being restricted from all other data within the Canary Historian. 

This is ideal for contractors or other third-parties that require access to some data but should not be able to see other data groupings. Again, this can also be useful for C-level or business unit team members that require data access for production tags but would be encumbered by having to navigate through thousands of other process values.

Condition Based Monitoring

Previously we used the parent-child example of the following tag:

YellowBirdCola.SouthWest.Austin.WestPlant.Line4.Boiler002.Pressure

If you recall, this example links the pressure tag to six different nested asset types - BusinessUnit.Region.City.Plant.Line.Boiler.Tag

Using this example, imagine the power if the client could easily request and visualize any of the following:

• "Show yesterday's min/max/average pressure for all boilers in the SouthWest region."
• "In West Plant, what boilers currently are over 220 degrees?"
• "When is the last time a boiler pressure within the entire YellowBird Cola business unit was the same value for more than 5 minutes?"

Complex Data Queries

By grouping tags into assets, it is easier to understand the relationship of one tag to another. This can become very useful when constructing complex queries. For instance, if a boiler has four tags, [Status], [Pressure], [Temperature], and [SteamProduction], it would be easy to create a table of all Boilers that match the following data query:

[Status] is TRUE, [Pressure] is less than 35, [Temperature] is greater than 220, and current [SteamProduction] for this hour is less than 10% of the [SteamProduction] from the previous hour.