Brannslange av tilstedeværelsesdata fra Cisco inn i Azure

Hvordan finne bruksmønsteret for et Smart Campus?

En essensiell faktor for å smarte opp et bygg, er data som kan si noe om bruken av bygget. Vi har flere mulige datakilder som kan si noe om bruken. Det som er et sentralt spørsmål er metodene bak disse tar høyde for personvern. Vi ønsker å bruke måter å forstå bruksmønsteret på, samtidig som hver bruker er anonym for systemet. Et eksempel på en måte å vite om et rom er i bruk eller ikke på en anonym måte, er en bevegelsessensor. Dette er vanlige sensorer i lysstyring, og noe som smart campus får fra byggautomasjonsystemet (som er vist eksempler på i bloggen om smart-campus-hvordan-vi-implementerer-digital-tvilling-plattform-av-universitetet. Denne vil likevel ikke gi oss svar på hvor mange som er inne i rommet, eller som har brukt rommet. Bevegelsessensoren slår ut uansett om det er én eller flere som beveger seg. Det er i tellingen av folk hvor personvern ofte blir en utfordring.

Cisco Spaces - telling av enheter som kobler mot internett

Én måte som kan telle antall brukere av et bygg er muliggjort av internett leverandøren Cisco. Cisco Spaces er en måte å gi anonymisert telling av bruksintensitet gjennom å telle antall enheter som spør om det finnes nettverk på universitetets mange aksesspunkter. Cisco tilbyr en tjeneste for å kunne telle antall besøkende enheter på alle nettverk som tilgjengeliggjøres på campus. På denne måten kan vi få anonymiserte tall på antall besøkende per bygg og etasje i byggene.

I Cisco Spaces finner vi dermed observasjoner av hver enkelt enhet som forsøker å logge seg på nett som leveres fra NMBU. Hver enhet sender ut signaler til aksesspunkt i nærheten, og siden flere aksesspunkter får signal fra samme enhet kan systemet triangulere posisjonen til enheten. På NMBU har de satt opp aksesspunktene slik at de kan telle brukere på bygg og etasjenivå. For store rom, slik som auditorier, kan man også få god nøyaktighet men for midre grupprom er det for dårlig nøyaktighet og andre metoder.

Ser man nærmere på grafen over så ser man at det er mange enheter som telles over natten. Selv om man kan velge seg ut nettverk som bare skal være brukt av enhetene folk bruker, så vil ikke det utelukke at folk bruker en PC. Cisco har mulighet til å filtrere bort mange av disse som gjør at tellingen blir enda mer nøyaktig, f.eks. med å fjerne duplikate enheter (når en bruker er pålogget fra flere enheter samtidig), men dette krever at man ikke anonymiserer MAC adressen (unik ID for enheten). Foreløpig har vi heller implementert en måte å trekke fra antallet som står over natten på grafen på rapporteringssiden, etter at dataene har gått gjennom plattformen vår.

Hvordan vi har koblet Cisco Spaces til plattformen

Så hvordan har vi koblet opp akkurat disse dataene som kilde til vår smart campus plattform? Jo, vi har faktisk gjort det to ganger. Den første metoden vi brukte var en daglig eksport av alle observasjoner som ble sendt i en csv fil til en Azure Blob Storage. Dette var rådataene for hver observerte enhet, når den startet å koble til nettet og når besøket var over. Vi koblet oss på eventet som skapes når filen kom, og trakk ut, talte antall observasjoner per tid og oppdaterte Azure Digital Twins med siste kjente telling for hver tidsenhet. Til dette brukte vi en brick:Occupency_Count type sensor per bygg og per etasje. Denne metoden hadde lav oppdateringsfrekvens (1 gang i døgnet), og krevede at vi prosesserte dataene i en durable function arkitektur for å komme frem til antallet i bygget per tid. Dette var før vi fikk vite om Cisco Firehose APIs, som gir oss sanntidsstrømmen av observerte antall enheter i bygget til enhver tid.

Cisco Firehose API - for Cisco Partnere

Dette er et API som kreves at man blir partner, som i utgangspunktet var tiltenkt andre programvareselskaper. Mazemap er et godt eksempel på en slik partner som bruker Firehose API fra Cisco.

Cisco har sett en trend mot at kunder bygger og ivaretar egne integrasjoner, så NMBU Smart Campus ble en av de første kundene som ble partner på denne modellen. Vi Smart Campus som app i partnerportalen, og satte opp en strøm mot en Azure Event Hub. Vi har mange mulige meldingstyper som kan strømmes, som beskrevet her, men for oss var det DEVICE_COUNT som var den mest interessante. Her får vi en melding for hver gang antallet personer i det aktuelle bygget eller etasjen endres, som da er gir oss et bilde av antallet mennesker som bruker byggene i sanntid.

Som vist under tar vi videre imot hvert event med en Azure Function som trigges for hver innkommende melding, og igjen oppdaterer Azure Digital Twin.

Det blir fortsatt laget en brick:Occupency_Count type sensor per bygg og per etasje, hvor Azure Digital Twin holder sist kjente telling, mens den forrige tellingen hele tiden dyttes videre over "historian" kobling til tidsseriedatabasen i Azure Data Explorer. Hele historikken og all kontekst er tilgjengelig herfra via REC APIet og direkte i dashboards, som vist i flyten uthevet i grønt.

Hvordan koble sensor til bygg og etasje?

Azure digital twins inneholder alle som tidligere beskrevet mange forskjellige tvillinger. Selv om Cisco er master for disse brick:Occupancy_Count sensorene, så er jo byggene og etasjene kommet fra DaluxFM. Det er et steg til som trengs for å koble sensor med det den observerer.

Her har vi gjort jobben litt enklere for oss selv med at navngivningen av hvert bygg har en konvensjon der byggnummeret settes på i forkant av byggnavnet slik skjermbildet viser under hvor 301 Ur (bygningen) er fremhevet i Cisco Spaces.

Dette forenkler mappingen til bygningene og etasjene vi får fra Dalux, som har byggnummer som navn i tvillingen slik som vist under.

Her har vi søkt frem bygninger, etasjer og deres respektive brick:Occupancy_Count sensorer fra Cisco. Her er 301 Urbygningen uthevet, og zoomer man inn som vist i neste bildet ser vi hvordan etasjer er koblet via hasPart/isPartOf relasjoner og sensorer via hasPoint/isPointOf relasjoner.

På byggnivå er det følgende sensor via hasPoint og den inverse isPointOf relasjonen.

Så kan vi følge videre ned til 2. etasje, så er dette koblet etter DaluxFM som kilde.

Så er sensoren under i bildet fra Cisco.

Disse koblingene skriptet vi føste gang, og videre vil dette være en av oppgavene til Smart Campus Admin app som vi skal snakke mer om i fremtidige blogposter.

Siste og historiske statuser på tvillingen

Går man videre inn og ser på "lastKnownValue" får man opp siste kjente telling som vises under.

Her ser vi at det var 238 enheter som ble talt i 2. etasje av 301 Urbygningen klokken 11:42 6. januar 2025. God start på det nye året. Ser man videre i Azure Data Explorer får man som nevnt opp historikken.

Her ser vi de siste 12 timene for den samme etasjen med minuttoppløsning. Denne innsikten brukes videre til å optimalsiere arealutnyttelsen og energiforbruket på campus. I senere blogposter vil vi komme nærmere inn på hvordan data på energiforbruk tas inn fra målere via Energinet API. Stay tuned.