ZOOMS is your search engine for process (trend) data.
Step 1: Go to the home page (using web browser)
Step 2: Input your keywords (hit enter)
Step 3: View the SERP
(SERP is an abbreviation for "Search Engine Results Page.")
This is the way that Google has conditioned the world to find pages of information on the internet and this is the user experience we at Zymergi think ought to be available in the enterprise.
But how do you configure ZOOMS?
It turns out for ZOOMS to work with your system, you need to answer 4 questions:
Step 1: Go to the home page (using web browser)
Step 2: Input your keywords (hit enter)
Step 3: View the SERP
(SERP is an abbreviation for "Search Engine Results Page.")
This is the way that Google has conditioned the world to find pages of information on the internet and this is the user experience we at Zymergi think ought to be available in the enterprise.
But how do you configure ZOOMS?
It turns out for ZOOMS to work with your system, you need to answer 4 questions:
- Where should ZOOMS get time-series data?
- Where should ZOOMS look to know about the points (i.e. tags or IO)?
- Where should ZOOMS look to find out what units and parameters exist on your system?
- Where should ZOOMS look to find "batches" that exist on your system?
In each of the cases, if the answer is, "I don't know," that's perfectly alright. ZOOMS has an internal database to keep track of all this.
Questions 1 and 2 refer to the time-series data and the point configuration. You see, ZOOMS is a search engine for trends, and trends are created when you plot values vs. time:
All this means is that you need some place to put the time-value pairs (OSI calls this the PI Archive); and you need some place to put the tag information (in OSIsoft PI, this is the "point database"). These two databases are responsible for the Y-axis.
Customers typically select OSIsoft PI as the time-series data source and the point data source. That's awesome. Zymergi is an OSIsoft Partner and frankly, we think they're fantastic.
Question 3 talks about units and parameters. Units and parameter are the alternative way that people refer to tags. People think of I/Os as a parameter of some piece of equipment, and so we need a place to store unit/parameter combinations.
ZOOMS was created back in 2008 (can you believe we're going on 7-years?) and back then, the data store for unit/"alias" data was the PI Module Database. Since then, OSIsoft has moved towards Asset Framework ("AF"), but since AF wasn't ready during ZOOMS development, we created our own metadata storage. So while any relational database will do, there is a local database that ZOOMS uses.
Question 4 is about time-windows. Since time-windows is what defines the X-axis of a trend, being able to search by time-windows is of utmost importance. In batch-processes (such as pharma and biotech companies), batch identification is used to identify time-windows, but if you're a continuous process, you can define batches as work-shifts, days of the week, fiscal metrics...whatever. It doesn't matter. What matters is that there is a way of storing time-window information:
This is why ZOOMS has a local time-window data store.
The key here is that being able to search for trend data depends on 4 data sources and thus the configuration of ZOOMS starts with setting these connection strings.
Questions 1 and 2 refer to the time-series data and the point configuration. You see, ZOOMS is a search engine for trends, and trends are created when you plot values vs. time:
All this means is that you need some place to put the time-value pairs (OSI calls this the PI Archive); and you need some place to put the tag information (in OSIsoft PI, this is the "point database"). These two databases are responsible for the Y-axis.
Customers typically select OSIsoft PI as the time-series data source and the point data source. That's awesome. Zymergi is an OSIsoft Partner and frankly, we think they're fantastic.
Question 3 talks about units and parameters. Units and parameter are the alternative way that people refer to tags. People think of I/Os as a parameter of some piece of equipment, and so we need a place to store unit/parameter combinations.
ZOOMS was created back in 2008 (can you believe we're going on 7-years?) and back then, the data store for unit/"alias" data was the PI Module Database. Since then, OSIsoft has moved towards Asset Framework ("AF"), but since AF wasn't ready during ZOOMS development, we created our own metadata storage. So while any relational database will do, there is a local database that ZOOMS uses.
Question 4 is about time-windows. Since time-windows is what defines the X-axis of a trend, being able to search by time-windows is of utmost importance. In batch-processes (such as pharma and biotech companies), batch identification is used to identify time-windows, but if you're a continuous process, you can define batches as work-shifts, days of the week, fiscal metrics...whatever. It doesn't matter. What matters is that there is a way of storing time-window information:
This is why ZOOMS has a local time-window data store.
The key here is that being able to search for trend data depends on 4 data sources and thus the configuration of ZOOMS starts with setting these connection strings.
No comments:
Post a Comment