OBJECTIVES

• Protection of drinking water intakes;
• Minimising and monitoring of point sources;
• Monitoring general water quality.

While these may appear common objectives for river monitoring, instead of using the normal procedures of sampling and subsequent analyses, which are time consuming and far from real-time, the objectives are met by the use of a geographically distributed network of automatic monitoring stations equipped with sensors and analysers.

The difficulty facing the users of existing monitoring systems is the rate and volume of data being collected, which prevents users from effectively overseeing the river state in real-time. Hence, their effective use demands real-time data handling capability in order to turn this monitoring data into useful information for water quality managers. This in turn enables them to make rapid and reliable decisions regarding the state of the river water for use in the production of drinking water.

USER REQUIREMENTS

• Validation of data before use in the decisionmaking process;
• Aggregated information concerning water quality - specifically changes in state;
• Ability to access information on the basis of events or specific periods;
• Prognosis modelling of pollution events (duration and concentration) at specific points of the river after a pollution incident has occurred;
• Identification of possible sources for pollution incidents;
• Calculation of different water quality indexes (including compliance control).

In order to meet these requirements, different data fusion/data handling methods were developed and implemented. These are summarised in Table 1.

Figure 1: Fusion Hierarchy

THE APPLICATIONS

The Paris-based application consists of the automated monitoring network, "APES," which is located on the River Seine and which relies on five monitoring stations located in the western part of the Paris region. The Barcelona-based application is built around the "SIAM," automated monitoring network, which is located on the river Llobregat. It relies on ten monitoring stations distributed along the river and its main tributaries. These stations are operated by Grupo Aguas de Barcelona. Tables 2 and 3 define the stations and the data collected for each application site.

THE VALIDATION PROCESS

Data synchronisation and gap filling are carried out according to a simple concept. If a current measurement of any data element does not exist within a specified time frame around the acquisition time, then the nearest valid measurement is used. In online mode, this is the last valid reading. Within the river environment, different data elements have different dynamic characteristics. Some may change faster than others. To take this behaviour into account, data elements that change slowly are allocated a "high persistence" ranking, and those subject to rapid changes, a "low persistence" value. The value is arbitrarily defined as the time for the confidence in a measurement to fall to 50 percent. As a specific measurement ages, the confidence ranking in the value decreases, and if the measurement continues to age the confidence should decrease progressively faster.

THE "SITUATION DESCRIPTION"

Cross validation utilises information from the time-series of two different but related data elements at the same locations. The cross validation algorithm calculates a confidence value for a measurement based on the rates of change of each of the two data elements. The rate of change for each data element is divided into three zones based on the "slope compliance" - slope ascending and slope descending rate limits, and allocated a confidence value. Consistent with geographical validation procedures, the basis for this confidence is the correlation between the variations of the two time-series.

"Space time" validation as part of the geographical validation process compares two time-series data sets of the same data elements at different monitoring stations. However, it also takes into account the transport time between the stations. For this purpose, the transport times between two stations are simply represented by a table which contains the normal observed transport time for each week in the year. These times are used to incorporate a time shift between the upstream and downstream time-series prior to a comparison of the trends. However the actual transport delays are expected to deviate from those in the table. Hence a deviation is considered in the time shift, and the best confidence figure found in the range of the compared time is used.

SITUATION ASSESSMENT

Figure 2: Low level validation train

The approach is generally the same for each of the methods, and in practical terms defines a software sensor that gives a one or two dimensional output, which then can be compared to a table of threshold values giving the class of the water quality.

Classification

Three classification methods are configured within the Paris application. The first two of these are based on the French river and canal water classification method developed by Duport and Margat [1] (known as the "Multipurpose Scale" method which has been in use in France since 1971) and which provide the user with:

• General water quality classification based on five classes;
• Pass/fail classification which divides the five classes into two groups - water suitable for use in the production of drinking water, and water unsuitable for drinking water production.

The third classification method is based on the newly proposed classification method SEQ-eau, which divides classification into different "use-types." The most important of these for potable water production is the AEP (Alimentation Eau Potable). This system is more complex but can be represented in a conservative manner using the generic classification method used in the tool.

In practice, it is not possible to collect online, all of the data elements included in the classification scheme discussed. Hence, within the actual application, only those data elements which are available are used to carry out the assessments. However where additional laboratory analyses can be made, these may be used in the same way as online data to compute water class information.

Variation Detection

The method can be regarded as a "constant window" on quality, from which it is possible to construct an online software sensor called "Detect" (where the values describe the variance in the data set), and compare this with another software sensor called "Threshold." The construction of "Detect" is based on the co-variance, because it is considered that the co-variance represents a variation in the data. The sensitivity of the detection method automatically varies in time according to the level of variance for the input data.

Feature Maps (Kohonen maps)

• Modeling a set of input data against a given number of prototypes which represent the underlying relationship between all measurements included in the input vector;
• Mapping the prototypes from a high dimensional space state (the River state) to a two-dimensional space (the Kohonen map);
• Preserving the data topology - near neighbours in the high-dimension space state will be near-neighbours in the two-dimensional map.

Figure 3: The propagation process of SOFM - finding the best matching unit to input data (sample).

Pollution Tracking

Therefore the project has included a simple pollution tracking method which is able to simulate the time of arrival and the concentration of a pollutant, and compare measured values at different stations. The method makes use of a table that gives rough estimates of dilution. The dilution is estimated from the known flows (weekly figures) of the various tributaries expressed as a percentage of the contribution to the main river at the most downstream station. The arrival time is computed using a transport timetable (weekly figures) as in the case of space time validation.

TRANSFERABILITY ASPECTS

The application of the tool to new sites is constrained only by the existing data collection infrastructure. However, where a suitable infrastructure does exist, the problems involved with implementing a new application are confined to existing database(s) and configurations.

Cost Benefit Considerations

Payback periods, calculated on the basis that the application allows for one person to oversee the data which would otherwise required more staff is short, usually about six months, especially since the application is only an add-on feature designed to handle data from existing systems. The investment required to purchase hardware, installation and configuration is expected to be about 20 KECU.