Forestil dig at stå med ansvaret for en kommunes vand- og regnvandssystem, hvor du kun får besked, når noget allerede er gået galt. Sådan fungerer hverdagen i mange kommuner, hvor tilsynet stadig klares med faste ruter og manuelle aflæsninger. Men hvad sker der, når man begynder at overvåge niveau, flow og overløb i realtid? Denne case fortæller historien om én kommunes rejse fra traditionelle rutiner til digital overvågning.Undervejs dykker vi ned i, hvorfor det giver mening at starte ved en håndfuld kritiske boringer og overløbsbygværker, hvad der typisk skal eftermonteres, og hvad det første år faktisk afslørede. Vi ser også på, hvorfor det ikke er sensorerne, men derimod alarmlogikken og driftsrutinerne, der tager tid at få på plads. Du får konkrete erfaringer med IoT i kommuner og en praktisk tilgang til at komme i gang uden at bygge hele systemet på én gang.Undervejs i artiklen bevæger vi os gennem sektioner som udgangspunktet med manuelle tilsyn, valget af kritiske målepunkter, eftermontering, realtidsdata, alarmlogik, overraskelserne fra det første år, og hvordan I kan starte småt. Har du spørgsmål undervejs, er du altid velkommen til at kontakte os på info@nodeledge.se eller ringe på +46(0)500 6000 22.
Udgangspunktet: manuelle tilsyn og kendte risici
Den regulatoriske ramme sætter spillereglerne. Miljøbeskyttelsesloven, Miljømålsloven, Lov om vandplanlægning, Spildevandsbekendtgørelsen og Vandrammedirektivet peger alle mod samme krav: en udledningstilladelse fastlægger, hvor meget der må komme ud, og hvilke koncentrationer og stofmængder der er acceptable (Miljøstyrelsen).
I praksis starter billedet et helt andet sted. Viden om overløb kommer fra skemaer, manuelle aflæsninger ved tilsyn og borgerhenvendelser efter kraftig regn. Altså bagefter hændelsen, hvor vandet for længst er videre. Det er netop den forskel, overvågning skal lukke, og springet fra manuel aflæsning til realtidsdata handler om at gå fra at rekonstruere til at vide.
Skalaen gør behovet konkret. Københavns spildevandsplan dækker cirka 68 km² kloakeret areal, omkring 1.100 km ledninger og 84 små og store pumpestationer. Omkring 80 % af arealet er fælleskloakeret, hvor regnvand og spildevand deler rør.
Det ændrer, hvad overvågningen skal kunne fortælle. Overløb er i høj grad et planlagt fænomen og ikke en fejl. Opgaven bliver at skelne det forventede overløb fra det uventede og at dokumentere mængde og varighed. Udstyret skal samtidig stå udenfor i al slags vejr, hvilket stiller sine egne krav til udendørs IoT-overvågning.
En vigtig rammesætning: fortællingen her er et repræsentativt mønster bygget på offentligt tilgængelige planer og regulering. Ikke en navngiven kommune med opdigtede tal og resultater. Erfaringerne skal komme fra rigtige driftslogs, ikke fra gætværk.
Derfor starter overvågningen ved en håndfuld kritiske boringer og overløbsbygværker
Når udgangspunktet er manuelle tilsyn og viden, der først kommer bagefter regnen, bliver næste spørgsmål ikke, hvor mange målere der kan monteres, men hvor en måling reelt gør ondt at mangle.
Vælg startpunkter efter risiko og konsekvens. Det betyder boringer, der forsyner mange borgere, og overløbsbygværker, der udleder til badevand eller særligt sårbare recipienter. To velvalgte målepunkter kan give mere driftværdi end tyve tilfældige, fordi pointen er at kunne svare på konkrete spørgsmål, ikke at dække hele nettet i første forsøg.
Københavns Spildevandsplan 2018 arbejder målrettet med at reducere overløb for bedre badevandskvalitet og peger samtidig på overløbsbygværker, der udleder til ferskvandsrecipienter. Det viser, hvilke bygværker der typisk er kritiske.
Overvågningen skal holde i årtier, ikke i en sæson. Planen vurderer, at separering af hele det berørte opland tager 20 til 30 år, og et anlæg under ombygning kan skifte karakter undervejs. Derfor skal både målepunkter og alarmlogik kunne tåle forandring. Har I midlertidige anlægsfaser, kan erfaringerne fra byggepladsovervågning med IoT være nyttig inspiration.
Skriv valget ned: hvorfor netop disse punkter blev valgt, hvilke spørgsmål de skal besvare, og hvad der skal til for at udvide senere. Det gør det langt lettere at argumentere internt, når næste bølge af målinger skal finansieres.
Hvad er der typisk blevet eftermonteret, og hvad kunne blive siddende
Når de kritiske punkter er valgt, er næste spørgsmål, hvad der egentlig skal op at hænge. Svaret er ofte mindre, end man tror.
Eksisterende udstyr kan nemlig ofte genbruges. Mange overløbsbygværker og pumpestationer har allerede niveausensorer eller signaler, der ligger i en PLC eller et SCADA-system, og som blot mangler at blive løftet ud til omverdenen.
Det, der reelt eftermonteres, er sjældent en ny sensor. Det er oftere en datalogger, en strømforsyning, en vejrbestandig kapsling og en forbindelse, der kan holde til fugt, frost og rørvand.
Hvor der hverken findes strøm eller signal, er trådløs langtrækkende forbindelse som LoRaWAN eller NB-IoT en praktisk vej. Den arbejder i baggrunden uden kompleks kabling, og batteridrift gør måling mulig på steder uden eltavle.
Hvor der slet ikke findes måling, monteres typisk en niveausensor i brønd eller overløbsbygværk og eventuelt en flowmåler på udløb. Niveau viser, om der løber vand over tærsklen, mens flow viser hvor meget.
Rækkefølgen betyder noget: verificer først i marken, at målingen er troværdig og reagerer fornuftigt ved test, og kobl den først derefter til dashboards og alarmer. Ellers får driften hurtigt mistillid til tallene. Myndighederne peger også på, at måleudstyr skal vedligeholdes for at være retvisende (LF’s høringssvar). Samme platform kan senere bære andre sensortyper, fx luftkvalitetssensorer i bygninger.
IoT i kommuner: niveau, flow og nedbør bliver synlige i realtid
Når målingen er verificeret i marken, begynder den egentlige gevinst: at se niveau, flow og nedbør samlet i realtid. I kommuner betyder IoT i praksis små enheder, der løbende rapporterer om deres omgivelser til et fælles sted. Det kan være niveauet i brønden, flowet i ledningen og nedbøren over oplandet. Værdien ligger i at se det nu, ikke i næste måneds rapport. Vil du forstå målelaget mere generelt, kan du læse om hvad trådløse IoT-sensorer måler i bygninger.
Niveaumåling i et overløbsbygværk fortæller, om vandet når tærsklen, og hvor længe det står over. Forestil dig, at den hændelse først opdages ved et manuelt tilsyn tre dage senere. Det er dyr viden, fordi både dokumentation og indsats kommer bagefter.
Flowmåling på udløb eller i hovedledning giver mængde og varighed, ikke bare tilstedeværelse. Det er grundlaget, når hændelser skal dokumenteres og prioriteres, eksempelvis i den regulatoriske rapportering af regnbetingede udløb.
Nedbørsdata fra en lokal vejrstation eller regnmåler gør det muligt at skelne regnbetingede overløb fra driftsfejl. Uden den sammenhæng bliver hver hændelse et åbent spørgsmål.
Alt samles i dashboards og rapporter, hvor driftsansvarlige kan se status lige nu og gå tilbage i historikken bagefter. Det er først her, enkelte målinger bliver til et system, der kan bruges i hverdagen.
Alarmlogik og driftsrutiner tager længere tid end sensorerne
Når data først ligger i dashboards, begynder den egentlige opgave. Erfaringen fra den slags projekter er nemlig, at hardwaren hurtigt kommer op, mens alarmlogikken tager måneder. Spørgsmålet er ikke kun teknisk: hvornår er en hændelse en alarm, og hvornår er den blot normal drift?
Definér derfor tærskler med både forsinkelse og varighed. Uden det kan en enkelt bølge udløse varsling midt om natten, selvom vandet allerede var på vej væk. Aftal også eskalering helt konkret: hvem får besked, ad hvilken kanal, hvornår i døgnet, hvad er næste skridt, og hvornår lukkes alarmen igen. En alarm uden en ejermand bliver hurtigt støj.
Start med få alarmer og skærp dem undervejs, så I undgår alarmtræthed. For mange varsler gør, at de vigtige forsvinder i mængden, og så holder systemet op med at blive brugt.
Skriv driftsrutinerne ned: hvad gør vagten ved en varsling, hvad logges i driftsjournalen, og hvordan bruges hændelsen efterfølgende i den årlige rapportering og i prioriteringen af renovering? Det er her, overvågningen bliver et arbejdsredskab frem for endnu et system ved siden af.
Når I vælger platform, så sørg for, at den kan rumme jeres alarmlogik og ændres i jeres tempo. Læs om, hvordan I vælger den rigtige IoT-platform til bygninger i realtid, hvis I vil have kriterierne.
Det første år afslører ofte det, ingen havde regnet med
Når alarmlogikken begynder at ramme nogenlunde, viser det første år typisk noget andet, end man havde regnet med.
Kalibrering kommer før konklusioner
Bakkeopstuvning, tilstopning eller sensorer, der langsomt sætter sig, kan få tal til at se rigtige ud, når de ikke er det. En stor del af året går derfor med at finde de sager og rette dem, før de bliver til beslutninger.
Mønstre bliver synlige
Måske viser det sig, at overløb oftere skyldes korte, intense byger end langvarig regn, og at de klumper sig sammen på bestemte tider af døgnet. Den viden styrer, hvor indsatsen gør mest gavn.
Uventede forbindelser
Pumpestationer kan arbejde tættere på grænsen, end nogen antog, og bygværker kan reagere anderledes, end tegningerne antydede. Det er ikke nødvendigvis fejl, men ny viden om anlægget.
Tid går til logik, ikke hardware
Selv efter de første måneder bruges tiden mest på at justere alarmer og ikke på at skifte sensorer. Det bekræfter, at det er driftsrutinerne, der tager tid at få rigtige. Lidt samme pointe kender man fra anden løbende dataindsamling i praksis, hvor det er brugen af data, der skaber værdien.
Dokumentation er den største gevinst
Nu findes der data til at prioritere renovering, til dialogen med myndighederne om udledningstilladelser og til at forklare politisk, hvorfor et bestemt anlæg skal komme først i køen. Det er også den slags indsigt, der gør det lettere at vælge næste målepunkt med omhu.
Sådan kommer I i gang uden at bygge hele systemet på én gang
Når det første års erfaringer er på plads, er næste skridt at gøre dem til en metode frem for at bygge hele systemet på én gang. Start med at vælge tre til fem kritiske punkter, fx en boring, der forsyner mange, og et overløbsbygværk ved badevand. Skriv derefter ned, hvilke spørgsmål overvågningen skal besvare: Løber vandet over tærsklen om natten? Hvor længe varer overløbet? Kommer det efter regn eller uden? Når spørgsmålene står på papir, bliver valg af sensorer og netværk meget lettere.
Kør så et pilotprojekt i seks til tolv måneder. Evaluer det ikke på teknisk oppetid, men på hvor mange alarmer der reelt førte til handling, og på den driftsværdi I fik. Undgå samtidig at låse jer til én sensortype eller ét netværk. Vælg en løsning, der kan tale sammen med det udstyr, I allerede har, og som kan udvides i jeres eget tempo. Det sparer både penge og hovedpine senere.
Planlæg fra dag ét, hvordan dataene bruges i den daglige drift, i rapporteringen og i den flerårige investeringsplan. Ellers ender målingerne som et system ved siden af alt det andet. Få til sidst hjælp til det tekniske, så jeres egne folk kan bruge tiden på drift og prioritering. Det er sjældent ved sensoren, et projekt falder, men ved alt det omkring den.
De vigtigste erfaringer at tage med
Når piloten er sat i gang, er der især tre erfaringer, der er værd at holde fast i. Start småt på de rigtige punkter: et par kritiske boringer og overløbsbygværker giver mere værdi end et stort, halvfærdigt system. Regn samtidig med, at alarmlogik og driftsrutiner kræver mest tålmodighed. Det er dem, ikke sensorerne, der afgør, om overvågningen stadig bruges om tre år. Og første år betaler sig typisk tilbage i form af dokumentation og bedre prioritering, også selvom tallene i starten skal justeres. Vil I drøfte, hvordan det kan se ud hos jer, er I velkomne til at kontakte Sensor-Online (by Nodeledge) på info@nodeledge.se eller +46 (0)500 6000 22. Som Sveriges største leverandør inden for IoT og sensorbaseret overvågning og med et hardware-uafhængigt dashboard til alarmstyring på tværs af netværk og protokoller hjælper vi gerne med at oversætte jeres behov til konkrete valg. Vil I se mulighederne for måling tættere på, kan I også tage et kig på sensorer til realtidsovervågning af vand.
