portfolio-optimiser/src/portfolio_optimiser/data/bundles/driftssenter-kjoling/tiltak-trinnstyring-kjoling.md

type	title	description	resource	measure_id	tags	timestamp
hypothesis	Trinnstyring av hovedkjølingen: fra 3 trinn til 13	Erstatte kontaktorstyrt 3-trinns regulering av hovedkjølingen med 13-trinns styring slik Driftsstandard DS-09 anbefaler. Modellert besparelse utledet av kvantiseringsoverskuddet i de to trinnrekkene, med et åpent kostnadsgulv.	DRIFTSSENTER-KJOLING	KJOLING-01	kjoling kjolestyring frekvensstyring ECM DS-09	2026-08-09

Tiltak: 13-trinns styring av hovedkjølingen

Oppgradering av styringen i høylast- og overgangssonen fra dagens 3-trinns kontaktorstyring til 13-trinns styring, slik Driftsstandard DS-09 (2021) § 9.6.1 anbefaler. Aggregatene byttes ikke — det er reguleringen som byttes.

Dette er tiltaket som er projisert inn i validatoren.

Tiltaket er beskrevet av standarden selv

DS-09 § 9.6.1 beskriver både utgangspunktet og målet, ordrett:

«Høylastsonens nedtrapping er gitt av kjølekurven i figur 9.2. I utførelse har dette vært begrenset til 3 trinn arrangert med oppdeling i kurser styrt via kontaktorer. Frekvensstyrte vifter og kompressorer åpner for en bedre tilpasning til kurven ved hjelp av styring i flere trinn som vil redusere energiforbruket vesentlig.»

«Det anbefales å definere høylast-/overgangssonen i 13 trinn henholdsvis 0-5-10-15-20-25-30-40-50-60-70-80-90-100 % alternativt dynamisk (…). Det bør som minimum legges til en hysteresetid på 60 sekunder for endringer i nivåene.»

Det er uvanlig komfortabelt utgangspunkt for en hypotese: standarden navngir dagens praksis, navngir tiltaket, og lister trinnene. Vi trenger ikke finne på noen av delene.

Parametere

Parameter	Verdi	Status	Kilde/forankring
Installert effekt, hovedkjøling	60 kW	[I]	se driftssenter-kjoling.md
Timer høylasttrinn aktivt	4 500 t/år	[I-avledet]	≈ 4 380 t over frikjølingsgrensen + sikkerhetsmargin
Trinnrekke FØR	3 trinn: 33,3 / 66,7 / 100 %	[V-forankret]	DS-09 § 9.6.1, «oppdeling i kurser styrt via kontaktorer»
Trinnrekke ETTER	14 nivåer: 0-5-10-15-20-25-30-40-50-60-70-80-90-100 %	[V]	DS-09 § 9.6.1, ordrett
Variabel energipris	1,00 NOK/kWh	[V-forankret]	se driftssenter-kjoling.md

Modellert besparelse (ex-ante)

Mekanismen er kvantiseringsoverskudd. En trinnstyrt regulator må aldri legge seg under det kjølekurven krever — gulvet er et driftssikkerhetskrav, ikke en preferanse. Den må derfor velge det laveste tilgjengelige trinnet som er ≥ kravet. Energitapet er den midlere overskytingen, og den krymper når trinnene blir finere.

Med kravet modellert som jevnt fordelt over trinnrekkens spenn blir midlere servert nivå:

3 trinn {33,3 %, 66,7 %, 100 %} → midlere servert nivå 66,67 % 13 trinn {0 … 100 %} → midlere servert nivå 54,25 % Reduksjon: 12,42 prosentpoeng av installert effekt = 18,625 % av hovedkjølingens energi

Regnestykket, med den ene antakelsen synlig:

Hovedkjøling i dag: 60 kW × 0,6667 × 4 500 t = 180 000 kWh/år Hovedkjøling etter: 60 kW × 0,5425 × 4 500 t = 146 475 kWh/år Besparelse: 180 000 − 146 475 = 33 525 kWh/år = 33 525 NOK/år

Det er 18,6 % av hovedkjølingens forbruk og 10,00 % av driftssenterets totale elforbruk.

Antakelsen som bærer tallet, og som ikke er verifisert: at kravnivået er jevnt fordelt. Det er det nesten sikkert ikke — T20 ved luftinntaket er skjevfordelt mot lave verdier store deler av året, og i den skjevheten hjelper de fine trinnene mer enn jevnfordelingen tilsier, ikke mindre. Ingen kilde i materialet gir en målt T20-fordeling for driftssenteret. Vi lar antakelsen stå eksplisitt i stedet for å skjule den i et rundt tall.

Kryss-sjekk mot konsernprosjektet ENTR (og hvorfor tallene ikke er like)

ENTR D2.1 modellerer et beslektet tiltak — «frekvensstyrt kjøling med lukket tilbakekobling» — på et referanseanlegg med samme geometriklasse som driftssenteret:

	ENTR D2.1	Driftssenteret (vårt)
Hovedkjøling før	158 059 kWh/år	180 000 kWh/år
Hovedkjøling etter	136 893 kWh/år	146 475 kWh/år
Besparelse	21 166 kWh/år (13,4 %)	33 525 kWh/år (18,6 %)

Størrelsesordenen stemmer — og det er hele poenget med en kryss-sjekk. Men vår andel er 5,2 prosentpoeng høyere, og det skal forklares, ikke bortforklares:

• ENTR-tiltaket beholder konvensjonelle termostater og forbedrer selve tilbakekoblingssløyfa. Vårt tiltak endrer trinnoppløsningen fra 3 til 13. Det er to ulike inngrep i samme kjede, og de har ingen grunn til å gi samme tall.
• ENTRs tall er modellert av prosjektet, ikke målt. Det er et anslag på linje med vårt, ikke en fasit vårt anslag skal kalibreres mot.
• Vår jevnfordelings-antakelse trekker i retning av for lavt anslag, ikke for høyt (se over).

⚠️ Og en felle i selve kilden: D2.1 oppgir ulik baseline før tiltak for nominelt samme referanseanlegg — 158 059 kWh/år for dette tiltaket, men 150 059 kWh/år for innkapslings-tiltaket (tiltak-kaldgangsinnkapsling.md). Baselinen er altså ikke felles på tvers av tiltakene i D2.1. De to kan ikke settes i samme regnestykke, og vi gjør det ikke.

Kostnadssiden — et anker med feil årstall

Eiendomsavdelingens prisbok (publikasjon 4) gir en intern enhetspris for kjøleanlegg:

«For serverhaller større enn ca. 300 m² kan gjennomsnittsprisen per m² variere mellom NOK 1000 og NOK 3000. (Prisen inkluderer aggregater, kabelbroer, installasjon av trafo og nettilknytning)»

For hovedkjølingens 600 m² gir det 0,6–1,8 mill. NOK. Men tallet er ubrukelig som det står, av to grunner:

1. Publikasjonen er udatert i vårt uttrekk. Et beløp uten årstall kan ikke prisjusteres. Prisboken omtaler «mer enn 700 tekniske rom i virksomheten» — virksomheten passerte det for mange år siden, så tallet er gammelt, men hvor gammelt vet vi ikke.
2. Prisen gjelder feil ting. Den dekker hele kjøleanlegget per m² — aggregater, kabelbroer, trafo, nettilknytning. Vårt tiltak bytter bare styringen. En styringsoppgradering er en brøkdel av et komplett anlegg, og ingen kilde i materialet gir den brøken.

Konsekvensen er at cost-baseline.json ikke får noen investeringsrad. Det er samme valg som klientpark-bundelen tok, men av en annen grunn: der fantes det ingen kilde, her finnes det en kilde som ikke bærer. Å prisjustere et udatert beløp til et tiltak det ikke gjelder, ville vært å produsere et tall og kalle det et anker.

ENTRs ≈ €35 000 per kjølekrets for det beslektede styringstiltaket er den nærmeste størrelsesordenen vi har, og den er fra et annet anlegg og udatert. Den står i kilder-kjoling-realisering.md som orientering, ikke som kostbase.

Usikkerhet (for Monte Carlo P10/P50/P90)

Den dominerende usikkerheten er ikke energiprisen — den er hvor godt styringen faktisk følger kurven i drift. Den usikkerheten er systematisk, ikke tilfeldig, og den peker én vei. Derfor håndteres den i verdict-laget (verdict-trinnstyring-fro.md), ikke her.

Den eksisterende validatorens Monte Carlo varierer enhetspris. I denne mappingen brukes derfor prisbandet 0,70–1,40 NOK/kWh som usikkerhetsakse, identisk med klientpark-mappingen.

Mapping til validatoren (hvorfor validator-input.json ser ut som den gjør)

Den eksisterende deterministiske validatoren er en feasibility-gate (claimed ≤ 30 % av affected total, Monte Carlo over enhetspris) bygd for kostnadskutt. Tiltaket mappes inn uendret:

• affected_items = [{code: "ENERGI-DRIFTSSENTER-EL", quantity: 335250 kWh/år, unit_cost: 1.00 NOK/kWh}] → hele driftssenterets årlige energikostnad (335 250 NOK).
• claimed_saving_nok = 33525 → den modellerte besparelsen.
• assumptions = {"ENERGI-DRIFTSSENTER-EL": [0.70, 1.40]} → prisbandet for Monte Carlo.

Hvorfor hele driftssenteret og ikke bare hovedkjølingen: hadde affected_items vært hovedkjølingens eget forbruk (180 000 kWh), ville besparelsen vært 18,6 % av den — under cap-en, men med langt mindre margin, og konvolutten ville vært feil størrelse i prinsippet: tiltaket virker på driftssenterets energikostnad, og det er den linjen anleggseieren betaler. Klientpark-bundelen tok samme beslutning med porteføljen som konvolutt. For ett enkelt anlegg er anleggets totale elforbruk den riktige analogien til en portefølje — ikke den sonen tiltaket tilfeldigvis sitter i.

Forholdet blir da claimed / nominal_feasible = 33 525 / 100 575 = **1/3 eksakt**, mot reservens 0,3333 og klientpark-bundelens 0,3386.

cost-baseline.json bærer nøyaktig samme rad. code, quantity og unit_cost er identiske i de to filene — ikke «innenfor toleranse», men identiske, fordi begge er skrevet fra summen 180 000 + 139 230 + 16 020. Hver code i affected_items finnes som nøkkel i items.

Ærlig begrensning: validatorens P10/P50/P90 betyr her «øvre feasible grense» (30 % av samplet energikostnad), ikke «styringsbesparelsens fysiske band». Det er bevisst — den domenetro modelleringen og realiseringsgapet hører hjemme i verdict-laget.