[Imported] Feature Request or Correction: High-High, High, Low, Low-Low on Historic Trend

[sbeadle]

>>Message imported from previous forum - Category:ClearSCADA Software<<
User: MikeForshock, originally posted: 2019-08-07 21:20:33 Id:481
The trends shows the current, as configured limits for Low, Low-Low, High, High-High.
As the process moves along these values may change, but the historic record is not shown on the trends.

Example:
Day 1 the High is set for 10, the process hits 10.5 so will show as surpassing the High level.
Day n the High is now 12, but the past record that hit 10.5 is no longer shown as high and all past records relate to the new High limit.

In our previous SCADA software this value was presented in the trends.

[sbeadle · Accepted solution]

>>Responses imported from previous forum

Reply From User: geoffpatton, posted: 2019-08-08 17:48:00
The trend display gets the limits from the point's configuration, and the limit is not saved in the historian, I suspect that it would be quite a lot of work to implement.

Would be handy at times though.

You have to contact your local support to put in a feature request.

Reply From User: adamwoodland, posted: 2019-08-08 21:48:07
Same problem exists with other things like state descriptions. Each historic record is currently 32 bytes on disk (ignoring NTFS cluster sizing), and adding extra information to that means customers with 300-400GB of historic may suddenly end up with 600GB-800GB of historic if the size of each record were to double (easily done with for some bytes for limits and say some descriptions).

It is unlikely to be added retrospectively so not exactly a disk issue overnight, but something the developers consider.

Reply From User: BevanWeiss, posted: 2019-08-12 00:04:12
[at]adamwoodland said:
Same problem exists with other things like state descriptions. Each historic record is currently 32 bytes on disk (ignoring NTFS cluster sizing), and adding extra information to that means customers with 300-400GB of historic may suddenly end up with 600GB-800GB of historic if the size of each record were to double (easily done with for some bytes for limits and say some descriptions).

It is unlikely to be added retrospectively so not exactly a disk issue overnight, but something the developers consider.

Things like the historical limits shouldn't be too bad though.
It only needs a historic entry added when the alarm setpoint value actually changes (so it wouldn't be associated with the historic point changes itself). Obviously things like Time Profile Alarm Setpoints become a slightly trickier situation (since they are always time varying).
But this is an issue with Time Profiles already (that they have no concept of their historical content).

Reply From User: du5tin, posted: 2019-09-27 14:08:54
If we enable property changes you get a record in the Property Changes table with the old value and new value. However, this table is not really built for the purpose of displaying values on a trend, and most systems I work on the time frame configured for storage is quite short, usually only a few weeks.

Have you considered adding points to the database to store the historical set point settings? It adds a lot to the configuration but if showing those values on trend is required, might be one of the easier ways of getting it done.

Reply From User: BevanWeiss, posted: 2019-09-28 00:26:52
[at]du5tin said:
If we enable property changes you get a record in the Property Changes table with the old value and new value. However, this table is not really built for the purpose of displaying values on a trend, and most systems I work on the time frame configured for storage is quite short, usually only a few weeks.

Have you considered adding points to the database to store the historical set point settings? It adds a lot to the configuration but if showing those values on trend is required, might be one of the easier ways of getting it done.

(I'm not the OP)
We do have a few customers with systems similar to this.. where there are dedicated Internal Analog Points for storing the alarm limits. I hate it. It absolutely chews through the license point count, and in general makes everything just a bit more painful.

I think in terms of the ClearSCADA application, it's a feature that it really should have natively, without the additional license cost for more points. It is historical data that should be associated with an analog point (with alarm limits).
I think ClearSCADA keeps itself out of some interesting industries (pharmaceuticals, and to a lesser extent general manufacturing) based on missing features like this..

Reply From User: MikeForshock, posted: 2019-10-10 18:39:30
[at]BevanWeiss is right on the money.
* additional Points
* Wasted time

Other systems we have worked on allowed is to log virtually any and all values (numeric, logical, etc.) and were not counted as points.

For processes with varying recipes (temperatures, flows, etc.) that have different tolerances this value would be very helpful.

2019 is still in beta...

Reply From User: BevanWeiss, posted: 2019-11-12 23:00:45
[at]MikeForshock I'm in general ok with the concept a Data Point should be a licensed Point, so I don't think licensing based on an 'asset' for instance makes sense. Since as you note, various assets have different levels of complexity.
Schneider should have perhaps thought at restricting down a few of the other 'features' as licensed models however (with low license costs). For example, having Email redirection as a $250 license wouldn't have been an issue, or having SMS redirection as a $250 license... if the per point cost dropped to compensate.
It all gets a bit commercial of course, but ClearSCADA is seeing some competition in the low end space from the likes of Ignition... which has such a scalable licensing model.