B e s k r i v e l s e

Transkript

1 B e s k r i v e l s e Emne: Beskrivelse: Oppdragsgiver: KfiO OSD Overordnet SD-anlegg og integratortjenester med rammeavtale Kravspesifikasjon med prisskjema Kirkelig fellesråd i Oslo Dato: 6. mars 2013 Oppdrag / Beskrivelse nr / Utarbeidet av: Kjetil Kolltveit Fag/Fagområde: Automasjon Kontrollert av: Pål Bang Ansvarlig enhet: 1065 Energibruk og bygningsfysikk Godkjent av: Trond Ivar Bøhn Emneord: Sammendrag: Kravspesifikasjon for overordnet SD-anlegg og integratortjenester for Kirkelig fellesråd i Oslos bygningsportefølje. Dokumentet omfatter: 1) Orientering 2) Tekniske krav til overordnet SD-anlegg 3) Rammeavtale 4) Pilotprosjekter 5) Prisskjema A Anbud 20 KjeK OB TIB For kommentar 20 KjeK Paab MC For orientering 23 JaT KjeK TIB Utg. Dato Ant.sider Utarb.av Kontr.av Godkj.av MULTICONSULT AS Nedre Skøyen vei 2 P.b. 265 Skøyen 0213 Oslo Tel.: Fax:

2 M U L T I C O N S U L T : Innholdsfortegnelse Side: 0 Innholdsfortegnelse 1. Orientering Ord, uttrykk og definisjoner Tekniske og funksjonelle krav til OSD Krav til programvare Nettverk og nettverksløsninger Objektorientert systemoppbygning Brukergrensesnitt og betjening Brukertilgang og rettigheter Skjermbilder Merking Lisens Maskinvare, server Backup og sikkerhet Rapportering Historikk og trendlogger Alarmer Energioppfølging Driftstidsregistrering Tidsstyring Testing og idriftsettelse Rammeavtale Integrator og kontrollfunksjoner Vilkår og betingelser for rammeavtale Dokumentasjon Pilotprosjekter Pilotprosjekt # 1: Nye Bøler Kirke Pilotprosjekt # 2: Oslo Domkirke Prisskjema Leveranse og implementering Priser rammeavtale

3 : KRAVSPESIFIKASJON Side: Orientering Kommunikasjon mellom lokale bygg/anlegg og det overordnede SD-anlegg vil foregå over KfiOs tekniske nettverk. Lokale arbeidsstasjoner skal således ikke være avhengig av annen programvare enn operativsystem og egnet web-browser. Tilgangsnivå og rettigheter for samtlige registrerte brukere skal være individuelt definert og uavhengig av hvor i det tekniske nettverket pålogging forekommer. Alle poster i prisskjemaet skal være utfylt ved innsendelse. Manglende utfylling kan medføre forkastelse av tilbudsgrunnlag. Poster priset til kr 0,- regnes som inkludert i øvrige priser dersom ikke annet opplyses. 1.1 Ord, uttrykk og definisjoner Kravspesifikasjonen inneholder en del forkortelser og uttrykk som ikke nødvendigvis er allment kjent eller omforente. For å unngå misforståelser er de mest benyttede forkortelser og uttrykk redegjort for i tabellene under, henholdsvis Tabell 1. (forkortelser) og Tabell 1. (uttrykk og definisjoner). Bruk av overordnet SD-anlegg og toppsystem (som i mange sammenhenger er en mer vanlig terminologi) forekommer likevel om hverandre i denne kravspesifikasjonen. Det vesentlige i denne sammenheng er likevel grunnprinsippet om sentralisert lisensiering. Forkortelse: Beskrivelse: ADS Applikasjon Data Server BACS Building Automation and Control Systems BBMD BACnet Broadcast Management Device BIBBS BACnet Interoperability Building Blocks BIM Bygnings Informasjons Modell BMS Building Management and Control System (SD-anlegg) BREEAM Building, Research, Establishment Environment Assessment Method. Sertifiseringsmetode for ivaretakelse av energi- miljøhensyn. Klassifisering skjer trinnvis avhengig av hvor strenge miljøkrav som skal følges. BUS Feltbuss - Informasjonsbærende transmisjonsmedium, fortrinnsvis kobberlinje, for overføring av lokal datatrafikk. Benyttes mellom logiske enheter (f.eks. undersentraler, energimålere etc.) med egen "adresse" i anlegget, dvs. CE Comitè Europèen csv-filer Comma-separated values - er et filformat som kan anvendes ved utveksling av data mellom ulike programmer som har forskjellige filformatstandarder DALI Digital Addressable Lighting Interface, system for lysstyring DB Database DBMS Database Management System (HMI/program for oppsett av database)

4 : KRAVSPESIFIKASJON Side: 1-2 Forkortelse: Beskrivelse: DMZ Demilitarized Zone EMC Electromagnetic compatibility EOS Energioppfølgingssystem FAT Factory Acceptance Test, ref. IEC Test av utstyr/programvare hos leverandør FØR utsendelse for installasjon FDV FM GW HMI HW ITB ITV KNX LAN LON LonTalk M-Bus ModBus ODBC OPC OpenBIM PDA PLS Proxy server SAT SCADA SCD SD Forvaltning Drift- og Vedlikehold Facility Management Gateway Human Machine Interface - grensesnitt mot bruker Hardware Integrerte tekniske bygningsinstallasjoner. Definert som egen standard under NS Omhandler systemintegrasjon for optimal tverrfaglig utnyttelse mellom ulike tekniske installasjoner Intern TV Konnex er en internasjonal standard ISO/IEC (tidl. EIB) Local Area Network Local Operating Network. Standardardisert åpen protokoll markedsført av Echelon Corporation, LonWorks Meter Bus, omforent feltbussprotokoll for kommunikasjon med forbruksmålere Kommunikasjonsprotokoll for feltbusskommunikasjon. Finnes i et utall dialekter der ModBus RTU er den mest standardiserte Open Database Connectivity - referansedatabase Object linking and embedding for Process Control. Standard for utveksling av prosessdata mellom programmer. BIM basert på den åpne internasjonale standarden IFC (tilsv.), og som administreres av med norsk avdeling: Personlig digital assistent Programmerbar logisk styring. Innen byggautomasjon blir ofte begrepet 'undersentral benyttet synonymt med PLS Mellomtjener er en server som står mellom en klient og en annen server. Ofte er en proxytjener satt opp for å begrense tilgangen til enkelte websider fra et nettverk. Site Acceptance Test, test av installert løsning på anlegget. Benyttes for å kvalitetssikre konsept og løsning ved oppstart av installasjonen Supervisory control and data acquisition System Configuration Tools Sentral Driftskontrollanlegg

5 : KRAVSPESIFIKASJON Side: 1-3 Forkortelse: Beskrivelse: SMS Short Message Service SNVT Standard Network Variable Type, datatype i et LON-basert kommunikasjonssystem. SQL TCP TFM UNVT UPS US VLAN VPN VVS Structured Query Language. Universelt kommandospråk for datautveksling og manipulasjon av relasjonsdatabaser (bl.a. lese, skrive, slette data). Transmission Control Protocol Tverrfaglig Merkesystem System for identifikasjon og merking av bygningsdeler, systemer og komponenter som er en del av selve bygget eller er installert i eller i forbindelse med bygget. Se eget vedlegg UBM for detaljer. Userdefined Network Variable Type Uninterruptible Power Supply Undersentral, typisk kommuniserende med øvrige anleggsdeler over BUS Virtual Local Area Network Virtual private network Vann, varme og sanitær Tabell 1.1 Uttrykk: Felt- /periferkomponenter Lokal automatikk Definisjon/beskrivelse: Enkeltkomponenter som utfører spesielle oppgaver i system/anlegg, typisk følere/givere, pådragsorganer, overvåkningsenheter, omformere mm. Periferkomponenter blir i all direkte tilkoblet mot US, men kan også kommunisere på BUS. Automatikk som på et lokalt plan ivaretar en eller flere oppgaver for styring, regulering og/eller overvåkning av tekniske installasjoner. Kan leveres med eller uten kommunikasjon eller grensesnitt mot øvrige systemer. Kommunikasjonsprotokoll Henviser til anvendt programmeringsspråk for kommunikasjon mellom forskjellige logiske enheter/systemer. Proprietære systemer Åpne systemer Systemer utviklet og levert av leverandører basert på egendefinerte oppsett, kommunikasjonsprotokoller og/eller standarder. Systemer/oppsett som benytter allment tilgjengelig og åpne kommunikasjonsprotokoller ved signaloverføring mot andre tekniske enheter/systemer. Altså ikke proprietære og/eller leverandøravhengige oppsett/systemer. Tabell 1.2

6 : KRAVSPESIFIKASJON Side: Tekniske og funksjonelle krav til OSD 2.1 Krav til programvare All implementering av overordnet SD-anlegg, inkludert underliggende og støttende moduler, skal skje ved bruk av åpne programvareløsninger. Med åpne programvareløsninger menes at plattform/programoppsett skal være basert på fritt tilgjengelig og kommersiell programvare, eksempelvis SCADA-systemer som Citect eller ifix. Tilsvarende gjelder for oppsett og opprettelse av database (DBMS for opprettelse av eksempelvis SQL-database). Tilbydere som ikke kan dokumentere at deres plattform tilfredsstiller slike krav, som helt eller delvis baserer sine oppsett på egenutviklede og proprietære programmer, vil bli avvist fra tilbudskonkurransen. Med bakgrunn i overstående betingelser skal all utviklet programvare, basert på åpne programvareløsninger, fremstå på norsk og i bokmålsform. Programvaredokumentasjon tillates levert på skandinavisk og/eller engelsk språk. Det legges stor vekt på dokumentasjon. Dokumentasjon skal innbefatte både nødvendige hjelpemenyer samt utfyllende kommentarer i benyttede kildekoder. Kommentarer i kildekoder tillates skrevet med skandinavisk og/eller engelsk språk mens alle hjelpemenyer skal være på norsk bokmål. 2.2 Nettverk og nettverksløsninger Tilrettelegging og drift av datateknisk nettverk er underlagt oppdragsgivers IT-avdeling. Nettverket til oppdragsgiver er stjerneformet med en serversentral i Akersbakken 32. Alle linjene er leid av Broadnet og kjøres i deres nett. Pr er nesten alle kirkene tilkoblet dette nettverket. Hovedsakelig er det SHDSL-linjer på 2 Mbit, alle linjene går pr i dag over kobber. Akersbakken har redundant 100 Mbit fiberlinje ut til Broadnet. Andre tjenester som bruker disse linjene er i hovedsak citrix terminalserversesjoner og IP-telefoni. Kommunikasjon fra perifert utstyr vil gå til sentral server i Akersbakken 32 via brannmur. Serveren vil stå i egen dedikert DMZ-sone. All maskinvare samt nødvendige nettverkskomponenter (routere/switcher) vil bli levert av oppdragsgiver. Tilbydere må spesifisere de nødvendige systemkrav deres oppsett krever. Dette gjelder i særlig grad linjekapasitet, rene maskinvarekrav, samt hva kreves for ivaretakelse av nødvendige backuprutiner (eksempelvis foretrukne RAID-løsninger). En illustrasjon av tiltenkt nettverkstopologi er vist i Figur 2.1.

7 : KRAVSPESIFIKASJON Side: 2-5 Figur Objektorientert systemoppbygning Som fundament for all systemoppbygging skal sammensetninger av komponenter være basert på objekter lagt i database. Alle slike komponenter skal bygges opp og legges inn med definerte egenskaper og grafiske symbol. Som et utgangspunkt skal et minimum av slike komponenter utarbeides. Disse utgjør et representerer utvalg ment som et utgangspunkt for videre integrasjonsarbeider. Alle objekter med tilhørende egenskaper skal benyttes ved opprettelse og oppbygning til samlede systemer/systemløsninger. Slike systemer/systemløsninger skal igjen kunne legges som egne objekter i database, for gjenbruk. Endring av objekters og/eller systemers egenskaper gjøres tilgjengelige for alle opprettede systemer, men ikke nødvendigvis tas i bruk. 2.4 Brukergrensesnitt og betjening Brukergrensesnittet i SD skal være standardisert så langt det lar seg gjøre, også mellom ulike leverandører for forskjellige lokale SD. Dette kapitlet beskriver noen viktige funksjoner i forhold til brukergrensesnitt, men endelige design av brukergrensesnittet avklares med byggherre. Universell 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

8 : KRAVSPESIFIKASJON Side: 2-6 ikke brukes. Eksempelvis skal teksten Innstilling av driftstider eller lignende benyttes i stedet for tekst som Editering av punktparametere. Dette innebærer at alle betjeningskommandoer, innstillinger etc. for systemene som vises i grensesnittet skal være atskilt fra programmeringsordre for programvare. 2.5 Brukertilgang og rettigheter Antall brukere som registreres i systemet skal være ubegrenset. Antall samtidige brukere skal være minimum 5. Brukere som gis tilgangsrettigheter skal kunne deles inn i følgende kategorier: Nivå: Rolle: Rettigheter: Nivå 1 Administrator Alle rettigheter (integrator) Nivå 2 Superbruker Alle rettigheter foruten tilgang til endringer av kildeprogramkoder og databaseoppsett Nivå 3 Driftsansvarlig Rettigheter for endringer av driftstider, settpunktverdier, reguleringssyklus, tildeling av nye brukere, oppsett av logger, endring av rapportoppsett, endring av alarmoppsett, kvittering men ikke sletting av alarmer Nivå 4 Operatør A Brukertilgang rettigheter for endring av driftstider og justering av settpunktinnstillinger for anlegg under eget ansvarsområde. Tilgang skal begrenses til kvittering av alarmer, ikke sletting. For anlegg som ikke ligger under brukers driftsansvar gis kun rettigheter etter Nivå 5. Nivå 5 Operatør B Kun lese rettigheter (innsyn), utskrift av rapporter og sammenligning av verdier. Tabell 2.1 Tabell 2.1 viser en forenklet fremstilling av tilgangsnivå for ulike typer brukere. Det sentrale er likevel grad av rettigheter for endringer 2.6 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 ha aktiv link til lokalt automatiseringsanlegg. For enkelte brukere skal det være mulig å koble disse direkte ned til riktig anlegg, dvs. ved hjelp 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 Settpunkt/fyringskurver/kompenseringskurver (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

9 : KRAVSPESIFIKASJON Side: 2-7 Tavlevenderenes posisjon Systembildene skal ikke inneholde for mange instrumenter 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. 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 anlegg/bygg skal være stor. 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 / klar Rødt = Feil Gult = Service/håndstyrt 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 samme standard Ingen firmareklame, navn e.l. skal i skjermbilder I topp skal det presenteres system-id, -navn og hva det betjener Alle farger skal standardiseres All systemstyring, ur skal angis i bunn midt på bildet 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.

10 : KRAVSPESIFIKASJON Side: Sonekontroll Det skal lages et oversiktsbilde hvor man kan klikke seg inn på ønsket etasje. Det skal lages ett oversiktsbilde 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 parametere 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 ev. eksisterende løsning av lokalt SD-anlegg. Alle skjermbilder skal oversendes byggherren for gjennomsyn før implementering. 2.7 Merking I alle nye prosjekter skal Statsbyggs tverrfaglige merkesystem (TFM) benyttes. 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. 2.8 Lisens Alle lisenskostnader skal spesifiseres av leverandør. OSD skal minimum ha 20 % reservekapasitet på nødvendig lisensiering ved overtakelsestidspunktet. Begrensninger i punktlisens eller lignende skal oppgis til KfiO. Systemet skal tillate minimum 5 samtidige brukere. Dette skal ikke legge noen begrensning på antall brukere med forskjellig tilgangsnivå, men kun begrense samtidighet. 2.9 Maskinvare, server Leverandør må spesifisere sine krav til maskinvaren og operativsystem, oppdragsgiver anskaffer og installere operativsystem etter de krav leverandøren har satt. Oppdragsgiver foretrukne operativsystem er Windows server 2008 R2 og databaseplattformen er Microsofts MsSQL. Kreves det mer enn en server bruker oppdragsgiver VmWare for å virtualisere serverne på en fysisk server. Leverandør er ansvarlig for å installere all programvare, inkludert og OSD-programvare.

11 : KRAVSPESIFIKASJON Side: Backup og sikkerhet Byggherre er ansvarlig for full systembackup av OSD-server. 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. KfiO 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 Rapportering Utskrifter av alle typer status (sanntid) som alarmer, effektgrenser, optimal start/stopp, oppsett etc. skal kunne foretas via OSD. 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å: Kvitterte 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) 2.12 Historikk og trendlogger OSD 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.

12 : KRAVSPESIFIKASJON Side: 2-10 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 per visning med forskjellig Y-akse hvor fargekoder benyttes for å skille kurvene fra hverandre. Historisk logging skal lagre data i minimum 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 CSVfil, uten sideskift 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. 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 Energioppfølging Måledata for energi- og mengdemåling skal videresendes fra OSD til eget energioppfølgingssystem (EOS). OSD må derfor klargjøres for dette 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.

13 : KRAVSPESIFIKASJON Side: Tidsstyring Endringer i tidsstyringen skal kunne foretas fra skjermbildet i OSD. Tidsstyringen skal lagres i lokalt automatiseringsanlegg slik at dersom kommunikasjonen mellom lokalt automatiseringsanlegg og OSD faller bort, skal siste definerte tidsstyring fortsette å gjelde for anlegget. 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 settpunkt 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 Testing og idriftsettelse 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: o Testresultater o Brukerveiledninger o Systemtegninger OSD/Lokale automatiseringsanlegg (oppdateres ved hver ny tilkobling) 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 avgjør hvorvidt det skal avholdes full funksjonstest av systemene, eller om en generell ferdigbefaring anses som tilstrekkelig.

14 : KRAVSPESIFIKASJON Side: Rammeavtale Implementering av et overordnet SD-anlegg utgjør kun første fase av det totale fremtidige oppsett. Under denne delen etableres og defineres det grunnleggende oppsett, som i stor grad vil legge premisser for alle fremtidige integrasjonsprosesser. Implementeringsfasen kontrolleres av medtatte og inkluderte pilotprosjekter. Disse skal sikre at leveransen tilfredsstiller de funksjons- og kvalitetsmessige krav som legges til grunn for kontraktsinngåelse. Selve grunnprisen i rammeavtalen skal inkludere 2 to årlige besøk, samt oppgradering av software til siste versjon når relevant. Andre type arbeider som blir bestilt separat fra byggherre prises etter oppgitte og omforente time- og enhetspriser i dette dokument. 3.1 Integrator og kontrollfunksjoner Selskap/leverandør som tildeles oppdraget i å implementere overordnet SD-anlegg skal også utfylle rollen som integrator. Integrator vil være direkte underlagt oppdragsgiver, med primæroppgaver knyttet til integrasjonsprosesser i forbindelse med tilknytning av nye og/eller rehabiliterte anlegg. I tillegg skal integrator utfylle en oppfølgings og kontrollfunksjon som sikrer at lokale automatikk- og systemleveranser implementeres i henhold til de respektive beskrevne underlag, samt at disse tilfredsstiller ytelser og krav definert i de overordnede mål. Integrator vil derfor utgjøre en viktig støttefunksjon til oppdragsgiver ved å påse at sentrale funksjoner blir ivaretatt videreført fra lokale anlegg til det overordnede SD-anlegg. Som grunnlag for slik tverrfaglig kontroll skal etablert standard for Integrerte Tekniske Bygningsinstallasjoner (ITB), NS 3935, legges til grunn. Foruten et rent integrasjonsmessig ansvar vil derfor ytelser fra integrator vil typisk bestå i en eller flere av følgende oppgaver: o Som kontrolledd ved mottatte prosjekteringsgrunnlag fra konsulenter, før utsendelse til prising i markedet (typisk for å avdekke feil og/eller mangler i slike) o Som kontrolledd ved mottatte tilbud fra entreprenører for å sikre at disse oppfyller de krav som er satt i forhold til integrasjon (for å kontrollere at leverandører har forstått oppgaven og benytter egnet oppsett for å løse oppdraget) o Bistand ved utforming av kontraktsforslag for å sikre at de tekniske forutsetningene blir ivaretatt o Ved oppstart av prosjekt, for å sikre at entreprenørers planlagte leveranse tilfredsstiller omforente betingelser og vilkår (en slags FAT) o Som kontrolledd når lokale tekniske installasjoner er ferdigstilt (for å sikre at forbindelse til overordnet SD-anlegg er utført korrekt) o Kontroll av rapporter og underlag etter test- og igangkjøring av lokale systemer o Kontroll av ferdig anlegg utført fra overordnet system o Sikrestille at beskrevne ytelser og funksjoner er ivaretatt før overlevering og endelig oppgjør mot tekniske entreprenører I det integrators rolle fortrinnsvis skal fokusere på selve integrasjonsprosessen mot overordnet SD-anlegg, gis det åpning for at den ITB-koordinerende rollen i større prosjekter kan settes bort og leveres av eksterne aktører (f.eks. rådgivende ingeniør eller annen tredjepart). Integrator skal i slike tilfeller kunne yte bistand i forbindelse med evaluering av tiltenkt ITB-koordinator, slik at oppdragsgivers interesser til enhver tid blir ivaretatt på en skikkelig måte.

15 : KRAVSPESIFIKASJON Side: 3-13 For å oppnå størst mulig grad av nøytralitet og objektivitet vil tilbydere av overordnet SDanlegg som selv ikke står som potensiell leverandør av lokale systemer bli foretrukket. Bakgrunnen for dette er å oppnå størst mulig uavhengighet i forhold til de lokale og fysiske leveranser med tanke på potensielle interessekonflikter. 3.2 Vilkår og betingelser for rammeavtale For å sikre kontinuitet i forbindelse med fremtidige utvidelser og integrasjonsprosesser på etablert systemplattform (overordnet SD-anlegg), skal det tegnes en rammeavtale mellom oppdragsgiver og systemleverandør. En slik avtale har til hensikt å sørge for at oppdragsgiver kan bestille tjenester og ytelser med bakgrunn i planlagte og/eller ønskede aktiviteter, basert på omforente vilkår og responstid. Det er derfor avgjørende at en slik avtale er basert på et fornuftig og gjensidig oppsett, som sikrer et stabilt og godt fremtidig samarbeid mellom partene. De påfølgende underkapitler omhandler de mest vesentlige faktorer som skal legges til grunn for prising av slike tjenester. Det ligger som et absolutt krav at tilbyder også skal signere en rammeavtale med oppdragsgiver. Signering vil skje parallelt med inngåelse av kontrakt for implementering av overordnet SD-anlegg. Tilbydere som ikke kan oppfylle de ytelser og tjenester oppdragsgiver krever, i henhold til poster under dette kapittel, avvises fra tilbudskonkurransen Grunnpris for rammeavtale og varighet En rammeavtale skal baseres på et årlig grunnhonorar. Grunnhonoraret er utgangspunktet for den forpliktelse tilbyder (integrator) har med oppdragsgiver. Regulering av grunnhonorar følger som øvrige prisposter iht. kapittel Inngått rammeavtale vil vare i 3+1 år. Vilkår for avvikling av samarbeid skal avtales mellom partene Timebasert arbeid og honorarer Såfremt det er praktisk mulig skal alle ytelser og tjenester, enten det dreier seg om integrasjonsprosesser, oppgradering, service, vedlikehold, evaluering av kravspesifikasjoner eller tilsvarende, foregå innenfor normale arbeidstider. Med normale arbeidstider menes vanlige ukedager i henhold til norsk kalenderoppsett, mellom kl.07:00 og 17:00. Bruk av overtid skal kun forekomme etter avtale. For arbeid etter medgått tid skal følgende prises: a) Pris på arbeid per time innenfor normale arbeidstider b) Pris på arbeid per time utenfor normale arbeidstider, inkludert helg og helligdager. c) Tillegg til per time som følge av helligdag (typisk akutt service) Reisekostnader For reiser innenfor Oslo skal kostnader inkluderes i timepris. Reisekostnader utover dette godtgjøres med bakgrunn i Statens reiseregulativ for reiser i innland. Dersom leverandør krever dekning utover dette, skal slike tillegg klart fremkomme Responstider For å sikre mot kritisk nedetid skal leverandør respondere senest i løpet av neste virkedag ved henvendelse innenfor normal arbeidstid. Ved behov for akutt respons skal dette skje innen fire timer, uansett tidspunkt for henvendelse. Tilleggskostnad ved akutt respons prises separat.

16 : KRAVSPESIFIKASJON Side: Systemintegrasjon Med bakgrunn i kapittel 2, som omhandler blant annet systemintegrasjon, visualisering av prosesser, oppsett av logger og database, skal tilbyder spesifisere kostnader forbundet med følgende: a) Pris for punktintegrasjon (gjelder innhenting, logging og visualisering per punkt) b) Priseksempel for systemintegrasjon basert på kjent oppsett og teknologi. Her benyttes et vanlig ventilasjonsaggregat med roterende gjenvinner med varme og kjølebatteri med til sammen 30 punkter c) Pris for integrasjon av samlet anlegg, med bakgrunn i eksisterende og utarbeidede objekter, 500 punkter d) Pris for integrasjon av samlet anlegg, med bakgrunn i eksisterende og utarbeidede objekter, 1000 punkter e) Pris for integrasjonsarbeider som medfører utarbeidelse av nye objekter, per punkt Det er antatt at systemintegrasjonsprosesser medfører stor grad av gjenbruk etter hvert som nye anlegg tilknyttes. Dette bør vektlegges ved prising av de ovenstående poster da oppdragsgiver står fritt til å velge om grunnlag for honorering av ytelser skal gjøres etter medgått tid eller basert på postpriser. Avklaring i forhold til honoreringsform skal i ett hvert tilfelle avklares før arbeidet påbegynnes Indeksregulering Pris for rammeavtalen og andre oppgitte enhetspriser er faste i rammeavtalens første periode på 3 år. Etter dette kan prisene indeksreguleres ved fornyelse av rammeavtalens fornyelsesdato som nevnt under. Som grunnlag for indeksregulering av en rammeavtales prisposter skal det benyttes underlag fra Statistisk Sentralbyrå, Byggekostnadsindeks for boligblokk, med utgangspunkt i kolonne for Elektrikerarbeid i alt. Regulering av rater gjelder for alle prisbærende poster, dvs. både for timebasert arbeid og systemintegrasjon. Indeksregulering av rammeavtale gjennomføres en gang per år, typisk i januar, med bakgrunn i gjeldende satser fra desember året før. Tilbyder skal oppgi startindeks for regulering. Indeksregulering i forbindelse med implementering av overordnet SD-anlegg utføres i henhold til kontraktsbestemmelser for prosjektet Automatisk forlengelse Rammeavtalen inngås i første omgang for 3 tre år, deretter forlenges avtalen automatisk for 1 ett år med mindre en av partene sier den opp Oppsigelse Oppdragsgiver kan når den måtte ønske avslutte rammeavtalen med 3 måneders skriftlig varsel. 4. Dokumentasjon Det skal leveres 2 sett med dokumentasjon på alt utstyr og software som leveres. Dokumentasjonen skal være i form av teknisk produktinformasjon, brukerdokumentasjon / håndbok samt FDV-dokumentasjon. Språket i dokumentasjonen skal fortrinnsvis være på norsk, men engelsk vil også bli godtatt der det ikke foreligger norsk språklig oversettelse.

17 : KRAVSPESIFIKASJON Side: Pilotprosjekter Formålet med pilotprosjektene er primært å danne et evalueringsgrunnlag for det implementerte overordnede SD-anlegg, i sanntid. Ferdig integrerte pilotprosjekter vil dermed utgjøre et test- og kontrollgrunnlag for både systemet (overordnet SD-anlegg), nettverket og nettverksforbindelser. Eventuelle justeringer i denne fasen skal gjelde for systemet totalt sett og ikke være forbundet med lokale utfordringer. Tilbydere skal avsette og medta et tillegg i tid for slike justeringer/korrigeringer tilsvarende minimum 5 % av estimert tidsforbruk for implementering av overordnet SD-anlegg. Eventuelle utfordringer knyttet til de lokale anleggene (pilotprosjektene) skal håndteres separat, typisk i samarbeid med leverandører av anleggenes respektive automatikk og/eller styringssystemer. Eventuelle endringer som følge av slike forhold reguleres i henhold til kontraktsbestemmelser. Oppsett for HMI skal ta utgangspunkt i utarbeidede objekter lagt til database. Av samtlige anlegg under KfiOs eiendomsportefølje inneholder kun to av disse tekniske installasjoner egnet for tilknytning og integrasjon mot et toppsystem (henholdsvis nye Bøler Kirke og Oslo Domkirke). Begge anlegg er rehabilitert og ferdigstilt innenfor de seneste to år, bestående av eksisterende og kjent teknologi. Det er derfor antatt at integrasjon av disse mot et overordnet SD-anlegg ikke vil kreve vesentlige tilpasninger eller spesialløsninger. Så fremt det er fysisk mulig skal derfor alle nødvendige tilpasninger mellom anleggene og overordnet SD-anlegg gjøres lokalt. Grunnfilosofien er at de respektive anlegg skal gjøres uavhengig av lokalt tilkoblede arbeidsstasjoner. All informasjonsutveksling skal dermed foregå fra lokalt nettverk til overordnet SD-anlegg via teknisk nettverk over lokalt plassert router/switch. Med dette vil også behov for lokal lagringsstasjon, slik at en eventuell svikt i nettverk ikke medfører tap av data. Slik lagring skal av sikkerhetsmessige årsaker fortrinnsvis utføres uten bruk av roterende disker. For begge de to pilotprosjektene vil leverandører av lokale automatikk og styringssystemer være tilgjengelig for bistand i forbindelse med integrasjonsprosessen. Av de systemene som er installert på disse anleggene er det fortrinnsvis styring, regulering og overvåkning av VVSprosesser som blir aktuelt (se kapittel 5.1 og 5.2 for nærmere detaljer). Eventuelle anleggsdeler som ikke allerede er en del av oppsettet, og som oppdragsgiver mener er av interesse, vil bli vurdert integrert underveis i prosessen. Slike forhold er å betrakte som endringer i oppdragsmengde og reguleres under inngåtte kontraktsbestemmelser. Tilbydere skal prise integrasjon av de to pilotprosjektene i henhold til det omfang som er estimert i de påfølgende kapitler. All form for HW-leveranse utføres av KfiO eller entreprenør av lokal automatikk. Skulle annet bli aktuelt er dette å anse som tillegg. Tilbydere som ønsker mer detaljert informasjon for beregning av omfang kan etterlyse dette før frist for å sende inn spørsmål utgår (se fremdriftsplan). 5.1 Pilotprosjekt # 1: Nye Bøler Kirke Automatikkanlegg for Bøler Kirke ble levert av selskapet NCS AS. Anlegget ble ferdigstilt og overlevert Anlegget er bygget opp med to automatikktavler for styring av sentrale funksjoner, hhv. VVS 1 og VVS 2. Tavle VVS 1 inneholder primært automatikk for varmeanlegget mens VVS 2 gjelder for ventilasjonssystemene. Anlegget består av følgende systemer: Sentralvarmeanlegg

18 : KRAVSPESIFIKASJON Side: Teknisk varme (ventilasjon, avledet fra hovedstokk) Radiatorer (avledet fra hovedstokk) Gulvvarme (avledet fra hovedstokk) Gatevarme (styres lokalt, pådragssignal fra Aiwell AC3000) Ventilasjonsaggregat (kirkerom og kontorer i plan 1 og 2) Ventilasjonsaggregat (barnehage og ungdomsklubb i plan U) Rom-/sonestyring plan U (21 rom), plan 1 (22 rom) og plan 2 (20 rom). Totalt 63 rom Antall punkter i anlegget er estimert til ca. 500, fordelt på analoge og digitale inn- og utganger fra undersentraler. Disse gjelder for både sentralstyring av varme og ventilasjon samt rom- og sonestyring (sonestyring gjelder spjeldstyring for avgrening fra sentrale ventilasjonssjakter). Varmesystemet består av et enkelt parallellpumpesystem, med avledet energi over varmeveksler. Anlegget forsynes av eksternt varmeaggregat, men skal på sikt tilkobles fjernvarmenett. Slik tilkobling vil ikke påvirke interne funksjoner. Med unntak av kurs for varmebatterier til ventilasjonsaggregater er alle tekniske kurser avledet fra hovedstokken med egen pumpe og styringsventiler. Disse funksjonene er lagt til de to aggregatene for ventilasjonskrets (kalt Teknisk i FDV-underlag). Gatevarmeanlegg inneholder også egen varmeveksler. Sekundærkrets styres av lokal automatikk, pådragsinitiert av separat styringssentral levert av Aiwell AS, type AC3000. Det eksisterer ingen kommunikasjon fra denne utover digital I/O til automatikkanlegget, men styringsenheten inneholder mulighet for kommunikasjon på Modbus. Begge aggregater ( og ), som ventilerer kirkerom og kontorer i plan 1 og 2, er av typen roterende gjenvinner. Begge har varmebatteri med vannbåren varme. Aggregat har i tillegg integrert kjøling (3-trinns DX med 2 stk. kompressorer). I det anlegget innehar romregulering skal disse presenteres på et utsnitt av arkitektens tegningsgrunnlag. Oppdragsgiver bistår med å fremskaffe nødvendig tegningsgrunnlag. 5.2 Pilotprosjekt # 2: Oslo Domkirke I henhold til dokumentasjonsunderlag ble automatikkanlegget for Oslo Domkirke ferdigstilt Automatikk og SD-anlegg ble levert av GK NORGE AS, avdeling Oslo Rehab. Anlegget består av styring av elektrisk varme i kirkesalen samt et ventilasjonsaggregat (360.01) som forsyner utstillingslokaler og kafé i krypt (kjeller) med klimatisert friskluft. Slik anlegget fremstår, består dette i realiteten som tre separate systemer: Styring av elektrisk varme (panelovner og varmekabler) i kirkelokaler Aggregat for ventilasjon av kjeller og kafé (krypt), Romregulering og ettervarmebatterier for arealer forsynt av ventilasjonsaggregat Automatikkutrustning for styring av elektrisk varme er lagt til fordeler mens romregulering (VAV) og ettervarmebatterier er lagt til Aggregatet er kun tilkoblet via I/O, lagt til fordeler I følge leverandør (GK) er aggregatet klargjort for kommunikasjon over feltbuss. Kun kabel mangler. Begge fordelere er utrustet med undersentraler av typen Honeywell Centraline (Niagara Jace). Kommunikasjon mellom undersentraler og SD-anlegg er utført på LonTalk (standardisert protokoll fra Echelon). Undersentralene har i utgangspunktet tilstrekkelig med internlagring for å tilfredsstille behovet for lokal lagring. Eventuelt behov for ytterligere lagring vil bli vurdert. Antall punkter i anlegget er estimert til maksimalt 150 stk.

19 : Priser Side: 6-17 Kode/Spesifikasjon Enhet Mengde Pris Sum 6. Prisskjema 6.1 Leveranse og implementering Programvare Pris på nødvendig programvare for komplett oppsett, inkludert evt. støtteprogrammer til ekstern tilkobling og beskrevet dokumentasjon. Pris skal også inkludere nødvendig programvare for visning og behandling av FDV-dokumentasjon (se nærmere spesifikasjoner under kapittel: 2. Tekniske og funksjonelle krav til OSD) Pris for denne leveranse. RS Brukeropplæring Pris for opplæring av kunde / sluttbrukere, 1 gang á 1 dag (8 timer) RS Installasjon av programvare Pris for installasjon av programvare på kundens server, inkluder oppsett av og tilpasning av grafikk, alarmhåndtering, brukerrettigheter samt utarbeidelse av nødvendige tilleggsobjekter Pris for denne leveranse. RS Pilotprosjekter Pris for ytelser beskrevet under kapittel: Pilotprosjekt # 1: Nye Bøler Kirke RS Pris for ytelser beskrevet under kapittel: Pilotprosjekt # 2: Oslo Domkirke RS Sum denne side Sum dette kapittel

20 : Priser Side: 6-18 Kode/Spesifikasjon Enhet Mengde Pris Sum 6.2 Priser rammeavtale Prisene under dette avsnittet skal ikke legges til ovenstående priser. NB! Mengder er kun til evalueringsformål Grunnpris Iht. kap år Timebasert arbeid og honorarer Timepris normal time Timepris overtid, også helg og helligdager time Tillegg for uttrykning innen 4 timer RS Enhetspriser Nytt objekt i OSD: Analog/modulerende styring av pådragsorgan, inkl. tilbakemelding for posisjon/pådrag, drift og feil. stk Nytt objekt i OSD: Av/på-styring av pådragsorgan (m/tilbakemelding for drift og feil) stk Nytt objekt i OSD: analog avlesning (giver) stk Nytt objekt i OSD: digital avlesning (vakt/bryter) stk Nytt skjermbilde i OSD, inkl. 35 dynamiske punkter og speiling av f.eks. systemskjema for et aggregat / varmesystem. stk 1 Sum denne side Sum dette kapittel