Prosjekteringsanvisning. Overordnet SD anlegg (OSD)

Transkript

1 NORD-TRØNDELAG FYLKESKOMMUNE EIENDOM 1 Prosjekteringsanvisning. Overordnet SD-anlegg OSD Fylke dato: Arkiv Ver264 FEF dato: Side 1 av Prosjekteringsanvisning Overordnet SD anlegg (OSD) Prosjektnr.: Prosjekt: Dato:

2 Prosjekteringsanvisninger for fylkeskommunen er inndelt etter fag tilsvarende NS FORMÅL Prosjekteringsanvisningene skal gi generelle retningslinjer for prosjektering og utførelse Det forutsettes at alle som utfører planleggings- og prosjekteringsoppgaver for FK gjør seg kjent med gjeldende anvisninger for det aktuelle prosjekt. Anvisning Generelle bestemmelser gjelder for alle fag. Anvisningene er utformet som sjekklister de prosjekterende bekrefter med signatur og dato ved de aktuelle punktene at de er utført i de enkelte fasene, etter hver fase skal de prosjekterende levere kopi av utsjekket prosjekteringsanvisning til byggherrens prosjektleder, Avvik fra prosjekteringsanvisningene i et byggeprosjekt De prosjekterende står fritt i å foreslå alternative utførelser. Alternative utførelser skal avklares med oppdragsgiver og endelig utførelse skal dokumenteres skriftlig med godkjenning fra oppdragsgiver. Prosjekteringsanvisninger for Nord-Trøndelag fylkeskommune er inndelt etter fag tilsvarende NS INNHOLDSFORTEGNELSE: INNLEDNING ORIENTERING OG GENERELLE KRAV Orientering Eksisterende bygningsmasse Datateknisk infrastruktur Generelle krav TEKNISKE OG FUNKSJONELLE KRAV TIL OSD/AUTOMATISERINGSANLEGG Brukergrensesnitt og betjening Tilgangsnivå Skjermbilder Merking Grensesnitt Lisens Maskinvare, server Backup og sikkerhet Rapportering Historikk og trendlogger Alarmer Lagring av forbrukstall (EOS) og klimastatistikk Driftstidsregistrering Tidsstyring Kommunikasjon mellom lokal SD og overordet SD-anlegg (OSD) Testing og ibruktakelse SJEKKLISTE FOR ANVISNING OSD REFERANSER VEDLEGG Side 2 av 12

3 1 INNLEDNING Hensikten med anvisningen er å forsikre at riktige systemløsninger blir levert i NTFK sine prosjekter. Det vil medføre at tekniske anlegg i eksisterende og fremtidig bygningsmasse som skal tilkobles byggherrens toppsystem, blir av samme minimumskvalitet og har standardiserte systemløsninger. Dette vil sikre god integrasjon mellom byggherrens tekniske systemer på de ulike eiendommene. Anvisningene vedlegges i alle tilbudsforespørsler initiert av NTFK som et minimumskrav til funksjon og valg av tekniske løsninger. Anvisningene vedlikeholdes og oppdateres av NTFK. 2 ORIENTERING OG GENERELLE KRAV 2.1 Orientering NTFK sine eiendommer er spredt. For å oppnå effektiv og enklere drift av disse eiendommene, skal automatiseringsanleggene kunne tilknyttes en felles driftssentral med et OSD. NTFK ønsker en større frihet for drifting av disse anleggene. Dette gjelder også støttedrift mellom eiendommene. Anvisningen stiller krav til prosjektering, idrftsettelse og opplæring av overordnet automatiseringsanlegg (OSD) i byggherrens eiendomsmasse. De ulike delene av anvisningen må sees i sammenheng for å få et komplett bilde av leveransen. Det påligger leverandør å gjøre seg kjent med øvrige faganvisinger fra NTFK. Øvrige faganvisninger kan innhentes hos NTFK (se ). Alle krav i anvisningene, med underkapitler og vedlegg, er å betrakte som minimum. Dette gjelder blant annet anleggsinformasjon, funksjonskrav og ytelseskrav. Det stilles krav til at leverandør av de lokale automatiseringsanleggene 1 (se anvisning for lokale automatiseringsanlegg) skal kunne aksessere sine undersentraler fra Internet, via NTFK sin valgte sikre pålogging (VPN). Dvs. at programmering, oppdatering av software eller lignende i undersentralen skal kunne foretas av leverandør uten å måtte fysisk være til stede på eiendommen og det tekniske anlegg. Opplasting av eventuelle oppdateringspakker (filtyper etc.) må avklares med byggherre OSD skal kunne betjenes fra Internet via valgte løsninger beskrevet i kapittel Eksisterende bygningsmasse Eksisterende eiendommer i NTFK skal/er OSD tilknyttes de lokale automatiseringsanleggene. Dette skal foregå via et eget dedikert virtuelt tekniske nett med åpne standarder som er avklart med NTFK. Alle bygg vil i tillegg ha et lokalt SD-anlegg, dvs skjermtilgang lokalt direkte mot undersentraler eller via intranet/internet til overordnet SD-anlegg ( OSD) Eksisterende bygningsmasse benytter i dag ulike løsninger fra flere leverandører, som pr. mars 2009 er Siemens, Johnson Controls, TAC og Honeywell. Følgende tabell viser status for eksisterende eiendomsmasse. Tabell 1 Status eksisterende eiendomsmasse Eiendsnr Skole Fabrikat Installert år Areal, brutto Tilknyttet OSD 22 Meråker videregående skole Siemens Ja 23 Ole Vig videregående skole, Stjørdal Siemens, Honeywell 2000/ Ja 24 Levanger videregående skole Johnson Control Ja 26 Verdal videregående skole Johnson Control Under etabl. 29 Mære Landbruksskole Siemens Ja 28 Inderøy videregående skole Johnson Control Under etabl. 27 Leksvik videregående skole Johnson Control Ja 30 Steinkjer videregående skole TAC (NTE) Nei 31 Steinkjer vgs, avd. Egge Siemens Nei 32 Olav Duun vgs, Namsos Siemens Ja 34 Grong vgs Satchwell / TAC ( NTE) Nei 35 Ytre Namdal vgs, Rørvik TAC (NTE) Nei 36 Fylkets hus, Steinkjer Siemens Ja 1 Lokalt automatiseringsanlegg inkluderer lokalt toppsystem, undersentraler, tavler og periferiutstyr. Side 3 av 12

4 2.3 Datateknisk infrastruktur Byggherren stiller krav til tilgangsnivå til OSD fra utsiden av brannmur. Figuren under viser forenklet hvordan kommunikasjonen med OSD skal foregå. Figur 1 Forenklet figur av hvordan tilgang til OSD skal foregå via brannmur NTFK har i dag egen fiberforbindelse med 50 Mbit/s hastighet til alle eiendommene de har ansvaret for i hele fylket. NTFK har delt opp sine nettverk i flere sub-nett og skal i forbindelse med overordnet toppsystem, opprette et virtuelt teknisk nett. Her skal kommunikasjonen mellom toppsystem og de ulike lokale anleggene foregå. Det tekniske nettet er et virtuelt LAN med egen virtuelt IP-subnett for skolene, felles for alle. Trafikken mellom skolene går inn til NTFK og så ut til skolene. NTFK har eget serverrom hvor servere for toppsystem skal være plassert. Tilgang til toppsystemet utenfor det tekniske nettverket skal pr. i dag foregå via VPN tunnel. Fra admin-nett får man tilgang til tekniske nett via router 2. Når brukeren er på innsiden av teknisk nettverk gjøres normal pålogging til OSD via desktop-grensesnitt eller web-grensesnitt via lokal IP. Alle undersentraler skal være IP-adresserte og kobles til ethernet. Side 4 av 12

5 Figur 2 viser en forenklet topologi av admin-nivå, automasjonsnivå og feltnivå 2.4 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 OSD. 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 til OSD og lokalt automatiseringsanlegg. Leverandør må også som en del av sin prosjekteringsytelse selv innhente opplysninger om systemer, anlegg og merkestruktur som skal tilknyttes OSD i sin leveranse. Dvs. at det påhviler leverandør å kontrollere lokale automatiseringsanlegg for å forsikre at nødvendig maskinvare/programvare er installert for å tilfredsstille denne anvisningen. Det er et krav at installert OSD ikke behøver programvareoppgraderinger for å kunne tilknytte nye eller eksisterende bygg. 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å oppgraderingskostnadene. Det er et krav at det ikke skal være praktiske begrensninger i OSD forhold til fremtidig tilknytning til systemet. All funksjonalitet skal prosjekteres slik at beskrevet funksjon (denne anvisning, beskrivelse og funksjonsbeskrivelser) og kapasitet (funksjons- og kapasitetstabeller) oppfylles. OSD skal ha et grensesnitt som tillatter styring på samme nivå som på de lokale automatiseringsanleggene. Det vil si at funksjonaliteten på OSD skal være minimum på samme nivå som på de eksisterende lokale automatiseringsanleggene på de ulike eiendommene. For nye anlegg henvises til NTFK anvisning for automatiseringsanlegg. All kommunikasjon mellom bruker og system skal være på norsk. Ved strømbortfall, manglede kommunikasjon og lignende skal følgealarmer undertrykkes, dvs. at ved logiske hendelser skal følgealarmer undertrykkes for å redusere alarmtrafikken. Side 5 av 12

6 3 TEKNISKE OG FUNKSJONELLE KRAV TIL OSD/AUTOMATISERINGSANLEGG 3.1 Brukergrensesnitt og betjening Brukergrensesnittet i OSD skal være standardisert så langt det lar seg gjøre, også mellom evt. ulike leverandører for de forskjellige OSD. Dette kapitlet beskriver noen viktige funksjoner i forhold til brukergrensesnitt, men endelige design av brukergrensesnittet avklares med byggherre. Universiell utforming og god brukervennlighet skal tilstrebes. Spesielt gjelder dette tilknytning til skjermbilder, betjening, farger etc. Funksjonaliteten på OSD skal være identisk med de lokale automatiseringsanleggene ved tilknytning til eksisterende automatiseringsanlegg. Innstillinger som settpunkt, driftstider etc. skal skje ved enkle betjeningsordrer direkte fra skjermbildet. Betjening skal skje ved enkle og logiske betjeningsordrer, og tekster skal ha direkte sammenheng med valget, slik at det er enkelt å forstå. Programmeringstermer skal ikke brukes. Eksempelvis skal teksten Innstilling av driftstider eller lignende benyttes i stedet for tekst som Editering av punktparametre. Dette innebærer at alle betjeningskommandoer, innstillinger etc. for systemene som vises i grensesnittet skal være atskilt fra programmeringsordre for programvare. 3.2 Tilgangsnivå Systemet skal kunne skille mellom ulike brukere. Hver bruker skal ha eget passord og spesifikt område brukeren har tilgang til. Tilgangen til OSD skal som minimum kunne styres etter følgende ulike kriterier: Fagkategori Anleggskategori I/O nivå (skal kunne utelukke/inkludere enkeltpunkter) 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. 3.3 Skjermbilder Inngangsbildet til alle OSD skal inneholde et felles startbilde som viser en oversikt over samtlige bygg. De bygg som er tilkoblet det aktuelle OSD skal aktiv link til lokalt automatiseringsanlegg. De bygg som ikke er tilkoblet det aktuelle OSD skal vise en henvisning til hvilken OSD (leverandørspesifikt) de ligger på. For enkelte brukere skal det være mulig å koble disse direkte ned til riktig anlegg, dvs. ved hjelpe av brukerstyring. Ved innlogging vil disse brukerne (drift) få direkte tilgang til sine anlegg. Det skal være mulig å klikke seg tilbake i hierarkiet for en mer overordnet oversikt. Skjermbilder skal minimum inneholde følgende informasjon: Komponentenes ID-kode Setpunkt/fyringskurver/kompenseringskurver (avtekkskompensert, utekompensert etc.) Alarmgrenser (høy, høy høy, lav, lav lav) Visualisering av alarmer Avlesning av målte verdier Visualisering av overstyringer Visualisering av status (start, stopp, halv, hel etc.) Systemets ID-kode, navn og hva det betjener Systemets eller komponentens fysisk plassering/romnummer i klartekst Tavlevenderenes posisjon Systembildene skal ikke overinstrumenteres, noe som kan gjøre bildene uoversiktlig. Alle IO og alle fiktive punkter (settpunkt, alarmgrenser etc.) skal vises i skjermbildene. Hvert system skal ha et eget skjermbilde. Avvik fra dette skal avklares med byggherre. Dersom to eller flere system henger sammen skal disse linkes sammen i skjermbildet. Alle skjermbilder skal ha systemskisse basert på systemskjema. Rene tabellariske opplistinger skal unngås. Side 6 av 12

7 Komponenter og alle IO i systemer og sonekontroll skal kunne settes i manuell overstyring. Overstyringer skal markeres i bildet slik at dette enkelt oppdages av operatør. Det skal være mulig å få opp gjeldende funksjonsbeskrivelsene fra skjermbildene. Det skal være enkelt å skrive ut skjermbilder og funksjonsbeskrivelser fra OSD. Utskrift av skjermbilder skal inneholde dato og tid for utskriften. Bruker skal løpende kunne legge inn nye eller endrede funksjonsbeskrivelser. Skjermbildene skal standardiseres, gjenkjennelsesfaktoren mellom de ulike leverandørspesifikke OSD skal være stor. Dette innebærer at leverandør må sørge for at skjermbilder/prosessbilder blir mest mulig like mellom de ulike OSD. I skjermbildene skal det være mulig å enkelt linke til en ekstern adresse som webcam, video eller bilder. Skjermbildene skal ha standard symboler og farger. 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. Her listes de viktigste: Grønt = Drift Hvit = Av Rødt = Feil Gult = Service/håndstyrt Bakgrunnsfarge på skjermbildene skal være hvit. Dette er viktig for lesbarheten. Følgende generelle krav gjelder til skjermbilder. Alle skjermbilder skal utformes tilsvarende, for eksempel med lik fargebruk på tur/retur og tilluft/avkast, symboler på komponenter, alarmer osv. All symbolbruk skal være etter en standard Ingen firmareklame, navn skal i skjermbilder. I topp skal etableres system ID, navn og hva det betjener. I topp skal etableres fliker/faner for tilhørende system Alle farger skal standardiseres etter mal. All systemstyring, ur skal angis i bunn mitt på bilde Alle kompenseringer, kurver skal angis i bunn til venstre Til/tur skal være nederst, mens retur/fra skal være øverst Til rom, hva det betjener skal være til høyre i bildet. Ved mye tekst i bilde kan etableres et eget ikon for å slå av og på supplerende tekst i bildet Nederst til høyre skal eget ikon for funksjonsbeskrivelse, bilder, videosnutter. Vedrørende automatiseringsnivå så henvises til egen anvisning, automatisering Sonekontroll Det skal lages et oversiktsbilde hvor man kan klikke seg inn på ønsket etasje. Det skal lages ett oversiktbilde for hver etasje. Hver sone i etasjen skal ha visning av målt temperatur, pådrag lys og evt. persondetektering. Dersom etasjen er for stor eller det er for mange soner på etasjen, skal etasjen deles opp i logiske deler med link mellom delene. Underlagstegninger kan fremskaffes hos byggherre. Ved å klikke på den enkelte sone skal alle tilgjengelige parametre vises i egen dialogboks/vindu, som pådrag styringer (varm/kjøling), settpunkt etc., for endring av settpunkt og overstyringer. Alle skjermbildene for visning av sonekontrollen skal ha visning av aktuelt romnummer. Mulighetene for visning av målte verdier og muligheten for endring av settpunkt og overstyringer i OSD skal være lik en evtl. eksisterende løsning av lokalt SD-anlegg. Alle skjermbilder skal oversendes byggherren for gjennomsyn før implementering. Side 7 av 12

8 3.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. Serveren må kunne programmeres med tilstrekkelig antall karakterer i flg. prosjektets merkestruktur. Evt. begrensninger skal oppgis av leverandør. I alle nye prosjekter skal NTFK merkeanvisning benyttes, se anvisning for merkesystem. 3.5 Grensesnitt Tilgang til toppsystemet forutsetter at klienten er tilknyttet lokalnettverket. Interne brukere har direkte tilgang til webgrensesnitt og/eller tilgang til desktop-grensenitt via terminaltilkobling mot terminalserver (SD-server). Eksterne brukere som skal ha tilgang SD-server kobler seg til lokalnettverket, beskrevet i kapittel 2.3. Det forutsettes at ingen installasjon av ekstra programvare på klienter som skal benyttes til SD-tilgang er nødvendig. Det forutsettes at disse klienter har preinstallert Windows Terminal Services med mulighet for Remote Desctop Connection eller annen terminalklient som er komptatibel med terminalserverene. 3.6 Lisens Alle lisenskostnader skal spesifiseres av leverandør. OSD skal minimum ha 20% reservekapasitet ved overtakelsestidspunktet. Begrensninger i punktlisens eller lignende skal oppgis til NTFK. Systemet skal tillate minimum 5 samtidige brukere. Dette skal ikke legge noen begensning på antall brukere med forskjellig tilgangsnivå, men kun begrense samtidighet. 3.7 Maskinvare, server Byggherre er ansvarlig for å levere nødvendig maskinvare og installere all programvare, utenom OSDprogramvare. Leverandør må spesifisere sine krav til maskinvaren og operativsystem. Serverne skal stå i serverrom til NTFK. Installasjon og konfigurering av toppsystem er leverandøren ansvarlig for, mens primærdrifting og backup blir ivaretatt av byggherre. OSD driftes av leverandør. 3.8 Backup og sikkerhet Byggherre er ansvarlig for full systembackup av servere i serverrom, også for OSD servere plassert i serverrom. Hver leverandør er ansvarlig for at OSD (programvare og database) kan inngå i byggherrens backupsystem. Leverandør spesifiserer hva byggherre skal ta backup av. NTFK sørger for at servere til OSD tilkobles egne UPS er, i tillegg til nødvendig programvare for automatisk nedkjøring. UPS skal ikke medtas av leverandør. OSD må kunne kjøres ned automatisk. Nødvendig programvare må medtas av leverandør og beskrives. 3.9 Rapportering Utskrifter av alle typer status (sanntid) som alarmer, effektgrenser, optimal start/stopp, oppsett etc. skal kunne foretas via OSD. Det skal kunne søkes etter fritt valgte karaktermønster (wild card søk i merkesystem), både midt i adresse og trunkering på slutten, samt midt i en adresse og trunkering samtidig. Søk skal kunne inneholde logiske parametre som <, >, >< og =. Bruker skal enkelt kunne generere rapporter som gir oversikt over alarmstatus, anleggsstatus, programpunkter etc. Rapportene skal kunne genereres ved tid (klokkeslett og dato, intervall) eller spesielle hendelser. Alle rapporter skal kunne eksporteres til PDF, RTF og csv. Tilgang til de ulike rapportene skal være brukerdefinert. All rapportuthenting av skal være oversiktlig og enkel. Alle rapporter og søk skal kunne utføres av en normal bruker. Følgende rapporter er å betrakte som minimum: - Standardrapporter (fastsatte vilkår) o Adresseliste o Alarmrapport med gruppering på: Utkvitterte alarmer Stående alarmer Side 8 av 12

9 o o o Alarmprioritet Tidsintervall og kombinasjon av valgene Oversikt over brukere med tilgangsnivå Oversikt over innloggingsstatistikk og hvilke endringer bruker har utført Energirapporter (dersom dette medtas i OSD) ET-kurver pr. måler/bygningsavsnitt/totalt Forbrukskurver pr. måler/bygningsavsnitt/totalt Effektbelastning Korrigert energirbruk - Spesialrapporter (vilkår velges av bruker) fritt søkbart i merkesystemet (trunkering) o Generelt globalt søk av alle statuser på alle punkter o Statusoversikt manuelle overstyringer o Endringsrapport (oversikt over endringer basert på valgt tidsrom) 3.10 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 parametre 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. 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 etc. 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 være mulig for operatør å finne ut hvor mange ganger et punkt har endret status og når Alarmer Alarm kan være feilmeldinger, statusendring, grenseverdioverskridelse etc. Stående alarmer og kvitterte alarmer skal angis forskjellig i systemet. Når og hvem som har kvittert alarmene skal også lagres i systemet. Alarm skal være rullerende lager med tilstrekkelig kapasitet. Alle alarmer skal lagres i statistikklager. Det skal være mulig for en operatør å finne ut når og hvor mange ganger et punkt har endret status. Alarmhåndtering, dvs. routing etc. skal settes opp i OSD. Tekst for alarmmeldinger og alarmprioritet i OSD skal være tilsvarende det lokale automatiseringsanlegg. Alarmtekster og prioriteringer skal oversendes byggherre for kommentarer før implementering. 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 utskriftsmengden ved f. eks. normal stans av aggregat. Da skal luftvakter, filtervakter og etc. undertrykkes i systemet. For analoge verdier skal der være mulig å definere minst 4 alarmnivåer Lagring av forbrukstall (EOS) og klimastatistikk Energi- og mengdemåling skal foregå på M-bus (målebus). Dersom det brukes digitale pulssignaler/analoge signaler skal dette avklares med NTFK (SD-ansvarlig eiendom) på forhånd. Side 9 av 12

10 3.13 Driftstidsregistrering Alle registrerte driftstider for tilknyttede motoreffekter skal registreres i US og skal være i tilgjengelig i OSD. Drifttidsregistreringen skal kunne forårsake varsel eller henvendelser til andre programmer (FDV program eller lignende) ved overskridelse av satte grenseverdier (tid). Driftspersonell skal kunne sette grenseverdier og nullstille driftsregistreringen Tidsstyring Endringer i tidsstyringen skal kunne foretas fra skjermbildet i OSD. Tidsstyringen skal lagres i lokalt automatiseringsanlegg slik at kommunikasjonen mellom lokalt automatiseringsanlegg og OSD faller bort, skal siste definerte tidsstyring fortsette å gjelde for anlegget. Tidsstyring settes individuelt for de ulike anleggene. Dette gjøres sentralt fra OSD. Punkter på anlegget skal kunne styres med 15 minutts oppløsning eller bedre. Tidsstyringen skal kunne styre for eksempel start/stopp av motorer, justering av setpunkt eller utskrift av rapport etc. Tidsstyringen skal ivareta faste og flytende helligdager, fridager og vinter/sommertid med norsk kalenderfunksjon (årskalender). Brukergrensesnittet for tidsstyringen skal være enkel og oversiktlig. Bruker skal kunne endre og justere driftstider på en rask og intuitiv måte Kommunikasjon mellom lokal SD og overordet SD-anlegg (OSD) NTFK har i dag egen fiberforbindelse med 50 Mbit/s hastighet til alle eiendommene de har ansvaret for i hele fylket. NTFK har delt opp sine nettverk i flere sub-nett og skal i forbindelse med overordnet toppsystem, opprette et virtuelt teknisk nett. Her skal kommunikasjonen foregå mellom toppsystem og lokale anlegg. Det tekniske nettet er et virtuelt LAN med egen virtuelt IP-subnett for skolene, felles for alle. Trafikken mellom skolene går inn til NTFK og så ut til skolene. OSD og de lokale automatiseringsanleggene blir tildelt en fast lokal IP i teknisk nett. Dersom eksisterende lokalt automatiseringsanlegg og nytt OSD leveres av samme leverandør, skal leverandør medta kostnader i forbindelse med oppgradering av lokalt automatiseringsutstyr (lokal SD PC, nettverkskontroller). Dersom lokalt automatiseringsanlegg og OSD leveres av forskjellige leverandører, skal standardiserte kommunikasjonsformer benyttes. For å nevne noen: Bacnet Lon EIB KNX OPC Etc. Leverandør av OSD skal være forberedt på fremtidig prosjekter. Leverandør skal beskrive alternative løsninger og hvordan installasjonen ivaretar en fremtidig tilkobling til OSD for: Nye bygg med lokale automatiseringsanlegg av samme fabrikat Nye bygg med lokale automatiseringsanlegg av forskjellig fabrikat 3.16 Testing og ibruktakelse Kommunikasjon til automatiseringsanleggene skal testes og dokumenteres. Dette gjelder også alle moduler i OSD som alarmhåndtering, logging, eksporter, rapportering osv. Stikkprøver på hele kommunikasjonskjeden skal utføres. Dette kan gjøres ved eksempelvis å utløse alarmer lokalt for å se respons i OSD (frostsikring e.l.). Stikkprøvetesting må dokumenteres. Ved overlevering av OSD skal minimum følgende dokumentasjon overleveres: Side 10 av 12

11 Testresultater Brukerveiledninger Systemtegninger OSD/Lokale automatiseringsanlegg (oppdateres ved hver ny tilkobling) Drifts- og vedlikeholdsinstruks jfr. NTFK anvisning for FDV Ferdigbefaring Leverandørs egne utsjekkingslister skal sendes byggherre i ferdig utfylt stand 1 uke før ferdigbefaring kan gjennomføres. Det vil ikke bli holdt overtakelsesforretning før alle punkter på ferdigbefaringsrapporten er dokumentert utført. Byggherre vurderer om det skal holdes en besiktigelse, eller om ferdigbefaringen anses som tilstrekkelig. Side 11 av 12

12 4 SJEKKLISTE FOR ANVISNING OSD Nr Stikkord OK Ikke OK Merknader ved avvik. 1 Kontroll av statisk skjermbilde 2 Korrekt mapping av punkter 3 Kontroll av alarmering 4 Test av kommunikasjon til lokale system 5 Kontroll av rapporteringsgenerator 6 Kontroll av energiregistreringer 7 Kontroll av tidstyring 8 Kontroll av historikk og trendlogger 9 Kontroll av alarmprioritering og alarmtekster 10 Kontroll av alarmlager og alarmhistorikk 11 Kontroll av alarmutsending 5 REFERANSER. Dersom det er referert til referanser så skal disse listes opp her. 6 VEDLEGG Side 12 av 12