Vi har ett avloppsnätverk där vi övervakar flödet mellan olika punkter för att effektivt budgetera och prioritera underhållsåtgärder. För detta ändamål vill vi beräkna mängden tillskottsvatten \((I)\) som tillkommer i sektionerna \[ B \to A, \; C \to A, \; D \to A, \; E \to A \]

Formeln som används för beräkningen är:

\[ I_{b,c,d,e \to a} = Q_a - (Q_b + Q_c + Q_d + Q_e) \]

där \(Q_x\)​ representerar flödet från respektive sensor vid nod \(x\). Grafen nedan visar beräknat tillskottsvatten för den givna tidsperioden.

Problemet

Vid analys av grafen kan vi observera att från cirka 27 mars till 10 april har vi negativt tillskottsvatten, vilket innebär att systemet förlorar vatten snarare än att få tillskott. Detta skulle kunna tyda på en läcka, men eftersom vi vet att inga åtgärder utfördes runt den 17 april, är en fysisk läcka osannolik. Därför är det mer troligt att en eller flera sensorer (B, C, D eller E) visar felaktiga värden under denna period.

Analys av individuella sensorer

För att kunna identifiera vilken sensor som är orsaken till felet, behöver vi undersöka mätdata från respektive sensor.

Sensor B ser också väldigt annorlunda ut innan 17e April och efter.

Datan från sensor C visar tecken på kommunikationsproblem. Värdena är ojämna och saknar stabilitet, vilket indikerar möjliga störningar i överföringen. Vid närmare observation ser vi också att flödet ofta ligger runt \(4 \, \text{m}^2\)

Tidsserien för Sensor D visar ett tydligt, ovanligt högt inflöde mellan 13 och 17 mars. Utöver detta verkar mätvärdena vara stabila och utan tydliga avvikelser.

Utmaningar med att identifiera felaktiga sensorer

Det är alltså svårt att identifiera vilken sensor som är felaktig enbart baserat på data. Ett möjligt sätt att närma sig detta problem är att fortsätta felsöka genom att visualisera summan av de ingående noderna jämfört med enskilda noder. Detta är dock tidskrävande och kräver stor ansträngning från expertens sida.

Konkretisering och avgränsning av problemet

Då detta är ett specifikt fall så gör vi problemet mer generellt. För det första så säger vi att vi litar på tidsserie A, detta är ett rimligt antagande då data från sensor A faktiskt inverkar på daglig operation av reningsverket. Hade sensorn varit trasig finns stort intresse att byta ut den eller åtminstone dokumentera att den är trasig

Vi antar följande:

• Typ: Varje tidsserie (\(S\)) representerar ett vattenflöde som mäts i samma enhet.

• Kointegrerade: Tidsserierna är uppströms eller nedströms från en gemensam punkt.

• Mängd:

  • \( N \in \{2\} \): Vi jämför två tidsserier åt gången

  • \( S(t), T<10 000 \): max 10000 tidssteg per tidsserie

Krav

Algoritmen ska returnera följande:

Alla tidssteg \( t \) där skillnaden mellan \( S\_A(t) \) och \( S\_B(t) \) överstiger ett angivet tröskelvärde, så att avvikelsen inte kan förklaras av slumpen.

Tillvägagångssätt

Den kanske bästa lösningen är att ha en model \(G\) som är tränad på indata \( G ( S_{b},S_{c},S_{d},S_{e} ) = \hat{S}_{a} \). Då kan vi hitta när en sensor avviker \( | \hat{S}_{a} - S_{a} | > threshold \). Problemet med denna lösning är att vi inte har en period där all sensorer fungerar att träna på. Då är vi tillbaka på ruta ett.

Förenkling

Givet tidsserie \( S_{c} \) där \(c\) är en koordinat kan den totala flödesbelastningen modelleras som en summa av Spillvatten \((SV)\) och Tillskottsvatten \((TV)\) enligt:

\[ S_{c} = SV_{c} + TV_{c} \]

Därmed får vi för uppskattad belastning vid en nod \(\hat{S}_{a}\):

\[ \hat{S}_{a} = (TV_b + SV_b) + (TV_c + SV_c) + (TV_d + SV_d) + (TV_e + SV_e) \]

För sensorpositioner som är nära varandra, så att

\[ distance(coord_a), (coord_b)) \to 0 \]

kan vi anta att:

\[ \hat{S}_{a} \approx \alpha_b \times S_b \]

där  \( \alpha_b \) är en konstant proportionalitetsfaktor. Detta leder till att:

\[ \hat{S}_{a} \propto S_b \]

Vidare kan proportionalitetsfaktor tas bort genom normalisering

\[ \text{NORM}(S_a) = \text{NORM}(S_b) \]

Vi dividerar på snittet för att normalisera.

\[ \frac{S_a}{\text{mean}(S_a)} = \frac{S_b}{\text{mean}(S_b)} \]

Delproblem 1

För att räkna ut hur mycket tillskottsvatten som tillkommer måste vi ta reda på vilken tidsserie som är mest olik den vi litar på. Detta kan göras med t.ex. linjär regression och kommer bli nämnt i ett senare blogginlägg. Då vi har satt ett scope på 10 tidsserier kan vi testa alla mot alla!

Delproblem 2

Vi använder \( \hat{S}_{a} \propto S_b \) och hittar vilken tidsserie som är mest olik de andra!

Vi börjar med att göra det grafiskt. NORM(\( S_{trust}\)) tidsserie och jämför med NORM(\(S_N\))

DTW with sliding window

För att räkna ut avståndet mellan två tidsserier så får vi

\[ \text{distance} = S_a - S_b \]

Detta är dock problematiskt då tidsserier uppströms kommer ligga några tidsteg före en tidsserie som ligger nedströms. Vi använder oss av Dynamic Time Warping (dtw) som ger ett värde på hur olika dessa är. Eftersom vi vill se vilken period som skiljer sig så beräknar vi skillnaden i mindre perioder och stegar igenom tidsserierna, ett så kallat Sliding Window (SW size). nedan går vi igenom storleken

Storleken på fönstret

Idén är att när fönstret blir mindre är det lättare att isolera små avvikande områden. Eftersom DWT-avståndet mellan sensorerna ökar när sliding window blir större (om de inte är exakt likadana), justeras detta i den tidigare nämnda tröskeln genom att multiplicera den med fönstrets storlek. Vi kan inte ha för korta fönster, eftersom varje del normaliseras baserat på medelvärdet för samma period. Ett fönster med endast en punkt skulle alltid ge avståndet 0, vilket innebär att det teoretiskt sett minsta fönstret är 2.

Window Size 720 (30 dagar)

Window Size 360 (15 dagar)

Window Size 240 (10 dagar)

Window Size 120 (5 dagar)

Window Size 48 (2 dagar)

Detaljerad visualisering av tidsserieavvikelse över 7-dagarsperioder

För att göra Anomaly Score-värdena lättare att tolka visar vi här en alternativ graf. I grafen nedan representeras Anomaly Score med en grön linje för hela den jämförda perioden, vilket hjälper läsaren att få en tydligare överblick över hur de olika tidsserierna varierar varje 7-dagarsperiod.

Threshold

Vi har haft stor framgång med följande:

\(\mathrm{threshold} = \frac{11}{120} \times \mathrm{SlidingWindowSize}\)

Nedan applicerar vi detta för att hitta anomalier:

\( \text{dtw}(a, b).\text{distance} > \text{threshold} \)

Applicering av modellen

Testa modellen på tidsserie D och jämför den med dem betrodda serierna. Om vår teori stämmer, kommer användningen av Dynamic Time Warping Sliding Window att ge ungefär lika resultat när den jämförs med någon av de betrodda tidsserierna under samma period.

Vi ritar även ut när en mänsklig expert har annoterat sensorn som trasig.

\(
\begin{array}{|c|c|c|c|c|c|c|c|}
\hline
\text{Series} & \text{TP} & \text{FP} & \text{TN} & \text{FN} & \text{Precision} & \text{Recall} & \text{F1} \\
\hline
A & 515 & 61 & 884 & 5 & 0.894097 & 0.990385 & 0.939781 \\
B & 520 & 656 & 289 & 0 & 0.442177 & 1.000000 & 0.613208 \\
C & 515 & 61 & 884 & 5 & 0.894097 & 0.990385 & 0.939781 \\
D & 515 & 61 & 884 & 5 & 0.894097 & 0.990385 & 0.939781 \\
E & 443 & 61 & 884 & 77 & 0.878968 & 0.851923 & 0.865234 \\
F & 419 & 61 & 884 & 101 & 0.872917 & 0.805769 & 0.838000 \\
\hline
\end{array}
\)

Avslutningsvis

Genom att använda denna DTW-baserade metod med glidande fönster kan vi isolera perioder med avvikande vattenflöde, vilket gör det möjligt att identifiera felaktiga givare även i komplexa datamängder. I följande graf undersöker vi om modellen kan upptäcka en förbipumpning (en operationell anomali).