Bygningsautomation

Fra energiwiki.dk

Skift til: Navigation, Søgning

Bygningsautomationen har gennem de sidste 15-20 år været præget af en kraftigt teknologisk udvikling og den er i stadig kraftig vækst. Bygningsautomationen omfatter i dag stort set alle de tekniske anlæg i en bygning. Der er mange forskellige behov der driver udbredelsen af bygningsautomationen frem, bl.a. øget anvendelse af energibesparende indeklimaløsninger. Et af de nye anvendelsesområder er anvendelsen af distribueret ventilation med øget varme- og kølekomfort i bygninger. Stigende energipriser og krav om reduktion af vores CO2 udledning driver ligeledes teknologiudviklingen.

Beskrivelsen vil i overordnede termer og principskitser give et overblik over bygningsautomationen set i et system- og energiperspektiv. Beskrivelsen omfatter:

  • Bygningsautomationens begreber
  • Bygningsautomationens ydelser og energiforbruget
  • Overordnet systemopbygning
  • Strategi for bygningsautomation


Der er mange nye muligheder med bygningsautomation i dag. En af disse nye muligheder er at integrerer alle tekniske anlæg vedrørende f.eks. brand, tyveri og videosikring i et fælles bygningsautomationssystem sammen med styringen af ventilations- og varmeanlæg. Det skal påpeges, at styrings- og reguleringsformer er af vital betydning for opnåelse af et optimalt indeklima med minimalt energiforbrug.


Indholdsfortegnelse

Bygningsautomationens begreber

Grundlæggende omfatter og forstås bygningsautomation som:

En automatisk styring og regulering af de tekniske anlæg i en bygning. Såsom varmeanlæg, køleanlæg, ventilation m.fl.

Der er gennem årene udviklet forskellige produkt- og systemløsninger som kan kategoriseres i følgende grupper:

Standalone eller autonom automatik uden kommunikation
Til styring og regulering af det enkelte ventilations- eller varmeanlæg findes der mere simple produkter, der kun regulerer det enkelte anlæg, uden kommunikation til andre anlæg eller computere. Et typisk produkt kan være en styringsboks for udsugningsventilatorer, små ældre ventilationsanlæg eller blandesløjfer.


Standalone eller autonom automatik med kommunikation
Til styring og regulering af det enkelte ventilations- eller varmeanlæg findes der også produkter der kun kan regulere et anlæg, men med kommunikation til andre anlæg eller computere. Kommunikationen kan foregå via mange forskellige typer kommunikationsprotokoller. Afhængig af hvilke kommunikationsprotokoller der anvendes kan det være mere eller mindre nemt at udveksles data. Se endvidere nedenstående afsnit om kommunikationsprotokoller og interfaces.


CTS-anlæg
CTS står for Central Tilstandskontrol og Styring (dansk begreb).

Et CTS-anlæg (den almene betegnelse for bygningsautomation) er fællesbetegnelsen for de computerbaserede produkter, der anvendes til overvågning, styring og regulering af bygningsanlæg. I praksis kaldes dette computerprodukt med reguleringssoftwaren for en CTS-undercentral forkortet til CTS-UC. Som det er illustreret i figur 1 har alle CTS-UC’er en kommunikationsudgang og kan tilsluttes en CTS-busforbindelse, således at CTS-UC’er kan kommunikere med andre CTS-UC’er. Der kan også tilsluttes en betjenings PC til CTS-bussen, hvor alle CTS-UC’erne så kan kobles op på. På betjenings PC’en er der en grafisk brugerflade hvorfra man kan betjene anlæg der er tilsluttet CTS-UC’er. Denne betjenings PC kaldes for CTS-hovedcentral (forkortet CTS-HC).

CTS-UC’erne indeholder I/O-moduler (Input / Output), hvorpå sensor og aktuator komponenter (f.eks. rumføler og motorventil for varme) tilsluttes via en ledningsforbindelse. CTS-UC’erne er frit programmerbare, således at der kan specialdesignes software til styring og regulering af varmen ud fra rumfølerens målte værdi. Funktionaliteten for styringen vises på den grafiske betjeningsflade på CTS-HC.


Figur 1. CTS-anlæg.


Som illustreret i figur 2 vil en CTS-hovedcentral, der har fulgt den teknologiske udvikling, i dag indeholde en SCADA platform (læs definition nedestående) og har en større programpakke for grafisk betjening, analyseværktøjer, trendlog, interfaceplatform til 3’part systemer, dataexport/import, database, energihåndtering. CTS-hovedcentralen kan køre på serveroperativsoftware og kan indgå i de forskellige netværks- og servermiljøer i IT-systemet.


Figur 2. CTS i moderne netværks-og servermiljøer.


Specialdesignet software gør sådanne løsninger omkostningstunge og centreret omkring de få personer der har udarbejdet løsningen. CTS-systemer har altid været målrettet bygninger, og for at billiggøre de meget avancerede CTS-software programmer arbejdes der med standardiseringer af softwaren i form af afprøvet applikationer. En applikation er et færdigt stykke testet og afprøvet software for f.eks. energieffektiv regulering af et ventilationsanlæg. Applikationen kan så tilpasses de specielle forhold som ventilationsanlægget skal indgå i. CTS’ens styrke i applikations-softwaren er bl.a. at den er afprøvet, standardiseret og færdigdokumenteret, således at kunden efterfølgende har fuld standard dokumentation for sit avancerede CTS-anlæg, samt at brugere og teknisk personel hurtigt kan sætte sig ind i, hvordan systemet fungerer og administreres.

Den mest standardiserede kommunikationsprotokol mellem hovedcentral og undercentraler er i dag BACnet. De fleste CTS-udbydere kan anvende BACnet i kommunikationsprotokollen med deres undercentraler. Undercentralens softwareprogrammer er dog stadigvæk forskellige. Læs mere om BACnet under kommunikationsprotokoller.

Hvis der samles flere anlægssystemer, f.eks. IBI-anlæg på CTS hovedcentralen, bliver CTS-hovedcentralen i dag også kaldt et BMS-anlæg (Building Management System, Se BMS afsnittet.).


IBI-anlæg
IBI står for Intelligente Bygnings Installationer

IBI-anlæg er billige små computere med begrænset kapacitet, som har ilagt et standardiseret og certificeret applikationssoftware. Disse computerenheder kaldes IBI-controllere. De mest avancerede IBI-controllere er certificeret af eu.bac – en sammenslutning af producenter indenfor bygningsautomation. Det betyder at controllerne lever op til de krav som EU har sat til hvor meget energi controllerne i sig selv anvender (EN15500) og at de applikationer der kører i controlleren (EN15232) lever op til kravene. Læs mere på www.eubac.org.

IBI applikationen styrer og regulere indeklima- og lysstyring i den enkelte rum, kaldet IBI-Zone. Styringsomfanget at IBI-zonen kan varierer, men kan omfatte bygningsinstallationer som lys, varme, køling, ventilation, solafskærmning og, betjeningspaneler.

Som vist i figur 3 er IBI arkitekturen en decentral opbygning med en IBI-controller i hvert enkelt rum. Arkitekturen skal sikre et bedre indeklima tilpasset den enkelte bruger i rummet, men IBI-controlleren sikre ligeledes at der kun anvendes energi til opvarmning eller køling af rummet når der er personer i rummet. Komforten og energihåndteringen fastlægges i rum/zonen, hvorefter der vælges en IBI-controller applikation der kan løse denne opgave.


Figur 3. IBI-anlæg.


Udover IBI-controllerne findes også et stort udbud af IBI-komponenter der ligeledes har en lille computer indbygget med en lille styringsapplikation. IBI komponenter kan være rumfølere, CO2- følere, målere, betjeningspaneler, lystændinger m.fl.

IBI komponenter kan sammenkobles med andre IBI-komponenter og IBI-controllere, således at der kan opbygges en funktionalitet mellem disse enheder. Dette kaldes at ”binde” systemet sammen. Man ”binder” applikationerne sammen. Kommunikationsprotokollerne mellem enhederne er standardiseret og certificerede. Det vil sige at det er afprøvede og testede protokoller som er blevet certificeret at en international institution. Når de mange IBI-komponenter kan kommunikere med hinanden, kan der opnås en interoperability mellem enhederne. Det vil sige funktionalitet mellem systemerne på IBI-niveau. Branchemæssigt kalder man også dette, at der lægges ”intelligens” i rummet eller zonen. Der er mange energi- og komfortmæssige fordele i en veldesignet IBI-anlæg. Et IBI-anlæg i en større bygning vil typisk blive stort og komplekst.

De kommunikationsprotokoller, der er standardiseret og certificeret og typisk er i anvendelse i IBI-zoner, er LonMark og KNX (tidl. EIB).

Til styring af det elektriske lys i IBI-zonen, anvendes i dag typisk en underliggende kommunikations bus og protokol til lysstyringerne, som kaldes DALI. DALI står for; ”Digital Addressable Lighting Interface”, som også er en standardiseret og certificeret protokol, i henhold til international organisation for DALI. I IBI-anlæg vil der normalt anvendes et interface mellem KNX / LON og DALI.


SRO-anlæg
SRO står for Styring Regulering og Overvågning (dansk begreb).

SRO er den danske betegnelse for det engelske SCADA, som står for System Control And Data Acquisition (system styring og data opsamling). SRO anlæg er den fælles betegnelse for automatikanlæg for styring af produktionsanlæg i industrien, på kraftværker m.m. SRO anlæg er opbygget og struktureret helt analogt til CTS anlæg, men hvor CTS anlægget tager sig af bygningsautomation med de standarder, der gælder her, tager SRO anlægget sig af andre og meget forskellige specifikke styringsopgaver i procesindustrien.

I SRO-anlæg kaldes de computerbaserede produkter for PLC’er som står for Programmable Logic Controller. I procesindustrien udvikler man helt specifikke programmer til styring af maskinerne og produktionslinier, f.eks. robotter, kraftværker, produktionslinier.


SCADA-anlæg eller SCADA platform
SCADA står for System Control And Data Acquisition.

Som beskrevet ovenfor er SCADA anlæg eller en SCADA platform et begreb som både anvendes i CTS- og SRO- anlæg. De fleste større CTS-leverandører har en SCADA platform indbygget i deres hovedcentral, således at der er interface og integrationsmulighed til 3’parts systemer via forskellige drivere, kommunikationsprotokoller og OPC interfaces. Hermed kan flere forskellige gamle og nye bygningsautomationssystemer samles og administreres i en serverplatform. De bygningstilpassede standardapplikationer for CTS og IBI anlæg kan fungere sammen med f.eks. kølemaskinens PLC specialstyring eller et eksisterende brandanlæg af ældre dato.


Kommunikationsprotokoller, interface, åbenhed
Der findes mange kommunikationsprotokoller og teknologier, som anvendes indenfor bygningsautomation. De mest gængse typer er:

BACnet (certificeret), som står for Building Automation and Control Networks og er den førende certificerede standard for CTS-anlæg og de samlede bygningsautomationsløsninger. Det er en ASHRAE, ANSI og ISO standardprotokol. Den er designet til det samlede bygningskontrolsystem som CTS, HVAC, brand- og tyveri sikringssystemer. Udviklingsarbejdet med BACnet blev startet i 1987 i USA. Når flere af de ovenstående bygningssystemer har BACnet, er det muligt at samle disse systemer på en fælles BMS-platform på opnå en højere fælles funktionalitet mellem systemerne.

BACnet certificering er opdelt i forskellige kategorier såsom BACnet på hovedstation, BACnet på kommunikation, BACnet på undercentralernes applikationer, m.fl. Og som det kan ses på BACnet organisationens hjemmeside er der er forskel på hvad de enkelte leverandører kan levere.

Målsætningen og arbejdet med BACnet standarden er at kunne få de forskellige bygningssystemer til at fungere sammen og opnå de funktionelle fordele, der ligger i det IT-mæssige samspil mellem systemerne. Efterhånden som de enkelte BACnet produkter udvikles til at kunne flere og flere funktioner, udvikles også muligheden for øget funktionalitet mellem systemerne via BACnet kommunikation. Denne udveksling af data mellem systemerne kaldes for at kommunikere med åbne BACnet protokoller og opnå interoperability (læs mere i nedenstående afsnit om åbenhed). Se mere på følgende websites: www.bacnet.org og www.bacnetinternational.org.

Som følge af de store integrationsmuligheder med, at systemer kan kommunikere sammen via BACnet, er der nogle overordnede forhold og betragtninger som man skal forholde sig til. Dette gælder for BACnet som for de efterfølgende beskrevne protokoller og interfaces (læs mere om dette under afsnittet åbenhed).


'LonMark (certificeret) eller Lon (ikke certificeret), som står for Local Operating Network. Anvendes primært på IBI-anlæg. Dog er der nogle CTS-undercentraler der også anvender Lon. LonMark er også åbne protokoller, som der kan opnås interoperability med. Se mere på følgende websites: www.echelon.com og www.lonmark.org.


KNX (certificeret) er en fusion af flere IBI-standarder som EIB, Batibus og EHS. KNX anvendes primært på IBI-anlæg og er åbne protokoller, som der kan opnås interoperability med. Se mere på websitet www.knx.org.


DALI (certificeret), står for Digital Addressable Lighting Interface. Det er åbne protokoller, som der kan opnås interoperability med. DALI anvendes primært til styring af elektrisk lys og ofte i en funktionel forbindelse med IBI-anlæg. Se mere på websitet www.dali-ag.org


M-Bus står for Meter-Bus. Det er en europæisk standard som har eksisterende i mange år. Den anvendes primært til opsamling af målerdata fra M-bus målere. Se mere på website: www.m-bus.com.


Modbus er en kommunikationsprotokol, som blev lanceret af Modicon i 1979 til brug i PLC’er. Som kommunikationsprotokol er den blevet lidt af en ”de facto standard” i industrien. Modbus anvendes primært i proces- og industrianlæg. I bygningsautomatik anvendes Modbus bl.a. ved køleanlæg, måleropsamling og nogle ventilationsanlæg med autonom automatik med kommunikation. Se mere på websitet www.modbus.org.


OPC står for Object Linkin and Embedding (OLE) for Process Control eller OLE for Proces Control. OPC er ikke en protocol, men et interface til anvendelse mellem forskellige industrisystemer. OPC anvendes primært til proces og industrianlæg. I bygningsautomatik ses OPC anvendt ved køleanlæg, elevatorstyringer, kommunikation til ældre CTS-systemer eller sikringsanlæg. Se mere på websitet www.opcfoundation.org.


TCP/IP står for Transmission Control Protocol (TCP) og Internet Protocol (IP). Dette er i daglig tale IP-protokollen, som de andre standarder bliver pakket ind i, når der kommunikeres over intra- eller Internettet. Se mere på www.en.wikipedia.org/wiki/Internet_Protocol_Suite.


Profibus står for Process Field Bus. Profibus anvendes primært i proces- og industrianlæg. Det er ligeledes PLC’er der primært anvender Profibus. Se mere på websitet www.profibus.com.


'Åbenhed i 3 trin
Hvis man vil have operabilitet mellem systemerne må man opdele åbenhed i flere niveauer. Som illustreret i figur 4 kaldes den laveste grad af åbenhed for compatability. Her kan flere enheder eksistere på samme niveau - f.eks. Lon målere og IBI controllere der bruger samme lonbus - uden at være forbundet til hinanden. Et mellemniveau af åbenhed kaldes interoperability. Her er protokoller åbne og standardiserede og certificerede til at kunne fungere sammen. Et eksempel er KNX IBI-controller, der uden problemer kan kommunikere og fungere sammen med et betjeningspanel på KNX. Det højeste niveau af åbenhed kaldes exchangeability. Dette niveau skal forstås som, at man bare kan skifte et produkt ud og sætte et andet i, hvorefter det fungerer uden at der sker noget tab af funktionalitet.

Som det er i dag, er det niveauerne compatability og interoperability der er åbenhedsniveauet for de åbne protokoller. Det mest åbne niveau exchangeability er nok mere af teoretisk karakter, idet tendensen er, at CTS, PLC og IBI enhedernes hardware og software samt applikationerne bliver mere specielle og individuelt udviklet til produkterne og løsningerne. Så det vil ikke være muligt at udskifte enhederne uden af skulle lave et større ombygningsarbejde.


Figur 4. Åbenhed i 3 trin.


Det er nærliggende at få den tanke, at med BACnet, LonMark og KNX må der være leverandør-uafhængighed, så man bare kan koble det hele sammen (som ”plug-and-play” filosofien i Microsoft standardprodukter) og frit kan vælge alle mulige leverandører til at arbejde og servicere i systemet. Dette er ikke målsætningen med specielt BACnet, hvorfor denne tankegang heller ikke virker i praksis hos brugeren. Den eneste, der er ”leverandør-uafhængig”, er systemintegratoren. Systemintegratoren skal ”binde” enhederne og systemerne sammen, og sidder med hele kompetencen for dette system. Er der flere leverandører under systemintegratoren, kan det blive et kompliceret leverance- og garantiforhold. Hvis ikke brugeren i sin tekniske afdeling har en systemintegrator ansat, der har den specifikke kompetence, skal denne specielle kompetence købes i byen. Hvis systemintegrationen ikke har dokumenteret sit projekt ordentligt, er der også en risiko for at blive mere personafhængig end leverandørafhængig. Det er derfor vigtigt at have fokus på en leverandør der har kompetence og organisation til at kunne supportere over en lang periode.


Netværk
CTS-anlæg, IBI-anlæg, sikringsanlæg m.fl. kommunikerer alle sammen via kommunikationsbusser. Disse kommunikationsbusser kaldes i daglig tale netværk. I netværksløsninger arbejder man med netværksstruktur og ID-adresser. For at have CTS- og IBI-anlæg, der konstant og hurtigt kan levere en høj ydelse, er en struktureret og strategisk opbygning af ID-adresser og netværksstrukturen af vital betydning. Netværksløsninger er en fagdisciplin for sig selv, som skal være med i den samlede betragtning af bygningsautomationen.


HMI (Human Machine Interface)
Hele bygningsautomationen er et meget teknisk system, hvor alt hvad der foregår i systemet som kommunikation, styringer, reguleringer er af meget teknisk karakter. For at driftspersonale og andre daglige brugere at systemet kan anvendes bygningsautomationen på en effektiv måde, er der udarbejdet en brugerflade eller et interface mellem ”mennesket og bygningssautomatikken”. Dette interface kaldes HMI, som står for Human Machine Interface. Som det er illustreret i figur 5, er den overordnede HMI placeret på CTS hovedcentralen. Det er via dette interface man gennem en grafisk betjeningsflader kan betjene de tekniske anlæg, oprette log på data i systemet, energiovervåge og udarbejde alarmlister fra hændelser i systemet. Et korrekt design og struktur i HMI er vigtig for hurtigt og enkelt at få den korrekte information og forståelse for bygningens klima og energiprocesser og for nemt at kunne reagere på hændelser i systemet. Andre betjeninger af systemet som betjeningspaneler, setpunkt på rumfølere er også HMI, dog i en mere enkel udgave.


Figur 5. Principskitse HMI.


BMS
BMS står for Building Management System. BMS er den internationale betegnelse for den “hovedcentral” hvor alle underliggende anlæg og systemer integreres op mod. Det betyder at man har en platform, hvorfra man kan betjene og administrere alle anlæg, systemer og data i bygnings-automationen. I Danmark er det typisk de CTS-hovedcentraler der har en SCADA platform, der har denne BMS funktion.


ERP
ERP står for Entreprise Ressource Planning.

BMS platformen har kommunikation til det tekniske system (bygningsautomationen) og en kommunikation til HMI (driftspersonel og brugere). Men med en korrekt opsat BMS platform er det også muligt at kommunikere data til de administrative systemer eller planlægningssystemer. Dette kaldes bl.a. for ERP. Det kan være energidata eller driftstimer fra bygningsautomationen, der skal overføres til det økonomiske system, til drift- og vedligeholdelsessystemet, til forbrugs- og energidata-systemet eller til et SAP / Oracle system.


Brandsikringsanlæg, ABA, ABDL, ASP
Det er ligeledes muligt med en del brandsikringssystemer at integrere disse på den fælles BMS platform, så man kan få en fælles betjeningsplatform af systemerne.


Tyverisikringsanlæg, ITV, AIA, ADK
Det er muligt med en del tyverisikringssystemer integrere disse på den fælles BMS platform, så man kan få en fælles betjeningsplatform af systemerne.


TBS (Total Building Solution)
TBS står for Total Building Solution. Mulighederne for bygningsautomationen bliver store, når alle de forskellige systemer som CTS, IBI, Brand, Tyveri er samlet i en fælles BMS platform. Og hvis der er interoperability mellem alle systemerne gennem standardiserede og certificerede protokoller, kan der laves tværgående funktionaliteter mellem systemerne, således at BMS bygningsautomationen kan leverer en højere ydelse til brugeren i form af energihåndtering, komforthåndtering og administration m.fl. Et af navnene på sådan en systemløsning er TBS.


Bygningsautomationens ydelser og energiforbruget

Dette afsnit beskriver i en meget forenklet principmodel bygningsautomatikkens grundlæggede ydelser og funktion for komfort og energiforbrug. Bygningsautomatikken kaldes fremefter for CTS-anlægget.

I figur 6 er vist en model, der skitserer opbygningen af et CTS-anlæg anvendt til komfort og energi.

Modellen er opbygget med fire kolonner, som fra venstre viser af bygningen får tilført komfort. Komfortydelsen leveres af bygningens tekniske procesanlæg. Der er lyskilder der leverer lys, radiatorer der leverer varme, ventilation der levere luft m.fl. Til at levere komforten og drive procesanlæggene kræves ekstern energiforsyning. Energiforsyningen er blandt andet kraftvarmeværker og vindmøller.


Figur 6. Principskitse for bygningsautomation, komfort og energi.


I den sidste kolonne er vist CTS-anlægget, som består af undercentraler med specielt designet software automatik, der styrer og regulerer det enkelte energiforbrugende procesanlæg. CTS-anlægget samler også oplysninger om forskellige tilstande og behov i bygningen. Dette gøres via forskellige sensorer som er placeret i bygningen. Det kan være rumfølere som måler den aktuelle temperatur i lokalet samt PIR-føler, der registrerer om der er mennesker i lokalet (varmebevægelse). Disse data koordineres med styringen af procesanlæggene. Energidata fra energimålere samles også op af CTS-anlægget. Disse anvendes til energiafregning, men kan også bruges til at koordinere det aktuelle energiforbrug med bygningens procesanlæg.

Komfort- og energikravene til bygninger i dag er meget høje. De skal bruge så lidt energi så muligt og levere en høj komfort. Der er mange personer i bygningerne som har meget forskellige komfort krav. Der er mange procesanlæg til at drive komforten og mange andre tekniske anlæg. Der er forskellige termodynamikker afhængig af bygningens udformning og design, typer, alder, teknologi m.fl. Et CTS-anlæg kan tilpasse løsninger til disse mange forhold.

Hvis der installeres et IBI-anlæg, kan hvert enkelt rum i en bygning få sin egen komfort og klimastyring. Dette kaldes en IBI zonestyring. Med en IBI-zonestyring er det muligt at lave endnu mere detaljeret og optimeret energistyring i forhold til komfortydelser.

Dette er bare med fokus på komfort i forhold til energiforbrug. Jo mere omfattende CTS-anlægget og bygningsautomationen er, jo flere ydelser kan man få leveret fra det, og med lidt øget investering kan man opnå mange ekstra ydelser, der kan være til fordel for den organisation eller virksomhed der er i bygningen. Dette er et meget omfattede emne, som ikke behandles i denne beskrivelse, men for at give en forståelse af mulighederne gives en kort beskrivelse i henhold til nedenstående principmodel i figur 7.


Figur 7. Principmodel: Ydelse kontra energiforbrug.


En bygning uden automatik vil konstant levere den ydelse, som bygningens procesanlæg er designet til, men til et stort årligt energiforbrug, og dermed til høje årlige driftsomkostninger.

Såfremt der kommer autonom automatik på procesanlæggene, vil der kunne leveres en eller flere stabile ydelser til et muligt reduceret energiforbrug, afhængig af procesanlæggenes indbyrdes sammenspil.

Hvis der kommer CTS-anlæg på bygningens procesanlæg, er det muligt at lave et meget bedre sammenspil mellem procesanlæggende og opnå flere ydelser fra anlæggende til et reduceret energiforbrug. Sammenkobles CTS- med IBI-anlæg kan disse fordele optimeres og øges yderligere.


Øges CTS eller CTS og IBI-anlæggenes styringsomfang og funktionaliteter på procesanlæggende vil mange kunne hente endnu flere ydelser ud at systemet, samt optimere ydelserne i forhold til energiforbruget.

Med sammenkobling af CTS, IBI og evt. Sikringsanlæg kan man få et BMS anlæg med mange ydelser. Vælges et TBS system kan alle bygningens tekniske installationer og procesanlæg fungere i samspil med hinanden gennem standardiseret protokoller, netværk etc., som tidligere beskrevet. Der kan opbygges et højt ydende system med mange ydelser og funktionaliteter til et energioptimalt energiforbrug.

Som det er beskrevet ovenfor er disse systemer nogle af løsningerne på fremtidens lavere energiforbrug og høje ydelser for bygninger. For at få en mere systemteknisk forståelse beskrives efterfølgende, hvordan et BMS-TBS system som overordnet struktur er opbygget.


Overordnet systemopbygning

Et BMS-TBS system bliver som regel rimeligt stort med mange teknologier, netværk, protokoller og fagdiscipliner, der er i samspil med hinanden.

Som det er vist i principmodel figur 8, bør sådan et system opbygges med en struktur hvor systemet er delt op i det tekniske system (som indeholder CTS, IBI, tekniske installationer og procesanlæg, sikringsanlæg m.fl.), som er samlet i en HMI / SCADA serverplatform (BMS-TBS serverplatform). HMI er den brugermæssigt grafiske betjeningsflade, der på en intuitiv og let opfattelig måde giver forståelse for procesanlæggenes ydelser, komfort og energiforbrug. Det skal ligeledes være let at betjene bygningens systemer fra HMI brugerfladen. Der skal være overblik og overskuelighed, med let adgang til data.


Figur 8. Systembeskrivelse af BMS/CTS anlæg.


BMS-TBS serveren kan være tilsluttet det administrative net eller planlægningsnettet, Serveren skal så kunne levere data til andre systemer som f.eks. energidata til energiovervågning, eller logdata for tryk / temperaturovervågning, energidata til økonomisystemer som SAP, Oracle m.fl.

Det tekniske system under BMS-TBS serveren bør være opdelt i et management level, hvor alle de overordnede ledelse- og betjeningsprocesser foregår. Herefter er der automation level, som er det niveau hvor automation eller styring af procesanlæggene foregår. Og til sidst er der field level som er det nederste niveau hvor alle de mere simple styringer er placeret. Dette niveau er også mere omfangsrigt da der er mange komponenter på dette niveau. Med denne opdeling har man decentraliseret processerne og styringerne, så det samlede system kan fungere hurtigere og med en høj performance.


Strategi for bygningsautomation

Bygningsautomationssystem som BMS-TBS, CTS-IBI bliver i mange tilfælde bare købt og implementeret uden større overvejelser om, hvad systemerne skal bruges til. Dette kan koster mange penge, og man kan få et ringe udbytte.

Derfor er det vigtigt at der gøres en del overvejelser inden man igangsætter et projekt. Det er et fagområde der spreder sig over mange discipliner, og som der egentligt ikke findes nogen uddannelse i. De største kompetencer og erfaringer findes hos de store CTS-leverandører der har hele produktporteføljerne og driver produktudviklingerne. En del af de større rådgivere har også gennem en lang årrække oparbejdet viden og kompetencer omkring disse fagområder. Disse virksomheder kan hjælpe til med at få designet og planlagt BMS-TBS, CTS, IBI systemer, der er meget velfungerende og teknologisk langstidssikrede. De kan også hjælpe med at opbygge en strategi og afdække de mange faldgrupper og sidespor der findes i denne proces med analyse, planlægning, implementering, drift og vedligehold, teknologisikring.

For at give en forståelse for de problemstillinger man kan stå overfor, når der skal lægges en strategi for BMS, er der i figur 9 vist en principskitse over et udpluk af de emner, som der typisk skal tages stilling til.


Figur 9. Principskitse for BMS/CTS strategimodel.


Den samlede performance
Der skal tidligt planlægges de krav og ydelser der ønskes fra systemet. Både nuværende ydelser og hvordan systemet skal kunne udvikles over tid. Da det er et IT-system der opbygges skal det teknisk designes til at kunne arbejde så nær real-tid som muligt. Man skal passe på uautoriserede IT-løsninger som blandt andet kan skabe problemer på netværk, IT-sikkerheden, versionshåndteringer, opgraderinger.


Service, drift og vedligehold
Man skal fra start tage stilling til hvilken driftsmodel der ønskes anvendt. Det skal sikres at systemets produkter, løsninger, ydelser og teknologi er driftsikre over lang tid, så driftsmålene kan opnås.


Teknologisikring, kompatibilitet, livscyklus og teknologiudvikling
Udviklingen inden for bygningsautomations-teknologierne går stærkt. Man skal have fokus på, at langt fra alle produkter er levedygtige over tid. Det er vigtigt at der er (bagud) kompatibilitet i produkterne og at de har en lang produkt- og system-livscyklus. Leverandørerne skal kunne teknologisikre systemerne, så investeringen ikke går tabt.


HMI platform
Der skal være fokus på, at HMI platformen er struktureret opbygget og at der er overblik og nem adgang til diverse bygningsdata og til betjening af anlæg. HMI’en er virkelig et emne man skal have afdækket, da det er hele brugerinterfacet til systemet.


Netværk, sikkerhed og protokoller
Der skal bruges tid på at planlægge og opbygge de rette netværksstrukturer og udviklingsstrategier. Dette gælder ligeledes for anvendelse af protokollerne og kommunikationsinterface for at have en smidig kommunikation. Det skal også overvejes hvilken sikkerhedspolitik og foranstaltninger der anvendes på netværket. De bygningstekniske systemer bliver efterhånden integreret mere eller mindre i det samlede IT-netværk, hvorfor der kan opstå nye sikkerhedshuller som man skal være opmærksom på.


Kompetence og produktsikkerhed
Det er vigtigt at bruge leverandører, der har kompetence til at håndtere alt med et bygningsautomationssystem. Som det tidligere er beskrevet er der mange fagdiscipliner, viden og produkter der er i anvendelse i bygningsautomation. Så det skal helst være leverandører der har en dyb og bred viden. Leverandøren skal også være en stabil virksomhed som man er sikker på vil eksistere i lang tid fremover. Leverandøren skal også gerne kunne håndtere produkt- porteføljen over tid, så det samlede bygningsautomationssystem hele tiden vil kunne fungere optimalt.


Energi og komfort
Der skal udarbejdes regulerings- og styringsstrategier for energi- og komfortudviklingen som bygningsautomationen skal imødekomme over tid.


Andre
Afhængig af hvor stort et omfang bygningsautomationen omfatter, skal man være indstillet på, at der vil være en del faktorer indenfor det tekniske, kommercielle, organisatoriske samt andre områder der skal afklares og lægges en strategi for. Man skal ikke bare fokusere på prisen, men fokusere på hvad man vil opnå af fordele. Forsøg at få afdækket behov og ydelsesområde så godt som muligt, inden der designes og tages beslutning.

Kommentarer

Det er ikke muligt at tilføje kommentarer uden en bruger.
Opret en bruger eller log ind her.

Gå til Bygningsautomations diskussionsside for at rette og/eller slette kommentarer her.

Personlige værktøjer