The Parameters feature in the Visual KPI Designer unlocks a lot of power and enables the following:
- Allows you to combine data from multiple data sources, including with calculation, into a single vale (e.g. actual, target, limits)
- Allows you to define more complex or nested functions to be performed on-the-fly (e.g. use the results of 3 different calculations from separate data sources in another calculation as your target)
- Enables you to get data from external sources for use in making other attributes dynamic (e.g. get the current grade of product running in this machine from a data source and make it the attribute for this KPI. Every time it changes in the data source, change the attribute in Visual KPI on the fly.
- A whole bunch of other cool stuff
Before we get into it here, please note you can contact us anytime to go through this (or any other) feature with our support team.
OK, let’s take a look at how parameters are defined in the Visual KPI Designer and how they work.
Adding values and interfaces
The usual way to return data from a source is to call the Interface and an associated tag or set of parameters. In the Visual KPI Designer, you select the Interface you want from a pull-down menu. Interfaces are added to the system in the Visual KPI Server Manager (more about interfaces here).
For example, if you’re setting up Actual and Target values for a KPI, you can return values from an interface. You can even perform a calculation on the returned value, and the final result is what users will see on your Visual KPI site (examples below use tags like cdt158 from an OSIsoft PI System (PIRDA)).
You have always been able to use multiple data sources in a KPI but you were limited to using only one data source per attribute/column (e.g. actual from 1 source; target from another, etc.). With parameters, this is no longer a limitation.
Using multiple data sources via parameters
Using parameters, you can return values from multiple data sources. You can set up to 10 parameters for each KPI. For each parameter, enter a value (or function) and an Interface. For example, you could return the current temperature in San Francisco from one data source, and return the temperature in Oakland from a separate data source. Or you could call market prices from a variety of data sources.
You can also perform calculations on parameters. For example, you could use a calculation to return the average temperature in San Francisco for 1 week. In the example above, you can see that Parameter 3 calls the same data source as Parameter 2 but instead of just returning the value from the source, it divides that value by 3.
Using parameters as inputs for other fields
Parameters can be used in many other fields and in other calculations. Users of your Visual KPI site don’t actually see the values returned as parameters. What they see are the values returned from other fields. You use parameters to return data from multiple data sources to come up with a value that you want to be displayed in a Visual KPI site.
Once you’ve set up parameters (up to 10), you can then use the values returned from any of those parameters to populate an attribute field or in a calculation to return a new KPI value. In the temperature example, you could calculate the average of temperature in the San Francisco Bay area and set this as the Actual value in your Visual KPI site.
Parameter 1=actual temperature in San Francisco
Parameter 2=actual temperature in Oakland
Average temperature = <((P1) + (P2)) /2>
Using the market price example, the Actual Price displayed in your Visual KPI site would be an average of the market prices from three data sources.
The actual value returned is the result of multiple calculations or multiple steps.
Note: When you use a parameter calculation for a field, leave the Interface field empty. Because your final value is coming from the parameters, which could represent several data sources (and it will most likely fail).
Parameters can be used in many ways, and can be as simple or complex as you want. You can use calculations in the parameters field and then use the final parameter value in another calculation as input for another KPI attribute.
Let’s look at an example from an oil refinery. As in many industries, sometimes we have products that run in batches at random times. In this example, we have different types of petrol run in batches: unleaded and premium unleaded.
If we wanted to do some comparisons of these batches, regardless of the time run, we could use offset time ranges to compare batches against like batches. We could use P1 to get the start time of batch 1, and P2 could be the start time of batch 2. Then we could use those P1 and P2 values in a calculation.
Or let’s say we want to use P1 as an attribute for a KPI to tell us what grade of oil is running currently in a unit. If P1 is set to retrieve the current grade from a data source in the example below, the attribute will change as the data in the source does, which serves to automate the system in many ways. For example, I might have a group of KPIs that is called ‘unleaded’ and is set to only show KPIs where Unit Type = Unleaded. As this attribute changes, this KPI will dynamically move in and out of that group on the fly.
Again, this is a pretty powerful feature with a lot of cool uses we don’t have time to describe here. Contact us on the web or send an email to firstname.lastname@example.org if you want us to show you around.