Bygningsautomasjonssystemer: typer, programvare, styring og leverandører

Bygningsautomasjonssystemer: typer, programvarelag og leverandørene bak dem

Foto av iSawRed på Unsplash.

Bygningsautomasjonssystemer holder et næringsbyggs anlegg i gang etter tidsplan og settpunkt: HVAC, belysning, adgang og den relaterte styringen de fleste i bygget aldri ser. Uttrykket dekker feltcontrollere på anlegget, den overordnede frontenden eiendommer åpner hver morgen, og programvarestacken som binder dem sammen. For definisjonsnivået av hva et BAS er på komponentnivå eier glossaret den marken. Denne teksten dekker typer av bygningsautomasjonssystemer, programvarelagene operatører faktisk kjøper, leverandørene bak store installasjoner, og hvor analyse sitter oppå det som allerede er installert.

Hvert næringsbygg av noen størrelse kjører et av disse systemene, enten eieren kaller det BAS, BMS eller, i EUs regelverksspråk, BACS. Det som varierer mellom bygg er hvilken generasjon programvare som kjører det, hvor mange leverandører som har lagret systemer oppå hverandre over årene, og om noen fortsatt får nyttig informasjon ut. Bygningsstyring og automasjon er den daglige jobben; rangert analyse er hvordan porteføljer gjør telemetrien til en kø i stedet for nok et dashboard.

Typer av bygningsautomasjonssystemer

Operatører som søker etter typer av bygningsautomasjonssystemer mener vanligvis anleggsdomenene et BAS dekker, ikke programvarelagsmodellen nedenfor. De fleste kommersielle eiendommer kjører flere av disse parallelt, ofte under én overordnet frontend og noen ganger som separate leverandørøyer.

HVAC. Oppvarming, kjøling, ventilasjon og anlegget som forsyner dem. Feltcontrollere holder loopene for luftbehandlingsaggregater, chillere, kjeler og VAV-bokser. Dette er vanligvis den største energi- og komfortlasten i bygget, og det første stedet drift viser seg som kostnad.

Belysning. Tidsplaner, dagslyshøsting, tilstedeværelsesbasert dimming og grensesnitt for nødbelysning. Belysning deler ofte samme BACnet- eller DALI-ryggrad som HVAC, men mange anlegg kjører fortsatt et separat belysningspanel som aldri snakker rent med resten av BAS-et.

Adgangskontroll. Dørcontrollere, lesere og identitetssystemer. Sikkerhetsteam eier ofte denne stacken separat fra facility, noe som er grunnen til at adgangstelemetri sent kobler seg til et bygningsovergripende analysefeed selv når protokollen allerede er åpen.

Brann og personsikkerhet. Deteksjon, varsling og spjeld-/vifteoverstyring. Disse systemene er hardt regulert og blir vanligvis på sitt eget panel. Et analyselag kan lese status der integrator tillater det; det erstatter ikke det sertifiserte brannsystemet.

Energi. Målere, undermålere og punktene som gjør kWh til kostnad og karbon. Energi selges noen ganger som sin egen bygningsautomasjonspakke, og noen ganger som et tynt sett punkter inne i HVAC-BAS-et. Uansett: uten pålitelig måling kan resten av stacken ikke prise det den finner.

Analyse som det sjette laget. De fem domenene over produserer telemetri. Et analyselag leser på tvers av dem, sjekker avlesninger mot hverandre og rangerer hva som trenger oppmerksomhet etter kostnad eller risiko. Det er ikke en sjette anleggscontroller. Det sitter over HVAC, belysning, adgang, brannstatus og energimålere slik at en portefølje ser én kø i stedet for fem øyer. Typer av bygningsautomasjonssystemer starter fortsatt med anleggsdomenene; analyse er hvordan du bruker dem sammen uten å rive ut et fungerende BAS.

Den listen er det de fleste operatører mener med typer av bygningsautomasjonssystemer. Neste avsnitt er et annet snitt: programvarelagene som implementerer de domenene.

De tre lagene av bygningsautomasjonsprogramvare

Feltnivåprogramvare lever inne i controllerne selv: DDC-controllere som kjører styreloopene som gjør en sensoravlesning til en kommando til en ventil eller en vifte. Controllere, paneler og feltenheter er maskinvareanatomien inne i en BMS-regulator. Over det sitter det overordnede laget, noen ganger en leverandørs egen frontend, noen ganger en Tridium Niagara-stasjon som abstraherer flere leverandører til ett grensesnitt, der en operatør setter tidsplaner og ser trender. Over det igjen sitter i økende grad et analyselag: programvare som leser telemetrien de to første lagene allerede produserer og gjør den til en prioritert liste over hva som trenger oppmerksomhet.

Det tredje laget er en relativt ny kategori, og det er det som vokser raskest. Felt- og overordnede lag har sett grovt like ut i to tiår; det som har endret seg er appetitten på å få mer ut av dataene de allerede genererte, uten å rive ut et fungerende BAS for å gjøre det.

I praksis kjører de fleste eksisterende bygg flere generasjoner av disse lagene stablet oppå hverandre. En ombygging legger til en ny frontend uten å røre feltcontrollerne under; en portefølje vokst gjennom oppkjøp arver tre ulike overordnede plattformer på tvers av tre bygg. Ingenting av det er et problem for et analyselag, så lenge det kan lese protokollen under. Det er et problem for den som prøver å få ett konsistent view alene ut av frontend-laget.

BAS-programvare, bygningsstyring og analyse er ikke det samme

Begrepene brukes om hverandre, men de beskriver ulike jobber. Bygningsstyring er maskinvaren og firmwaren som faktisk åpner en ventil eller dimmer en lampe, inne i feltcontrollerne. Programvare for bygningsautomasjonssystemer er den bredere pakken: styringen pluss den overordnede frontenden som planlegger og overvåker dem. Feildeteksjon og diagnostikk (FDD) er et smalere tillegg, vanligvis regelbasert, som sammenligner forventet mot faktisk utstyrsadferd og flagger et mismatch. Ingen av de tre erstatter de andre; et bygg kjører typisk alle samtidig, installert i ulike tiår av ulike entreprenører.

Analyse er den nyeste av de fire, og den som oftest forveksles med FDD. Der FDD kjører faste regler mot en håndfull kjente feilssignaturer, leser en full analyseplattform på tvers av hvert system et bygg har, HVAC, måling, IoT, sjekker avlesningene mot hverandre før den stoler på dem, og rangerer det den finner etter kostnad snarere enn etter hvilken regel som traff. FDD spør om et spesifikt kjent mønster inntraff; analyse spør hva, av alt som skjer i bygget akkurat nå, som er verdt en operatørs neste time.

Leverandørlandskapet for bygningsautomasjon

En kort liste over leverandører står for de fleste store bygningsinstallasjoner: Honeywell, Johnson Controls (Metasys), Siemens (Desigo) og Schneider Electric (EcoStruxure Building), sammen med Tridiums Niagara-rammeverk under mange flerleverandørssites. En enkelt portefølje kjører ofte to eller tre av disse side om side, arven fra ulike bygg satt i drift i ulike tiår av ulike entreprenører.

Vi behandler dem alle som integrationsmål, ikke konkurrenter. Explore leser et byggs eksisterende BAS over dets native protokoll eller leverandør-API i stedet for å be noen standardisere på én plattform først. Vår integrationshub dekker detaljene for Siemens Desigo, Schneider EcoStruxure, Honeywells Niagara-baserte stasjoner, Johnson Controls Metasys og Honeywell Trend, inkludert hva hver eksponerer og hvordan tilkoblingen settes opp.

Leverandørlåsing i bygningsautomasjon kommer sjelden fra protokollen selv; BACnet og Modbus er åpne standarder uansett hvem som solgte panelet. Den kommer fra lisensiering: per-punkt-gebyrer, setebasert tilgang til frontenden og proprietære utvidelser som bare den leverandørens egne verktøy leser rent. Et bygg kan kjøre en åpen protokoll under og fortsatt være låst til én leverandørs programvare for å få full verdi ut av dataene den produserer.

Valg av bygningsautomasjonsprogramvare

De fleste eiendommer velger ikke bygningsautomasjonsprogramvare fra et blankt ark; de arver det som ble spesifisert ved oppføring eller siste større ombygging, og lever med det. Der det finnes et reelt valg, mest ved nybygg eller full BAS-utskifting, er beslutningene som betyr mest hvor åpent protokollaget er (BACnet og åpne Niagara-stasjoner er langt enklere å bygge videre på enn en lukket proprietær buss), hvor mye av eksisterende feltkabling og controllere som overlever byttet, og om frontenden kan utvides eller må byttes ut helt for ny kapabilitet.

Det vanskeligere spørsmålet for de fleste bygg er ikke hvilket BAS man skal kjøpe. Det er hva man skal gjøre med det som allerede er installert. Å erstatte et fungerende BAS for bedre synlighet er dyrt og forstyrrende, og feltcontrollere og kabling er vanligvis fine; verdien som går tapt sitter oppstrøms, i hvordan dataene brukes, ikke i styringslaget selv.

Total eierkostnad er der mange av disse beslutningene går galt. Kjøpsprisen på en ny frontend er vanligvis en liten brøkdel av det et bygg bruker over det følgende tiåret på lisensiering, integrasjonsarbeid og tekniker-timene som trengs for å holde punktlisten aktuell. Et billigere system med dyr integrasjonsgjeld koster ofte mer i år fem enn alternativet som så dyrere ut på dag én.

Hvor FrostLogic Explore passer inn

Explore sitter oppå det BAS som allerede kjører. Det starter med skriveadgang slått av som standard via BACnet, Modbus, OPC UA, oBIX eller et leverandør-API avhengig av hva som er installert. Skriveadgang forblir av til du gir det et scope. FrostLogic Edge Agent kan skrive settpunkter og tidsplaner innenfor de scopene uten å erstatte integratorens styrelogikk; se Automation for hvordan tillatelsesstyrt skriving scopes. Utenfor et gitt scope overtar Explore aldri et spjeld eller en chiller, og det er ikke en erstatning for BAS-et under det. Det er et analyselag som gjør dataene BAS-et allerede produserer til en rangert kø over hva som koster penger eller er på vei mot en feil, evidensbasert og priset snarere enn begravet i et alarmpanel. For hvordan det fungerer på tvers av en portefølje av bygg og BAS-generasjoner, se vår side om BMS-analyseplattform. Energihalvdelen av den køen er Explores energistyringslag; kontinuerlige måleravlesninger ligger under Explores kontinuerlige målerlag.

Fordi Explore leser den protokollen en portefølje allerede kjører, kan én utrulling spenne over bygg på helt ulike bygningsautomasjonsplattformer uten først å tvinge dem over på én leverandørs stack. Det betyr mest for porteføljer sammensatt gjennom oppkjøp, der å standardisere BAS-et selv sjelden er verdt forstyrrelsen, men å standardisere hva som leses ut av det er greit.

Det betyr også at Explore ikke er et CMMS. Det løfter frem og rangerer hva som er galt; å logge en arbeidsordre og sende en tekniker blir hos det vedlikeholdssystemet et team allerede kjører.

Ofte stilte spørsmål

Hva er programvare for bygningsautomasjonssystemer? Det er programvaren som kjører et byggs HVAC, belysning, adgangskontroll og relaterte systemer automatisk: feltcontrollere som kjører styreloopene, en overordnet frontend for tidsplaner og trender, og i økende grad et analyselag som leser på tvers av begge. Se vårt glossaroppslag for oppdelingen på komponentnivå.

Hvilke typer av bygningsautomasjonssystemer finnes? De fleste kommersielle anlegg dekker HVAC, belysning, adgangskontroll, brann og personsikkerhet samt energimåling som anleggsdomener, ofte under én overordnet frontend. Analyse sitter over de domenene som et sjette lag som rangerer funn på tvers av dem. Programvarelagssnittet (felt, overordnet, analyse) er en annen modell av samme stack.

Hvilke er de største bygningsautomasjonsselskapene? Honeywell, Johnson Controls (Metasys), Siemens (Desigo) og Schneider Electric (EcoStruxure Building) kjører de fleste store kommersielle installasjonene, ofte sammen med Tridiums Niagara-rammeverk som binder flere leverandører sammen. De fleste porteføljer av noen størrelse kjører mer enn én.

Er et bygningsautomasjonssystem det samme som et BMS? Ja. BAS (building automation system) og BMS (building management system) beskriver samme kategori av system; BAS er vanligere i Nord-Amerika, BMS vanligere i Europa. Ingen av termene innebærer en spesifikk leverandør eller protokoll.

Erstatter FrostLogic mitt eksisterende bygningsautomasjonssystem? Nei. Explore starter med skriveadgang slått av som standard via ditt BAS native protokoll eller leverandør-API, og legger til et analyselag oppå. Skriveadgang forblir av til du gir det et scope; Edge Agent kan deretter skrive settpunkter og tidsplaner innenfor det scopet uten å erstatte BAS-et under det.

Hvordan integrerer FrostLogic med Siemens-, Schneider-, Honeywell- eller Metasys-systemer? Gjennom hver leverandørs native protokoll eller API snarere enn en truckløft-oppgradering. Vår integrationshub dekker detaljene for hver.

Ikke sikker på hvilket lag som koster deg mest?

Hvis du veier en BAS-utskifting opp mot å legge til analyse oppå det som allerede er installert, fortell oss hva som kjører, og vi gir deg et rett svar, inkludert når det ærlige svaret er at et nytt BAS ikke er løsningen. 30 eller 60 minutter, ditt valg. Ingen forpliktelse uansett. Snakk det gjennom.