Subject: Re: Visupro Data Magnitude and Precision
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 26 Apr 2002 02:40:00 -0700 (PDT)

While I can understand the argument for reducing the amount of storage space 
required for the STARLite database, I want to emphasize that I believe that 
we should mimic what is already being done in the STAR database.  Haven't 
each of the variables been data-typed there already?

Jeff

David Miller
04/26/2002 09:28 AM
To: Kevin Cousineau/EWC/Enron@ENRON
cc: Jeff Marecic/EWC/Enron@Enron 

Subject: Re: Visupro Data Magnitude and Precision  

Kevin,

I think that perhaps it is simpler than all that. I want to match the 
precision of the data storage to the accuracy of the measurements. Here is an 
example of what I am looking for:

Wind speed (5,2)

In this example,  there are five digits and two are after the decimal (e.g. 
###.##.) This variable could hold a value up to (but not including) 1000 with 
an accuracy of +/- .01. As I recall, wind speed sensors are accurate to one 
decimal place (at best) and it is standard practice to go one decimal beyond 
to prevent rounding error.

As for how the data is stored, I believe that Number(M,N) is stored 
internally as M nibbles and puts the decimal before the last N digits. Thus, 
the value listed above would require less than 3 bytes to store. A standare 
double precision IEEE floating point requires 8 bytes.

As to the issue of the number of variables... I can't be held responsible for 
the conscientious manner in which you SCADA people wish to satisfy the data 
requirements of the company. Seriously, I hope that many of the sensors are 
the same type (e.g. temp sensors) and the values, once determined, can be 
applied to multiple parameters.

I hope this makes the issue clear.

David

Kevin Cousineau
04/26/2002 07:47 AM
To: David Miller/EWC/Enron@Enron
cc:  

Subject: Re: Visupro Data Magnitude and Precision  

David: 

First, I would like to understand how the data will be stored using only 
magatitude and precision values. Precision is pretty much useless without 
knowledge of the actual accuracy of the sensor and the converter. By 
magatitude do you mean the number of bits? This changes depending upon where 
the data is collected. First,  the sensor's are analog so they do not have a 
bit weight. Second, the A/D converter used in the Bachmann controll has a 
limit to its number of bits, but when reported through the "system" may be 
changed to ASCII where the number of bits grows, but not the accuracy! Also, 
many of the items on your list do not have a magnatitue or precision, such as 
Turbine ID. This is not a sensor or an analog signal, although it does have a 
size in bytes. 

The list is extensive and will require a large amount of work to complete. 
Once again I am not comfortable with data reduction that does not include the 
accuracy consideration of the sensor, the A/D converter etc., Precision 
without accuracy is a perfect example. This leads to meaningless numbers. 
Consider a sensor with an overall accuracy of +/- 1%. This sensor may be 
connected to a 16 bit converter with a precision and accuracy of +/- .0015%. 
Therefore we will have a system that can display the sensors 0 to 10 volt 
output down to three decimal places when its actual accuracy is only good to 
one decimal place. The remaining digits are useless. Because we use a PLC, we 
do not tailer the sensor to the system, therefore this type of event happens 
throughout the Bachmann controller. Wind speed readings are a perfect 
example. The anemometer has an overall accuracy of about +/- 2% during high 
wind speeds, and +/- 5% at low wind speeds, yet the anemometer counter is 
capable of accuracies approaching 24 bit, or +/- .000006%. Once again we will 
have lots of digits that are not usable in anyones calculations. 

Perhaps an explanation of how the reduction will work is in order. It would 
be helpful for you to know the actual accuracy of the systems so that we may 
determine how many ditigs are usefull and how many are not. This would be a 
better approach to help limit the amount of data. As an example, wind speed 
storage to more then one or two decimal places is simply a waist of storage. 

Perhaps an explanation of how the reduction will work is in order. Once Garth 
returns from Europe I will ask that he start on this task. 

Looking forward to your comments. 

Regards 

KLC