| ||
| ||
Logging Data/ArchivingThe I/O signal engine (IOMON 3.0) on Borynet Data control Server (DCS) provides a range of archiving options. The signal logging or archiving is simple and yet very well integrated into DCS and its remote intend and nature. The idea of archiving is to capture and summarize the trend of the signals over the defined time. There is no need and it is beyond capabilities of DCS to record every single value read. So, the user need to decide the time period that make sense. Often, an hour is a common time period used to catch the signal trend. The signal logs or archives are written to a file. The log file than contains a set of records for a particular. Each record is a signal summary of the specific period of time. All signals can be archived including the formula ones but usually it makes less sense to archive digital signals. If however a digital signal is archived, its TRUE state is converted to floating number 1.0 and FALSE to 0.0 and the digital signal is processed as if were an analog signal. Many archives can be defined for IOMON to run. The archives may differ by the set of signals included, the period of time that the records will represent, and the final format of the logs. Presently, four formats are available: HTML , XML, SQL, and CSV. When logs are saved in HTML format, they are suitable for immediate viewing using a browser. Such logs can be easily integrated into functionality of the web server providing powerful solution. The XML and CSV formats are intended for further processing and are defined for convenience of the user parsing method. The SQL format is intended for immediate insertion to a SQL database. Each record is formated as an ANSI SQL INSERT statement. T his type of file is intended for integration of logs into SQL server. As an example let's consider a network of monitoring devices running DCS. The data log files can be pushed or pulled daily to a data center running a SQL server. The log files in the SQL format can be than easily (without additional parsing) inserted into the database. While in SQL server all kings of trending and reports can be generated. Let's assume that we are monitoring a temperature signal (TEMP01) and the IOMON is sampling all the signals once a second. So, we get a new temperature reading every second, that is 3600 reading an hour. Let's also assume that it's enough to trend the temperature per hour to satisfy our needs. We can then average the 3600 samples into one record, and daily instead of 86,400 readings we get 24 summary records. The archive definition can look like this: [Archive=1] Format=CSV Type=Hourly File=hourly_data Path=/usr/iomon/data/ Column=AVG(TEMP01) In the above example, a log file (/usr/iomon/data/hourly_data.csv) defined by the Path, File, and Format would be created . The records consisting of 1 field/column representing the hourly temperature average would be appended every hour. The file would grow indefinitely until an user intervention such as deleting the file, renaming it, or moving to different location. Every time a new record needs to be written, the log engine is trying to open the log file. If it exists the record is appended and if it doesn't a new file is created. This mechanism combined with enriched file naming feature allows for quite interesting results. File name definition accepts additional time format commands as defined in LINUX strftime function. Before log engine opens the log file, it runs its name thought strftime function. This way the final log file name may be different depending on time and effectively allowing to group records into files based on date and time. Let's a file defined as follow: FILE=hrdata_%y_%m_%d When file name is run through strftime function , the %y is replaced with 2-digit year (without century), the %m is replaced with current month number, and %d is replaced with current day number. As a result, if the current date is 6/1/2008, we get “hrdata_08_06_01”. 24 hourly records will be stored there and when the midnight passes and new day comes, the new file “hrdata_08_06_02” will be created. Using this technique all kinds of grouping can be achieved. The hourly records may be group by day, week, or month. The daily records may be grouped by a month or year. For full list of command allowed for a File definition, please, refer to Linux strftime function. The Type directive in archive definition allows to define trend time period. The allow values are: hourly, daily, and user. Hourly defines a trend period on an hour, and daily a trend period of 24 hours. If the user needs to define a different trending period, he/she must define type as user and follow with the definition of TimeMin , a number representing a period of time in minutes. For example, Type=User TimeMin=15would define trend time of 15 minutes and Type=User TimeMin=120would define trend time of 2 hours. In the archive, the columns or fields are define with a directive “Column=...”. The column directive might be repeated a many times as necessary. The column argument may be as follows: To summarize, to following example shows how to define archive file for temperature signal with 15 minutes trending period grouped on the daily basis. Starting on 6/1/2008, the files would be created in the web server directory and html format on daily basis as “/var/www/data/IOHR_2008_06_01”, ... . Each file, would contain, 96 records, representing quarter hour time periods. Each record, would contain 6 fields/columns: date, time, sample count, minimum temperature, average temperature, and maximum temperature for that period of time. [Archive=1] Format=HTML Type=User TimeMin=15 File=IOHR_%Y_%m_%d Path=/var/www/data/ Column=DATE Column=TIME Column=COUNT Column=MIN(TEMP01) Column=AVG(TEMP01) Column=MAX(TEMP01) | ||
|
