|
|
|
|
|
|
|
Introduction Quietly, there is a data crisis lurking in water instrumentation - data overload. When considering collection of data from monitoring instruments most return a single value. There is a black sheep in the family - the particle counter. A single particle counter can collect copious amounts of data. With regulatory requirements in the water industry dictating the need for not only monitoring for compliance failure, but also records to track trends leading to any compliance problem, there is a need to collect a wide range of data. This paper discusses where the data comes from, what format it might take, how it should be collected and data management strategy.
The source a volume of data The mathematics of data collection is easy to demonstrate: take a single particle counter, and a single collection pot (this is the totaliser for counting same sized particles). The data in this pot will depend upon the type of particle counter; those used say for the oil industry use 3 or 4 byte representation able to count millions of particles per millilitre. The Diverse PCS2000 uses a 2 byte representation able to count to 64,000 particles per millilitre - although this might seem a poorer specification, in the scenario of water monitoring such a particle density would be nearly 2 orders of magnitude beyond the alarm point. Further, because modern water filtration is turning to membrane filters, there may be less than 10 particles per millilitre, with alarm levels as low as only a few hundred particles per millilitre. Most particle counters split the measurement range up into size related pots, e.g. 2um to 3um, 3um to 5um and 3um to 7um to spot particles of cryptosporidium dimensions etc. This allows the particle distribution to be assessed, and inferences made about the source of the particles, for example filter breakthrough, process failure or supply degradation. Each pot will be represented by at least 2 bytes, so for a system which has 8 pots, this will require 16 bytes per sample. Sampling periods vary widely depending upon the process timing and the required reaction speed. Nonetheless, sampling of water is carried out at relatively long time intervals compared to other industrial applications, so typically the fastest sampling rate is likely to be around 15 minutes. With the pressure to lower costs, and the need to instrument filter arrays, modern particle counters can be arranged as counter clusters (in the case of the PCS2000 the cluster size is up to 16 nodes). Taking this into account, the data collection rate becomes: 2 * 8 * 16 * 4 = 1 Kbytes per hour. With times between data archive of say 7 days, the active data storage requirement would be 200K bytes per cluster. Local storage within the particle counter will cover several days logging but at this data collection rate, downloading of data should be carried out daily. Finally, for a large system with a central data collection facility, there may be many out station particle counter clusters - up to say 100 (1,600 particle counters). The total data collected would then be 20 Mbytes per week, or 1 Gbyte per year!
Data transfer There are a number of mechanisms for transferring and collating the data. Historically the industry has used the simple method of 4-20mA loops and a SCADA system. This approach does however have the disadvantages that only one pot can be monitored, and a separate channel is required to indicate which particle counter in a cluster the data refers. Such reporting is further restricted to only total particle count, so particle spectrum would not be available except at the instrument itself. Serial transfer to a PC is a reasonable approach. Most particle counting instruments have a serial port RS232 or RS485, which can be connected to a PC. Data can then be transferred, using either a simple terminal emulator, or a dedicated program. In either case the data transferred increases because in order that the data be readable by a simple terminal emulator, it must be supplied as ASCII, so a 2 byte count would be transferred as 6 bytes, 5 digits and a delimiting space character. This alone increases the data transferred on the example maximum system to 3 Gbytes per year. Serial transfer can be fast - up to say 115,000 Baud or around 10K bytes per second. However, in order to accommodate most PCs and keep data errors low, data rates of 9600 Baud or 1 Kbytes per second are typical. Using the example quoted above, the data to be transferred from a 16 channel system with 15 minute logging of 8 pots will be: 4 * 8 * 16 * 24 = 12,000 samples per day With 6 bytes per sample, 74,000 bytes need to be transferred; this translates to about 80 seconds to complete the transfer at 9600 Baud. Although 80 seconds does not sound long, and indeed for manned plants, it could be integrated into a daily maintenance schedule with little cost impact, such a strategy bucks current trends of reducing manning at plants which for the most part require only intermittent attention. The drawbacks of the above methods are mostly overcome by using remote data collection and reporting. This approach requires a link using either a telephone land line or a GSM mobile. In this case data is transferred in packets, delivered on demand by the particle counting system to the master PC at the central data collection station. Each packet of data is protected by checksum, and automatically repeated if data transfer errors occur. Data transfer rates can be as high as 57,000 Baud but realistic practical rates are around 2,400 Baud. Compared with local serial transfer, this increases the time to complete a days transfer for the 16 node system to about 5 minutes. This implies that a large system of 100 16 node clusters will be transferring data for 8 hours per day. Such heavy usage, and the need to accommodate noisy lines, retries and line/cell breaks suggest that for large systems the data collection should be spread over more than one data collection PC.
Alarm Handling Traditionally, alarms would be indicated by either local relay closure or 4-20mA out of range at say 2.5mA. This data would then be either indicated locally and/or transferred to the base station over the SCADA link. The remote connection assumes that the PC collector is the master and the particle counter is the slave in the communications protocol. This protocol can be reversed to cater for alarm scenarios. So if the alarm level is exceeded, qualified by the time in alarm being exceeded, the particle counter can telephone a PC, identify itself and location and report the alarm condition. Alarms can include status alarms on the instrument itself. This simple reactive system allows a single PC at base to monitor for alarms across a whole network - without any manual intervention until an alarm occurs. With the PCS2000, if conflicts occur, for example if two instruments need to raise an alarm at the same time, then the first to get a telephone line through will post its message - the second will retry until the line is clear.
Databases and What happens back at base Data is best handled by a database. This may seem a trite statement, but with so much data involved, saving ASCII files and interpreting interleaved data from many different sites and counter nodes is not practical. Using a database, all the particle counter data for a complete catchment area can be stored in a single file. Database management tools allow the data from a particular site, over a particular time frame to be extracted and plotted.
Cost of ownership The cost of ownership is a very important part of any instrument for the water industry. In the case of a particle counter the costs can be evaluated either as cost over time, or as a cost per bit for the information collected. In either case the optimisation of costs can be evaluated using standard management techniques such as multi attribute utility theory. Without entering into the detailed cost analysis which would be different for each site and catchment area, it is clear that there are potentially large cost savings, with essentially automatic monitoring, and periodic on-demand maintenance.
Conclusion This paper has shown that huge amounts of data will need to be collected and collated if particle counters are to be deployed successfully. The PCS2000 system is designed to address all of the issues raised, allowing simple installation and minimal maintenance input. It makes unattended remote monitoring is a reality, and as with any large database system there is a key requirement to provide simple clear reporting to maintenance managers, so that prompt action is possible in the face of filter breakdown. Modern particle counters such as PCS2000 should not be seen as supplied as single stand alone instruments, but as a data collection strategy offering a real opportunity to automate plant maintenance. Indeed the day may be close when the central data collection site is also unmanned, and the maintenance manager is provided with the current plant status directly to his mobile phone.
|
|
|
|
Tel. +44 (0) 1223 84 44 44
|
