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.

Initial Considerations

Since the Views service is the single access point for all Historian data queries, Virtual Views can be created on top of the underlying Historian archive.  This process allows system administrators to alias tag names, add structure, leverage metadata properties, and ultimately group tags into asset models.

To be successful with Virtual Views, it is important to first consider the following:

1. Firmly understand the methodology behind structuring tag names to group and identify assets.
2. Multiple Virtual Views can be built. One Virtual View does not have to suit all use cases.
3. Virtual Views can be built from multiple underlying DataSets.
4. A Virtual View can be built on top of another Virtual View. For example, one view could establish a unified name space while a second view built upon the first establishes an asset model.
5. Consider how a user wants to report or browse data. This proves a good indicator on how to organize a Virtual View.  For example, you may want to implement views that address some or all of these common model types:
   • Flat Models - If the only desire is to create a table of all known 'Boilers' across the entire organization, spending time on large detailed asset models with multiple levels of asset hierarchy may not be necessary. The model could be very flat and only contain one level.
   • Production Focused - Business units that only care about production values may not need to see process value tags. The model they access should have very limited tags but clearly link production figures to sections of the operation that can then be rolled up into production tags that represent several levels of the operation - perhaps line production statistics roll to section stats, section to plant, plant to district, district to region, and ultimately region to company production numbers.  
   • Deep Models - Some models need to be very complex and deep in their hierarchy, representing multiple levels of parent-child nesting. This allows visibility of how one set of assets impacts others.
   • Maintenance and Preventative Models - If the desire is to incorporate maintenance ticketing systems or enterprise asset management systems, the Virtual View should be constructed to match the existing structure that has already been defined. This can often be accomplished by supplementing the model with metadata properties that are actively pulled from these existing systems. 
   • SCADA/DCS Models - Duplicating the existing data views of a SCADA or DCS system can be useful when providing data queries to staff that are accustomed to interacting with data in that format.
   • No Defined Assets - Some Virtual Views don't use asset modeling at all; they are built to filter out unwanted tags from the browse tree and/or to alias tag names. These views can be very helpful from a data access point of view. Security permissions can be applied to an entire Virtual View and allow for designated users to only access data from the provided Virtual View.

How to Structure Tag Names

If a Virtual View is being built to construct an asset model, it is important to understand how Canary reads tag structure. The goal is to add periods within the tag path that indicate multiple levels of hierarchy and establish asset structure. There are no set limits in place on the number of branches a tag name may contain, thus allowing for very deep models.

Notice in the below example how the tag names in the first column use the period to section the tag into three parts.  

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. As demonstrated, multiple asset types can occupy the same branch or sub node. Finally, the third section of the tag name describes the sensor or I/O metric that is being recorded.

There is no need to separate the asset type and the corresponding asset instances in the tag structure. The following structure would be problematic, "Line.1.Boiler.001.Pressure". Instead, structure the tag as "Line 1.Boiler 001.Pressure", combining the asset type and asset instance inside the same section. 

There is flexibility in tag structure as well. For instance, not all tags need to have the same number of branches. If two tags were added to the above model, each 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. Instead, because the tag name terminates in the second branch, the tags [Production_YTD] and [Alarm] would be linked to the asset type, Line.

Understanding Asset Components

Asset models are built from asset types. Asset types are user defined. They can represent physical assets, geographic areas, or even business units. Once an asset type is defined, the number of occurrences of that asset are referred to as asset instances. 

Above, we demonstrated four asset types, Line, Boiler, Filler, and WaterMain.  There is only a single asset instance of Line currently and it is called Line1. There are two asset instances of the Boiler asset type. They are known as Boiler001 and Boiler002.

Since the asset instances of the Boiler asset type are nested under a Line asset type, we know that Boiler001 and Boiler002 are children of Line1. We also know that Boiler001 and Boiler002 are related to Filler001 and Filler002 in that all four are children to Line1.

Note, we have not established that Boiler001 is related to Filler001 and not to Filler002. In order to do this, the tag names would need to be adjusted. How would the model change using the following tag names?

Based on the above tags, we can derive the following:

1. This model has three levels of asset types. 
2. The first level is Line which has two tags associated with it and three linked asset types: Boiler, WaterMain, and Filler. 
3. WaterMain is represented by two tags and contains no child asset types.
4. Boiler is defined by three tags as well as the Filler asset type.
5. Some Boiler instances have a single Filler (Boiler001) while another Boiler instance has two Filler instances (Boiler002).
6. Filler is defined by five tags and has no child asset types.

An asset instance can also be associated with multiple parent asset types. For example, a single WaterMain instance may need associated with multiple Line asset type instances.

Transforming Tag Names

Often tag names have the existing logic required to transform them into asset models. If tag names are not descriptive or do not contain enough contextual information, tag metadata can be used. Sometimes tag metadata is provided at the point of logging; however, for most organizations, this data lives in other databases. This data can be actively read and added to the Views service if it is held in Microsoft SQL or SQLite.

To utilize metadata properties from an external database, open the Canary Admin client and select the Views tile. Navigate to the Configuration menu at the bottom and select the Settings tab on the left.

The linked database can be configured from the EXTERNAL PROPERTIES section but will require additional table configuration, specifically, the creation of stored procedures within the SQL database as well as the creation of a DataSet table within the SQL database. Canary does not require a fixed table schema. See How to Configure External Property Storage for Populating Metadata in Virtual Views for more details.

In nearly all cases, assistance from the Canary Support Team is necessary for metadata property integration.  

Using Regular Expressions to Alias Tags and Build Models

Since the building of Virtual Views often requires tag names to be transformed based on existing logic found within the names or the metadata linked to the tag, system admins need a fast and efficient way to find, capture, and replace tag names in mass.

Regular Expressions (also called RegEx) allow for rules to be created and applied that achieve the following outcome:

1. The exclusion of tags not useful to the view
2. Capturing useful tag names while excluding or removing useless content
3. The addition of or reordering of tag structure
4. Identifying asset types and their corresponding instances
5. Determining which part of a tag string provides the unique name of an asset instance

Types of RegEx Rules

The above is accomplished by creating rules within the Virtual View.  There are four rule types:

• Model Rules - These rules focus primarily on restructuring and aliasing tag names based on existing tag name logic and any other metadata properties needed.
  • Example - Transforming the tag name 20-BL001-PT-001-PV to be aliased and structured as Line1.Boiler001.SteamOut
• Asset Rules - Identifies asset types within tag name branches and determines how asset instances of those types are named.
  • Example - Identifying the following tag Line1.Boiler001.SteamOut as containing an asset type of Line within the section of the tag name and defining the asset instance of a Line as well as the numeric value that immediately follows Line but not the rest of the tag string, resulting in the asset instance being named Line1.
• Parent/Child Rules - Less commonly used but highly effective for cloning or duplicating an asset that is a child of multiple parent assets.
  • Example - The tag Line1.WaterMain.Volume may also need cloned to represent Line2.WaterMain.Volume if both Line asset types share a single physical WaterMain asset instance.
• Copy Rules - Used to copy a branch of tags from one section of the hierarchy to another.
  • Example - The Boiler assets may need moved to be seen as a top-level asset in addition to a child-asset of the Line.

These rules are configured within the Views Edit screen seen below.

Navigating the View Edit Screen

The table at the top of the screen displays all existing rules and data around those rules including the number of tags MATCHED, any DUPLICATES that were found, the number of unique asset INSTANCES, and the amount of TIME (MS) it took to complete the rule. Additionally, a series of options present as buttons at the bottom of this window.  These buttons allow for the creation, modification, removal, and diagnostics of view rules.

Below the table is a preview of the view's structure based upon the rules that have been applied.

Click here to see how a virtual view is created.