Under heldagsseminaret om byggautomasjon VVS-foreningens Oslo Gruppe arrangerte i desember, tok Skjold blant annet for seg grensesnitt og koordinering.

– ITB-standarden definerer rollen som ITB-koordinator allerede fra forprosjekt, påpeker han. Det å håndtere grensesnitt er en viktig del av ITB-rollen.

– Vi skiller mellom funksjonelle og tekniske grensesnitt, forklarer Skjold. De tekniske handler bare om gjennomføring, for eksempel om en ventil-aktuator passer i radiatorventilen som skal installeres, eller om kabeldimensjon og størrelse på rekkeklemmer samsvarer.

– Dette er en del av grensesnittavklaringer, sier Skjold.

Velge relevante data

Funksjonelle grensesnitt er mellom to eller flere tekniske systemer som har en eller annen funksjon for regulering, styring eller overvåkning, og som skal utveksle informasjon. Bak de funksjonelle grensesnittene ligger normalt en funksjonsbeskrivelse som skal tilfredsstilles.

– Poenget er å gjøre det mulig å drifte på effektiv, rasjonell måte, forklarer Skjold. Alle tekniske anlegg knyttes opp til toppsystem (SD-anlegg) for styring, regulering og overvåkning. Det betyr til gang på store datamengder, fra energimålere, frekvensomformere, kjølemaskiner, pumper og mye mer. 

– Vi må være påpasselige slik at vi ikke får altfor mye opp i toppsystemet – vi vil ikke ha opp data som ikke er relevante for drift. Dette er eksempel på en type vurdering vi gjør i grensesnittarbeidet, forklarer Skjold. Mye data er bare beregnet for lokal feilsøking eller feilsøking for leverandørene.

I/O-lister
Grensesnittavklaringer er en del av design- og prosjekteringsfasen for byggautomasjon. Noen av de vanligste arbeidsverktøyene i denne fasen er I/O-lister (Input-Output), grensesnittliste, grensesnittbeskrivelser, funksjonsbeskrivelser og databaser.

I/O-lister er en tradisjonell måte å innsamle en del data på fra alle systemer, først og fremst data utenfor tekniske rom. I større prosjekter kan det omfatte alt fra nivåvakt og fettutskiller til temperatur og CO2-føler i rom og styring av utelys med fotoceller. Det inkluderer ikke minst signaler fra elektro som skal inn i toppsystem/SD-anlegg.

Grensesnitt
– Grensesnitt er ikke standardiserte. Vi trenger oversikt over alle grensesnitt vi må gjøre noe spesielt med, og det trenger ikke være avanserte grensesnitt, sier Skjold. Som eksempel nevner han radiator-aktuator. Det finnes mange typer radiatorer, og hvis automatikk skal levere aktuator, er det ikke sikkert at valgt aktuator passer til den radiatortypen som installeres i prosjektet.

– Noen ganger er det feil gjenger, andre ganger feil slagmengde på aktuator. Dette er eksempler på små detaljer som det er kjempeviktig å få med seg, understreker Skjold.

Grensesnittlister er oppramsing av alle grensesnitt som krever beskrivelser.

– Slike lister er levende dokumenter gjennom prosjektet; ofte vil vi supplere eller stryke punkter underveis, forteller Skjold.

Grensesnittbeskrivelse
De ulike grensesnittene må beskrives i hvert prosjekt. Ifølge Skjold bør slike beskrivelser kort si noe om systemene som inngår i grensesnittet, ha en funksjonsbeskrivelse av grensesnittet, og angi krav til:

- utveksling av informasjon
- komponenter og utstyr
- dokumentasjon
- igangkjøring, testing, evaluering og opplæring
- kommunikasjon mot SD-anlegget.

– Grensesnittbeskrivelsene bør også inneholde en framdriftsplan med milepæler, sier Skjold.

Buss-eller nettverksbaserte grensesnitt

En rekke buss-baserte systemer krever egne grensesnittbeskrivelser.

– Hvordan skal vi for eksempel kommunisere med ferdigaggregater, og hvilke detaljer trenger vi? Dette må avklares, poengterer Skjold. Andre eksempler på buss-baserte systemer som trenger grensesnittebeskrivelser, er romkontroll for behovsstyrt ventilasjon, pumper med integrert frekvensomformer og energimåler, fancoils, varmepumper/kjølemaskiner, tørrkjølere, energimålere, reservekraft-aggregat og jordfeilsystemer.

Også løsninger integrert på TCP/IP trenger grensesnittbeskrivelse; som ferdigaggregater, kjølemaskiner/varmepumper og reservekraftaggregat.

– Busstyper, protokoller, formater og mengde data er noe av det vi må beskrive for bussbaserte grensesnitt, forklarer Skjold.

Adressestruktur er et eget dokument det er viktig å holde orden på i prosjektene, ikke minst fordi bussbaserte og nettverksbaserte grensesnitt har blitt mer vanlig.

– Spesielt når ting kommer på TCP/IP eller BACnet er det ekstremt viktig å ha orden på adressestrukturer i prosjekt. Vi på automasjon vil gjerne styre den, sier Skjold.

Detaljerte og forpliktende
– Beskrivelsene må være så detaljerte som mulige. Hvis det ikke er mulig i første omgang, er det bedre å lage beskrivelsene i flere runder, mener Skjold. Og avklaringer må gjøres så tidlig i prosjektet som mulig.

– Vi har jevnlige grensesnittmøter fra tidlig i prosjektet. Noen er større koordineringsmøter med flere aktører, og så har vi en rekke møter med ulike aktører som er involvert i et eller flere grensesnitt, forklarer Skjold. 

Beskrivelsen klargjør hvilke aktører som har ansvar for hva; alt fra å levere tekniske data og montere til å sette bussadresser og kable/koble til automatikkskap. Hvordan signalene skal kommuniseres, er selvsagt en viktig del av grensesnittbeskrivelsen.

– Grensesnittbeskrivelsen må avklares tidlig i prosjektet. Den må være forpliktende for alle parter - ned på detaljnivå, understreker Skjold. I praksis betyr det at alle parter må signere beskrivelsene.

Flytte på grensesnitt
Beskrivelser og avklaringer er viktig også fordi det ofte kan være gunstig å flytte på grensesnittene mellom fagene i et prosjekt. Hvis byggautomasjon i utgangspunktet skal levere energimåler, kan det være fornuftig å flytte dette grensesnittet når rør kan levere pumpe med integrert energimåler.

– Totalt sett er det en bedre løsning. Men selv om slike skift er ønskelig, kan det være svært vanskelig å få til fordi alle holder på sitt, fastslår Skjold. Hans erfaring er at slike skifter går lettere i totaltekniske entrepriser.

 

Godt samspill og god komfort

I prosjekter handler mye av arbeidet med grensesnitt om å sørge for at ting kommer i riktig rekkefølge, og sikre godt samspill mellom tekniske systemer.

– Overordnet handler automasjonsanlegg om å oppnå godt inneklima og god komfort for brukerne av bygget, god økonomi for eierne og anlegg som er hensiktsmessige og effektive for driftere. I tillegg forsøker vi hele tiden å oppnå energieffektivitet – i hele byggets levetid, understreker Skjold.

FAKTA: Typiske grensesnitt og avklaringer
Skjold har vært ITB-koordinator for den nye bydelen Hamar Stadion, et byggeprosjekt på 75.000 m2 hvor GK Norge har hatt totalteknisk entreprise. Erfaringene fra prosjektet viser eksempler på typiske grensesnitt og avklaringer:

Kjølemaskin og tørrkjøler

  • Hvem har ansvar for å gi spenning til tørrkjøler-skal det gå via automatikktavle, eller direkte fra elektro

    Hvor mye skal automasjon styre kjølemaskina? Maskina styrer isvann automatisk, mens automasjon skal gi start og stopp. Hva med strømningsvakter og pumpestyringer?

  • Er det et kjent produkt, eller bør vi teste det på forhånd?

  • Skal maskinen tilknyttes på buss eller TCP/IP?

Pumper

  • Hvordan skal vi styre pumper – bare av/på eller også hastighet?

  • Er det fornuftig å måle pumpeeffekt?

  • Hva slags buss-kommunikasjon skal vi i så fall ha?

 

Automatikk-tavle

  • Hvor skal vi sette tavla?

  • Hvem skal beregne kabeldimensjonen fra tavla og ut?

  • Hva slags underlag må elektro ha for å kable?

Frekvensomformere

  • Hvem skal levere dem – vifte- eller pumpeleverandør eller automasjon?

 

Datanettverk

  • Skal SD-nettverket bruke det generelle datanettverket i bygget, eller lage sitt eget?

– Automasjon er en av de store brukerne i datanettverk fordi mye utstyr er TCP/IP-basert. Jeg har ofte sett at datanettverk har blitt løst altfor sent prosjekter, så derfor tar jeg det alltid opp tidlig, forteller Skjold.

– Automasjon er en av de store brukerne i datanettverk fordi mye utstyr er TCP/IP-basert. Jeg har ofte sett at datanettverk har blitt løst altfor sent prosjekter, så derfor tar jeg det alltid opp tidlig, forteller Skjold.

 

CCstadion kveiler teknisk rom.jpg

Koordinering av grensesnitt er viktig fra starten av – ikke minst i store prosjekter som Hamar Stadion. Foto: Hilde Kari Nylund