Bygningsautomationssystemer: typer, software, styring og leverandører

Bygningsautomationssystemer: typer, softwarelag og leverandørerne bag dem

Foto af iSawRed på Unsplash.

Bygningsautomationssystemer holder et erhvervsbygnings anlæg kørende efter tidsplan og sætpunkt: HVAC, belysning, adgang og den relaterede styring, som de fleste i bygningen aldrig ser. Udtrykket dækker feltcontrollere på anlægget, den overordnede front end, ejendomme åbner hver morgen, og den softwarestack, der binder dem sammen. For definitionsniveauet af hvad et BAS er på komponentniveau ejer glossaret den jord. Denne tekst dækker typer af bygningsautomationssystemer, de softwarelag operatører faktisk køber, leverandørerne bag store installationer, og hvor analyse sidder oven på det, der allerede er installeret.

Hver erhvervsbygning af nogen størrelse kører et af disse systemer, uanset om ejeren kalder det BAS, BMS eller, i EU's regelsprog, BACS. Det, der varierer mellem bygninger, er hvilken generation af software der kører det, hvor mange leverandører der har lagret systemer oven på hinanden over årene, og om nogen stadig får nyttig information ud. Bygnings- og anlægsstyring er det daglige job; rangeret analyse er, hvordan porteføljer gør telemetrien til en kø i stedet for endnu et dashboard.

Typer af bygningsautomationssystemer

Operatører, der søger efter typer af bygningsautomationssystemer, mener typisk de anlægsdomæner et BAS dækker, ikke softwarelagsmodellen nedenfor. De fleste kommercielle ejendomme kører flere af disse parallelt, ofte under én overordnet front end og nogle gange som separate leverandørøer.

HVAC. Opvarmning, køling, ventilation og det anlæg, der forsyner dem. Feltcontrollere holder loopene for luftbehandlingsaggregater, chillere, kedler og VAV-bokse. Det er normalt den største energi- og komfortbelastning i bygningen, og det første sted drift viser sig som omkostning.

Belysning. Tidsplaner, dagslyshøst, tilstedeværelsesbaseret dæmpning og grænseflader til nødbelysning. Belysning deler ofte samme BACnet- eller DALI-rygrad som HVAC, men mange anlæg kører stadig et separat belysningspanel, der aldrig taler rent med resten af BAS'et.

Adgangskontrol. Dørcontrollere, læsere og identitetssystemer. Sikkerhedsteams ejer ofte denne stack separat fra facility, hvilket er grunden til, at adgangstelemetri sent tilslutter sig et bygningsovergribende analysefeed, selv når protokollen allerede er åben.

Brand og personsikkerhed. Detektion, varsling og spjæld-/ventilatoroverstyring. Disse systemer er hårdt regulerede og bliver typisk på deres egen panel. Et analyselag kan læse status, hvor integrator tillader det; det erstatter ikke det certificerede brandsystem.

Energi. Målere, undermålere og de punkter, der gør kWh til omkostning og CO2. Energi sælges nogle gange som sin egen bygningsautomationspakke, og nogle gange som et tyndt sæt punkter inde i HVAC-BAS'et. Uanset hvad: uden pålidelig måling kan resten af stacken ikke prissætte det, den finder.

Analyse som det sjette lag. De fem domæner ovenfor producerer telemetri. Et analyselag læser på tværs af dem, tjekker aflæsninger mod hinanden og rangerer, hvad der kræver opmærksomhed efter omkostning eller risiko. Det er ikke en sjette anlægscontroller. Det sidder over HVAC, belysning, adgang, brandstatus og energimålere, så en portefølje ser én kø i stedet for fem øer. Typer af bygningsautomationssystemer starter stadig med anlægsdomænerne; analyse er, hvordan du bruger dem sammen uden at rive et fungerende BAS ud.

Den liste er, hvad de fleste operatører mener med typer af bygningsautomationssystemer. Næste afsnit er et andet snit: softwarelagene, der implementerer de domæner.

De tre lag af bygningsautomationssoftware

Feltniveau-software lever inde i controllerne selv: DDC-controllere, der kører styreloopene, som gør en sensoraflæsning til en kommando til en ventil eller en ventilator. Controllere, paneler og feltudstyr er hardwareanatomien inde i en BMS-controller. Over det sidder det overordnede lag, nogle gange en leverandørs egen front end, nogle gange en Tridium Niagara-station, der abstraherer flere leverandører til én grænseflade, hvor en operatør sætter tidsplaner og ser trends. Over det igen sidder i stigende grad et analyselag: software, der læser den telemetri, de to første lag allerede producerer, og gør den til en prioriteret liste over, hvad der kræver opmærksomhed.

Det tredje lag er en relativt ny kategori, og det er det, der vokser hurtigst. Felt- og overordnede lag har set groft ens ud i to årtier; det, der har ændret sig, er appetitten på at få mere ud af den data, de allerede genererede, uden at rive et fungerende BAS ud for at gøre det.

I praksis kører de fleste eksisterende bygninger flere generationer af disse lag stablet oven på hinanden. En ombygning tilføjer en ny front end uden at røre feltcontrollerne under; en portefølje vokset gennem opkøb arver tre forskellige overordnede platforme på tværs af tre bygninger. Intet af det er et problem for et analyselag, så længe det kan læse protokollen under. Det er et problem for den, der forsøger at få ét konsistent view alene ud af front end-laget.

BAS-software, bygningsstyring og analyse er ikke det samme

Begreberne bruges om hinanden, men de beskriver forskellige jobs. Bygningsstyring er hardwaren og firmwaren, der faktisk åbner en ventil eller dæmper en lampe, inde i feltcontrollerne. Software til bygningsautomationssystemer er den bredere pakke: styringen plus den overordnede front end, der planlægger og overvåger dem. Fejldetektering og diagnostik (FDD) er et smallere tillæg, typisk regelbaseret, der sammenligner forventet med faktisk udstyrsadfærd og flagger et mismatch. Ingen af de tre erstatter de andre; en bygning kører typisk alle på én gang, installeret i forskellige årtier af forskellige entreprenører.

Analyse er den nyeste af de fire, og den der oftest forveksles med FDD. Hvor FDD kører faste regler mod en håndfuld kendte fejlssignaturer, læser en fuld analyseplatform på tværs af hvert system en bygning har, HVAC, måling, IoT, tjekker aflæsningerne mod hinanden, før den stoler på dem, og rangerer det, den finder, efter omkostning snarere end efter hvilken regel der ramte. FDD spørger, om et specifikt kendt mønster indtraf; analyse spørger, hvad ud af alt, der sker i bygningen lige nu, der er værd en operatørs næste time.

Leverandørlandskabet for bygningsautomation

En kort liste over leverandører står for de fleste store bygningsinstallationer: Honeywell, Johnson Controls (Metasys), Siemens (Desigo) og Schneider Electric (EcoStruxure Building), sammen med Tridiums Niagara-framework under mange flerleverandørssites. En enkelt portefølje kører ofte to eller tre af disse side om side, arven fra forskellige bygninger idriftsat i forskellige årtier af forskellige entreprenører.

Vi behandler dem alle som integrationsmål, ikke konkurrenter. Explore læser et bygnings eksisterende BAS over dets native protokol eller leverandør-API i stedet for at bede nogen standardisere på én platform først. Vores integrationshub dækker detaljerne for Siemens Desigo, Schneider EcoStruxure, Honeywells Niagara-baserede stationer, Johnson Controls Metasys og Honeywell Trend, inklusive hvad hver eksponerer, og hvordan forbindelsen sættes op.

Leverandørlåsning i bygningsautomation kommer sjældent fra protokollen selv; BACnet og Modbus er åbne standarder uanset hvem der solgte panelet. Den kommer fra licensering: per-punkt-gebyrer, sædebaseret adgang til front end og proprietære udvidelser, som kun den leverandørs egne værktøjer læser rent. En bygning kan køre en åben protokol under og stadig være låst til én leverandørs software for at få fuld værdi ud af den data, den producerer.

Valg af bygningsautomationssoftware

De fleste ejendomme vælger ikke bygningsautomationssoftware fra et blankt ark; de arver, hvad der blev specificeret ved opførelse eller den seneste større ombygning, og lever med det. Hvor der er et reelt valg, mest ved nybyggeri eller fuld BAS-udskiftning, er de beslutninger, der betyder mest, hvor åbent protokollaget er (BACnet og åbne Niagara-stationer er langt lettere at bygge videre på end en lukket proprietær bus), hvor meget af den eksisterende feltkabling og controllere der overlever skiftet, og om front end kan udvides eller skal udskiftes helt for ny kapabilitet.

Det sværere spørgsmål for de fleste bygninger er ikke, hvilket BAS man skal købe. Det er, hvad man skal gøre med det, der allerede er installeret. At erstatte et fungerende BAS for bedre synlighed er dyrt og forstyrrende, og feltcontrollere og kabling er normalt fine; den værdi, der går tabt, sidder opstrøms, i hvordan data bruges, ikke i styringslaget selv.

Total cost of ownership er, hvor mange af disse beslutninger går galt. Købsprisen på en ny front end er normalt en lille brøkdel af, hvad en bygning bruger over det følgende årti på licensering, integrationsarbejde og de tekniker timer, der skal til for at holde punktlisten aktuell. Et billigere system med dyr integrationsgæld koster ofte mere i år fem end det alternativ, der så dyrere ud på dag ét.

Hvor FrostLogic Explore passer ind

Explore sidder oven på det BAS, der allerede kører. Det starter med skriveadgang slået fra som standard via BACnet, Modbus, OPC UA, oBIX eller et leverandør-API afhængigt af, hvad der er installeret. Skriveadgang forbliver slået fra, indtil du giver det et scope. FrostLogic Edge Agent kan skrive sætpunkter og tidsplaner inden for de scopes uden at erstatte integratorens styrelogik; se Automation for, hvordan tilladelsesstyret skrivning scopes. Uden for et givet scope overtager Explore aldrig et spjæld eller en chiller, og det er ikke en erstatning for BAS'et under det. Det er et analyselag, der gør den data, BAS'et allerede producerer, til en rangeret kø over, hvad der koster penge eller er på vej mod en fejl, evidensbaseret og prissat snarere end begravet i et alarmpanel. For hvordan det fungerer på tværs af en portefølje af bygninger og BAS-generationer, se vores side om BMS-analyseplatform. Energihalvdelen af den kø er Explores energistyringslag; kontinuerlige måleraflæsninger ligger under Explores kontinuerlige målerlag.

Fordi Explore læser den protokol, en portefølje allerede kører, kan én deployment spænde over bygninger på helt forskellige bygningsautomationsplatforme uden først at tvinge dem over på én leverandørs stack. Det betyder mest for porteføljer sammensat gennem opkøb, hvor at standardisere BAS'et selv sjældent er værd forstyrrelsen, men at standardisere, hvad der læses ud af det, er ligetil.

Det betyder også, at Explore ikke er et CMMS. Det fremhæver og rangerer, hvad der er galt; at logge en arbejdsordre og sende en tekniker bliver hos det vedligeholdelsessystem, et team allerede kører.

Ofte stillede spørgsmål

Hvad er software til bygningsautomationssystemer? Det er softwaren, der kører en bygnings HVAC, belysning, adgangskontrol og relaterede systemer automatisk: feltcontrollere, der kører styreloopene, en overordnet front end til tidsplaner og trends, og i stigende grad et analyselag, der læser på tværs af begge. Se vores glossaropslag for opdelingen på komponentniveau.

Hvilke typer af bygningsautomationssystemer findes? De fleste kommercielle anlæg dækker HVAC, belysning, adgangskontrol, brand og personsikkerhed samt energimåling som anlægsdomæner, ofte under én overordnet front end. Analyse sidder over de domæner som et sjette lag, der rangerer fund på tværs af dem. Softwarelagssnittet (felt, overordnet, analyse) er en anden model af samme stack.

Hvilke er de største bygningsautomationsvirksomheder? Honeywell, Johnson Controls (Metasys), Siemens (Desigo) og Schneider Electric (EcoStruxure Building) kører de fleste store kommercielle installationer, ofte sammen med Tridiums Niagara-framework, der binder flere leverandører sammen. De fleste porteføljer af nogen størrelse kører mere end én.

Er et bygningsautomationssystem det samme som et BMS? Ja. BAS (building automation system) og BMS (building management system) beskriver samme kategori af system; BAS er mere almindeligt i Nordamerika, BMS mere almindeligt i Europa. Ingen af termerne indebærer en specifik leverandør eller protokol.

Erstatter FrostLogic mit eksisterende bygningsautomationssystem? Nej. Explore starter med skriveadgang slået fra som standard via dit BAS' native protokol eller leverandør-API og tilføjer et analyselag ovenpå. Skriveadgang forbliver slået fra, indtil du giver det et scope; Edge Agent kan derefter skrive sætpunkter og tidsplaner inden for det scope uden at erstatte BAS'et under det.

Hvordan integrerer FrostLogic med Siemens-, Schneider-, Honeywell- eller Metasys-systemer? Gennem hver leverandørs native protokol eller API snarere end en truckløft-opgradering. Vores integrationshub dækker detaljerne for hver.

Ikke sikker på, hvilket lag der koster dig mest?

Hvis du vejer en BAS-udskiftning op imod at tilføje analyse oven på det, der allerede er installeret, fortæl os, hvad der kører, og vi giver dig et lige svar, inklusive når det ærlige svar er, at et nyt BAS ikke er løsningen. 30 eller 60 minutter, dit valg. Ingen forpligtelse uanset. Tal det igennem.