|
|
Enron Mail |
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
|