---
type: hypothesis
title: "Trinnstyring av hovedkjølingen: fra 3 trinn til 13"
description: "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."
resource: DRIFTSSENTER-KJOLING
measure_id: KJOLING-01
tags: [kjoling, kjolestyring, frekvensstyring, ECM, DS-09]
timestamp: 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](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](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](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](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](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.