Databehandling: hva vi leser og skriver
Driftstelemetrien vi leser, settpunktene vi skriver tilbake, hvor dataene lagres, og hvorfor telemetrien ikke er persondata.
Arcturus leser driftsdata fra SD-anlegget og sensorene deres, skriver tilbake optimaliserte settpunkter og lagrer begge datatypene for analyse. Denne guiden forklarer hva som leses, hva som skrives, hvor dataene lagres, og hvorfor driftstelemetrien ikke er persondata.
Det vi leser
Kun driftstelemetri — hver avlesning er én av disse typene: inne-, ute-, tillufts- eller avtrekkstemperatur, CO₂, luftfuktighet, viftehastighet og luftmengde, ventil- og spjeldstilling, av/på-status og alarmstatus for utstyr, samt energimåleravlesninger der det finnes. Den eksakte listen per bygg er det adresseliste-CSV-en fra SD-leverandøren eksponerer; vi finner ikke opp punkter.
Det vi skriver
Kun settpunkter — temperatursettpunkter, luftmengdesettpunkter og tidsplaner der integrasjonen støtter det. Vi skriver aldri kjørbar kode, konfigurasjonsendringer eller noe som kobler om SD-anlegget. Selve reguleringen (PI-sløyfer, start/stopp av utstyr, alarmer) blir der den alltid har vært: lokalt i SD-anlegget.
Hvor dataene lagres hos oss
- Tidsserie-telemetri (hver avlesning og hver skriving) → en tidsseriedatabase, partisjonert per bygg.
- Byggkonfigurasjon (hvilke kontrollere, hvilke datapunkter, hvordan soner kobles) → en driftsdatabase ved siden av tjenestene som kjører.
- Leverandørlegitimasjon (API-nøklene vi bruker mot IWMAC, Airthings osv.) → kryptert i hvile med AES-256-GCM; krypteringsnøkkelen ligger i en Kubernetes-secret, ikke i en rad i databasen.
Hvorfor dette ikke er persondata
Telemetri fra et ventilasjonsanlegg beskriver bygget, ikke personene som oppholder seg der. CO₂-nivåer og viftehastigheter i et møterom identifiserer ikke hvem som var i rommet. Persondataene Arcturus håndterer, er administratorkontoer for selve plattformen (påloggingsidentiteten til personene som bruker dashbordet), og de holdes adskilt fra driftstelemetrien.