Udgivet af BMS. Danmarks Tekniske Universitet DTU Campus Service

Transkript

1 VEJLEDNING I INDKØB OG INSTALLATION AF BACNET ENHEDER Denne standard er en del af DTU s standarder til entreprenører og kunder omhandlende BMS (Building Management System). Standardc:\users\topl\dropbox\dtu\bms\standarder\ netværk\4 vejledning\vejledning i indkøb og installation af bacnet ip Side 1 af 7

2 BESKRIVELSE AF INDKØB OG INSTALLATION AF BACNET ENHEDER Gældende fra Version 1.2 MSKLA Indhold Indledning... 3 Formål... 3 Indkøb Controllere... 3 Controllere generelt... 3 Krav til kritiske controller enheder... 4 Krav til ikke kritiske controller enheder... 5 Krav til I/O - enheder... 5 Krav til gateway - enheder Krav til BACnet objekter... 6 Relaterede dokumenter:... 7 Versionshistorik:... 7 Kvalitetssikring:... 7 Side 2 af 7

3 1 Indledning Dette dokument beskriver krav til BACnet enheder installeret på DTU s BACnet IP - netværk. Kravene tager udgangspunkt i BACnet standarden: ANSI/ASHRAE Standard , A Data Communication Protocol for Building Automation and Control Networks. BACnet - standarden indeholder definitioner af objekter, application-services samt protokol - kodning. Dette dokument er inddelt i afsnit omhandlende forskellige aspekter af de krav der stilles til systemet. Standarden omhandler udelukkende enheder koblet direkte til DTU s BACnet IP - netværk. Dette dokument anvendes ved indkøb, projektering og installering af BACnet enheder på DTU. Målgruppen for denne standard er rådgivere, entreprenører og installatører. 2 Formål Formålet med denne standard er at sikre, at alle enheder som kobles på DTU s BACnet IP netværk overholder BACnet kravene samt de supplerende krav som DTU stiller. Kravene til b.la. objekttyper, properties og andre parametre stilles, så alle enheder kan håndteres på en ensartet måde, af det fælles SCADA system, Vijeo Citect. Derudover er formålet at sikre den nødvendige dokumentation af enheder, herunder navngivning af punkter i undercentraler o.l. for efterfølgende godkendelse af DTU vha. af E-EDE dokumentet. Slutteligt er formålet at sikre en ensartet projekthåndtering, herunder tildeling af IP-numre og BACnet netværksnumre fra DTU s side samt udfyldelse af BPAT-dokumenter foretaget af leverandøren Indkøb Controllere Dette afsnit omhandler controllere. Controllere defineres i DTU sammenhæng ved, at de har en regulerende og / eller styrende funktion. Enheder som modtager eller måler værdier for herefter at påvirke udgange på baggrund af det målte, er at opfatte som controllere. Afsnittet definerer hvilke typer controllere der skal anvendes til hhv. kritiske og ukritiske anlæg. Bemærk! Udover krav til controlleren, stilles der yderlige krav til objekter og properties (se afsnit Krav til BACnet objekter) 3.2 Controllere generelt For alle enheder som kobles på DTU s BACnet - netværk skal der udleveres en PICS ( Protocol Implementation Conformance Statement ). Dette dokument beskriver, hvilke dele af BACnet standarden en given enhed har implementeret. PICS en skal afleveres i Word format (docx) samt i epics format for videre elektronisk behandling. Alle enheder skal være testet i forhold til de objekttyper og services som leverandøren har oplistet i den tilhørende PICS. Det er leverandørens ansvar, at standarden overholdes men der stilles ikke direkte krav til BTL listing. Enheden skal dog stadigvæk været testet i henhold til "Testing Conformance to BACnet. Side 3 af 7

4 DTU forbeholder sig retten til at afvise enheder som fejler en BTL test, foretaget efter den gældende testversion, på daværende tidspunkt. Eventuelle afvigelser skal altid godkendes af DTU. For controllere med mere end 20 objekter, synliggjort på BACnettet via en BACnet - gateway, skal følgende krav overholdes: DS-RPM-B Data Service Read Property Multiple Programmerbare controllere, hvor enkelte bagvedliggende I/O enheder ikke er direkte synlige på BACnettet men, hvor der er oprettet et antal BACnet objekter (max. 20 stk.) som repræsenterer I/O værdier fra de bagvedliggende enheder, kan accepteres, hvor det ikke er muligt at opnå en decideret gateway funktion. Ved brug af intern alarmbehandling i controllere skal følgende BIBB s være supporteret: - AE-N-I-B - AE-ACK-B - AE-INFO-B Ved brug af trendlogning i controllere skal følgende BIBB s være supporteret: - T-VMT-I-B - T-ATR-B Ved brug af Schedule Objects skal følgende BIBB være supporteret: - SCHED-I-B Alle controllere skal kunne håndtere forespørgsler minimum hvert 10 sek. i henhold til DTU Beskrivelse for bygningsautomation, afsnit Generelt Stk. 5 stk Krav til kritiske controller enheder I forbindelse med kritiske anlæg skal controlleren som minimum overholde følgende device profil: B-BC BACnet Building Controller B-BC stiller b.la. krav til, at alarmnotifikation og trendlogning skal kunne foretages i selve controlleren. Derudover stiller B-BC krav til Schedule Objects som kan styre analoge og digitale værdier både i controlleren selv samt i andre enheder. Foruden ovenstående krav skal B-BC have skrivbar Recipient_List (property) og listens værdier skal bevares ved reset og strømsvigt. Side 4 af 7

5 3.4 Krav til ikke kritiske controller enheder I forbindelse med ikke - kritiske anlæg skal følgende device-profil som minimum overholdes: B-ASC BACnet Application Specific Controller 3.5 Krav til I/O - enheder Begrebet, I/O enheder dækker over simple sensor - eller aktuator - enheder som ikke foretager en selvstændig logisk behandling af de målte data. Enhederne aflæser fysiske værdier og overfører dem til netværket eller modtager værdier fra netværket som derefter påvirker fysiske udgange i enheden. Normalt er kravene til sensorenheder opfyldt hvis I/O enheden overholder en af følgende device - profiler: B-SS B-SA BACnet Smart Sensor BACnet Smart Actuator 3.6 Krav til gateway - enheder Dette afsnit omhandler kommunikation med enheder som ikke er direkte tilsluttet et BACnet IP netværk (i denne sammenhæng kaldet fieldniveau). Der findes forskellige muligheder, for at udføre denne form for kommunikation. Det kræves, at andre protokoller integreres, via en af følgende, i BACnet - standarden definerede gateway-funktioner (se ANNEX H - COMBINING BACnet NETWORKS WITH NON-BACnet NETWORKS i BACnet standarden): - Router-Gateway hvor en gateway enhed optræder som en BACnet router og via interne regler simulerer at der routes til et eller flere andre BACnet - netværk. Med denne funktion vil det tilsluttede fieldniveau med en anden protokol, optræde med netværksnummer på BACnettet, samtidig med at enheder tilsluttet fieldniveau, vil optræde som BACnet - enheder på dette netværk. Eksempel: På et IBI netværk sidder der 20 IBI enheder som kommunikerer internt med LON protokol. Med en router gateway gives LON - nettet et BACnet netværksnummer. Gatewayen optræder som en BACnet router, samtidig med at de 20 LON enheder, vil optræde i systemet som 20 BACnet enheder på det routede netværk. De 20 IBI enheder vil derfor have hver deres fysiske adresse samt hver deres device ID svarende til en, hvilken som helst anden BACnet - enhed. Fra BACnet IP backbone ses altså en router til et underliggende BACnet netværk med eget nummer og med et antal enheder med hver deres adresse på dette net. - Virtual BACnet Devices hvor gateway - enheden simulerer at der findes en eller flere virtuelle BACnet - enheder. Gateway en svarer med flere device objekter (ID s) som hver især repræsenterer en fieldniveau - enhed med en anden protokol. Eksempel: På et IBI netværk sidder der 20 IBI enheder som kommunikerer internt med LON protokol. Med en Virtual Device Gateway vil gateway - enheden indeholde 20 virtuelle Device Side 5 af 7

6 - objekter som hver især repræsenterer en IBI - enhed på det underliggende net. Alle 20 enheder har altså samme fysiske adresse nemlig gatewayens adresse. Derudover har hver af de virtuelle enheder, device - objekter og properties som en hvilken som helst anden BACnet - enhed. Fra BACnet IP backbone ses altså kun en fysisk enhed (med IP adresse) men denne indeholder 20 virtuelle Device - objekter som derved sidder tilsluttet IP nettet uden routing. Gateway - funktionen skal automatisk reflektere ændringer i det bagvedliggende netværk. Dette har b.la. den fordel, at udskiftning af enheder på fieldniveau ikke medfører ændringer af BACnet objekterne. 4 Krav til BACnet objekter I det følgende beskrives krav til BACnet objekter - og properties. Generelt skal alle analoge indgange oprettes som analoge indgangsobjekter, analoge udgange som analoge udgangsobjekter, digitale indgange som digitale indgangsobjekter osv. I forbindelse med AI objekter aflæses målte værdier på Present_Value propertien. Der stilles krav til at Unit propertien er udfyldt korrekt og svarer til enheden for den målte værdi. Derudover kræves det, at Description propertien er udfyldt på alle objekter. Forcering af Analog_Input_Objects foretages vha. Out_Of_Service propertien som BACnet standarden foreskriver. Forcering af Output_Objects fortages ved at skrive værdien i Priority_Array med prioritet 8. Hardwarealarmer på følere o.l. skal oprettes vha. Reliability - propertien. Setpunkter, setpunktsgrænser og kurvepunkter skal oprettes som Analog_Value_Objects. Forcering af Output_Objects fortages ved at skrive værdien i Priority_Array med prioritet 8. Det foretrækkes desuden at der anvendes Multi_State_Value objekter i forbindelse med driftvælgere (omskiftere). For programmerbare controllere og gateways er det et krav, at driftvælgere konfigureres som Multi_State_Value - objekter samtidig med, at State_Text_Array - propertien er skrivbar. For fastprogrammerede controllere med eller uden faste tekster skal de forskellige States oplyses (udfyldes i skema). For programmerbare controllere skal State_Text_Array være udfyldt og tekster godkendt af DTU s driftorganisation. For kritiske anlæg skal High -og Low_Limit properties anvendes til henholdsvis høj -og lav alarm i henhold til BACnet standarden. Side 6 af 7

7 Relaterede dokumenter: Nedenstående er oplistet relaterede dokumenter Se standardoversigten Versionshistorik: Version Dette er 1. version Version Navnet på dokumentet ændret fra beskrivelse til vejledning Version Præciseringer i afsnittet Krav til Gateway enheder Kvalitetssikring: Version Dato Godkendt Ansvarlig TOPL MSKLA Side 7 af 7