God behovsstyring krever godt samspill mellom tekniske systemer. Det å optimalisere kan for eksempel kreve informasjon om spjeldvinkel og ønsket tilluftstemperatur fra romkontroll inn i regulator for ventilasjon.  

– Alt dette skal samkjøres, hele tida. Vi skal få ned energibehovet, og samtidig ivareta optimal komfort, poengterte Mortensen under byggautomasjon-seminaret Oslo Gruppe i VVS-foreningen arrangerte i desember.

Besparelser med integrert I/O
Det finnes mange ferdigsystemer som kan brukes på romnivå.

– En tradisjonell I/O-løsning for ventilasjon krever mer kabling, høyere hardware-kostnader, lengre installasjonstid og total installasjonskostnad blir høyere enn for integrert I/O, fastslår Mortensen. Han underbygger dette med et eksempel hvor tradisjonell I/O krever 19 signalkabler til tavle, mens det er nok med 11 kabler for integrert I/O. (Se figur).  


Ventilasjon med tradisjonell I/O-løsning (til venstre) krever 19 signalkabler til tavle i dette eksempelet og 28 I/O-signaler, mens integrert I/O krever ca 11 kabler og 10 I/O-signaler. Illustrasjon: Dan Frode Mortensen/Honeywell.

Integrert I/O gir både mindre og enklere kabling, og tilgjengelig teknologi har kommet langt.

– Vi har høy grad av instrumentering internt i utstyret, og det gir mange muligheter, fastslår Mortensen. Pumper, frekvensomformere og også ventiler har mye data. Blant annet kan man hente ut luftmengder og energibruk for å beregne SFP- og SPP-faktorer. Per i dag har de færreste dette integrert.  

– Slike løsninger gir høyere grad av instrumentering for sluttbruker. Dermed er det mulig å sette opp tilstandsanalyser, rapportering og eventuell alarmering. Det gir kjempefordeler i forhold til betjening, mener Mortensen.

Stor variasjon for undersentraler
Veldig mye av integrasjonen skjer på feltnivå.

– Autonom behandling av for eksempel ventilasjon og varme på feltnivå, er helt klart en fordel, sier Mortensen. Undersentraler finnes i mange ulike typer fra ulike produsenter, og med ulike ambisjonsnivåer. De kan være konfigurerbare, programmerbare og fritt programmerbare.

Konfigurerbare undersentraler kan for eksempel være ferdigaggregat som leveres med undersentral som har et visst program.

– Da kan du velge hvilke funksjoner du vil sette opp, men du kan ikke gjøre radikale endringer, understreker Mortensen.

Også med de programmerbare er en del ting låst, slik at man for eksempel ikke kan hente inn hva somhelst av IO-konfigurasjoner.

– Her finnes det en del begrensninger i enkelte produsenters undersentraler, sier Mortensen.

Bør være fleksibel
Med de fritt programmerbare kan man gjøre nesten hva som helst – men selvsagt velge ut fra behovet i det enkelte systemet.

– De største forskjellene handler om programmeringsverktøy og hvilke bibliotek man har tilgjengelig for å lage den logikken man trenger. Det viktigste er at undersentralen er fritt programmerbar og fleksibel i forhold til ulike kommunikasjonsmetoder. Og det er en stor fordel å velge systemer som er testet i henhold til en viss standard – og godt dokumentert, anbefaler Mortensen.

Dessuten understreker han at historikken bør lagres i undersentralen slik at man beholder den hvis kommunikasjonen med toppsystemet forsvinner.

– Å bytte leverandør kan bety at funksjonaliteten er ulik. Noen ganger er det derfor en fordel å velge samme leverandør slik at man får lik funksjon på et bygg. Hvis ikke blir det mer uoversiktlig for drifterne, poengterer Mortensen. Tverrfaglig merkesystem (TFM) er eksempel på et godt verktøy som gir gjenkjennelse for driftere.

Lon litt av moten
En av de vanligste buss-kommunikasjonsløsningene er Lon.

– Den brukes på feltnivå til I/O-kommunikasjon. I andre sammenhenger til elmålere, T-banekontrollsystemer, brannvarsling med mer, forteller Mortensen. I Europa er den mest brukt til twisted pair (serielt).  Lon ble utviklet av Echelon i 1988, og fortsatt må alle kjøpe en chip (hardware) av selskapet for å kunne bruke denne bussen. Lon må kommisjoneres i hvert enkelt prosjekt – det vil si å sette opp adresser på noder, og velge hvilke noder og punkter som skal kommunisere med hverandre. Kommisjoneringen kan bare gjøres fra ett verktøy.

– Det er en god og stabil buss, men for byggautomasjon tør jeg påstå at Lon har gått litt av moten, sier Mortensen.

M-buss langsom
M-buss ble utvikler for kommunikasjon av termiske energimålere.

– Den er ikke kjapp, så det er viktig å bruke den til hva den er tiltenkt: innhenting av data. M-buss bør ikke brukes hvis du er avhengig av rask kommunikasjon, understreker Mortensen. Den er leverandøruavhengig, og har fri topologi slik at det er mulig å ha flere kilometer kabel.

– Den er også selvdokumenterende, og finner enheter og objekter som er tilkoblet, opplyser Mortensen.

Ulik kommunikasjon for Modbus
Modbus er utviklet for industri, og er leverandøruavhengig. Den er master/slave-basert, og brukes til feltutstyr, energimålere/nettanalysator – og den er mye brukt til ferdig-automatikk som ventilasjonsggregater, kjølemaskiner og brannspjeld. Modbus er kjappere i forhold til kommunikasjon.

– Ulempen er at Modbus ikke er godt nok standardisert. Selve kommunikasjonen er standardisert, men ikke datalagringen i de ulike registrene.  Man mådefinere registre, og velge hvilke og hvordan verdier er lagret i de ulike registrene. Det finnes veldig mange produsenter som ikke leverer en helt god definisjon, sier Mortensen.

Foretrekker BACnet
For kommunikasjon på undersentral-nivå har han en klar favoritt:

– BACnet er den foretrukne løsningen, mener jeg. Det er utviklet spesifikt for byggautomasjon-systemer, er leverandøruavhengig og datalaget er uavhengig av bærer, sier Mortensen. Flere ulike fysiske bærere er tilgjengelig, som BACnet Mstp (seriell EIA485/RS485) og BACnet IP (standard ethernet-kabel).

Utstyr kan testet hos en uavhengig testlab, etter en egen standard for hvordan testene skal utføres.

– Alt er ikke testes, og det er noe av utfordringen. Man bør alltid velge utstyr som er testet, såkalt BTL-sertifisert, mener Mortensen. BACnet er også den eneste protokollen man bruker på alle nivåene, poengterer Mortensen. Kommunikasjonen er objektbasert, og BACnet er selvdokumenterende, det vil si at den finner enheter og objekter.

Rett fra toppsystemet
Mortensen bruker tidsstyring som eksempel for å illustrere fordelene med BACnet.

– Her finnes det et eget objekt som inneholder all informasjon om tidsstyringen, med svitsjetider og alt. Undersentralen kan ha klokka liggende i seg og klokka kan styres fra toppsystemet, forklarer Mortensen. På Modbus ligger tidsstyringen som regel i toppsystemet, som svitsjer et register av og på.

Med BACnet kan toppsystem kan kommunisere direkte med feltutstyr via undersentralens router uten prosjektering i undersentral, ifølge Mortensen en kjempefordel. For eksempel kan man hente ut energidata som ikke nødvendigvis trengs på undersentralnivå.

– Og BACnet kan bli gedigne systemer med flere millioner enheter, sier Mortensen.