Prosjekteringsanvisning

Transkript

1 PROSJEKTERINGSANVISNING, OVERORDNET SD- ANLEGG (OSD) Fylke dato: FEF dato: Filnavn: ver264.doc Side: 1 av 17 Prosjekteringsanvisning OVERORDNET SD-ANLEGG (OSD) Mindre suppleringer. PIM/TIH BSK JSP Anvisning OSD TJO/TIH BSK JSP Revisjon Revisjons dato Beskrivelse Utarbeidet Kontrollert Godkjent

2 Side: 2 av 17 INNHOLDSFORTEGNELSE 1 INNLEDNING Revisjonskommentarer 1, utsendelse Revisjonskommentarer HENSIKT Håndtering av avvik fra anvisningen ORIENTERING OG GENERELLE KRAV Orientering Oppbygging lokale SD-anlegg og OSD Datateknisk infrastruktur Generelle krav TEKNISKE OG FUNKSJONELLE KRAV, OVERORDNET SENTRAL DRIFTSKONTROLL (OSD) Brukergrensesnitt og betjening Meny og navigering generelt Symbolforklaringer Topologiskisse Tilgangsnivå Skjermbilder Merking Grensesnitt Lisens Maskinvare, server Programvare Backup og sikkerhet Rapportering EOS, energiregistrering og oppfølging Historikk og trendlogger Alarmer Alarmervarsling via GSM og Lagring av forbrukstall (EOS) og klimastatistikk Driftstidsregistrering Tidsstyring Kommunikasjon mellom lokal automatiseringsanlegg og overordet SD (OSD) SJEKKLISTE FOR ANVISNING OSD... 17

3 Side: 3 av 17 1 INNLEDNING For effektiv bygging, drift og vedlikehold av Akershus fylkeskommune (AFK) sin bygningsmasse er det utarbeidet prosjekteringsanvisninger. Denne anvisningen tar for seg retningslinjer rundt overordnet SD-anlegg (OSD). Disse retningslinjer skal følges som et minimumskrav og dersom det ønskes avvik fra disse retningslinjer skal dette skriftlig godkjennes av byggherre på forhånd. 1.1 Revisjonskommentarer 1, utsendelse Dette er første revisjon av anvisning for overordnet SD-anlegg (OSD). 1.2 Revisjonskommentarer 1.1 Noen suppleringer og samkjøringer med anvisning for automatisering. 2 HENSIKT Hensikten med anvisningene er å forsikre at riktige systemløsninger blir levert i AFK sine prosjekter. Anvisningen skal bidra til standardisering av systemløsninger med samme kvalitet, i tillegg til at integrasjon mot overordnet SD-anlegg (OSD) blir standardisert. Anvisningene vedlegges i alle tilbudsforespørsler initiert av AFK som et minimumskrav til funksjon og valg av tekniske løsninger. Anvisningene vedlikeholdes og oppdateres av AFK. 2.1 Håndtering av avvik fra anvisningen Prosjekterende og utførende (aktører = rådgiver/entreprenører/leverandører) skal følge denne anvisningen. Det påhviler alle parter å gjøre AFK oppmerksom på eventuelle avvik som registreres i forhold til denne anvisning. Ved et hvert tilbud skal prosjekterende, entreprenør og leverandør angi eventuelle avvik i forhold til anvisningen. Dersom underlag avviker fra denne anvisningen har aktøren varslingsplikt overfor den ansvarlige for SD/Eiendomsdrift hos byggherren (AFK). Dersom slik godkjenning ikke foreligger på forhånd må aktøren utføre utbedringer/endringer for egen kostnad. 3 ORIENTERING OG GENERELLE KRAV 3.1 Orientering AFK sine eiendommer er spredt. For å oppnå effektiv og enklere drift av disse eiendommene, skal automatiseringsanlegget kunne tilknyttes én felles driftssentral med et OSD (overordnet SD-anlegg). Derfor må de tekniske anleggene standardiseres og instrumenteres slik at de blir egnet for fjerndrift. Det er laget to tekniske anvisninger: Anvisning for overordnet sentral driftskontroll (OSD) beskriver toppsystem, skjermbilder, kommunikasjon og funksjonalitet. Anvisning for automatiseringsanlegg beskriver automatiseringsgrad, funksjonalitet, kommunikasjon, sonekontroll og feltutstyr. De ulike anvisningene må sees i sammenheng for å få en komplett forståelse av anleggsoppbyggingen til AFK. Det påligger aktøren å etterspørre og gjøre seg kjent med øvrige faganvisinger fra AFK

4 Side: 4 av 17 Det er viktig for AFK at nye anlegg skal være driftsvennlige, energieffektive noe som ofte medfører behovsstyring av lokale tekniske anlegg. Automatiseringsanleggene skal betjenes via overordnet SD-anlegg (OSD). 3.2 Oppbygging lokale SD-anlegg og OSD I figur 1 er den prinsipielle oppbyggingen av automatiseringsanlegg og kommunikasjon til OSD. På feltnivå i byggene inngår givere, pådragsorgan (ventiler, pumper, vifter), sonekontroll osv. På automasjonsnivå er undersentralene (US) installert. Det vil være naturlig at hvert bygg eller lokale bygningsmasse (for eksempel alle bygg på en skole) samles i ett punkt for kommunikasjon ut på det felles tekniske nettverket til AFK. Enheten som kommuniserer ut på det felles tekniske nettverket kan være en undersentral, konsentrator, tradisjonell PC, industri-pc etc. Tilgang og betjening av automatiseringsanlegget skal foregå via AFK sitt tekniske nettverk med kommunikasjon mot OSD på administrasjonsnivå. Hver tavle skal ha minimum ett ekstra uttak (Rj45) for tilkobling av PC til OSD via det tekniske nettverket. Figur 1 Forenklet topologi av topp-nivå (OSD), automasjonsnivå og feltnivå

5 Side: 5 av Datateknisk infrastruktur Alle eiendommer med lokale automatiseringsanlegg i AFK skal tilknyttes OSD via et eget dedikert virtuelt tekniske nett med åpne standarder. Figur 2 viser skjematisk hvordan kommunikasjonen med OSD skal foregå. Figur 2 Forenklet figur av hvordan tilgang til fra automatiseringsanleggene til OSD skal foregå AFK har i dag en ADMnett linje på ca. 10Mbit/s kapasitet til sine eiendommer. Kommunikasjonen mellom OSD og de lokale Automatiseringsanleggene skal gå over teknisk nett (Admin nett), som er et virtuelt LAN med egen virtuelt IP-subnett for skolene. AFK har eget serverrom hvor server for toppsystem skal plasseres og driftes. Pålogging fra Internet gjøres via en Citrix-klient sammen med registrert mobilnummer til en SSL webserver som innehar kryptert sikker pålogging. Når brukeren er på innsiden av teknisk nettverk gjøres normal pålogging til OSD via desktop-grensesnitt via lokal IP.

6 Side: 6 av Generelle krav Det forutsettes at de lokale automatiseringsanleggene fungerer autonomt, dvs. at kritiske funksjoner som regulering, sikkerhetsfunksjoner, tidstyringer, kalenderfunksjoner 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. 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 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. All kommunikasjon mellom bruker og system skal være på norsk. OSD skal overvåke kommunikasjon til alle tilknyttede anlegg og gi alarm ved manglende kontakt (watch dog). 4 TEKNISKE OG FUNKSJONELLE KRAV, OVERORDNET SENTRAL DRIFTSKONTROLL (OSD) Dette kapittelet omfatter leveransene til overordnet sentral driftskontroll (OSD). Leveransen skal omfatte alt utstyr, montasje, programmering og testing som er nødvendig for å tilfredsstille de funksjoner som er beskrevet. Stikkordsvis kan nevnes: Krav til brukergrensesnitt og betjening Krav til menyer og navigering generelt Krav til skjermbilder Krav til merking Krav til programvare o Krav tilgangsnivå o Krav til backup og sikkerhet o Rapportgenerering o Historikk og trendlogger o Håndtering av alarmer o Tidsstyring Lagring av forbrukstall (EOS) og klimastatistikk Kommunikasjon mellom lokal automatiseringsanlegg og overordet SD (OSD) Krav til alarmgenerering via og GSM Alle IO og viktige fiktive punkter som for eksempel settpunkt, start/stopp-signal til enkeltkomponenter og systemer og alarmgrenser, skal presenteres i det overordnede systemet. 4.1 Brukergrensesnitt og betjening Brukergrensesnittet i OSD skal være standardisert så langt det lar seg gjøre. Dette kapitlet beskriver noen viktige funksjoner i forhold til brukergrensesnitt, men endelige design av brukergrensesnittet avklares med

7 Side: 7 av 17 byggherre. Universiell utforming og god brukervennlighet skal tilstrebes. Spesielt gjelder dette tilknytning til skjermbilder, betjening, farger etc. For eksisterende anlegg skal det for OSD etableres minimum funksjonalitet som det lokale SD-anlegget. For nye anlegg skal det for OSD etableres full funksjonalitet i forhold til lokalet automatiseringsnivå. 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. 4.2 Meny og navigering generelt All navigering er i utgangspunktet brukerbasert, dvs. at det vil variere hvilke eiendommer eller bygg en bruker skal ha direkte tilgang til etter innlogging, dvs. uten å måtte gå via eiendomskart. Her skal det være mulig å klikke seg både opp og ned i hierarkiet. Tilgangen til de tekniske anleggene er brukerstyrt, dvs. at driftspersonalet har ulike tilgangsnivå på de ulike eiendommene. Eiendom Normalt inngangsbilde for OSD skal vise en oversikt over de eiendommer som på logget bruker har tilgang til. Disse skal være klikkbare slik at man kommer inn på de riktige eiendommene. Det skal også være mulig å hente opp eiendomskartet som viser alle AFK sine eiendommer. Det skal skilles mellom de bygg som er tilknyttet OSD, ikke tilknyttet og de man har tilgang til. Bygg Etter at bruker har valgt eiendom skal et oversiktsbilde for relevante bygg innenfor eiendommen vises med klikkbare linker for bygg og plan. Figur 3 oversiktsbilde Nannestad VGS Systemer og soner Etter at bruker har valgt bygg skal aktuelle systemer og soner for det valgte bygget komme frem. Videre derfra skal bruker kunne betjene anleggene på bygget. 4.3 Symbolforklaringer Hovedbilde skal inneholde en link til et skjermbilde som viser symbolforklaringer til alle symboler brukt i brukergrensesnittet, se figur 4.

8 Side: 8 av 17 Prosessbilder, dynamisk/aktiv prosessfremstilling Dynamiske prosessbilder skal forstås som prosessbilder hvor meddelelse til bruker skal foregå vha. fargeskift av symboler og endring av prosessverdier. Hjelpetekst kan om nødvendig benyttes i tillegg. Bilder som hører prosessteknisk sammen skal ha innlagt link for å forenkle skifting mellom de ulike bildene. Det stilles krav til enhetlige bilder. I utgangspunktet skal alle brukerjusterbare parametere vises i skjermbildet. Bildet skal ha standard symboler og farger. Blinkende symbol for feil/alarmer. I bildet skal angis hvilke prioriteter av feil som er aktive. Figur 4 viser et eksempel på symbolforklaring

9 Side: 9 av 17 KOMPONENT GRUNNFARGE STATUS AKTIV STATUS ALARM DIV. Bunnfarge Hvit Rom og arealer Hvit Sort ramme Friskluft Fiolett Tykk Forbehandlet luft Rød Tykk Behandlet luft Rød Tykk Avtrekk Gul Tykk Avkast Gul Tykk Varmtvann Rød Tynn Kaldtvann Blå Tynn Glycol Fiolett Tynn Fjernvarme Rød Tynn Trykkluft Grå Tynn Olje Trykkluft Brun Grå Oksygen Nitrogen Lystgass Propan Rørpost Gul Lyseblå (Rød-blå) Sort TEKSTER: Tekster for melding Verdier for målepunkt: Sort Sort

10 Side: 10 av 17 KOMPONENT GRUNNFARGE STATUS AKTIV STATUS ALARM DIV. Ønsket verdi Ønsket verdi (utregnet) Er-verdi Merketekst (adr) Manuell overstyrt Produkter anlegg som står Topptekst, info Fiolett Mørk blå Sort Blå Gul Grå Grønn Rød blink Sort Anleggsnummer Sort Rød Ev.skjult Informasjonstekst Bildeskift (ikon) Sort Lys-blå Henv,/tekst Ev.skjult

11 Side: 11 av Topologiskisse Leverandøren av OSD skal utarbeide et eget bilde med topologi som angir hvilke systemer som er operative. Informasjonen om topologien til de forskjellige eiendommene skal leverandør av lokale system fremskaffe. Figur 5 viser eksempel på et bilde med Topologi som angir hvilke systemer som er operative 4.5 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: Eiendom 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. Det skal være mulig å defineres minimum 10 brukernivå og uavhengig av bygg og byggkategorier. 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. 4.6 Skjermbilder 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:

12 Side: 12 av 17 Systemets ID-kode, navn og hva det betjener Visualisering av alarmer Avlesning av målte verdier Visualisering av overstyringer Visualisering av status (start, stopp, halv, hel etc.) Systemets eller komponentens fysisk plassering/romnummer i klartekst Tavlevenderenes posisjon Driftsstatus Utetemperatur Link til funksjonsbeskrivelse Memo/service-side for merknader. Link til tilstøtende bilder Link til kalenderstyring Link til kompenseringskurver Link til trendkurver Link til sett punkt Link til alarmgrenser Animasjon og 3-dimensjonale bilder og symboler skal unngås Standard symbolbruk ( NS) Det er viktig at systembildene er oversiktlige og at igjen kjennelseseffekten er stor. Alle IO og alle viktige fiktive punkter (settpunkt, alarmgrenser etc.) skal vises i skjermbildene. Hvert system skal ha et eget skjermbilde. Dersom to eller flere system henger sammen skal disse linkes sammen i skjermbildet. Alle skjermbilder skal ha systemskisse basert på systemskjema. Rene tabellariske oppstillinger skal unngås. 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. Sikkerhetsfunksjoner skal ivaretas. Det skal være mulig å få opp gjeldende funksjonsbeskrivelsene fra skjermbildene. Det skal være enkelt å skrive ut skjermbilder og funksjonsbeskrivelser OSD. Utskrift av skjermbilder skal inneholde dato og tid for utskriften. Bruker skal løpende kunne legge inn nye eller endrede funksjonsbeskrivelser. 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: Bakgrunnsfarge på skjermbildene skal være hvit. Anvisning for automatisering angir eksempel på systembilderr for ulike fagområder. 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

13 Side: 13 av 17 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, servicerapporter. 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. 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. Alle skjermbilder skal oversendes byggherren for godkjenning før implementering. 4.7 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. Systemets database må kunne håndtere 3 merkestrukturer. Serveren må kunne programmeres med tilstrekkelig antall karakterer i flg. prosjektets merkestruktur. I alle nye prosjekter skal AFK merkeanvisning benyttes, se anvisning for merkesystem som bygger på TFMsystemet. 4.8 Grensesnitt Tilgang til toppsystemet forutsetter at klienten er tilknyttet lokalnettverket. Interne brukere har direkte tilgang til webgrensesnitt. Eksterne brukere som skal ha tilgang til OSD, kobler seg til lokalnettverket som beskrevet i kapittel 3.3 datateknisk infrastruktur. Det forutsettes at ingen installasjon av ekstra programvare på klienter som skal benyttes for å få tilgang til OSD er nødvendig. Det forutsettes at disse klientene har preinstallert Windows Terminal Services med mulighet for Remote Desctop Connection eller annen terminalklient som er komptatibel med terminalserveren(ne). 4.9 Lisens Alle lisenskostnader skal spesifiseres av leverandør. Det kan forventes ca 50 samtidige brukere samt I/O-punkter. Systemet skal ikke ha begrensninger forhold til antall samtidige brukere, sentralt og lokalt Maskinvare, server Byggherre er ansvarlig for å levere nødvendig maskinvare og installere all programvare, utenom OSDprogramvare. Serverne skal stå i serverrom til AFK. Installasjon og konfigurering av toppsystem er leverandøren ansvarlig for, mens primærdrifting og backup blir ivaretatt av byggherre Programvare Programvaren skal kommunisere med eksisterende system og til enhver tid være oppdatert med siste versjon. Versjonsendringer skal meddeles og godkjennes av AFK og ivareta forhold til de lokale servere (bakoverkopatibilitet)

14 Side: 14 av Backup og sikkerhet Byggherre er ansvarlig for full systembackup av servere i serverrom, også for OSD server plassert i serverrom. Leverandør av OSD er ansvarlig for at OSD (programvare og database) kan inngå i byggherrens backupsystem. Leverandør spesifiserer hva byggherre skal ta backup av. AFK sørger for at server 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 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 Eiendomsliste o Adresseliste o Alarmrapport med gruppering på: Utkvitterte alarmer Stående alarmer Alarmprioritet Tidsintervall og kombinasjon av valgene o Oversikt over brukere med tilgangsnivå o Oversikt over innloggingsstatistikk og hvilke endringer bruker har utført - 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) 4.14 EOS, energiregistrering og oppfølging. Det skal etableres et eget energiregistreringssystem og oppfølgingssystem (EOS) installert på en egen WEBserver som kommuniserer via GSM til de enkelte energimålere. Likeledes hentes energidata fra nettleverandør, fjernvarmeleverandør og oljeleverandør. Informasjonen innhentes fra disse via og baserer seg på standard overføring. OSD skal ivareta effektovervåkning av anleggene og på denne måte være i forkant av energibruken. Systemet leveres av 3-partsleverandør som tilknyttes AFK.

15 Side: 15 av 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 Alarmervarsling via GSM og . OSD skal etablere alarmvarsling fra de lokale automatiseringsanleggene via GSM og til de ulike driftspersoner/ leietakere. Oppsett skal gjøres fra OSD og rutes til ulike aktører på GSM og . Standardteksten skal følge ID-systemet sin kode med supplerende tekst for hva det er og evnt hva som må gjøres. sending skal inneholde en ytterligere supplerende tekst samt rapport på at meldingen er sendt på GSM, til hvem og hvilket nummer. Utsendelses skal styres til ulike personer avhengig av tid på døgnet, vaktordning og evnt direkte til leietakere. Systemet skal ha tilbakekvittering via GSM og dersom dette ikke gjøres innen angitt tidsperioder sendes meldingen til neste person på vaktlisten.

16 Side: 16 av 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 AFK (SD-ansvarlig eiendom) på forhånd 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. Det skal etableres en egen modul for driftstidsberegning som skal benyttes i fremtidig energiattest for byggene 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 automatiseringsanlegg og overordet SD (OSD). Kommunikasjonen mellom lokale automatiseringsanleggene og OSD vil foregå over ADMnett med 10Mbit/s linje. ADMnett er et virtuelt LAN med egen virtuelt IP-subnett for eiendommene. Kommunikasjonen mellom lokale automatiseringsanleggene og OSD vil foregå over teknisk nett (ADMnett) med 10Mbit/s linje. ADMnett er et virtuelt LAN med egen virtuelt IP-subnett for eiendommene. OSD og lokale automatiseringsanlegg blir tildelt en fast lokal IP i teknisk nett. Dersom lokalt automatiseringsanlegg og OSD leveres av forskjellige leverandører skal standardiserte kommunikasjonsformer benyttes. AFK ønsker å standardisere på følgende 3 kommunikasjonsformer og alle skal kunne kommunisere over IP / Ethernett. OPC - Versjon og type oppgis av Byggherre før aksept av leveranse av OPC server Lon - Lon-merkede produkter med Lon kommunikasjon uten egenutviklede profiler, SNVT er BacNet Der hvor det planlegges å benytte OPC server-klient løsning må leverandøren av OPC-serveren (lokalt anlegg) benytte samme versjon og type som overordnet SD. Dette sikrer at OPC-serveren som leveres kan kommunisere med OSD. Liste over tag/objekter skal utarbeides i samarbeid mellom leverandør av OPCserver og leverandør av OSD(klient server). Listen skal oversendes til OSD før idriftsettelsen av OPC serverklient løsningen. Der hvor Lon benyttes for kommunikasjon skal xif-fil leveres av entreprenør slik at kommunikasjon kan etableres. Om det er samme leverandør av lokalt automatiseringsanlegg og OSD kan lokalt automatiseringsanlegg knyttes direkte til OSD, etter spesifikk avtale med Byggherren.

17 Side: 17 av 17 5 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