Stavanger eiendom. Sist lagret: 16. desember 2015 Side 1 av 12

Transkript

1 Side 1 av 12

2 Innholdsfortegnelse 1 Generelt Hensikt Håndtering av avvik fra anvisningen Krav til automatiseringsanlegg Orientering Tekniske krav til automasjonsgrensesnitt Tekniske og funksjonelle krav til automatiseringsanlegg Brukergrensesnitt og betjening Tilgangsnivå Skjermbilder Merking Lisens Backup og sikkerhet Historikk og trendlogger Alarmer Tidsstyring Testing og idriftsettelse Ferdigbefaring Side 2 av 12

3 1 Generelt For effektiv prosjektering, bygging, drift og vedlikehold av bygningsmassen til Stavanger kommune, er det utarbeidet en rekke prosjekteringsanvisninger. Denne anvisningen tar for seg retningslinjer for leveranse av lokale automatiseringsanlegg som, via dedikerte leverandørservere, skal kobles opp mot overordnet betjeningsportal i Stavanger kommunes driftssentral. Eventuelle avvik fra disse retningslinjer, skal skriftlig godkjennes av byggherre på forhånd. Prosjekteringsanvisninger for Stavanger kommune, er inndelt etter fag tilsvarende NS Oversikt over gjeldende prosjekteringsanvisninger: Prosjekteringsanvisning 1, Prosjekteringsanvisning 2, Prosjekteringsanvisning 3, Prosjekteringsanvisning 4, Prosjekteringsanvisning 5, Prosjekteringsanvisning 5C, Prosjekteringsanvisning 6, Prosjekteringsanvisning 7, Generelle bestemmelser Bygning (Ikke utarbeidet) VVS-tekniske anlegg Elektrotekniske anlegg Teletekniske anlegg Byggautomatisering Andre installasjoner Drift og vedlikehold (Ikke utarbeidet) Det forutsettes at alle som utfører planleggings- og prosjekteringsoppgaver for Stavanger kommune skal gjøre seg kjent med gjeldende anvisninger for det aktuelle prosjekt. Byggeledelse og entreprenører skal i oppstartsmøte gjøres kjent med forutsetningene som er gjort ut fra prosjekteringsanvisningene og forholdet til behandling av eventuelle avvik som beskrevet i pkt Prosjekteringsanvisning 1 gjelder for alle fag. I Vedlegg Bygningsspesifikke krav er det listet opp spesifikke krav og forutsetninger for ulike bygningsgrupper, beskrevet i henhold til NS 3451 som skal ivaretas. Side 3 av 12

4 2 Hensikt Hensikten med anvisningene er å sikre at riktige systemløsninger blir levert i Stavanger kommune sine prosjekter, samt at overgang fra byggefase til driftsfase skal gå så sømløst som mulig. Det vil medføre at tekniske anlegg i eksisterende og fremtidig bygningsmasse som skal tilkobles kommunens driftsportal, blir av samme minimumskvalitet og har standardiserte systemløsninger. Formålet er å sikre god integrasjon mellom byggherrens tekniske systemer på de ulike eiendommene og gi god ressursutnyttelse i etablert driftssentral gjennom en sentralstyring og overvåking av lokale bygg automasjons/sd-anlegg. Anvisningene vedlegges alle tilbudsforespørsler initiert av Stavanger kommune som et krav til funksjon og valg av tekniske løsninger. Anvisningene vedlikeholdes og oppdateres av Stavanger kommune, Stavanger eiendom ved Drift- og Energiseksjonen. 2.1 Håndtering av avvik fra anvisningen Prosjekterende og utførende (rådgiver/entreprenører/leverandører) aktører skal følge denne anvisningen, men de prosjekterende står fritt i å foreslå alternative utførelser. Alternative utførelser skal avklares med prosjektleder og endelig utførelse skal dokumenteres skriftlig med godkjenning fra prosjektleder. Ved et hvert prosjekt skal prosjekterende, entreprenør og leverandør angi eventuelle avvik i forhold til anvisningen. Side 4 av 12

5 3 Krav til automatiseringsanlegg 3.1 Orientering For å oppnå effektiv og rasjonell drift av de kommunale eiendommene i Stavanger, skal de lokale automatiseringsanleggene tilknyttes et felles toppsystem for byggautomasjon. Det stilles krav til at leverandør av de lokale automatiseringsanleggene skal kunne aksessere sine undersentraler fra Internett, via Stavanger kommunes valgte sikre pålogging. Stavanger kommune vil gi de nødvendige rettigheter og tilganger. Dette innebærer at programmering, oppdatering av software eller lignende i undersentralene skal kunne foretas av leverandør, uten å måtte fysisk være til stede på det aktuelle tekniske anlegget. Opplasting av eventuelle oppdateringspakker (filtyper etc.) må avklares med byggherre. Det skal være et webgrensesnitt til det lokale automatiseringsanlegget. 3.2 Tekniske krav til automasjonsgrensesnitt Krav til Bacnet-standard som kommunikasjonsgrensesnitt Alle driftsdata skal oversendes kontinuerlig til toppsystemet vi et enhetlig kommunikasjonsgrensesnitt. Grensesnittet mellom toppsystemet og det lokale automatiseringsanlegget (undersentraler, buss-systemer etc.) skal være basert på etablerte teknologistandarder og ikke være avhengig av leverandørspesifikke produkter. Kravet gjelder alle kontrollere, pls er og undersentraler uavhengig av system de skal styre. Følgende krav og standarder legges til grunn: Bacnet standard EN-ISO Undersentraler, kontrollere, pls er skal ha følgende BacnetDevice Profile: B-BC Undersentraler skal være testet og vist konformitet hos BACnet Conformance test (test standard DIN EN ISO , conformance testing) Det skal vedlegges sertifikat som viser at standarden utstyret er godkjent på og hvilke Bacnet-objekter som sertifikatet gjelder. Bacnet-objekter for tidsstyring, trendkurver, alarmbehandling etc. skal kunne visualiseres og betjenes via standard funksjoner i toppsystemet Utstyret skal leveres med, Protocol Implementation Statement (PICS) Proprietære kommunikasjonsprotokoller og konvertere mellom toppsystemet og automasjonsanleggene for å oppnå Bacnet kravet godtas ikke. Leverandører som ikke har den nødvendige sertifiseringen på sentralene vil bli vurdert som vesentlig avvik fra kravspesifikasjonen og vil medføre avvisning. Side 5 av 12

6 Systemet skal i størst mulig grad benytte funksjonaliteten til Bacnet-objektene. Eksempel: For en temperaturmåling skal måleverdi og tilhørende grenseverdier for alarm tilordnes respektive parametre i et felles Bacnet-objekt, Analog Input». Tidsstyring Betjening av tidkatalogene skal være enhetlig for alle systemer som er knyttet opp mot toppsystemet. Tidkatalogene skal derfor kunne visualiseres og betjenes fra toppsystemet via Bacnet-objektene «Calendar» og «Schedule». Tidkatalogene skal lagres lokalt og fungere uavhengig av status på kommunikasjon mot toppsystemet. Dokumentasjon av kommunikasjonsgrensesnitt Automatikkentreprenøren skal leveres komplett dokumentasjon av kommunikasjonsgrensesnittet mot toppsystemet. Dokumentasjonen skal foreligge elektronisk på lesbart format og omfatte all nødvendig informasjon for integrasjon og konfigurasjon i toppsystemet. (komponent-id) i henhold til merkesystemet*, komplett kommunikasjonsadresse, verdiområde, statustekster, etc.). For Bacnet skal EDE-formatet benyttes. (veiledning og eksempelfiler kan lastes ned fra Automatikkleverandøren skal bistå ved test av toppsystemets funksjoner mot lokal automatikk. *Byggherren vil tildele automatikkleverandøren nødvendige ID og portnummer for undersentraler og Bacnetobjekter for den aktuelle eiendommen systemet skal installeres på. Lokal kommunikasjon Lokal kommunikasjonsløsning skal være basert på TCP/IP. Systemets oppbygning skal være basert på Bacnet hvor all integrasjon skal ivaretas via Bacnet, også mot feltbus baserte komponenter (LON/Dali/KNX/Modbus/M-Bus) Systemet skal kunne ha full to-veis kommunikasjon med andre systemer via Bacnet over IP. Følgende krav stilles til grensesnittet: Alle inn- og utganger skal være tilgjengelige over grensesnittet. Systemet skal kunne lese og behandle inn- og utgangssignaler fra andre systemer. Det skal kunne gis styresignaler til andre systemer og komponenter over grensesnittet. Systemet skal kunne motta styresignaler fra andre systemer. All tidsstyring skal baseres på Bacnet-objektene «Calendar» og «schedule». Grensesnitt mot Bacnet skal inngå i leveransen. Teknisk spesifikasjon av Bacnet grensesnittet skal være en del av dokumentasjonen. Side 6 av 12

7 Datateknisk infrastruktur Det administrative datanettverket leveres og vedlikeholdes av Stavanger kommune, ITavdelingen. Det vil bli gjort tilgjengelige nødvendige data kontakter (RJ45) på det aktuelle bygg for tilkobling av automatiseringsanlegget til kommunens administrative datanettverk. All intern kommunikasjon mellom installasjoner i det aktuelle automatiseringsanlegg inkl. eventuelle ekstra routere etc. skal ivaretas av den aktuelle automatikkleverandøren. Generelle krav Det forutsettes at de lokale automatiseringsanleggene fungerer autonomt, dvs. at kritiske funksjoner som regulering, sikkerhetsfunksjoner osv. skal ivaretas av de lokale automatiseringsanleggene ved en evt. kommunikasjonssvikt med driftssentralen. Dette gjelder også tids- og kalenderfunksjoner, samt automatisk justering av sommer- og vintertid. Dersom det er nødvendig med ytterligere maskinvare eller tilpasninger av annet utstyr for å oppnå beskrevet funksjon, skal dette spesifiseres og inkluderes. Dette gjelder både utstyr og programvare for tilknytning til toppsystemet og lokalt automatiseringsanlegg. Leverandør må også som en del av sin prosjekteringsytelse selv innhente opplysninger om systemer, anlegg og merkestruktur for installasjoner som skal tilknyttes automatiseringsanlegget. Det innebærer at det påhviler leverandør å kontrollere lokale automatiseringsanlegg for å sikre at nødvendig maskinvare/programvare er installert for å tilfredsstille prosjekterings-anvisning 5C. Det er et krav at automatiseringsanlegg som blir installert skal kunne ivareta utvidelser ved tilknytning av flere bygg / anlegg Ved overlevering av anlegg skal siste versjon av programvare være installert. Dersom det ved tilknytning til nye eller eksisterende bygg blir nødvendig med ytterligere lisensiering, skal dette inngå i oppgraderingskostnadene. All funksjonalitet skal prosjekteres i henhold til beskrivelser i denne anvisning med nødvendig kapasitet (funksjons- og kapasitetstabeller) oppfyllet. Side 7 av 12

8 4 Tekniske og funksjonelle krav til automatiseringsanlegg 4.1 Brukergrensesnitt og betjening Dette kapitlet beskriver noen viktige funksjoner i forhold til brukergrensesnitt, men endelige design av brukergrensesnittet avklares med byggherre. 4.2 Tilgangsnivå Tilgang for betjening av anleggene, skal skje ved innlogging på Stavanger kommunes toppsystem. Systemet skal kunne skille mellom ulike brukere. Hver bruker skal ha eget passord og spesifikt tilgangsområde. Brukere med administratorrettigheter eller høyeste brukernivå (typisk operatører i driftssentralen), skal ved innlogging få direkte adgang til alle tilknyttede installasjoner uten å måtte spesifikt logge seg på de enkelte anlegg/undersentral. Underbrukere (typisk driftsansvarlige på de enkelte bygg), skal ved innlogging i toppsystemet kun få lesetilgang til sitt anlegg. For alle disse nivåene skal det være mulig å definere brukere kun med lesetilgang. Systemet skal kunne utarbeide rapport over alle brukere som har tilgang til systemet og deres rettighetsnivå. Dette gjelder også informasjon om hvem som er innlogget og har vært innlogget. Systemet skal også vise adgangsnivå for innlogget bruker. Den som har administratorrettigheter hos Stavanger kommune, skal kunne foreta tildeling som beskrevet over. 4.3 Skjermbilder Skjermbildene skal etableres på toppsystemet av toppsystemleverandør etter underlag gitt av automatikkleverandøren. Som beskrevet i kapittel 3.2 skal automatikkleverandøren levere et elektronisk underlag og flytskjema som viser oppbygning. Automatikkleverandøren skal bistå ved test av toppsystemets funksjoner mot lokal automatikk. Systembildene skal ikke over instrumenteres, noe som kan gjøre bildene uoversiktlig. Følgende skal ivaretas: Alle IO og alle fiktive punkter (settpunkt, alarmgrenser etc.) skal kunne vises i skjermbildene. Hvert system skal ha et eget skjermbilde. Dersom to eller flere system henger sammen, skal disse linkes sammen i skjermbildet. Dette gjelder også hvis systemet er så omfattende at det er nødvendig eller hensiktsmessig å dele det opp i flere skjermbilder. Side 8 av 12

9 Alle skjermbilder skal være basert på systemskjemaer som samsvarer med anleggene som blir levert. Systemskjemaene vil som oftest være en del av anbudsgrunnlaget, men automatikkleverandøren er ansvarlig for kvalitetssikring av skjemaene og innhenting av underlag for utforming av skjermbildene. Rene tabellariske opplistinger skal unngås, såfremt dette ikke er spesifikt beskrevet. Komponenter og alle IO i systemer og sonekontroller, skal kunne settes i manuell overstyring. Overstyringer skal markeres i bildet og indikeres i alarmliste og hendelseslogg slik at dette enkelt oppdages av operatør. Det skal være mulig å få opp gjeldende funksjonsbeskrivelser fra skjermbildene. Det skal være enkelt å skrive ut skjermbilder og funksjonsbeskrivelser fra portalen. Bruker skal løpende kunne legge inn nye eller endrede funksjonsbeskrivelser. Skjermbildene skal standardiseres slik at gjenkjennelsesfaktoren mellom de ulike leverandørspesifikke SD-anlegg skal være stor. Det henvises her til Vedlegg 5C-01 Mal for skjermbilder ved Stavanger Kommune som er utarbeidet og vedlikeholdes av Stavanger kommune, Stavanger eiendom, Drift- og energiseksjonen. Avvikende og nye utforminger av bilder skal godkjennes før de tas i bruk. I skjermbildene skal det angis hvilke feil som er aktive. Symboler skal skifte farge ved spesielle hendelser. Drift og feil på komponenter skal vises med fargesymboler på selve komponenten. Fargebruk i bildene skal være i henhold til Mal for skjermbilder ved Stavanger kommune. 4.4 Merking Merking og navngiving i skjermbildene skal være sammenfallende med merking og navngiving ute i anlegget og i all annen dokumentasjon som beskriver byggherrens merkestruktur/merkesystem. Systemet må kunne programmeres med tilstrekkelig antall karakterer i flg. prosjektets merkestruktur. Eventuelle begrensninger skal oppgis av leverandør. I alle nye prosjekter skal Stavanger kommunes merkeanvisning benyttes. Se anvisning for merkesystem i Prosjekteringsanvisning 1, Generelle bestemmelser. 4.5 Lisens Systemet som blir levert skal tillate minimum 5 samtidige brukere. Dette skal ikke legge noen begrensning på antall brukere med forskjellig tilgangsnivå, men kun begrense samtidighet. Mulighet for utvidelse av antall samtidige brukere skal oppgis, og eventuell kostnadskonsekvens skal spesifiseres. Eventuelle tilleggs lisenser for Web-grensesnitt, trendlogginger, historiske logginger, etc, skal alltid være inkludert og aktivert i leveransene. All nødvendig programvare for å ivareta grensesnitt mellom det enkelte automatiseringsanlegg og toppsystemet skal være inkludert i leveransene. Programvaren skal settes opp med fullverdig terminalserver funksjonalitet og programmeringsrettigheter. Side 9 av 12

10 Alle lisenser skal kunne knyttes til programvaren direkte. Fysiske programvarelåser godtas ikke. 4.6 Backup og sikkerhet Leverandør er ansvarlig for at de leverte automatiseringsanleggene (programvare og database) kan inngå i byggherrens backupsystem. Leverandør spesifiserer hva byggherre skal ta backup av og hvordan backup tas av systemene. 4.7 Historikk og trendlogger Programmet skal kunne registrere (i database) alle historiske verdier /statuser for alle I/O. Brukere skal enkelt og oversiktlig kunne angi hvilke verdier som skal logges og hva som skal inngå i korttidslager eller langtidslager. Det skal skilles mellom korttidslager og langtidslager. Oppløsning og loggefrekvens skal kunne bestemmes av bruker/driftsoperatøren. Oppløsningen skal kunne settes fra maksimalt 5 sekunder og oppover til minimum 7 døgn. Logging av flere ulike parametere skal kunne settes inn i samme loggesekvens med felles akser. Totalt skal systemet kunne håndtere minimum 50 loggesekvenser. Eksport av historiske trendlogger til csv-filer skal være mulig. Både analoge og digitale signaler skal kunne logges. Minimum 10 punkter skal kunne settes opp pr. logg med forskjellig Y-akse hvor fargekoder benyttes for å skille kurvene fra hverandre. Alle målerverdier, settpunkt og pådrag skal være klargjort for logging. Avleste verdier for pådrag skal være reelle tilbakemeldingssignaler. Det aksepteres ikke at utgangssignaler benyttes som indikasjon for pådrag. Det skal være mulig å logge med rullerende lagring hvor de eldste dataene slettes når ny blir lagret. Den faste perioden skal kunne være et døgn, uke, måned eller ett år. Systemet skal ha en kontinuerlig lagring av alle hendelser, alarmer, systemmeldinger, ut og innlogginger i et tilstrekkelig stort rullerende lager. Begrensninger i dette lageret skal oppgis. Det skal være mulig å lagre alarmstatistikk og hendelsesstatistikk for direkte import i csv-fil, uten sideskift. Det skal være mulig for operatør å finne ut hvor mange ganger et punkt har endret status og når. 4.8 Alarmer Alarm kan være feilmeldinger, statusendring, grenseverdioverskridelse etc. Alle målerverdier med reguleringsfunksjon skal avgi alarm ved justerbar under- eller overskridelse av grenseverdi. Alarmmeldinger skal alltid være i klartekst. Undertrykkelse av meldinger og alarmer skal være mulig. Utskrift/logging av punkter som endrer status som følge av f. eks. en alarm skal kunne sperres (filtreres). Dette for å begrense Side 10 av 12

11 utskriftsmengden ved f. eks. normal stans av aggregat. Da skal luftvakter, filtervakter, temperaturalarmer, etc. undertrykkes i systemet. For analoge verdier skal der være mulig å definere minst 4 alarmnivåer. Alle alarmer fra systemet skal kunne eksporteres via standardiserte protokoller som e-post, TXT, XML-filer eller lignende. Lisens for dette skal være inkludert i programvaren. Alarmgrenser og prioriteter skal fritt kunne endres av bruker. 4.9 Tidsstyring Endringer i tidsstyringen skal kunne foretas fra Toppsystemet via Bacnet. Tidsstyringen skal lagres i lokalt automatiseringsanlegg, slik at siste definerte tidsstyring fortsetter å gjelde for anlegget ved kommunikasjonsbortfall mellom lokalt automatiseringsanlegg og toppsystemet Testing og idriftsettelse Kommunikasjon mellom toppsystemet og automatiseringsanleggene skal testes og dokumenteres. Dette gjelder også alle moduler i portalen, som alarmhåndtering, logging, eksporter, rapportering osv. Fullverdig test av hele kommunikasjonskjeden skal utføres. Dette kan gjøres ved eksempelvis å utløse alarmer lokalt for å se respons i toppsystemet (frostsikring e.l.). Testresultatene må dokumenteres. Ved overlevering av automatiseringsanlegget skal, i tillegg til dokumentasjonskrav gitt i Prosjekteringsanvisning 1 Generelle bestemmelser, følgende minimumsdokumentasjon overleveres: Testresultater (plassering, merking, funksjonstester, alarmtester, etc.). Brukerveiledninger (manualer på norsk, elektronisk). Systemtegninger som viser grensesnittet toppsystem/lokale automatiseringsanlegg. (Oppdateres ved hver ny tilkobling). Leverandørens egne utsjekkingslister skal dokumentere korrekt montasje, tilkobling og utført funksjonstest for alle komponenter/tilkoblinger. Det skal som vedlegg til anbud leveres eksempel på sjekkliste. Denne skal som et minimum inneholde kvitteringsrubrikker for hver komponent/tilkobling med separate daterte bekreftelser på korrekt montasje, merking, kobling og programmering/funksjon. Korrekt programmering og funksjon skal i tillegg dokumenteres med beskrivende tekst (som gjøres tilgjengelig via direkte linker i systembildene) for de enkelte system. Alle settpunkt innstillinger for driftsstyring skal dokumenteres, godkjennes og overleveres før ferdigbefaring. Side 11 av 12

12 Ferdigbefaring Ferdigmelding leverandør/entreprenør Leverandøren skal oversende skriftlig melding til byggherren med varsel om når kontraktsarbeider vil bli ferdigstilt og være klar for prøvedrift. Ferdigmeldingen skal sendes med minst 14 dagers frist. Se ellers Prosjekteringsanvisning 1-generell del Side 12 av 12