Virtual Views and Asset Models Primer (version 23)

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 the option to alias tags within the Canary Historian multiple times, providing clients specific Virtual Views of the historian archive that can be custom-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 straightforward 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, or dot, 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 water main.  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 current example, 'Boilers', 'Fillers', and 'WaterMain' assets are all linked based on the 'Line' instance they are found.  Associating these 'child' assets to the 'parent' line instance is a common practice and is not limited to just a few branches.  For instance, 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 by increasing the unique identifier, in this case numeric, 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 a '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 cost 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 laymen'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 from 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 and then deploy it for all asset instances.

Constant I/O Reassignments

Within testing and quality control use cases, it is not uncommon for I/O to be linked to different tag names for the duration of each test.  When this happens, the admin must waste unnecessary tag licenses to provide a unique tag name each time a new test is administered, or lose the ability to associate the I/O with a unique name for the duration of the test.  

Virtual Views solves this problem by allowing the I/O to be aliased. Each time a new test is run, a new Virtual View is created and named in a way that links it to that test.  As time passes, these previous Virtual Views can still be recalled, and the data that is represented within them will still be associated with the proper tag name.  The client simply needs a time reference for when the test was administered.  

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 Views security permissions based on entire Virtual Views, specific users or usergroups can easily be given only access to specific 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.