Pre-computing in Historians

Precomputing in Industrial Historians Learning about Industrial Historians. Precomputing. What is it and why modern historians use it. When one looks at the way people use historians, the window of time they are looking at can cover anything from a minute to a year. For example, one person will be looking at the steam flow around a trip over a period of 1 minute, another is looking at tank levels over a period of a day and third person is looking at production over a period of 1 year. Not a problem in theory since the information stored per second or per minute is all there in the historical tables. In practice however, if you want a trend of information over a period of a week say and your historian is storing data every ten seconds then that is a staggering 7*24*60*6=60,480 samples for each tag. Not exactly convenient to put in a report and an absolute dog to try to display! In this case, what we really want to look at is probably the hourly averages over that period which would only be 7*24=168 samples which we can manage quite easily. Of course we could create a program in SQL or VB that works out these values based on averaging out the various 10 second samples to create our hourly averages? If you try this, you will quickly see that this is not that easy when one starts to take account of various things like missing data, matching up the beginning periods of the hour, bad data, out of range data, the complex structure of the underlying tables etc. Additionally, it is extremely CPU hungry. This is why modern historians like St James Software's jHistorian precompute the variables like hourly averages, maximums and minimums etc. and store this information in the relational database. Does this make the required disk space enormous? Not really, when you consider that by definition, the hourly average file is one sixtieth the size of the one minute file for the same period. Now to look at the data over a period of a week, all we need do is write a SQL statement like "Select FIC100 from hourAv where logtime > now()-7" and bang, there are our 168 hourly averages. The other advantage of this strategy is that trend viewers like the St James jBrowser can be made to automatically choose the best sample rate to display. A week's data comes up just as snappily as 10 minutes of data. Another benefit of this strategy quickly becomes apparent...we might be very interested in the 10 second values of the flow during an upset last night, but we are really not that interested in the 10 second values two years ago. Here we are more interested in the hourly averages or even the daily averages. So, you will typically choose to only store very fast data for the last week or two weeks and as the time extends into the distance, you will store the averages of the data. Once again, this makes the data more manageable. But how do we choose what averages we want to store and how do we tell the historian to do this? Each site will have their own preferences based on the time constants of their process. A typical site might store 4 days of 10 second values, a week of one minute averages, 3 months of 6 minute averages and 10 years of hourly and daily averages. For the jHistorian, you can just enter these variables as the historian is running (no need to stop it) and it will structure your files accordingly and the data is there all pre-computed and ready to be used! View the on-line Demo Please send me more information Click here to view our Price List.