A solution for expanding an already existing pipeline SCADA for real time leak detection is presented. The work consisted in attaching a FDI scheme to an industrial SCADA that regulates liquid distribution from its source to end user. For isolation of the leak a lateral extraction is proposed instead of the traditional pressure profile of the pipeline. Friction value is a function of pipe physical parameters, but on line friction estimation achieved better results. Aspects that were important in the integration of the FDI scheme into the SCADA were the non synchrony of pipeline variables (flow, pressure) and their accessibility, that leaded to data extrapolation and the use of data base techniques. Vulnerability of the location algorithm due to sensors bandwidth and sensitivity is showed, so the importance of selecting them. The FDI scheme was programmed in LabVIEW and executed in a personal computer.
Leak detection and isolation in pipelines is an old problem that has attracted the attention of the scientific community since decades. A paradigmatic example is the oil leakage in the Siberian region [1], where the effects on the surrounding nature have been disastrous. In Mexico, a semi desert country, there is the need to transport water to the population on long distances via aqueducts; this requires complex supervision systems that detect leakages in early ways. Also, there exist a complex net of pipelines that transport oil and its by-products; in this net, besides the leakage problem, there exist also the illegal extraction of the product transported in the pipeline; this forces that the distribution system should have a leak detection and location monitoring system.
Since the 1970s’ years have been issued several works that have been fundamental for the detection and location of leakages as the one of Siebert [2], where on the basis of the steady state pressure profile along the pipeline simple expressions are derived, based on correlations,that detect and locate a leakage. Later Isermann [3] published a survey showing the state of the art on fault detection by using the plant model and parameter identification. Recently, Verde published a book [4] making emphasis on signal processing, ∗Supported by II-UNAM and IT100414-DGAPA-UNAM. pattern recognition and analytical models for failure diagnosis.
But all the later is pure academical, our aim here is to share some of our practical experiences acquired during a re-engineering project that consisted on adding a real time leak detection and location layer to an already existing SCADA. The original objectives of that SCADA were the administration and delivery of some products, through pipelines, from the source to the end user. As it was our first approach to integrating a FDI to an existing SCADA and that we didnt’ have experience on this subject, we proposed a solution that involves simple algorithms for detecting and locating a leak. In future work wel’l use more elaborate algorithms as dedicated observers or detecting two simultaneous leaks.
In order to show how we solved the targets of the project we divided the solution in five major parts (each one included in sections 2 to 6 down here). Some of them are extracted from available theory, as the dynamical model for a flow in a pipe and the expression for leak location, and others are consequence of the experience achieved in our lab facilities, as the calculus of pipe friction and and the choice of sensors, and finally the data acquisition imposed by the nature of the available SCADA.
Delivering a fluid to clients means steady operation, then our solution required a suitable model for that condition, section two describes how to achieve a simple steady state model for a pipeline. Once the model is at hand an appropriate expression for leak location is needed, for that purpose in section three a simple method for locating a leak is presented. From our experience, pipe friction plays a fundamental role in the exact location of the leak and that real time estimated friction is better than a beforehand constant one; an on-line expression for calculating the pipeline friction is showed in section four. In this project we didnt’ have the option to choose sensors, but we consider appropriate to share here our experience in this matter, a comparative study on how different type of sensors affect the leak location is presented in section five. The data acquisition system of the SCADA is based on a MODBUS system and a database with the information of the pipe variables, we didnt’ have the right to get into the MODBUS but in the database, section six shows how the indirect measurement of pipe variables issue was solved by using ethernet and data bases, also, the extrapolation of data of non existing data during sample times is presented. Finally, the concluding remarks of this work are presented in section seven.
In most applications a dynamical model of the system is required but not here because of the steady operation of the pipeline, then a steady state model is more suitable. Besides, the pipeline lies buried in the field and has an irregular topography, but it is possible to derive a model that handles it like a horizontal one. This model is simpler as will be showed.
In the following we modify the model of a pipeline with topographical profile as showed in Figure 1 into one with a right profile piezometric head, where the pressure variable depends on a reference value h, as is the hight over sea level along the pipeline. Consider the one dimension simplified flow model in a pipeline with n sections [5], 1 ∂Qi(zi, t) Ai ∂t + g ∂Hi(zi, t) ∂zi + f Qi(zi, t)| Qi(zi, t)| + g sin αi = 0 2Di(Ai)2
+ ∂Hi(zi, t) b2 ∂Qi(zi, t)
= 0
∂t gAi ∂zi
which assumes that fluid is slightly compressible, pipe walls
are slightly deformable and negligible convective changes
in velocity. Q is volumetric flow, H is pressure head, A
is pipe cross-sectional area, g is gravity, f 1 is the
D’ArcyWeissbach friction [6], b is the velocity of pressure wave,D
is pipe diameter, z is distance variable and t the time. Super
index i = 1, 2, ..., n indicates pipeline section characterized
by its slop with angle αi, n is the total number of sections.
(
Sensors locations 2340 2320 ] l[m2300 e v e la2280 e s r ve2260 o h t ig2240 e H 2220 22000 1 2
3 Length [m] 4 5
We start with the following hypothesis: the system works in steady state and that the pipeline lay on an horizontal surface. Therefore we need a steady state model that takes into account these conditions.
In order to describe the behaviour of the pressure head Hi(zi, t) along a section without branches it is assumed steady state flow, so from (2) one gets (3) (4) with
M i(Qi) = μiQi| Qi| + sin(αi) = mi(Qi) + sin(αi) (5) that is independent of the spacial coordinate zi, and μi := f i/2Di(Ai)2g. Then the solution of (4) reduces to
Hi(zi) = −M i(Qi)zi + Hi(0) for 0 ≤ zi ≤ Li (6) with Hi(0) the pressure head at the beginning of section i. Defining boundary conditions for section i in terms of pressure at the ends:
Hi(zi = 0) := Hiin
Hi(zi = Li) := Hoiut. (
Hiin − Hoiut = M i(Qi)Li = mi(Qi)Li + ∆ Hi, where ∆ Hi = Lisin(αi) is the height difference between section ends.
It is reported in [7] and [8] that the pressure head Hi(zi) =
P i(zi) ρg can be written in terms of the piezometric head H˜i(zi), wich depends on a heigth h that can be related to sea level, i.e.
H˜i(zi) = Hi(zi) + h(zi), h(zi) in m over reference datum or sea level, ρ is fluid density. Then the profile pressure (8) is equivalent to
H˜iin − H˜oiut = mi(Qi)Li
for section i and sea level h(zi) along the section. Finally,
considering that boundary conditions are related by
from this equation and (
H˜oiut = H˜iin+1, H˜i1n − H˜onut = n ∑ Limi(Qi) i=1 which is function of the piezometric head for a pipeline with n sections without branches.
The profile of Figure 1 corresponds to the topography of the pipeline under study. The pressure head H(z) and the resulting piezometric head H˜(z) are shown in Figures 2 and 3, respectively. Take into account the uniformity of H˜(z) similar to the one of a horizontal pipeline. The reference datum was the height of the first sensors location.
As a consequence, if H˜i1n = H˜in and H˜onut = H˜out,
besides if mi(Qi) = m(Q) = M (Q) for all i, then Equation
(
H˜in − H˜(z) = LM (Q)
where L = ∑in=1 Li the total length of the pipeline.
Equation (
We consider a leakage as an outlet pipe at the leak location
as is shown in Figure 4. A branch or lateral pipe in
section i breaks the continuity of variables Q(z, t) and H(z, t),
therefore new boundary conditions must be satisfied [9]. In
Combining (
⇒ Qi constant
+ M i(Qi) = 0,
1This friction characterizes the shear stress exerted by the
conduit walls on the flowing fluid.
(8)
(9)
(
3
Length [m]
4
5
particular, the union of three pipes is associated to a
geometry shown in Figure 4 and the corresponding conditions that
describe the action of separating flow are reduced to
where H2 and H3 are pressures at the beginning of pipes
2 and 3 and the functions κ1η(· , · ) with η = 2, 3
represent losses caused by friction and change of flow
direction. For adjusting the order of magnitude of these
functions flow simulations were held with Pipelinestudio [10]
with the topology of the study case shown in Figure 1.
Simulation reported that terms κ12 and κ13 were negligible, then
ࢠ ൌ
ͳ
ࢠ ࢈
ࡽ
ࡴ
ࡴ
ࡴ
ࡸ െ ࢠ
ࡽ
࢈
ࡽ
͵
ࢠ ൌ ࡸ
(
Hin − Hzb
zb Hzb − Hout
L − zb − M (Qin) = 0 − M (Qout) = 0.
Obtaining the variable zb associated to the position of the branch zb = =
M (Qout)Li + Hout − Hin
M (Qout) − M (Qin)
m(Qout) − m(Qin)
L sin α + m(Qout)L + Hout − Hin , (21) in terms of the piezometric head zb = m(Qout)L + H˜out − H˜in .
m(Qout) − m(Qin)
Equation (22) is the key for leak isolation. In order to see the performance of this leak location method some experiments were held in our pipe prototype [11], which is an iron pipe of 200 m long, 4 inches diameter and six valves attached to it for leak simulations. Table 1 shows the percent deviations of locating the leak position. In each experiment a valve was fully open. Coriolis sensors were used. 4
The D’Arcy-Weissbach friction is a function of the pipe
parameters, [6] and [12], and operation conditions, as the
Reynolds number. For practical purposes the friction f is
obtained from tables provided by the pipe manufacturers.
But we observed that that value differs from the real one of a
working pipeline where, no matter that is working in steady
state, the value is influenced by noise -caused by pipe
inner surface imperfections and attachments (nipples, elbows,
etc.)-, therefore using a previous fixed value of f is of no
use in Equation (
To overcome the problem of not having the friction right value, we proposed a solution that was an on line friction estimation. In the following we show how to calculate this friction. For that, we part from the steady state momentum equation, Equation (4). Turning back the original parameters we get
dH f g dz + 2DA2 Q | Q| + gsinα = 0 (23) solving the integral, considering that H0 and HL are pressures at he beginning and at the end of the pipeline and L the length, results f g(HL − H0) = −( 2DA2 Q2∞ + gsinα)L (24) where Q∞ is volumetric flow in steady state, the absolute term disappears when flow goes in one direction only. Friction has the following expression
2DA2g (H0 − HL − Lsinα) f = (25)
L Q2∞
Equation (25) is used to calculate on line the friction value, as is shown in Figure 5, experiment realized in our pipeline prototype. The calculated friction has a considerable amount of noise, but this noise can be attenuated via weighted mean value with forgetting factor (MVFF, continuous line in figure). Actually, we are working on the use of recursive identification procedures for a better friction estimated.
Unfiltered MVFF 0.026 0.025 iitno0.024 c r F 0.023 0.022 0 100 300
400 200
Samples ods are based on processing a residual that is a flow difference. Due to our lack of experience, and by suggestion of a supplier, we start our flow measurements with a paddle wheel flow sensor [13]. Later on, as ultrasonic sensors are widely used in the field, we decide to change to them [14], thinking that our measurements would be better. Finally, we reached the conclusion that success on leak detection and location depends strongly on the sensors quality (make and sensing principle), so we acquired sensors based on the Coriolis effect [15].
An experiment that we made in our pipe prototype was to cause a leakage (outflow in a extraction point) and estimate the location with the measurements of the three sensors. Figure 6 shows the deviation of the calculated location depending on the type of sensor. Oscillations are observed around the operating point, which leads to the necessity of signal filtering in the diagnosis process. Table 2 shows the error leak location, Paddle Wheel and Coriolis sensors have similar error, but standard deviation is bigger with the Paddle Wheel. In order to compare performance in the fourth column the accuracy of the instruments are presented; remark that Coriolis error standard deviation is about seventy times bigger than sensor accuracy. The observation here is that the quality of the results depends more on the behavior of the flow than on the accuracy of the instrument used.
Leak location (Real position= 49.8 m)
Coriolis Paddle wheel Ultrasonic 60 50 40 ] [nm30 o it ca 20 o L 10 0 −100
One of our goals in the SCADA expansion project was to deliver results in real time. For this, sensors experiments were performed to determine which one would have the faster response. An index to take into account is the time response, it can be appreciated in Figure 6 but is practically the same, therefore we measured the settling time from the moment when the leakage valve is opened. In Figures 7, 8 and 9 the flow development is observed, dotted line indicates the time when the leakage valve is opened to 100%. In Table 3 are the measured times, being the ultrasonic sensor which requires more time (this by the number of points used to calculate a mean value).
Considering the settling time and noise in measurements (taking the STD as the measure for that), Coriolis sensor has the best performance. Experiments showed in this section were made with 1 s sampling period. 6
In the academy, we are used to work with benchmark systems or laboratory facilities with ad hoc data acquisition systems, sufficient sensors, controlled environments, etc. But these conditions are not necessarily in the practice, as was the case of the SCADA expansion, where the access to flow and pressure sensors of the pipeline were not available, but through a database. So the solution adopted was as follows: 1. The leak locator is on a dedicated computer, independent of the system that regulates de distribution of the fluid, it connects to the database server, see Figure 10, via intranet or VPN (Virtual Private Network) connection in a LAN (Local Area Network) system. 2. With proper permission a program, task performed with Visual Studio 2010 tool that runs every minute (it is a program without GUI -Graphic User Interfacerthat runs silently), brings system data and creates a database with pipeline flow and pressure information, data required by the locator for proper operation. 3. The locator program (made in the LabVIEW platform, [16]) periodically takes data (through SQL data server of Microsoft), applies the detection algorithm and when detects a leak proceeds to locate it, displays on the screen the location of the leak (Figures 12 and 13), generates a visual warning and creates a file with data leakage.
But the data acquisition system of SCADA do not meet the condition of sampling the system variables with constant sampling period. The nominal sampling period was 3 min, but in reality this varies from one to several tens of minutes. On the other hand, the locator was assigned a sampling period of 3 min, determined by the condition that nominally SCADA performs a polling of all measuring stations in that time span. To solve the problem of having a value of flow and pressure of each station at all sampling time, it was added to the localizer an algorithm that extrapolates the missing data when it is not available. Two algorithms were tested, one that retains the last data in the following sampling periods and one that generates straight line with the last two values available, that when the value of the variable that is brought from the database is not a new one, then the one determined by straight line is used. In order to compare results with both proposals a simulation with real data with 17.5
17 i] n 3 /m [m16.5 w o l F
16 15.50 three leaks was carried on, in Figure 11 the real and extrapolated input flow data are shown. It can be seen that at certain intervals the extrapolation by a straight line delivers values that may be beyond the normal range of measurements, this situation is exacerbated in large intervals with empty data as the line grows monotonically delivering data outside the region of validity. In Figure 12 the location of a leak is shown when extrapolated data are used and in Figure 13 when retained data are used. The pipe length is about 20 km, so that retention has outperformed extrapolation, since the latter yields higher values than the length of the pipe. Original leak location was about 10 km.
Extrapolation Retained
Real 50 6.1 Alternate database communication As part of the project requirements, an alternate way of communication with the SCADA database was experimented. In previous section the communication between leak locator and database was direct trough a LAN system, the alternate way was through a third party via internet and VPN connection. Figure 14 shows the principal elements of this scheme.
The client is the computer with the locator program build in LabVIEW platform that performs basically two activities: leak detection and location, and request and sending data to communications broker using JSON strings. The remote client interface is a Java process that runs locally and handles communication, authentication, data formatting, encryption and security of the communication with data server.
It connects to the database in the SCADA through TCP sockets and VPN. For data handling JSON format is used, which is broadly used for information interchange trough internet. JSON (Java Script Object Notation) is a data interchange text format, easy for humans to read and write [17]. JSON is a collection of pairs {variable name : value}, realized as an object, record, structure, dictionary, hash table, keyed list, or associated array, see in Figure 15 an object example.
Communications broker attends clients requests (leaks locator is not the only one) and also SCADA requests. The database attached to the broker contains not only pipeline data but also data generated by the other clients. At the end, the SCADA has an interface in which information of leakage events is displayed.
Figure 16 shows a test ran with real data but off line. That
experience showed that locator not always received answers
from the broker. But this communications scheme is still in
development.
An interesting result is that a pipeline with certain
topography may be analyzed as an horizontal pipe in which the
piezometric head is a sum of measurements and terrain
heights, Equation (
Compared with traditional methods for locating a leak in a pipe, the method shown here, Equation (22), requires less computational effort and has a simple expression for calculating it.
Another relevant result is the expression for on line calculation of the pipeline friction, Equation (25), as it is enough to measure pressure at the ends and steady state flow. The value of friction was found to be a key parameter for the exact location of the leak. It is to remark that when a leak occurs the pressures change modifying the friction value; in order to avoid wrong location of the leak we keep a delayed value of friction that is frozen when leak alarm occurs.
On the other hand, is to highlight the importance of choosing the appropriate sensor. It is not enough to choose a sensor capable of measuring a certain physical variable, also must be included in the selection process the purpose for which the measurements are needed.
The world of measurements for control targets is not limited to direct measurement of the physical variable, it is possible to achieve the control objectives with indirect measurements, as was the case of reading the variables from the plant via the network to a database. Also, with the partial absence of data we cannot use the plant model to predict data, then the use of extrapolation methods proves to be a powerful tool that helped to achieve the goal of this project; in this paper we use two simple methods, but this is an area that we continue to explore.
The experience with JSON format strings showed that it is easier to work with text characters than with specialized database commands and, no matter the VPN connection and data encryption, the scheme depends strongly on internet conditions. If internet fails leak detection scheme fails, situation that scarcely appears when the locator connects with database through a LAN system.
To the moment this paper was written our FDI system is in the proof stage at the SCADA facilities and we are waiting for in the field results. 8
Authors are very thankful to Jonathán Velázquez who helped us by solving the database issues emerged in this project.
Proceedings of the 26th International Workshop on Principles of Diagnosis 152