IT-infrastruktur og strategi for IoT-enheder

AF LEILA IMER, SILKEBORG KOMMUNE Allerede i 2018 blev det klart for os i Teknik og Miljøafdelingen i Silkeborg Kommune, at denne nye teknologi kunne hjælpe os med at øge kvaliteten af vores service og at udføre vores arbejde mere effektivt. Derved begyndte vores spændende rejse mod en moderne datainfrastruktur. For at være klar havde vi IoT for ti år siden. Vi – ligesom mange andre kommuner – implementerede parkeringsskiltene for at hjælpe bilisterne med at navigere til ledige parkeringspladser. Men begrebet IoT var ikke populært dengang. I hvert faldt ikke hos os. Hvis vi havde IoT, ville det have været nogle særskilte løsninger.

Så, hvad er det, der gør det svært at adoptere IoT? Inden jeg svarer på dette spørgsmål, er det vigtigt at forstå IoT-arkitekturen, se figur 1.

Selve enhederne, som bruges til at måle noget, har som regel ikke forbindelse til Internet. Afhængigt af enhedens type kan de måle en eller flere ting, og de kan placeres på nogle fjerne steder fx på vandets overflade eller under overfladen i en sø. Derfor er det upraktisk, at de har forbindelse til Internet. I stedet bruger disse enheder forskellige transmissionsprotokoller til at sende data.

I nærheden af enhederne findes en eller flere Gateways, som modtager data fra enhederne. Gateway er også en enhed, som til gengæld har forbindelse til Internet. Gateway sender data videre, typisk til en database i skyen. Signalerne, som enhederne sender til Gateway, kommer i et analogt format – i et format, som vi ikke forstår. Her omsættes data til noget, som vi kan bruge: 20 ºC, 50 cm, 4 personer, etc.

Endelig analyseres, kombineres og visualiseres data, og bruges til at træffe beslutninger.

NFC Bluetooth zigbee sigfox LoRa Mobil netværk

Enheder med sensorer Enheder med sensor

Figur 1: IoT-arkitektur med sensorer, gateway, dataprocessering samt applikation

For at dække et konkret behov kan man købe hele pakken – dvs. alle fire lag af denne arkitektur hos en IoT-leverandør, altså alt fra enhederne til en smart applikation og ofte en dataportal. Problemet er, at man ikke kan købe alt hos én leverandør, fordi nogle leverandører kun specialiserer sig i trafikdata, mens andre arbejder med en bestemt transmissionsprotokol, fx ”Sigfox”. Nogle er ekstremt dyre og en overvejelse er, at det ikke altid kan betale sig at købe løsningen. Det, man ender med, er en række uafhængige løsninger og en række forskellige dataportaler, som hver kræver forskellige loginoplysninger, og i den sidste ende kan man ikke kombinere data og bruge det som supplement til eksisterende data.

I takt med, at vi i Silkeborg Kommune eksperimenterede med IoT, var vi i gang med at implementere digitaliseringsstrategi i Teknik og Miljø. Denne strategi havde bl.a. data i fokus. Ifølge strategien skulle data skabe sammenhæng og udnyttes optimalt, data skulle understøtte beslutningsprocesser, der skulle øge dataanvendelse på flere områder, og der skulle bruges forskellige former for data. Hvis vi skulle være i stand til at understøtte digitaliseringsstrategien, så lå det klart, at vi

skulle have data hos os, hvilket indebar, at vi skulle bygge en robust infrastruktur, der kunne håndtere data. Så vi gik i gang med at implementere vores digitaliseringsstrategi.

Vi startede med at skabe overblik over vores nuværende (AS-IS) arkitektur. Ud fra digitaliseringsstrategien tegnede vi et billede af vores målarkitektur (TO-BE) og lavede en ”Gap-analyse”, dvs. en analyse, der fortæller, hvad det er, der skal til for at komme i mål. Analysen resulterede i en række mindre projekter.

Vi har lavet en model for IoT-data, hvor data er organiseret i faktatabeller og dimensionstabeller, se figur 2.

Uanset hvad det er, vi måler, og uanset, hvor data kommer fra, så bliver data altid konverteret i denne model. Der er flere fordele ved denne model, idet det er nemmere at kombinere data, når man skal lave analyser, og det er nemmere at udstille data, fordi det er standardiseret.

Vores forventning var, at IoT-data, men også data generelt, ville eksplodere i mængden. Derfor byggede vi en infrastruktur i skyen for at aflaste almindelig drift, men også for at udnytte skyens potentiale og fleksibilitet.

Nogle enheder kan sende batteristatus, men når en enhed løber tør for batteri, kan den ikke sende noget. Derfor implementerede vi vores egen enhedsstyring (Device Management), se figur 3. Det kontrolleres, om data er indkommet, og hvis ikke, så sættes en alarm i gang, så man kan tage stilling til de enheder, som er blevet inaktive.

Der kommer omkring 2 millioner beskeder ind i vores databaser om dagen fra forskellige enheder. Data kommer i forskellige intervaller.

Nogle enheder sender data hvert minut, nogle hvert kvarter og nogle kun et par gange om dagen. For at sikre os, at vores databaseservere og integrationsservere kan klare data, og at de kører fejlfrit, implementerede vi infrastrukturovervågning.

Figur 2: IoT-datamodel med faktatabeller og dimensionstabeller.

For at gøre det nemt at tilgå data og for at sikre, at der kun er en indgang til data, lavede vi vores egen dataportal. Både medarbejderne og ledelsen i Teknik og Miljø, men også medarbejdere fra andre af kommunens afdelinger, kan nemt navigere i portalen og finde data, som er relevant for dem.

I dag har vi en moderne datainfrastruktur, som sikrer en let, ensartet og hurtig adgang til data, dataserier og analyser, og som kan anvendes på tværs af organisationen.

Figur 3: Oversigt over IoT-enheder - Device Management