TEKNISK KRAVSPESIFIKASJON

Transkript

1 TRONDHEIM EIENDOM Anskaffelse av EOS-system BILAG A1: TEKNISK KRAVSPESIFIKASJON KONKURRANSE MED FORHANDLING KNYTTET TIL KJØP OG VEDLIKEHOLD AV WEB-BASERST ENERGIOPPFØLGINGSSYSTEM (EOS-SYSTEM) Kontraktsvarighet: 8 år (Avtalen løper i 2 år med opsjon på års forlengelse) med planlagt oppstart NB! Endringer fra opprinnelig dokument er markert med gul farge.

2 Trondheim kommune Trondheim eiendom Side 2 av 33 INNHOLDSFORTEGNELSE: 1 OM ANSKAFFELSEN PRIMÆR FUNKSJON ANDRE BRUKSOMRÅDER ET- OG AVVIKSDIAGRAM EKSEMPLER PÅ ARBEIDSMETODER OG SYSTEMATIKK ET- OG AVVIKSDIAGRAM PÅ BYGGNIVÅ ER IKKE TILSTREKKELIG FUNKSJONSKRAV ET-DIAGRAM FUNKSJONSKRAV AVVIKSDIAGRAM FUNKSJONSKRAV - AVVIKSTABELL BYGG OG ENERGIBLOKKER, GRUPPER OG UTVALG BYGG ENERGIBLOKKER FUNKSJONSKRAV BYGG OG ENERGIBLOKKER GRUPPER OG UTVALG Filtrering av bygg Sammenligning av utvalg Samlet statistikk for et utvalg FUNKSJONSKRAV GRUPPER OG UTVALG ÅRSSAMMENLIGNING OG GRADDAGSKORRIGERING FUNKSJONSKRAV ÅRSSAMMENLIGNING MÅLERE OG ANDRE DATA AUTOMATISKE TIMEMÅLERE PROFILMÅLTE MÅLERE VIRTUELLE MÅLERE BRUKERE FORBRUKSDIAGRAM FUNKSJONSKRAV - FORBRUKSDIAGRAM VARIGHETSDIAGRAM FUNKSJONSKRAV - VARIGHETSDIAGRAM NEDLASTING AV DATA FUNKSJONSKRAV NEDLASTING AV DATA OVERGANGSPERIODE FUNKSJONSKRAV - OVERGANGSPERIODE ØVRIGE KRAV FUNKSJONSKRAV ØVRIGE KRAV BEKREFTELSE PÅ AT TILBYDER HAR FORSTÅTT DOKUMENTET... 33

3 Trondheim kommune Trondheim eiendom Side 3 av 33 1 OM ANSKAFFELSEN Trondheim kommune utlyser anbud for leveranse av energioppfølgingssystem i 8 år. Systemet vil benyttes av en rekke ulike brukergrupper, fra skoleelever og lærere til driftspersonell og energirådgivere. Kravene til funksjonalitet er imidlertid satt høyt da den primære brukergruppen vil være kommunens energirådgivere. Energioppfølgingssystemet skal ved start håndtere rundt m 2 oppvarmet bygningsmasse med et årlig forbruk mellom 100 og 110 GWh. Dette er fordelt på 230 bygg hovedsakelig barnehager, skoler og helse- og velferdssentre. Det forventes at antall energiovervåkede bygg, dertil areal, vil øke i fremtiden. Hvert bygg har 2-3 energimålere og en rekke bygg har automatiske målere som registrerer vannforbruk. Både antallet energimålere og bygg med automatisk vannmåling er forventet å stige betraktelig de neste årene. 1.1 Primær funksjon Trondheim kommune benytter sitt energioppfølgingssystem (EOS) til å oppdage avvikende energiforbruk og analysere årsak. Hvert bygg har individuelle energi-temperatur-kurver (ET-kurver) som viser forventet forbruk basert på utetemperatur. ET-diagrammet for et bygg blir manuelt definert basert på erfaringer fra bygget over en lengre tidsperiode. Avvik fra ET-diagrammet vil dermed kun vise nye feil eller driftsforandringer som har oppstått på et bygg, ikke underliggende problemer som har fulgt bygget over lengre tidsperioder. Kommunens EOS skal ha mulighet til å håndtere ukentlig informasjon på byggnivå, hvor man med kommentarer og opplastede dokumenter kan kvittere ut årsaken til avviket. Denne historikken kan bidra til å oppdage tilbakevendende feil, driftsforandringer eller ekstraordinær bruk, og slik gi en mer effektiv energioppfølging. Den viktigste oppgaven til et nytt EOS vil være å oppdage avvikende energiforbruk og å kunne føre føre en kommentar- og datalogg over hendelser, driftsforandringer og løsninger. I tillegg forventes det funksjonalitet for både lett å identifisere og analysere avvik. 1.2 Andre bruksområder Kommunens EOS benyttes også når det skal produseres års- og halvårsrapporter, samt i arbeid med å oppdage systematiske feil. Til denne bruken benytter vi i dag EOS som en databank, hvor data lastes ned og graddagskorrigeringer og andre beregninger tas i excel-ark. Særlig innen bearbeiding av data til rapportering forventes det at nytt EOS kan redusere intern arbeidsmengde hos Trondheim kommune. Rapportering omhandler her i all hovedsak endring i spesifikt energiforbruk [kwh/m2] over tid, og det er spesielt viktig at systemet har en god funksjonalitet når det gjelder graddagskorrigering av energiforbruk. Særdeles viktig i så henseende vil være muligheten til å kunne: Sette ulik grunnlast for ulike datointervall, eksempelvis: Grunnlast: 5400 kwh/uke Fra: Til: Grunnlast: 4900 kwh/uke Fra: Til: Grunnlast: 5100 kwh/uke Fra: Til: _løpende_ Sette ulikt areal for ulike datointervall, eksempelvis: Areal: 2400 m2 Fra: Til:

4 Trondheim kommune Trondheim eiendom Side 4 av 33 Areal: 2000 m2 Fra: Til: Areal: 2100 m2 Fra: Til: _løpende_ Trondheim kommune forventer fortsatt at jakten på underliggende feil vil måtte gjøres på egne regneark, og det er derfor viktig at det er lett og oversiktelig å laste ned data for individuelle målere. Den nest viktigste oppgaven til et nytt EOS vil være god funksjonalitet rundt graddagskorrigering av data for hyppigere rapportering (måneds-/kvartalsrapportering).

5 Trondheim kommune Trondheim eiendom Side 5 av 33 2 ET- OG AVVIKSDIAGRAM Kommunens energioppfølging fokuserer primært på å oppdage avvikende energiforbruk hvorav feilene grovt sett kan deles inn i to kategorier: lett identifiserbare og tungt identifiserbare. En varmegjenvinner som har stoppet eller et ventilasjonsanlegg som har blitt satt i manuelt på er eksempler på feil som ofte oppdages lett, spesielt på små eller lite komplekse bygg. Disse feilene gir typisk store tydelige avvik og kan lett finnes ved å besiktige energiforbruk på timebasis. De feilene som er tyngre å identifisere finnes ofte på større bygg, hvor et betydelig energitap kan forsvinne i et støyete forbruksbilde. Eksempel på et slikt avvik kan være et 2,5 kw snøsmelteanlegg som er slått på. Dette gir kun 60 kwh økt forbruk i løpet av en dag, men kan bidra med kwh i økt energiforbruk i varme tørre år. På store bygg med forbruk over kwh hvert år, så vil ikke dette avviket være så lett å oppdage. Når man skal oppdage og finne de tyngst identifiserbare feilene, er man avhengig av god funksjonalitet knyttet til ET- og avviksdiagram. 2.1 Eksempler på arbeidsmetoder og systematikk For at tilbyderne skal forstå hvor viktig funksjonaliteten er rundt ET-diagram, har vi valgt å vise tre typiske karakteristikker på avvik, både i ET- og avviksdiagram. Vi har valgt å kalle disse Type 1-, Type 2- og Type 3-avvik, som illustrert med ET-diagrammene i Figur 1 på side 6. ET-diagram kan ofte være vanskelige å lese og tolke, selv med ulike farger eller symboler for respektive år. For å bedre oppdage og identifisere feil er man avhengig av avviksdiagram som viser hvordan energiforbruk har avveket fra ET-diagrammet over tid. På side 7 til 9 har vi vist avviksdiagram for Type 1-, Type 2- og Type 3-feil i henholdsvis Figur 3, Figur 4 og Figur 5. Avvikene er vist både spesifikt [kwh] og relativt [%] til forventet forbruk. I figurtekstene forklares hvilke karakteristikker vi ser samt ulike årsaker til disse. På grunn av at ET-diagram har en så sentral plass i arbeidet med å oppdage og identifisere avvik, er det viktig at Trondheim kommune har gode muligheter til å definere ET-diagram. Mange plasser vil enkle ET-diagram med ett knekkpunkt kunne gi en god beskrivelse av et byggs energiforbruk, men ofte er dette ikke tilfellet. I sammensatte bygg, gjerne bygg med innfløkte oppdelinger, ulike driftsmønster og bruk, og få målere, er vi avhengige av å kunne opprette ET-diagram med mange knekkpunkt. For å belyse dette behovet er det gitt eksempler i Figur 5 på side 10.

6 Trondheim kommune Trondheim eiendom Side 6 av ET-diagram Type 1-avvik ET-diagram Simulert feil ET-diagram Type 2-avvik ET-diagram Sim ET-diagram Type 3-avvik ET-diagram Sim Figur 1 - I grafene over er det illustrert 3 typer avvik som Trondheim kommune opplever på sine bygg. Sort stiplet linje viser eksisterende ET-kurve og det er plottet erfaringsdata fra I tillegg har vi simulert tre ulike typer avvik som ofte forekommer, for året Disse simulerte dataene er vist med gule symboler og det er skissert inn en rød stiplet ET-trendlinje for 2016-dataene.

7 Trondheim kommune Trondheim eiendom Side 7 av 33 Avviksdiagram Type 1 [kwh] Uke Uke Uke Uke Avviksdiagram Type 1 [%] 100,0 % 80,0 % 60,0 % 40,0 % 20,0 % 0,0 % -20,0 % -40,0 % -60,0 % -80,0 % -100,0 % Uke Uke Uke Uke Figur 2 Grafene viser avvik for en tenkt feil som vi har valgt å kalle Type 1 og som oppstår i uke Som vi kan se av den øverste grafen, er det ikke et konstant avvik i kwh over tid. Ser vi derimot på avvik i prosent, som vist i nederste graf, så ser vi enkelte konstante avvik på vinter-vår og høst-vinter, mens det ikke er noe avvik på sommer. Dette betyr at det er et proporsjonalt avvik ved lave temperaturer og ingen avvik ved høye temperaturer, og problemet er sannsynligvis et Type 1-avvik. Type 1-avvik er relaterte til for eksempel virkningsgraden på varmegjenvinnere eller økt innetemperatur.

8 Trondheim kommune Trondheim eiendom Side 8 av 33 Avviksdiagram Type 2 [kwh] Uke Uke Uke Uke Avviksdiagram Type 2 [%] 100,0 % 80,0 % 60,0 % 40,0 % 20,0 % 0,0 % -20,0 % -40,0 % -60,0 % -80,0 % -100,0 % Uke Uke Uke Uke Figur 3 Grafene viser avvik for en tenkt feil som vi har valgt å kalle Type 2 og som oppstår i uke Den øverste grafen viser avvik i kwh, og vi kan se at det har etablert seg et nytt konstant avvik på rundt kwh/uke fra uke 1, Et slikt forhold observeres ikke når vi ser på avvik i prosent, som vist i nederste graf. Eksempler på Type 2-feil er snøsmelteanlegg som står manuelt på, lekkasjer av varmt tappevann og andre feil som ikke påvirker utetemperaturbasert oppvarmingsbehov.

9 Trondheim kommune Trondheim eiendom Side 9 av 33 Avviksdiagram Type 3 [kwh] Uke Uke Uke Uke Avviksdiagram Type 3 [%] 100,0 % 80,0 % 60,0 % 40,0 % 20,0 % 0,0 % -20,0 % -40,0 % -60,0 % -80,0 % -100,0 % Uke Uke Uke Uke Figur 4 - Grafene viser avvik for en tenkt feil som vi har valgt å kalle Type 3 og som oppstår i uke Feilen gir ikke noe konstant avvik når vi ser på kwh/uke. Ser vi derimot på avvik i prosent er det et klart konstant avvuj på rundt 30 prosent. Type 3-feil er primært relatert til økte driftstider men kan også oppstå når for eksempel tidligere nedstengte deler av bygg tas i bruk.

10 Trondheim kommune Trondheim eiendom Side 10 av 33 ET-diagram - Sammensatt bygg A B C A+B+C Knekkpunkt Eksempel X Eksempel Y X Knekkpunkt Y Knekkpunkt Eksempel Z Z Knekkpunkt Figur 5 - I øverste illustrasjon ser vi et sammensatt ET-diagram. Dette kan være et bygg som kun har én energimåler, men i realiteten består av flere bygg eller bygningsdeler. Grønn kurve kan beskrive et uisolert lager med frostsikring, mens rød og blå kan være to deler av et skolebygg. Da alt energiforbruk registreres på én måler, vil denne ha en komplisert karakteristikk med mange knekkpunkt. ET-diagrammene illustrert med X, Y og Z viser tre andre typiske sammensatte ET-diagram, henholdsvis et bygg med snøsmelteanlegg, et bygg med redusert viftedrift under -5 celsius og et bygg med kjøling.

11 Trondheim kommune Trondheim eiendom Side 11 av ET- og avviksdiagram på byggnivå er ikke tilstrekkelig I mange tilfeller kan avvik på individuelle målere være betydelige men sett opp i mot byggets totale forbruk kan den ene måleren forsvinne i støy. Dette kan føre til at enkelte avvik ikke oppdages før lenge etter de oppstod og i enkelte tilfeller, ikke oppdages i det hele tatt. En slik situasjon er illustrert i Figur 6. Den øverste illustrasjonen i Figur 6 viser avviksgrafen for et tenkt bygg med mange undermålere det er stor variasjon fra uke til uke, men over tid er avvikene rimelig sentrerte rundt 0. Uke 31 i 2014 oppstår en feil på én av målerne, men grunnet lite visuelt inntrykk av feilen på avviksgrafen blir det antatt at dette er en naturlig variasjon. Over tid kan et trent øye kanskje oppdage at en feil har oppstått, men feilen kan like gjerne gå uoppdaget. I den nederste illustrasjonen i Figur 6 ser vi en avviksgraf for kun den ene måleren som har fått feil i uke 31, Her er det tydelig at det har oppstått et avvik. Dette er et eksempel på at det er nødvendig med mulighet til å generere avviksgrafer basert på ET-diagram også for enkeltmålere eller grupper av utvalgte målere (ofte kalt energiblokker). 50,0 % 40,0 % 30,0 % 20,0 % 10,0 % 0,0 % -10,0 % -20,0 % -30,0 % -40,0 % -50,0 % Avvik [%] Avvik [kwh] ,0 % 40,0 % 30,0 % 20,0 % 10,0 % 0,0 % -10,0 % -20,0 % -30,0 % -40,0 % -50,0 % Avvik [%] Avvik [kwh] Figur 6 - Avviksgrafer for et sammensatt bygg (øverst) og for én individuell måler (nederst) på det samme bygget. På grunn av mye støy og høyt samlet forbruk, forsvinner et avvik med 35 % på én enkelt måler i den øvrige støyen. En individuell avviksgraf for en spesifikke måleren viser imidlertid et tydelig avvik fra uke 31, 2014.

12 Trondheim kommune Trondheim eiendom Side 12 av Funksjonskrav ET-diagram Figur 7 - Illustrasjonen viser hvordan et ET-diagram bør kunne defineres. Eksempelet er basert på et ET-diagram med 6 koordinater. Røde stiplede linjer viser hvordan ET-diagrammet bør ekstrapoleres utenfor det definerte temperaturintervallet.

13 Trondheim kommune Trondheim eiendom Side 13 av 33 Dette dokumentet inneholder 13 kravtabeller (K1-K13). Tabellene består av 4 rader: Rad 1 representerer krav-nummer (eksempelvis K 2.1, K 4.2) Rad 2 inneholder krav-tekst Rad 3 viser om kravet er et: o o o SKAL-krav Disse krav skal oppfylles. Tilbyder gis imidlertid mulighet til å komme med kommentar på SKAL-krav. Hver kommentar skal gjøres på individuelle ark og det skal i overskriften komme tydelig frem hvilket krav det refereres til med henvisning til punktnummer. Tilbyder som ikke oppfyller alle SKAL-krav kan bli avvist. REDEGJØRE-krav På lik linje med SKAL-krav, skal Tilbyder oppfylle alle krav merket med REDEGJØRE. Tilbyderen skal skrive en redegjøring for disse punktene. Hver redegjørelse skal gjøres på individuelle ark og det skal i overskriften komme tydelig frem hvilket krav det refereres til med henvisning til punktnummer. Vil bli vektlagt i tilbudsevalueringen. Tilbyder som ikke oppfyller alle REDEGJØRE-krav kan bli avvist. BØR-krav Ikke absolutte krav. BØR-krav vil imidlertid bli vektlagt i tilbudsevalueringen. På lik linje med SKAL-krav står Tilbyder fritt til å kommentere individuelle BØR-krav på egne ark. Rad 4 inneholder to avhakingsfelt, ett for Ja og ett for Nei. På alle krav skal ett av feltene ja eller nei krysses av. Dette inkluderer SKAL-, REDEGJØRE- og BØR-krav. K 1 K 1.1 K 1.2 K 1.3 K 1.4 ET-diagram Generelt om ET-diagram Hvert bygg, basert på summen av byggets hovedmålere, skal ha et ET-diagram. Hver energiblokk, basert på summen av inkluderte målere, skal ha et ET-diagram. ET-diagram skal være definert på ukenivå, med ukestart mandag og ukeslutt søndag. Ukenummer skal være definert som i NS ISO Horisontal akse skal vise ukentlig utendørs snittemperatur og vertikal akse skal gå fra null og vise totalt ukentlig energiforbruk. Krav Leveres Administrasjon og definering av ET-diagram K 1.5 ET-kurve skal manuelt kunne defineres med minimum 5 koordinater (Se Figur 7 for et eksmpel på et ET-diagram definert med 6 koordinater). K 1.6 Utenfor temperaturintervallet til den manuelt definerte ETkurven, skal det gjøres en ekstrapolasjon av nærmeste definerte linjestykke (røde stiplede linjer i Figur 7). K 1.7 Det skal være mulig å definere flere ET-kurver for et bygg eller en energiblokk, som er gyldige for bestemte tidsintervaller.

14 Trondheim kommune Trondheim eiendom Side 14 av 33 K 1.8 K 1.9 K 1.10 Til hver ET- kurve, og i det bestemte tidsintervallet som ETkurven er gyldig, skal man manuelt kunne definere en ukentlig grunnlast. Til hver ET- kurve, og i det bestemte tidsintervallet som ETkurven er gyldig, skal man manuelt kunne definere et oppvarmet areal. Til hver ET-kurve, og i det bestemte tidsintervallet som ETkurven er gyldig, skal man manuelt kunne legge til en kommentar.

15 Trondheim kommune Trondheim eiendom Side 15 av 33 Figur 8 - Ved å holde musepeker over et punkt i ET-diagrammet, skal man kunne se kommentarer knyttet til den spesifikke uken for bygget. K 1.11 K 1.12 K 1.13 K 1.14 K 1.15 K 1.16 K 1.17 Visning av ET-diagram (gjelder også for administrasjon av ET-diagram) Så snart det foreligger komplette ukedata for et bygg eller en energiblokk, skal det ET-diagrammet oppdateres med ett ukentlig datapunkt. Man skal manuelt kunne velge datointervall for visning av datapunkter i ET-diagram. Man skal manuelt ha mulighet til å vise eller skjule individuelle kalenderår i visningsintervallet. Data fra ulike kalenderår skal vises med ulike farger og/eller symboler. Ved å velge eller holde musepekeren over et datapunkt i ETdiagrammet, skal man kunne se dato (DD.MM.ÅÅÅÅ), snittemperatur, avvik samt eventuelle kommentarer koblet til den omtalte uken. (Eksempler på mulig visning er illustrert i Figur 8) Som standard skal siste definerte ET-kurve vises i fremstillingen av ET-diagram. Det bør være mulig å velge visning av én eller flere historiske ET-kurver BØR Ja Nei

16 Trondheim kommune Trondheim eiendom Side 16 av Funksjonskrav Avviksdiagram Figur 9 - Figurene viser avviksdiagram i energimengde (kwh, til venstre) og prosent (%, til høyre). Horisontal akse skal være dato, vertikal akse skal være henholdsvis kwh eller %, og man skal kunne sette start- og sluttdato for visningsperiode. K 2 Avviksdiagram K 2.1 Alle bygg og energiblokker skal ha et avviksdiagram som viser ukentlig avvik fra ET-kurve (vist i Figur 9). K 2.2 For vertikal akse skal man kunne velge å vise enten avvik i energimengde eller prosent, som vist i Figur 9. K 2.3 Avviksdiagram bør være basert på historisk tilhørende ETkurver. BØR Ja Nei K 2.4 Jamfør K 2.3 bør det være mulig å skjelne at ulike historiske ETkurver BØR Ja Nei gjelder i ulike tidsintervall på avviksdiagrammet. K 2.5 Man skal kunne velge datointervall for visningen. K 2.6 Ved å velge eller å holde musepekeren over et datapunkt i avviksdiagrammet, skal man kunne se dato (DD.MM.ÅÅÅÅ), avvik (enten energimengde eller prosent) samt eventuelle kommentarer koblet til den omtalte uken (tilsvarende som for ET-diagram illustrert i Figur 8).

17 Trondheim kommune Trondheim eiendom Side 17 av Funksjonskrav - Avvikstabell Figur 10 - Avvikstabell som viser avvik for bygg og energiblokker kun de 8 øverste resultatene vises i illustrasjonen over. Det skal være mulig å vise eller skjule bygg eller energiblokker, man skal kunne sortere alle kolonner og man skal kunne bla mellom uker. K 3 K 3.1 K 3.2 K 3.3 K 3.4 K 3.5 K 3.6 Avvikstabell Hver uke skal det genereres en eller to avvikstabeller som viser avvik for bygg og energiblokker (eksempel på samlet tabell i Figur 10). Denne tabellen skal genereres fortløpende og oppdateres med alle bygg og energiblokker som har mottatt komplette data for den respektive uken. Det skal være mulig å vise og skjule bygg eller energiblokker (som vist i Figur 10), eventuelt skal dataene fra bygg og energiblokker fremstilles i separate tabeller. Det skal være mulig å bla mellom avvikstabeller for siste og alle foregående uker. Avvikstabellen skal som minimum ha kolonnene Byggnavn/Energiblokknavn, Energiforbruk, Avvik i prosent, Avvik i kwh, ukekommentar. Det skal lett være mulig å sortere avvikstabellen basert etter enten Byggnavn/Energiblokknavn, Energiforbruk, Avvik i prosent, Avvik i kwh eller ukekommentar og det skal være mulig å sortere i enten stigende eller synkende rekkefølge. Det bør vær mulig å utelukke bestemte bygg eller energiblokker fra avvikstabell for bestemte tidsintervall. BØR Ja Nei

18 Trondheim kommune Trondheim eiendom Side 18 av 33 3 BYGG OG ENERGIBLOKKER, GRUPPER OG UTVALG Trondheim kommune mottar komplette data for hele byggporteføljen på ukebasis. På grunn av at byggene har ulik drift på forskjellige ukedager, vil det også være mer naturlig å sammenligne energidata fra uke-uke enn dag-dag. Én gang i uken, og når nye energidata er mottatt, genereres en tabell som viser avvik fra ETdiagrammet, altså avvik fra forventet forbruk, for hele byggporteføljen. Som beskrevet i kapittel 2.2 og 2.3, er man helt avhengig av god funksjonalitet når det gjelder definisjon av ET-diagram samt mulighet til å se på avvik for mindre grupper av målere. Vi ønsker derfor å knytte ET-diagram til Bygg (se 3.1) og Energiblokker (se 3.2). 3.1 Bygg Et bygg kan representere et enkeltbygg, en samling av bygninger eller deler av et sammensatt bygg, som illustrert i Figur 11. Hvert bygg skal defineres med et utvalg målere som er byggets Hovedmålere, og det skal være mulig å definere også en gruppe Undermålere. Videre skal det være mulig å definere samlinger av målere for bygg, typisk kalt Energiblokker (videre forklart i avsnitt 3.2). Figur 11 Som illustrert med blå stiplet linje over, skal både et bygg, deler av et bygg eller en samling av bygninger kunne defineres som et Bygg i EOS. 3.2 Energiblokker For å bedre isolere ulike funksjoner eller deler av et bygg, skal energioppfølgingssystemet inkludere energiblokker. Som illustrert i Figur 12, kan energiblokker samle målere som for eksempel omfatter byggvarme, tappevann og snøsmelteanlegg, men de kan like gjerne benyttes til å avgrense forbruk i ulike deler av et bygg. Ved bruk av virtuelle logiske målere (se 5.3) kan energiblokker også kunne vise virkningsgrad eller effektfaktor for ulikt energiproduserende utstyr, som for eksempel varmepumper. Det skal hverken være begrensninger på antall energiblokker man kan definere for et bygg, eller antallet ganger en enkeltmåler inngår i ulike energiblokker for bygget.

19 Trondheim kommune Trondheim eiendom Side 19 av 33 Figur 12 - Til hvert bygg skal det være mulig å definere energiblokker. Dette er samlinger av ulike målere som tilhører bygget typisk målere som til sammen dekker byggets forbruk av varmt tappevann, byggvarme, snøsmelteanlegg etc.

20 Trondheim kommune Trondheim eiendom Side 20 av Funksjonskrav Bygg og energiblokker K 4 K 4.1 K 4.2 K 4.3 K 4.4 Bygg og energiblokker Generelt om bygg og energiblokker Det skal være mulig å opprette, endre, parkere og slette bygg og tilhørende energiblokker. Et bygg skal ha kunne lagre informasjon og relevante data, slik som energimerke, geografisk plassering, adresse, etc. Det bør være mulig å lagre dokumenter sammen med øvrig bygningsinformasjon. Man skal kunne velge temperaturstasjon for et bygg, og byggets energiblokker skal arve denne. BØR Ja Nei Figur 13 Figuren illustrerer hvordan et bygg kan ha hoved- og undermålerkategorier og energiblokker, og hvordan disse er definert ut fra målere som er tilordnet bygget.

21 Trondheim kommune Trondheim eiendom Side 21 av 33 K 4.5 K 4.6 K 4.7 K 4.8 K 4.9 K 4.10 K 4.11 K 4.12 K 4.13 K 4.14 K 4.15 K 4.16 K 4.17 Administrasjon av bygg og energiblokker For hvert bygg skal det være mulig å definere to nivåer av målere, da hovedmålere og undermålere (se Figur 13). Hver enkelt undermåler skal knyttes opp mot én hovedmåler (se Figur 13). Det skal eksistere en grafisk fremstilling av målerstruktur på byggnivå, jamfør boksen Målerstruktur i Figur 13. For hvert bygg skal det være mulig å definere et ubegrenset antall energiblokker (eksempler på energiblokker er henholdsvis Byggvarme, Byggstrøm og Tappevann i Figur 13). En energiblokk skal ha ett målernivå, altså ingen struktur med undermålere. Som et minimum skal hver hoved- og undermålerstruktur samt energiblokk kunne tildeles et ubegrenset antall av alle Trondheim kommunes målere reelle så vel som virtuelle. Hvert bygg bør kunne tilordnes et ubegrenset antall målere fra Trondheim eiendoms totale portefølje av målere (se Figur 13). Videre bør disse utvalgte målerne dukke opp som valg når man skal sette hoved- og undermålere samt energiblokker. Det skal være å mulig tildele hver måler en farge/fargekategori som kan representere for eksempel generell byggstrøm, strøm til el-kjel, fjernvarme, bioenergi, sol etc. Denne farge skal gjenspeiles i visning av. Dersom det inngår flere målere av samme fargekategori i et forbruksdiagram, skal de ulike målerne vises med ulike nyanser av den bestemte fargen. I grafisk fremstilling av målerstruktur, skal det være lett å skjelne mellom reelle og virtuelle målere gjerne ved bruk av stiplet ramme, mønster kombinert med fargekategori eller lignende. Det skal være mulig å inkludere en kommentar til byggets målerstruktur. Det bør eksistere en grafisk fremstilling av hver enkelt energiblokk, gjerne i samme skjermilde som byggets målerstruktur. For energiblokker skal det ikke tegnes noen hierarki eller linjer som illustrerer tilhørighet. BØR Ja Nei BØR Ja Nei

22 Trondheim kommune Trondheim eiendom Side 22 av Grupper og utvalg Vi er ofte interesserte i å se på utvalg av bygg og hvordan et bygg i én byggkategori oppfører seg i forhold til andre bygg i den samme byggkategorien. Typisk vil dette handle om å se hvordan et sykehjem presterer opp mot andre sykehjem, eller hvordan en barnehage presterer opp mot andre barnehager. Dette gjør at vi har et behov for å tildele ulike kategorier tilbygg, og gjerne flere kategorier for hvert enkelt bygg. En skole kan være plassert i alle kategoriene Skoler, Sone sør, Bygg fra , Bygg med varmepumper og Bygg med fjernvarme Filtrering av bygg For å kunne se på et utvalg av bygg, bør EOS-systemet kunne filtrere basert på flere byggkategorier. Dette betyr at man samtidig bør kunne sette flere kriterier, som både Skole og Bygg med fjernvarme, når man filtrerer et utvalg av bygg Sammenligning av utvalg I prinsippet kan man være interessert i å sammenligne en rekke ulike parametre fra ulike bygg. Noen eksempler på dette kan være: Felles visning av byggs ET-kurver Felles visning av byggs spesifikke forbruk (kwh/m2) både reelt og graddagskorrigert Filtrering av ukentlig avviksliste (se kapittel 2 ET- og avviksdiagram) Samlet statistikk for et utvalg Ofte er vi interessert i å se hvordan en hel bygningskategori presterer sammen, som for eksempel hvor høyt forbruket var for skoler i 2015 kontra Det bør således være mulig å vise samlet forbruk for et utvalg, både energiforbruk og spesifikt energiforbruk, og det bør være mulig å vise reelle og graddagskorrigerte verdier. 3.5 Funksjonskrav Grupper og utvalg K 5 Grupper og utvalg K 5.1 Hvert bygg skal kunne klassifiseres med et utvalg av kategorier. K 5.2 Man skal kunne filtrere bygg basert på flere kategorier K 5.3 Man skal både kunne sammenligne enkeltbygg og vurdere bygg opp mot et filtrert utvalg. REDEGJØRE Ja Nei

23 Trondheim kommune Trondheim eiendom Side 23 av 33 4 ÅRSSAMMENLIGNING OG GRADDAGSKORRIGERING For at graddagskorrigering av energiforbruk skal være mest mulig korrekt, er det viktig å ha nøyaktig definert grunnlast. Grunnlast skal ikke graddagskorrigeres kun utetemperaturavhengig energiforbruk skal graddagskorrigeres. Dette betyr at graddagskorrigering for et bygg/en energiblokk skal gjøres basert på en definert grunnlast for det respektive bygget eller energiblokken. Det aksepteres altså ikke forenklede metoder for graddagskorrigering basert på nasjonale bygningsstatistikker eller lignende, og tilbud som inneholder slike løsninger vil forkastes. Grunnlasten bør kunne defineres sammen med ET-diagrammet til et bygg/en energiblokk. Her kan for eksempel ET-diagrammets laveste punkt eller linje (grunnlast) automatisk danne grunnlag for beregningen av en gjennomsnittlig døgngrunnlast, hvorpå denne døgngrunnlasten multipliseres opp til antall dager i den respektive måneden som det skal gjøres graddagskorrigering for. Alt energiforbruk som overskyter denne grunnlasten for en respektiv måned skal graddagskorrigeres. Det skal også være mulig å manuelt sette ukentlig grunnlast for et bygg. Hvordan grunnlast bør defineres og beregnes for et bygg er illustrert i Figur 14. Her ser vi et bygg med en ukentlig grunnlast på 1000 kwh, samt hvordan man beregner grunnlast for de to månedene januar 2016 og februar Figur 14 - Bildet viser hvordan ukentlig grunnlast defineres og hvordan man på bakgrunn av dette kan beregne grunnlast for en spesifikk måned. I regneeksemplene er det valgt månedene januar 2016 og februar 2016 med henholdsvis 31 og 29 dager. I skuddår, som 2016, blir måneden februar 3,6 prosent lengre enn normalt (28 dager). Etter beregninger for graddagskorrigering er foretatt for skuddår, bør korrigert forbruk inklusive grunnlast multipliseres med 96,55 prosent (28/29 = 0,9655).

24 Trondheim kommune Trondheim eiendom Side 24 av Funksjonskrav Årssammenligning K 6 K 6.1 K 6.2 K 6.3 K 6.4 K 6.5 K 6.6 K 6.7 K 6.8 K 6.9 K 6.10 K 6.11 K 6.12 K 6.13 Årssammenligning Oppsett og definisjon Energiforbruk for hvert bygg og hver energiblokk skal kunne sammenlignes med et utvalg av foregående år. Man skal kunne velge blant alle tilgjengelige år på årssammenligningen, og det skal være mulig å vise eller skjule enkeltår. Det skal være mulig å vise forbruk på måneds-, kvartals-, og halvårsbasis. Man skal kunne vise både akkumulert og ikke-akkumulert forbruk. Man skal kunne velge å vise reelle eller graddagskorrigerte verdier. Som standard skal årssammenligningen vise graddagskorrigerte verdier, hvorpå man manuelt må velge bort denne visningsformen for hver økt. Basis for graddagskorrigering skal gjøres basert på en normaltemperatur-liste for Trondheim for som Trondheim eiendom gir EOS-leverandør. NB! Så snart normaltemperaturdata for Trondheim i perioden foreligger, skal Trondheim eiendom oversende disse dataene til leverandør som deretter oppdaterer sin normaltemperaturliste vederlagsfritt. Energimengder som er lavere enn grunnlast skal ikke graddagskorrigeres. Kun den energimengde som overstiger grunnlast skal graddagskorrigeres. Graddagskorrigeringen gjøres ved at den reelle energimengde som overskyter grunnlasten divideres på reelle graddagstall for den spesifikke måneden. Videre mulipliseres dette med normale graddagstall, som definert i liste fra Trondheim eiendom, og adderes til grunnlasten. For skuddår bør graddagskorrigerte data for februar multipliseres med 0,9655 for å tilsvare 28 dager. I årssammenligningen skal det være mulig å vise dataene enten som energiforbruk (kwh) eller spesifikt energiforbruk (kwh/m2). Både når det gjelder bruk av grunnlast til graddagskorrigering samt oppvarmet areal til beregning av spesifikt forbruk, så skal man benytte de grunnlaster og arealer som er definert i ETdiagram for de aktuelle tidsperioder. BØR Ja Nei

25 Trondheim kommune Trondheim eiendom Side 25 av 33 5 MÅLERE OG ANDRE DATA 5.1 Automatiske timemålere Trondheim kommune har i dag hovedsakelig timemålte anlegg, med data fra Statkraft Varme AS og Trønderenergi Nett AS. I tillegg eksisterer det et mindre antall målere hvor det foregår automatisk sending av data fra SD-anlegg på e-post og noen benytter mobilnettet for å lagre dataene på en database hos Kamstrup i Danmark. 5.2 Profilmålte målere Kommunen har fortsatt en del målere som er profilmålte. Det er forventet at disse vil fases ut med tid, men det vil på starten av perioden være behov for å kunne registrere energiforbruk for enkelte målere manuelt. 5.3 Virtuelle målere Det eksisterer mange årsaker til at man ønsker å kunne definere virtuelle målere. Ett typisk eksempel vil være for å differensiere forbruk på undermålernivå, der summen av undermålere til sammen ikke dekker alt forbruk. En slik situasjon er illustrert i Figur 15. Eksempel på en annen virtuell måler kan være effektfaktoren på en varmepumpe (COP), hvor COP finnes ved å dividere produsert varme på tilført elektrisitet til varmepumpen. Figur 15 - Eksempelet over viser et bygg som har to hovedmålere for elektrisitet og fjernvarme. I tillegg har bygget to undermålere som registrer alt forbruk som ikke går til el-kolber i tappevannstank og varme distribuert med byggets hovedstokk.

26 Trondheim kommune Trondheim eiendom Side 26 av 33 K 7 Målere og målerdata K 7.1 Systemet skal håndtere time- og profilmålte målere. K 7.2 For timemålte anlegg (automatiske) skal systemet kunne lagre data som enten tellerstand (akkumulert) eller timeforbruk. K 7.3 For profilmålte målere skal det være et brukergrensesnitt hvor man kan velge å registrere enten målerstand eller differanse på målerstand. K 7.4 For profilmålte målere skal energiforbruket mellom avlesninger midles og være flatt. K 7.5 Ved tap av data i et tidsintervall, skal energiforbruket estimeres eller målerstanddifferanse benyttes dersom dette eksisterer. I tidsintervallet dette gjelder skal energiforbruket midles og være flatt. K 7.6 Det skal være mulig å legge inn en beskrivelse/kommentar på hver enkelt måler, både for reelle og virtuelle målere. K 7.7 Det bør være mulig å hefte ved ett elle flere dokumenter til BØR Ja Nei målerbeskrivelse. K 7.8 Systemet skal kunne håndtere virtuelle målere som med logiske operasjoner som addering, subtrahering, multiplikasjon og divisjon av andre målere og konstanter. K 7.9 For timemålte målere, skal systemet håndtere både energi-, temperatur- og volumdata. K 7.10 Temperaturdata fra Meteorologisk institutt (Voll værstasjon i Trondheim) skal hentes minimum en gang i døgnet, med oppløsning på timenivå. K 7.11 EOS-leverandøren skal kvalitetssikre overførte data, og gi kunden avviksmelding på e-post om mangler eller åpenbare feil. K 7.12 Alle målerdata og behandlede data som danner grunnlag for grafiske fremstillinger, skal som minimum ha en oppløsning på 1 kwh, og det tillates ikke at det foretas avrundinger til nærmeste hundre eller tusen. Dette omfatter også graddagskorrigerte energidata. K 7.13 Systemet skal kunne hente ut data fra ELhub når denne er etablert, og skal for øvrig kunne motta data fra Trønderenergi nett (evt. strømleverandør) og Statkraft Varme AS K 7.14 Systemet skal ta vare på, samt kunne fremstille, alle historiske målerdata.

27 Trondheim kommune Trondheim eiendom Side 27 av 33 6 BRUKERE K 8 K 8.1 K 8.2 K 8.3 K 8.4 Brukere og brukerstøtte Brukere EOS-systemet skal ha passordbeskyttet innlogging. Hver bruker skal ha mulighet til å sette sitt eget passord. Det skal være mulig med et ubegrenset antall brukere på de forskjellige brukernivåene. Brukeres rettigheter skal styres med tildeling av definerte roller med tilpassede rettigheter, som endring-, lese- eller skrivetilgang til noen utvalgte eller alle bygg. Øverst i brukerhierarkiet skal Trondheim kommune ha mulighet til flere systemadministratorer med full endringstilgang. Som eksempel, men ikke begrenset til, skal systemadministratorer kunne: Opprette, slette, sperre brukere Endre tilgangsnivå til brukere Definere og endre ET-diagram med tilhørende faktorer, som grunnlast, oppvarmet areal, beskrivelse/kommentar m.m. Opprette virtuelle målere Opprette bygg Sette opp målere og målerstruktur for bygg og energiblokker Definere byggkategorier til bygg NB! Kort fortalt skal Trondheim eiendom i prinsippet kunne operere og bruke EOS uten behov for bistand fra EOS-leverandør. Dette inkluderer imidlertid IKKE import og behandling av reelle timemålte data da dette er EOSleverandørens ansvar. REDEGJØRE Ja Nei Brukerstøtte K 8.5 I tidsrommet kl hver virkedag, skal EOSleverandør yte teknisk support per telefon og e-post. K 8.6 Henvendelser på telefon skal svares ut direkte eller innen 1500 samme dag. K 8.7 Henvendelser pr e-post skal svares ut senest innen 1500 neste virkedag. K 8.8 Henvendelser som er et resultat av tekniske feil på eller manglende funksjonalitet av EOS, skal ikke faktureres. K 8.9 Dersom EOS-leverandør mener en supporthenvendelse er i ferd med å krysse terskelen til betalt driftsstøtte eller energirådgivning, skal EOS-leverandøren gjøre kunden oppmerksom på dette. K 8.10 EOS-leverandøren skal kun gi betalt driftsstøtte eller energirådgivning til et utvalg av predefinerte personer hos Trondheim kommune/trondheim eiendom. Øvrige personer som kontakter EOS-leverandør i en slik forbindelse skal bes ta kontakt med Trondheim kommune/trondheim eiendom.

28 Trondheim kommune Trondheim eiendom Side 28 av 33 7 FORBRUKSDIAGRAM Når man har oppdaget energiforbruk som avviker fra ET-kurve, er man avhengig av gode visuelle forbruksdiagram. Dette er diagram som viser energiforbruk på time-, døgn- eller ukenivå på bygg-, energiblokk- eller målernivå. Med tanke på at bruk av forbruksdiagram er visuell, er man helt avhengig av tydelige og klare grafer som gir god lesbarhet. Dette betyr at grafene må kunne dekke et stort areal på skjermen, ulike målere må kunne fremstilles med distinkte og lett differensierbare farger, linjer må være tydelige etc. Da en stor andel av energiforbruket er temperaturavhengig, er det viktig å kunne se korrelasjon mellom temperatur og energiforbruk. En slik korrelasjon kan illustreres med inverterte temperaturdata da temperaturavhengig oppvarmingsbehov har en invers korrelasjon med temperatur. 7.1 Funksjonskrav - Forbruksdiagram Figur 16 - Figurene illustrerer ønsket funksjonalitet på forbruksdiagram, enten stablet søyle eller stablet linjediagram. Det skal være mulig å vise (figurer til venstre) eller skjule enkeltmålere (figurer til høyre). K 9 Forbruksdiagram K 9.1 Målerdata for et bygg eller en energiblokk skal fremstilles som et stablet søyle eller linjediagram. K 9.2 Data skal kunne vises på uke-, døgn- og timeoppløsning. K 9.3 Definerte hovedmålere skal danne grunnlag for standard visning av energiforbruk på uke-, døgn- og timebasis på byggnivå. K 9.4 På byggnivå skal det være mulig å velge visning av undermålernivå. K 9.5 Intervallet for datafremstillingen skal defineres med en startdato og en sluttdato.

29 Trondheim kommune Trondheim eiendom Side 29 av 33 K 9.6 K 9.7 For å kunne estimere om uke-, døgn- eller timeforbruk er som forventet, skal løsningen inkludere utetemperatur med invertert skala på sekundærakse. Utetemperatur skal vises med invertert skala og være skalert og vertikalt forskjøvet slik at det er enkelt å se korrelasjon mellom temperaturdata og energiforbruk. Oppløsning på inverterte temperaturdata bør være av samme oppløsning som energidataene, både uke-, døgn- eller timeoppløsning. Det skal være mulig å vise eller skjule enkeltmålere samt inverterte temperaturdata.

30 Trondheim kommune Trondheim eiendom Side 30 av 33 8 VARIGHETSDIAGRAM Varighetsdiagram er et viktig verktøy innen dimensjonering av varmesystemer. I tillegg gir varighetsdiagram viktig informasjon om hvordan et bygg forbruker energi, da spesielt hvor høye maksimaleffekter bygget har i forhold til gjennomsnittseffekt. 8.1 Funksjonskrav - Varighetsdiagram K 10 K 10.1 K 10.2 Varighetsdiagram Det skal være mulighet til å generere varighetsdiagram for enkeltmålere virtuelle så vel som reelle. Det skal fritt kunne velges tidsintervall for visning av varighetsdiagram. 9 NEDLASTING AV DATA Selv om det stilles høye krav til EOS, forventes det at mange analyser vil måtte tas i Excel. På grunn av dette er det viktig at det eksisterer god funksjonalitet rundt nedlasting av data. 9.1 Funksjonskrav Nedlasting av data K 11 Nedlasting av data K 11.1 Alle tabeller skal kunne lastes ned på excel- og csv-format K 11.2 For alle grafer/diagrammer, skal det være mulig å laste ned datagrunnlaget i excel-format for den viste tidsperioden. K 11.3 Det skal være mulig å laste ned målerdata for manuelt bestemte tidsintervall. K 11.4 Ingen nedlastede excel-ark skal ha oppdelte eller sammenslåtte celler. K 11.5 Alle data som lastes ned skal ha både et beskrivende navn og datostempel. Eksempelvis skal varighetsdiagram ha datostempel knyttet til hver enkelt verdi i varighetsdiagrammet, og datostemplingen skal være på form DD.MM.ÅÅÅÅ TT:MM eller tilsvarende.

31 Trondheim kommune Trondheim eiendom Side 31 av OVERGANGSPERIODE Vi er avhengige av å ha kontinuitet i kommunens energioppfølging, og det er derfor viktig at overgangen til nye EOS-avtale går smidig. Samtidig er det viktig at ny funksjonalitet rundt årssammenligning er på plass tidlig i januar, noe som vil gi en betydelig reduksjon av intern ressursbruk Funksjonskrav - Overgangsperiode K 12 Overgangsperiode K 12.1 Alle kostnader med å overføre data til ny EOS skal være inkludert i den årlige tilbudte lisenskostnaden. K 12.2 Leverandøren skal beskrive hvordan den planlegger å implementere nytt EOS-system for Trondheim kommune. Dette inkluderer migrering av data, hvilke oppgaver EOSleverandør vil utføre samt hvilke oppgaver det er forventet at Trondheim kommune tar. Det skal presenteres en fremdriftsplan for overgangen til ny EOS-leverandør, hvor det fremkommer arbeid med ny funksjonalitet, etablering av dataoverføring fra el- og fjernvarmeleverandører, SD-anlegg, etc. og innhenting av historiske data. NB! Energirådgivere ved Trondheim eiendom kan selv opprette bygg og mate inn bygginformasjon samt velge målere og opprette målerstruktur, energiblokker og definere historiske ET-kurver, areal og grunnlast K 12.3 Funksjonalitet for etterspurt beregning av årssammenligning skal foreligge senest REDEGJØRE Ja Nei

32 Trondheim kommune Trondheim eiendom Side 32 av ØVRIGE KRAV 11.1 Funksjonskrav Øvrige krav K 13 Øvrige krav K 13.1 Alle menyer og tekster skal være på norsk K 13.2 Det skal ikke være nødvendig å installere komponenter/moduler i den enkelte brukers PC for at EOS-systemet skal fungere mot de vanligste nettlesere spesifikt, Safari (ios), Chrome, Firefox, iexplorer eller EDGE. K 13.3 EOS-systemet bør støtte HTML 5.0 BØR Ja Nei K 13.4 All produsert og oppdatert forvaltnings-, drifts- og vedlikeholdsdokumentasjon (FDV-dokumentasjon) for EOSsystemet, skal være tilgjengelig vederlagsfritt for alle brukere. K 13.5 EOS-systemet bør kunne ha en funksjonalitet for å vise virkningsgrader eller effektfaktorer, som for eksempel effektfaktor for varmepumper, virkningsgrad for bioekjeler eller lignende. BØR Ja Nei Følgende krav er tilføyd fra opprinnelig dokument: K 13.6 EOS-leverandøren skal årlig gi én tilrettelagt opplæring av driftspersonell, som driftsoperatører, områdeledere, SD- /automatiserings-arbeidere, og skal være inkludert i de årlige lisenskostnadene. Opplæringen vil foregå i et auditorium/sal og kan inkludere et antall deltagere som bestemt av Trondheim kommune/trondheim eiendom. K 13.7 Denne opplæringen skal være foregå i tidsrommet på en dag valgt av Trondheim kommune minimum 45 dager før opplæringen arrangeres. Brukermanualer til alle kursdeltagere skal ved kursets start foreligge på norsk, både elektronisk og i papirformat.

33 Trondheim kommune Trondheim eiendom Side 33 av BEKREFTELSE PÅ AT TILBYDER HAR FORSTÅTT DOKUMENTET Dette dokumentet inneholder 13 kravtabeller (K1-K13). Tabellene består av 4 rader: Rad 1 representerer krav-nummer (eksempelvis K 2.1, K 4.2) Rad 2 inneholder krav-tekst Rad 3 viser om kravet er et: o o o SKAL-krav Disse krav skal oppfylles. Tilbyder gis imidlertid mulighet til å komme med kommentar på SKAL-krav. Hver kommentar skal gjøres på individuelle ark og det skal i overskriften komme tydelig frem hvilket krav det refereres til med henvisning til punktnummer. Tilbyder som ikke oppfyller alle SKAL-krav kan bli avvist. REDEGJØRE-krav På lik linje med SKAL-krav, skal Tilbyder oppfylle alle krav merket med REDEGJØRE. Tilbyderen skal skrive en redegjøring for disse punktene. Hver redegjørelse skal gjøres på individuelle ark og det skal i overskriften komme tydelig frem hvilket krav det refereres til med henvisning til punktnummer. Vil bli vektlagt i tilbudsevalueringen. Tilbyder som ikke oppfyller alle REDEGJØRE-krav kan bli avvist. BØR-krav Ikke absolutte krav. BØR-krav vil imidlertid bli vektlagt i tilbudsevalueringen. På lik linje med SKAL-krav står Tilbyder fritt til å kommentere individuelle BØR-krav på egne ark. Rad 4 inneholder to avhakingsfelt, ett for Ja og ett for Nei. På alle krav skal ett av feltene ja eller nei krysses av. Dette inkluderer SKAL-, REDEGJØRE- og BØR-krav. Tilbyder bekrefter med dette at han har forstått hvordan tabeller med krav skal fylles ut. Tilbyder bekrefter også at han skal redegjøre for alle REDEGJØRE-krav. Tilbyder er inneforstått med at alle BØR-krav og alle krav som krever redegjøring vil være gjenstand for evaluering. Trondheim kommune forbeholder seg retten til å forkaste alle tilbud som ikke oppfyller reglene beskrevet i dette kapittelet. Firmanavn: Firmaets representant: Navn (Blokkbokstaver) Rolle Dato og sted Signatur