Kvart punkt i kravspesifikasjonen skal ha svar i eiga vedlegg. Sjå «Svarskjema kravspesifikasjon»

Størrelse: px

Begynne med side:

Download "Kvart punkt i kravspesifikasjonen skal ha svar i eiga vedlegg. Sjå «Svarskjema kravspesifikasjon»"

Arnold Dalen
6 år siden
Visninger:

1 Side 1 av 5 Bygge- og eigedomstenesta Sakshandsamar: Magne Westvik E-post: Magne.Westvik@sfj.no Tlf: Vår ref. Sak nr.: 12/ Gje alltid opp vår ref. ved kontakt Internt l.nr. 7567/12 Dykkar ref. Dato LEIKANGER, Bilag 1 til ssa-k_lille Kravaspesifikasjon Kvart punkt i kravspesifikasjonen skal ha svar i eiga vedlegg. Sjå «Svarskjema kravspesifikasjon» Innhold 1 Beskrivelse av programmet Generelle krav Krav til løysninga Krav til tal brukara Datatekniske krav Måletekniske krav Målardata Brukarmanualar Rapporter Alarmer Struktur Historiske måleverdier Innlogging og datautveksling Opplæring og tilpassing Vedlikehaldsavtale... 5 Svaret skal ha nummer etter punkta under. Dette vil danne grunnlaget for tilbydar si løysningsspesifikasjon, bilag 2 i etter til Statens Standardavtaler, SSA-K lille og SSA-V lille. Fylkeshuset Askedalen LEIKANGER Tlf.: Faks: Bankgiro: postmottak.sentraladm@sfj.no Org.nr.: NO MVA

2 Side 2 av 5 For krav merka Demo blir oppretting av ein nettbasert demonstrasjonsbrukar for kvar kommune rekna som tilstrekkeleg dokumentasjon. Denne må være tilgjengeleg i perioden som er sett av til tilbodsbehandling. Dei andre skal gjerast greie for skriftleg, fortrinnsvis i vedlagt tilpassa skjema. Svaralternativ lista i tabell skal bli nytta: Svaralternativ Ja Nei Delvis Seinare versjon Særskilt kostnadsdrivande Skreddarsaum Skildring Kravet vert oppfylt Kravet vert ikkje oppfylt Kravet vert dekka delvis og tilbydar spesifiserer kva som vert levert og ikkje Kravet blir oppfylt i ein versjon som kommer etter tilbodsfristen. Angi dato for når dette kjem inn i programmet. Kravet vert oppfyllt, men er spesielt kostnadsdrivande for prisen. Dersom fleire krav vert dekka av same komponent må dette komme fram klart og tydeleg. Omfanget av jobben vert spesifisert med eit estimert tal timar som må kjøpast for å innfri kravet. 1 Beskrivelse av programmet Programmet skal samle inn, behandle og presentere måleteknisk data. 2 Generelle krav Formålet med konkurransen er å få eit standard program for innsamling og behandling av måletekniske data. Programmet skal være brukarvennleg, effektivt, enkelt å drifte og utvide, og ha høy grad av sikkerheit. Programmet må i driftsperioden holdast oppdatert. Det vil sei at programmet til ein kvar tid skal halde et høgt nivå i bransjen og at feil skal rettast kontinuerleg. 3 Krav til løysninga 3.1 Krav til tal brukara 1. I lista over målarar er det sagt kor mange brukara som skal som eit minimum inkluderast i prisen. Viss det er ein grense på tal samtidige brukara skal han leggast på eit nivå som ikkje gjer praktiske problem med det talet brukarar som er oppgidd. 3.2 Datatekniske krav Programmet må kunne nyttas med PCer som kjører Windows XP og Windows Programmet skal være web-basert og skal kunne nyttast via Internet Explorer og Mozilla firefox og andre kjende nettlesare.

3 Side 3 av 5 2. Ein kopi av databasen skal med jevne mellomrom kunne bli oppdatert på server hos oppdragsgivar. 3. Angi mulegheita for og leggja programmet på ei lokal server og drifta løysinga frå denne. 3.3 Måletekniske krav 1. Programmet skal være tilrettelagt for følgjande typar målingar: Energi elektrisitet Energi fjernvarme Energi gass Energi fjernkjøling Energi olje Manuelt registrert forbruk Måleverdier kalkulert frå andre målepunkt. Så som effektfaktor varmepumper og kjølemaskiner Vann Avfall Frå oppstartinga skal bare målepunkt oppgitt i målepunktlistane prisast. 3.4 Målardata Det skal vektleggast løysingar som er rimelige i drift, så som overføring ved hjelp av epost der dette er mogleg. Kostnader til oppsetjing av datafangst skal vera inkludert. 1. Det skal ikkje være praktiske grenser på tal målepunkt som programmet kan bli utvida for. 2. Programmet skal kunne mota målardata frå netteiger eller kraftleverandør i MSconsformat. Se 3. Programmet skal kunne mota måledata frå målarar som gir ut pulssignal. Utstyr for innsamling av signal skal være inkludert ferdig kopla og med kommunikasjon til programmet. 4. Programmet skal kunne mota målardata via utveksling frå SD-anlegg. Slik utveksling skal være basert på fortløpande forbruksdata og ikkje akkumulerte verdiar lagra i SD-anlegget. Datafangst frå SD-anlegg skal bare bli valt der dette blir den klart rimelegaste løysinga. Kostnader i samband med å koordinera seg fram til å få denne datafangsten til å fungera skal vera inkluder. 5. Demo: Det skal være mogleg å manuelt legge inn og korrigere måledata direkte i datafelt. 6. Programmet skal dagleg mota data på temperatur og vind frå MET si offisielle målestasjoner i Sogn og Fjordane. Desse data skal på kommunenivå bli nytta til ET-kurve og graddags korrigering av forbruksdata ut frå middeltemperaturar. Der det er fleire målare i kommunen skal gjennomsnittet bli nytta, men ikkje målepunkt på fjelltopper og kystfyr som skal utelatast. Referanseperiode for gradagskorrigering skal være den nye som er basert på åra Angi moglegheiten for og knyta reelle prisar for ulike energibærare til dei registrerte forbruksdataene. Angi graden av automatisering av oppdatering av prisar på kraft og nettleige og kjente feilkjelder i systemet.

4 Side 4 av Brukarmanualar 1. Det skal leverast brukarmanual for rapportverktøy. Brukarmanualen skal bli gjennomgått og godkjennast av oppdragsgjevar. Utgangspunktet for brukarmanualen kan gjerne være generell, men alle systemtilpassa funksjoner spesielt for denne leveransen skal bli nemnt. Brukarmanualen skal være på Norsk og skal bli levert elektronisk. 2. Demo: Det blir lagt vekt på at programmet skal vera så lettfattelig og intuitivt som råd. 3.6 Rapporter 1. Demo: Rapporter skal kunne bli tilpassa brukerane. 2. Demo: Data skal bli levert både som reelle og graddagskorrigerte. Det skal være mulig å legge inn faktor for vind. 3. Demo: Rapporter skal kunne veljas ut på fleire nivå som målepunkt, energikjelde, eigedomsgruppe, byggruppe osv. 4. Demo: Det skal vere mogleg å legge til skriftlege kommentarar til avvik eller andre observasjonar knyta til energibruk. Til dømes helgearrangement. 5. Demo: ET-kurva skal ha kroneverdi på den eine vertikale aksen for å gjøre synleg ein omtrentleg kostnad til avvika i forbruket. Til dømes energikostnaden til eit helgearrangement i ei elles vanleg veke. 6. Systemet skal kunne sende ut ferdig definerte rapporter inn til et overordna system eller ha innebygd muligheit til å gjera utvalt rapporter automatisk tilgjengelig for publikum via ein fast lenkeadresse. 3.7 Alarmer 1. Det skal bli gitt automatiske alarmer viss ikkje energibruken ligger innanfor ein kontrollgrense som for eksempel kan være ± 10 % i forhold til Et-kurve. Kontrollgrensa skal kunne bli tilpassa kvar energiblokk og målar. 2. Det skal bli gitt automatisk alarm dersom effekttopp overskrider angitt nivå for timesavleste målare. 3. Det skal bli gitt automatisk alarm på grunn av feil i datatrafikk frå datakjeldene. Til dømes at det ikkje blir registrert data i det heile ein peiode. 4. Alarmar blir sendt på epost til nærmare bestemte personar for kvar enkelt energiblokk. 3.8 Struktur 1. Demo: Kvart bygg eller institusjon skal kunne bestå av fleire energiblokker. 2. Demo: Målepunktane skal kunne bli knyta til bygget eller ein bestemt energiblokk 3. Det skal være mogleg å definera undermålare, for å tilpasse energiflyten i forskjellige bygg og energiblokkar. 4. Det skal være mogleg å definera undermålare som er kalkulert frå andre målerar med ein matematisk funksjon. 3.9 Historiske måleverdier 1. Historiske timesverdier for skal bli importert frå netteigar for de målarane som er timesmålte, for å etablere historikk på bygga. 2. Det skal være mulig å importere historisk forbruk av olje og fjernvarme på ned til ukesoppløysning frå eksisterande database eller rekneark. Spesifiser format og syntakst som er ønska.

5 Side 5 av 5 3. Meteorologiske data på kommunenivå for skal bli innhenta. Disse skal i sum vere dei årlege graddagstallene som blir publisert på enova.no Innlogging og datautveksling 1. Programmet skal støtte felles innlogging med andre datasystem som til dømes FDVUsystem. Angi mulegheitene som fins for dette. 2. Det skal bli angitt moglegheit for utveksling av data med FDVU-system. Angi byggdata som kan bli importert og oppdatert gjennom slike system og angi FDVU-leverandørar der slik integrasjon er gjort tidligare Opplæring og tilpassing 1. Driftspersonell skal læres opp i å nytta programmet, samt bruk av supportteneste. Angi kor mange timar som er inkludert i svarskjema. 2. Ein eller to brukara skal lærast opp i å legge til og utvide med nye målepunkter. 3. Alle naudsynte aktiviteter skal bli lista opp i en overordna plan for leveransen Vedlikehaldsavtale 1. Det skal inngås vedlikehaldsavtale om vedlikehald og service. Avtaledokumentet er Avtale om vedlikehald og service av utstyr og programvare i mindre omfang, DIFI den lille vedlikehaldsavtalen, SSA-V lille. Se ellers Vedlikehaldsavtalen skal være løypande og prisen skal bli oppgidd som årlig sum. 2. I «ssa-v_lille_bilag» skal tilbydar fylla inn vilkår som dei vil tilby. Fortrinnsvis standard vilkår for verksemda.

Like dokumenter

Konkurransegrunnlag e-målere og fordeling C-bygg

Konkurransegrunnlag e-målere og fordeling C-bygg Side 1 av 7 Bygge- og eigedomstenesta Sakshandsamar: Magne Westvik E-post: Magne.Westvik@sfj.no Tlf.: Vår ref. Sak nr.: 13/3679-1 Gje alltid opp vår ref. ved kontakt Internt l.nr. 17152/13 Dykkar ref.