Kenneth Barber
My feedback
-
1 voteKenneth Barber
shared this idea
·
-
8 votesKenneth Barber
commented
My long comment in the link below demonstrates why we need to give theory a bit more attention:
https://feedback.osisoft.com/forums/555148-pi-server/suggestions/31923244-2-timestamps-for-future-data-tagsKenneth Barber
commented
# Tag Theory (part 2) #
• Uses and properties of Boolean tags (tags whose values are only 0 or 1 and whose step attribute is on)
Examples:
- The time-weighted average and the integration over time within a time range produce the same value, but they mean slightly different things. The time-weighted average is unitless. The integration over time represents the number of days in the time range that the tag was 1.
- Multiplying a Boolean tag by a tag that represents a rate over time reproduces the rate tag only when the Boolean tag is 1, and it is 0 otherwise. This effectively produces a conditional signal, and we can, say, integrate this new tag over time to simulate conditional integration on the original rate tag.• When to use digital states on a single tag versus using multiple Boolean tags.
Details: As long as only 1 of the states can occur at any given time, then digital states are appropriate, otherwise the overlapping states should be separated into their own Boolean tags.• Maximizing the use of a tag-limited PI system (trade off simplicity and calculation time for cost savings and reduced disk space)
Examples:
- Combine up to 64 Boolean tags into a single Int64 tag. Use bit masking to extract the individual Boolean values.
- If you get very desperate trying to pack multiple signals into a single tag, consider using a string or BLOB tag.
- Instead of using 1 tag for each each test frequency, apply all frequencies at once. Separate the output into signals by frequency by applying the Fourier transform.
- If historical forecast values are not important, then instead of having 1 tag per time period in the future (e.g. 1 day, 2 days, 1 week), just use a single future data tag and overwrite its values.
- If a signal has a fractional part and requires more digits than Float64 allows (52), then scale the signal to an integer and save as Int64. If even more digits of precision are required, break the signal into 2 tags: one for the upper digits and one for the lower digits.
- A totalizer tag can afford to reset to 0 at most once in its life time without needing to keep track of when the resets occured. The reset would ideally occur when the value reaches maximum value that the tag's point type supports. When doing a subtraction over a time range, if the value is negative, add back this maximum value to get the correct value.
- Write a program to alternate 2 sets of tags between scan = on and scan = off to break the tag limit (the tag limit limits the number of scan = on tags, not the number of tags) at the expense of a much lower scan rate for both sets.# PI Asset Framework Theory #
• Easy confusions and poor design, and how to fix them.
- Choosing the primary parent.
- Instead of having unused attributes for certain equipment that follows an element template, separate the template into a base one and a derived one.
- When to use a child element as opposed to more attributes or child attributes.
- When to use child attributes as opposed to leaving the attributes "flat".
- When to use categories versus container elements. Compare and contrast. Pros and cons.
- When to make a whole new database versus using more container elements to group elements into "pseudo-databases". Compare and contrast. Pros and cons.
- When to use layers of container elements versus leaving the element list "flat". For example, if I have 2 sites, 2 areas within each site, and 2 models of equipment, what are the pros and cons of creating multiple arrangements of hierarchy (e.g. \Site\Area\Model\ and \Area\Model\Site\ and etc. all co-existing) versus not nesting site, area, and model within each other (e.g. \Site\Equipment and \Area\Equipment and \Model\Equipment all co-existing)?• Explaining and justifying the cardinality of relationship between databases, elements, child elements, element template, derived templates, attributes, child attributes, categories, analyses, tags, notifications, AD groups, PI Identities, event frames, event frame templates, child event frames, etc. A giant diagram encapsulating all of the cardinalities would probably help.
• PI Asset Framework as a directed graph, not necessarily a hierarchy. Weak references create the illusion of a hierarchy (tree).
• Compare and contrast PI Asset Framework against a traditional, multi-table relational database.
Kenneth Barber
commented
These are only examples of possible video topics. OSIsoft knows PI much better than I do, so they can probably think of more useful topics.
# Tag Theory #
• Translating from relational database thinking to time series database thinking.
Details:
- Arrange your table of values so that you only have 2 types of columns: the value column and columns that comprise the compound primary key. The columns that comprise the compound primary key, minus the timestamp column, identify the PI Point. The timestamp column and the value column identify an event that is saved to that PI Point.
- A relational database treats all dimensions (columns) as discrete, but time series databases have a continuous time dimension represented by discrete samples, and a discrete "tag" dimension.
- Disadvantages of a relational database for time series data.• Different ways to handle signals over discrete time or signals over a time range
Examples:
- The mass of rock for a single load into a haul truck, where the haul truck can take multiple loads before driving away to dump off its load, and where the weight scale is on the loader, is only recorded at precise times, and the times that the loader is empty is not recorded. Interpolation between these values is not appropriate. Possible approaches: avoid using interpolated values or create a new tag that tracks the mass being held in the haul truck, which can be interpolated.
- A line on a monthly invoice applies to a time range (the month) and cannot be broken down accurately into smaller pieces. Possible approaches: avoid using interpolated values or convert the cost to cost per day, which would produce a continuous signal over time.• Defining named constants in the PI Data Archive.
Details: Make a tag named after the constant. Save a single event to it, where the timestamp is the beginning of time (January 1, 1970) and the value is the constant.• Why use linear interpolation between events on a PI Point, as opposed to say, a cubic spline?
Details: Linear interpolation will produce a line segment whose slope equals the average of all slopes in the same time period in the original signal. See the mean value theorem. Also, the interpolation method used between events should not produce interpolations that are greater than or less than the values at the interpolated events, otherwise false alarms might be generated.• Creating a tag that accurately represents the product of 2 tags (e.g. mass flow rate × % of particles within a certain size, rate × Boolean tag) if both are step = on, both are step = off, or one is step = on and the other is step = off.
• Maximum changes in accuracy and precision compared to the "true" signal after different operations.
Examples: sampling, step interpolation, linear interpolation, exception, compression, changing scan rate, numerical integration over time, event-weighted derivative with respect to time, combining signals (e.g. sum or product)• Uses and properties of totalizers.
Examples:
- Totalizers are the definite integral with respect to time of a rate over time. As such they have all of the properties of integrals. For viewers that are less math-inclined, totalizers can be thought of as a cumulative sum of measurements over small time ranges, starting from some arbitrary starting time.
- A totalizer is continuous over time, as opposed to the measurements over time ranges mentioned earlier, which are not.
- You can find a "sum" in a time range by subtracting the values at the time range's end points. This is much faster than summing every small measurement in a time range.
- The starting time of the totalizer is irrelevant, since only the difference between totalizer values matter, and the differences are not affected by the starting time. Use visuals to prove this!
- Even though a linearly interpolated totalizer is just an approximation of the "true" totalizer, an exact derivative with respect to time of the interpolated totalizer can be calculated. Since the totalizer is a series of line segments, the derivative is a series of flat lines (i.e. step = on). Similarly, integrating a tag that represents a rate over time and that has step = on can be integrated over time to produce an exact totalizer. However, taking the derivative of a step = on tag produces all 0 or undefined, and integrating a step = off tag produces parabolic pieces that require more saved events than the original tag to reproduce accurately.Kenneth Barber
shared this idea
·
-
8 votesKenneth Barber
commented
Most websites don't say which browsers they support, but they will tell you if your browser is not supported or not recommended. If it is not recommended, then they will tell you the recommended browser.
-
2 votesKenneth Barber
shared this idea
·
-
3 votes
We will make this fix in an upcoming version.
Kenneth Barber
commented
In which upcoming version will this be fixed? The "Planned" status was added over a year ago!
Kenneth Barber
supported this idea
·
Kenneth Barber
commented
The context that you are talking about appears to be programming. The context that I am talking about is UI. To me, it doesn't make sense to use programming spelling in a UI, especially since most PI administrators aren't programmers.
For UTC, it is programming convention to only capitalize the 1st letter of acronyms if you are using camel case, which produces the Utc spelling. Outside of camel case function and variable names, no one uses Utc.
Kenneth Barber
shared this idea
·
-
6 votesKenneth Barber
commented
Brent, if the administrators do not modify this suggestion, maybe you should post a new suggestion. Then, in the comments of both suggestions, reference the other suggestion.
Kenneth Barber
commented
I'm OK if the title of this request is changed to be more general.
Kenneth Barber
shared this idea
·
-
10 votesKenneth Barber
commented
As a workaround, you can change the scan time to be very long and take note of the previous scan time in the data source's description.
-
0 votesKenneth Barber
commented
I recently learned that OSIsoft is trying to migrate away from Event Viewer logs and towards log files that are specific to each product. It doesn't matter to me what approach they take, as long as the approach is consistent across all products.
Kenneth Barber
shared this idea
·
-
2 votesKenneth Barber
commented
Can someone please move this to be a Product Downloads suggestion for myOSIsoft? At the time that this was posted, there was no better place for this on OSIsoft UserVoice.
Kenneth Barber
supported this idea
·
Kenneth Barber
shared this idea
·
-
4 votesKenneth Barber
commented
Can someone please move this to be a Product Downloads suggestion for myOSIsoft? At the time that this was posted, there was no place on OSIsoft UserVoice for suggestions about the website.
Kenneth Barber
shared this idea
·
-
2 votesKenneth Barber
supported this idea
·
Kenneth Barber
shared this idea
·
-
2 votesKenneth Barber
supported this idea
·
Kenneth Barber
shared this idea
·
-
1 voteSTARTED / IN DEVELOPMENT · 0 comments · myOSIsoft » Customer Portal Overall · Flag idea as inappropriate… · Admin →Kenneth Barber
shared this idea
·
-
5 votesKenneth Barber
commented
We can now see all NOC support cases since the new Customer Portal was released. We still can't see any NOC support cases from before then, though. If OSIsoft is planning to never make these older NOC support cases visible to customers, then this suggestion should be marked as completed.
Kenneth Barber
shared this idea
·
-
5 votesKenneth Barber
commented
I posted a more generalized suggestion here:
https://feedback.osisoft.com/forums/920320-myosisoft/suggestions/38099461-update-standardize-the-properties-of-osisoft-proKenneth Barber
commented
It doesn't look like this change has been made across the board yet.
Kenneth Barber
shared this idea
·
-
1 voteKenneth Barber
commented
This suggestion is the generalized version of this one:
https://feedback.osisoft.com/forums/555148-pi-server/suggestions/35231404-use-the-https-versions-of-links-in-help-link-sKenneth Barber
shared this idea
·
-
2 votesKenneth Barber
shared this idea
·
-
4 votesKenneth Barber
commented
I have the same issue. I think that OSIsoft has tested their website on large monitors only and not laptop screens.
Downloading PI API 2018 is especially bad, since there is a lot of text before the license agreement. I can't see the "I Agree" check box or the "Download" button.
Kenneth Barber
supported this idea
·
-
4 votesKenneth Barber
supported this idea
·
-
7 votesKenneth Barber
commented
Angela Hill brings up an interesting case, but her case is different from the case in my suggestion in more ways than you might expect.
In the case in my suggestion, at any particular time for a particular type of value (e.g. power output), you can make predictions to multiple times in the future. Similarly, any particular time in the future can have multiple predictions against it for a particular type of value (e.g. it can have the "1 day later" prediction from yesterday and the "2 days later" prediction from the day before yesterday). There is a many-to-many relationship between the 2 types of timestamps even within a single type of value (e.g. power output), so we have no choice but to represent each value of 1 of the types of timestamps as a new tag.
Angela's case is a bit different. Each occurrence of a particular type of event is logged only once (I'm assuming), so for that type of event, there is only 1 logged time for each occurrence time, but multiple occurrences of the same type of event can share the same logged time. That is, there is a 1-to-many relationship between the occurrence time and the logged time for a particular type of event. In such cases, for each type of event, you can have 1 tag that captures the value and 1 tag that captures the logged time, where both tags use the occurrence time as the timestamp. You can then create an element template called "Logged Event" that has 1 attribute for each of the 2 tags that I just mentioned. Then, instead of representing each type of event as a different attribute in an element, you would instead create 1 element, based on the Logged Event template, for each type of event, and each of these elements would be child elements to the element that the event applies to.
I think that situations like the one above support the idea that it wouldn't hurt for OSIsoft to talk about the theoretical side of PI, design patterns, and different approaches to problems in PI. Solutions like the one that I described are not immediately obvious and customers may be doing things suboptimally and not even realize it. https://feedback.osisoft.com/forums/602086-osisoft-learning/suggestions/31689928-make-more-videos-about-the-theoretical-side-of-pi
Kenneth Barber
commented
I realize that not every future event is a prediction. For example, it could be a goal. But even goals are set at specific times.
I also don't expect PI to support an arbitrary number of continuous dimensions (e.g. resistance predictions as predicted current, predicted voltage, and distance into the future change over time). That might be a time to use fancier tools.
Kenneth Barber
shared this idea
·
Another design pattern to cover: notifying users of the value and timestamp of a forecasted (future) event. Notifications only have access to the current value and timestamp of an attribute. To work around this, you need to create an attribute to hold the future value and another attribute to hold the future timestamp.