Hvorfor der s\u00e5 let opst\u00e5r et parallelt system<\/h2>\n
PLC og SCADA styrer anl\u00e6gget i realtid, hvor hvert sekund t\u00e6ller. De nye LoRaWAN-sensorer skal noget andet: give overblik, historik og rapporter om fugt, tryk, vandstand eller temperatur. To verdener med hver sin logik.<\/p>\n
Derfor lander m\u00e5lingerne ofte i en separat skyportal. Det er den hurtigste vej i gang, n\u00e5r driften selv k\u00f8ber sensorer ind.<\/p>\n
Prisen kommer senere. To sandheder om samme anl\u00e6g, to alarmlister og ingen f\u00e6lles historik, n\u00e5r nogen skal forklare en afvigelse. Driftsfolk skifter mellem sk\u00e6rme, og beslutninger om service og vedligeholdelse tr\u00e6ffes p\u00e5 et ufuldst\u00e6ndigt grundlag. Det g\u00e6lder ikke mindst udend\u00f8rs, hvor udend\u00f8rs IoT-overv\u00e5gning af klimask\u00e6rmen<\/a> ellers nemt bliver endnu en portal at holde \u00f8je med.<\/p>\n Artiklens \u00e6rinde er ikke at v\u00e6lge mellem de to systemer. Det er at f\u00e5 de nye m\u00e5linger ind i det SCADA\/HMI, driften allerede stoler p\u00e5, frem for at leve med et system ved siden af.<\/p>\n N\u00e5r beslutningen er taget om at undg\u00e5 et parallelt system, f\u00f8lger dataene en fast k\u00e6de i fem trin.<\/p>\n Trin 1, sensoren:<\/strong> En LoRaWAN-sensor m\u00e5ler og sender sm\u00e5 datapakker, typisk nogle f\u00e5 snese bytes. Rapporteringsintervallet ligger ofte p\u00e5 minutter frem for sekunder, afh\u00e6ngigt af ops\u00e6tningen. Det passer til overv\u00e5gning, hvor udvikling er vigtigere end millisekundprecision, for eksempel vandstand i forsyningsnettet<\/a>.<\/p>\n Trin 2, gatewayen:<\/strong> Gatewayen samler pakker fra mange sensorer og videresender dem. LoRa r\u00e6kker typisk flere kilometer i bymilj\u00f8 og l\u00e6ngere i \u00e5bent terr\u00e6n, men den faktiske r\u00e6kkevidde afh\u00e6nger helt af placering, bygninger og forstyrrelser.<\/p>\n Trin 3, netv\u00e6rksserveren:<\/strong> L\u00f8sninger som TTN, ChirpStack, Actility eller LORIOT godkender enheder, fjerner dubletter og afkoder payload til l\u00e6sbare v\u00e6rdier som grader, liter eller bar.<\/p>\n Trin 4, integrationen:<\/strong> Afkodede v\u00e6rdier hentes via MQTT eller HTTP og \u00e5bne API’er. Her afg\u00f8res, hvilket system der reelt ejer data.<\/p>\n Trin 5, SCADA\/HMI:<\/strong> V\u00e6rdierne vises p\u00e5 samme sk\u00e6rmbillede som resten af driften, med samme alarmer og historik.<\/p>\n En vigtig ramme: EU-reglerne om duty cycle begr\u00e6nser, hvor ofte radioen m\u00e5 sende. LoRaWAN er derfor ikke en hurtig realtidskanal, men til overv\u00e5gning er det en fordel, fordi sensoren kan k\u00f8re p\u00e5 batteri i \u00e5revis.<\/p>\n N\u00e5r datastien er p\u00e5 plads, st\u00e5r en vigtig arkitektur-beslutning tilbage: Hvad skal LoRaWAN-sensoren egentlig bruges til i dit anl\u00e6g? Kontrolsl\u00f8jfer, hvor en ventil skal \u00e5bne eller en pumpe regulere flow sekund for sekund, h\u00f8rer fortsat hjemme p\u00e5 kablede PLC’er med forudsigelig responstid. LoRaWAN er bygget til at overv\u00e5ge, ikke til at styre. Derfor skal du ikke rive automatiseringen ud. Du l\u00e6gger et overv\u00e5gningslag oven p\u00e5 det, der allerede virker.<\/p>\n Arbejdsdelingen er enkel: PLC’en styrer pumpen, mens LoRaWAN-sensoren fort\u00e6ller, at vandstanden i br\u00f8nden er ved at blive unormal. Gevinsten er, at godkendte styringsprogrammer og eksisterende sikkerhedslogik forbliver ur\u00f8rt, hvilket g\u00f8r \u00e6ndringen nem at forsvare over for b\u00e5de drift og ledelse. N\u00e5r m\u00e5lingerne samtidig ligger i SCADA, samles gr\u00e6nsev\u00e6rdier, alarmer og historik \u00e9t sted i stedet for i to systemer, der ikke kender hinanden.<\/p>\n N\u00e5r m\u00e5lingerne f\u00f8rst lander i SCADA, bliver n\u00e6ste sp\u00f8rgsm\u00e5l uundg\u00e5eligt: hvor skal de egentlig bo? Dataejerskab handler ikke om jura, men om noget s\u00e5 konkret som, hvor den originale m\u00e5ling gemmes, hvem der kan l\u00e6se den, og hvem der bestemmer over den om fem \u00e5r. Det er den beslutning, der afg\u00f8r, om l\u00f8sningen kan vokse, og om du senere kan skifte leverand\u00f8r uden at miste historikken.<\/p>\n V\u00e6lg ud fra driftens behov f\u00f8rst og teknologi bagefter. Sp\u00f8rg dig selv: hvem skal kunne se data om fem \u00e5r, og hvad skal de bruge dem til? L\u00e6s mere om, hvordan du v\u00e6lger en platform, der kan vokse med din bygningsmasse<\/a>.<\/p>\n Uanset hvor data ender, b\u00f8r aftalen beskrive tre ting: hvem der har adgang, hvordan data eksporteres, og hvad der sker, hvis samarbejdet stopper.<\/p>\n N\u00e5r valget falder p\u00e5 SCADA eller on-premise, skrives m\u00e5lingerne direkte ind i det eksisterende SCADA. Her bliver de en del af den f\u00e6lles historik og de f\u00e6lles alarmer, og driften arbejder i det v\u00e6rkt\u00f8j, de allerede stoler p\u00e5. Der opst\u00e5r ingen ny portal at logge ind i. Det kr\u00e6ver en integration, der kan tage imod MQTT eller kalde et \u00e5bent API, plus en klar aftale om, hvordan netv\u00e6rksserveren forbinder sig sikkert. Modellen passer bedst, n\u00e5r internetadgang er begr\u00e6nset, eller n\u00e5r data af forretningshensyn ikke skal forlade huset. V\u00e6r opm\u00e6rksom p\u00e5 ulempen: fjerntliggende anl\u00e6g kan v\u00e6re sv\u00e6rere at samle, og skal data senere ud, kr\u00e6ver det ekstra arbejde. Vil du forst\u00e5 m\u00e5lelaget f\u00f8rst, kan du l\u00e6se om tr\u00e5dl\u00f8s overv\u00e5gning af bygninger<\/a>.<\/p>\n Her er gatewayen eller et lille integrationslag bindeleddet: den taler LoRaWAN p\u00e5 den ene side og MQTT eller et \u00e5bent API p\u00e5 den anden. Fordelen er fleksibilitet. Den samme m\u00e5ling kan sendes til SCADA til drift og til et rapporteringsmilj\u00f8 til opf\u00f8lgning, uden at der bygges to installationer. Moderne gateways findes i udgaver, der kan sende data videre til b\u00e5de OPC UA mod SCADA\/MES og MQTT mod skyen samtidig. Det er et markedseksempel p\u00e5, at dobbelt udstyr ikke er n\u00f8dvendigt. L\u00e6s mere om gateway-mulighederne her<\/a>.<\/p>\n Ulempen er, at integrationslaget bliver et nyt kritisk punkt, som nogen skal eje, opdatere og kunne fejlfinde p\u00e5, ogs\u00e5 en s\u00f8ndag nat. Aftal derfor p\u00e5 forh\u00e5nd, hvem der har ansvaret for netop det lag, og hvordan en konfiguration gendannes efter et nedbrud. Det er den slags detalje, der ellers f\u00f8rst bliver besvaret, n\u00e5r nogen er g\u00e5et p\u00e5 pension. N\u00e6ste mulighed er at l\u00e6gge dataejerskabet i skyen med \u00e5ben eksport.<\/p>\n Det sidste sted, dataejerskabet kan ligge, er i skyen, og her afh\u00e6nger alt af \u00e5benheden. M\u00e5lingerne gemmes i en platform, som ogs\u00e5 h\u00e5ndterer enheder, dashboards, alarmer og rapporter, og hentes derefter ind i SCADA via MQTT eller et \u00e5bent API. Styrken er, at onboardning af nye sensorer, historik og brugervenlig visning er l\u00f8st fra dag et, ogs\u00e5 p\u00e5 tv\u00e6rs af mange bygninger. Foruds\u00e6tningen er, at data kan eksporteres og hentes via API uden s\u00e6rlig tilladelse, og at aftalen ikke l\u00e5ser dig til \u00e9n leverand\u00f8r. Sp\u00f8rg konkret: Hvordan eksporterer vi alle r\u00e5data, hvilke formater f\u00e5r vi dem i, og hvad koster det, hvis vi vil flytte dem? Det passer godt til organisationer med mange sm\u00e5 anl\u00e6g, hvor et fuldt SCADA-projekt pr. sted vil v\u00e6re uforholdsm\u00e6ssigt dyrt. Synkronisering av sensordata till andra system<\/a> viser, hvordan data kan tr\u00e6kkes ud.<\/p>\n Uanset hvor dataejerskabet ligger, hviler integrationen p\u00e5 f\u00e5, kendte mekanismer. MQTT fungerer som et let samlingspunkt, hvor modtagerne abonnerer p\u00e5 de emner, de skal bruge, frem for at sp\u00f8rge konstant; det passer til mange sm\u00e5 m\u00e5linger MQTT 5.0<\/a>. \u00c5bne API’er lader dig tr\u00e6kke v\u00e6rdier ind i den historik og de rapporter, I allerede bruger, og kombinere dem med data fra andre systemer, fx luftkvalitetssensorer i bygninger<\/a>. Gamle instrumenter kan ogs\u00e5 med: 4-20 mA og Modbus RS485 f\u00f8res ind i LoRaWAN via noder, s\u00e5 de bliver en del af netv\u00e6rket uden udskiftning. Sensor-Online leverer b\u00e5de platform og sensorer, hardware-agnostisk med dashboards, alarmer, rapporter og integration mod LoRaWAN, Modbus, OPC, MQTT, PLC\/SCADA og \u00e5bne API’er, uden leverand\u00f8rl\u00e5s. V\u00e6lg f\u00e5 mekanismer og brug dem konsekvent; det g\u00f8r vedligeholdelse og fejlfinding lettere for dem, der overtager l\u00f8sningen.<\/p>\n N\u00e5r protokollerne er valgt, afg\u00f8r fysikken, om l\u00f8sningen holder. Gatewayens placering betyder ofte mere end databladet: h\u00f8jde hj\u00e6lper, mens tykke betonv\u00e6gge, metal og k\u00e6ldre typisk sv\u00e6kker signalet. Planl\u00e6g ogs\u00e5 for, at gatewayen falder ud. Beskriv p\u00e5 forh\u00e5nd, hvad der sker med m\u00e5linger, alarmer og historik, mens den er v\u00e6k, og lad gateway eller netv\u00e6rksserver buffere data. S\u00e5 undg\u00e5r korte udfald huller i historikken og falske alarmer bagefter. Test d\u00e6kningen i marken med de faktiske sensorer i stedet for kun at regne p\u00e5 r\u00e6kkevidde. En enkelt eftermiddag kan spare uger med forklaringer. Skriv til sidst ned, hvem der ejer gatewayen, hvem der har adgang, og hvordan en udskiftning foreg\u00e5r uden at r\u00f8re resten af anl\u00e6gget. S\u00e5 bliver redundans en aftalt rutine, ikke en overraskelse.<\/p>\n N\u00e5r gatewayen er p\u00e5 plads og ejerskabet er aftalt, er n\u00e6ste skridt at holde netv\u00e6rket adskilt. Hold OT og IT adskilt, og v\u00e6r bevidst om pr\u00e6cis hvilke veje data krydser, og hvad der reelt har tilladelse til at krydse. MQTT kan sikres med kryptering og adgangsstyring pr. enhed, s\u00e5 \u00e9n kompromitteret sensor ikke \u00e5bner for alt andet. LoRaWAN krypterer p\u00e5 b\u00e5de netv\u00e6rks- og applikationsniveau, hvilket er en del af grunden til, at teknologien egner sig til m\u00e5linger uden for egen bygning. Giv sensorer og gatewayer egne netv\u00e6rk eller segmenter, og tag det med i den sikkerhedsgennemgang, I allerede laver, frem for at lave en separat proces. Not\u00e9r til sidst, hvem der har n\u00f8gler og konti, og hvordan de skiftes. Det er den slags detalje, der ellers f\u00f8rst bliver besvaret, n\u00e5r nogen er g\u00e5et p\u00e5 pension. Med styr p\u00e5 adskillelse og adgang kan vi g\u00e5 videre til tjeklisten.<\/p>\n N\u00e5r netv\u00e6rksadskillelse og n\u00f8gleansvar er p\u00e5 plads, er n\u00e6ste skridt at g\u00f8re beslutningerne eksplicitte, f\u00f8r f\u00f8rste LoRaWAN-sensor g\u00e5r i drift.<\/p>\n Det er de syv beslutninger, der g\u00f8r en LoRaWAN-integration til en del af driften frem for et nyt system ved siden af.<\/p>\n Checklisten er gennemg\u00e5et. Nu kan du med ro i maven v\u00e6lge begge dele: dit velfungerende PLC- og SCADA-landskab f\u00e5r lov at styre, mens LoRaWAN l\u00e6gger sig som et overv\u00e5gningslag ovenp\u00e5. Datastien bygges af kendte dele, sensor, gateway, netv\u00e6rksserver og integration via MQTT eller \u00e5bne API’er, og ender i det HMI\/SCADA, driften allerede kender. Brug kr\u00e6fterne p\u00e5 den beslutning, der betyder mest: hvor dataejerskabet ligger. Resten er teknik, der kan l\u00f8ses undervejs. Start sm\u00e5t med et enkelt anl\u00e6g, test d\u00e6kning og integration i marken, og udvid f\u00f8rst, n\u00e5r det virker. Det er den hurtigste vej til at undg\u00e5 et parallelt system. Er du i tvivl om, hvordan sensorer, gateways og netv\u00e6rksservere kobles bedst p\u00e5 netop jeres opbygning, s\u00e5 tag fat i os. Som Sveriges st\u00f8rste leverand\u00f8r med erfaring p\u00e5 tv\u00e6rs af bygninger, energi, vand og industri hj\u00e6lper vi gerne med de tekniske detaljer. Skriv til info@nodeledge.se<\/a> eller ring p\u00e5 +46 (0)500 6000 22.<\/p>\nS\u00e5dan n\u00e5r LoRaWAN-sensorer ind i dit SCADA\/HMI: datastien skridt for skridt<\/h2>\n
Styringen bliver i PLC’en: LoRaWAN som overv\u00e5gningslag<\/h2>\n
Beslutningen der betyder mest: hvor skal dataejerskabet ligge?<\/h2>\n
Dataejerskabet i SCADA eller on-premise<\/h3>\n
Dataejerskabet i gatewayen eller integrationslaget<\/h3>\n
Dataejerskabet i skyen med \u00e5ben eksport<\/h3>\n
Byggeklodserne: MQTT, \u00e5bne API’er og konvertering af eksisterende signaler<\/h2>\n
Gateway-placering og redundans i den virkelige verden<\/h2>\n
![](\"https:\/\/sensor-online.se\/wp-content\/uploads\/2026\/10\/TJd0JO4Nemv5IDfMk1qJH.webp\")
<\/figure>\nSikkerhed og adskillelse af netv\u00e6rk, holdt jordn\u00e6rt<\/h2>\n
Tjekliste: s\u00e5dan undg\u00e5r du faldgruberne<\/h2>\n
\n
Kort sagt: behold styringen, berig den<\/h2>\n
![](\"https:\/\/sensor-online.se\/wp-content\/uploads\/2026\/10\/UW9genbNakW2I0xywdaJF.webp\")
<\/figure>\nSlutsats<\/h2>\n