refactor(examples): replace sector-specific example material with generic, fictitious examples
The context sets, the packaged knowledge bases and the example bundles are replaced by one fictitious example set about IT operations in an invented organisation: three context sets (serverrom-2027, driftsavtale-2027 and the two-base drift-og-avtale-2027), two synthetic knowledge bases under src/portfolio_optimiser/data/kunnskapsbaser and two example bundles under src/portfolio_optimiser/data/bundles. Numbers, codes and structural values in tests and fixtures are kept; names, ids and wording change. Dated measurement documents that only recorded runs on the replaced material are deleted. Gate figures measured on the new set are not comparable with earlier ones. The exclusion gate from the previous commit is green: 0 tracked files hit outside the shared/ subtree. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
parent
058dd25570
commit
37547fe292
SSH key fingerprint:
SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q
1147 changed files with 24138 additions and 9503 deletions
|
|
@ -2,7 +2,7 @@
|
|||
type: index
|
||||
okf_version: 0.1
|
||||
title: "Bygg-energi mikro-A — repo-lokal fixture (kryssprosjekt-læring)"
|
||||
description: "Minimal repo-lokal OKF-bundle under data/ for S2.0 kryssprosjekt-lærings-tester. Backer prosjekt k+1 i road-k + bundle-k+1-topologien, så dens bundle_dir-gatede Step-1 ExpeL-fold fyrer."
|
||||
description: "Minimal repo-lokal OKF-bundle under data/ for S2.0 kryssprosjekt-lærings-tester. Backer prosjekt k+1 i ref-k + bundle-k+1-topologien, så dens bundle_dir-gatede Step-1 ExpeL-fold fyrer."
|
||||
tags: [fixture, S2.0, kryssprosjekt-laering]
|
||||
timestamp: 2026-07-15
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
{
|
||||
"_note": "SYNTHETIC repo-local mini-bundle IR-projeksjon (Fase 2a S2.0-fixture) — ikke ekte data. Backer prosjekt k+1 i road-k + bundle-k+1-topologien; project_id matcher det bundle-backede prosjektets id (run._project_from_bundle fail-faster ved mismatch).",
|
||||
"_note": "SYNTHETIC repo-local mini-bundle IR-projeksjon (Fase 2a S2.0-fixture) — ikke ekte data. Backer prosjekt k+1 i ref-k + bundle-k+1-topologien; project_id matcher det bundle-backede prosjektets id (run._project_from_bundle fail-faster ved mismatch).",
|
||||
"project_id": "BYGG-ENERGI-MIKRO-A",
|
||||
"measure": "LED-retrofit av 120 lysrorarmaturer i kontorflA (90 W -> 40 W)",
|
||||
"affected_items": [
|
||||
|
|
|
|||
|
|
@ -0,0 +1,10 @@
|
|||
{
|
||||
"_note": "Prosjektets kostdata for DRIFTSSENTER-KJOLING, i det formatet den konsumerende implementasjonen definerer (dens akse - bundelen normerer ikke dette formatet). Raden er driftssenterets arlige energikostnad: hovedkjoling 60 kW x 2/3 x 4 500 t = 180 000 kWh/ar, lavlast-/utlopssone 21 kW x (4 500 t x 1,00 + 4 260 t x 0,50) = 139 230 kWh/ar, ovrige tekniske anlegg 16 020 kWh/ar, sum 335 250 kWh/ar a 1,00 NOK/kWh eks. mva. quantity og unit_cost er BYTE-IDENTISKE med affected_items-raden i validator-input.json fordi begge filene er skrevet fra denne ene summen - 5 %-toleransen er lukket ved konstruksjon, ikke ved avstemming. Investeringskostnad er BEVISST utelatt: eiendomsavdelingens prisbok (publikasjon 4, fiktiv) gir 1 000-3 000 NOK per m2 for kjoleanlegg, men publikasjonen er UDATERT (et belop uten arstall kan ikke prisjusteres) og prisen dekker HELE kjoleanlegget, mens tiltaket bytter bare styringen. En utledet verdi horer ikke hjemme i en kostbase. Se driftssenter-kjoling.md og tiltak-trinnstyring-kjoling.md.",
|
||||
"project_id": "DRIFTSSENTER-KJOLING",
|
||||
"items": {
|
||||
"ENERGI-DRIFTSSENTER-EL": {
|
||||
"quantity": 335250,
|
||||
"unit_cost": 1.0
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
---
|
||||
type: project
|
||||
title: "Driftssenteret — kjøling"
|
||||
description: "Fiktivt driftssenter med to serverhaller à 2 400 m², driftsklasse 80, IT-last under 4 000 kWh/døgn. Energibaseline for kjølingen sone for sone, og rammene kjølekravene setter."
|
||||
resource: DRIFTSSENTER-KJOLING
|
||||
tags: [driftssenter, kjoling, hovedkjoling, energibaseline, DS-09, B-500]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Driftssenteret (DRIFTSSENTER-KJOLING)
|
||||
|
||||
**Fiktivt anlegg.** Tallene er illustrative, og geometrien og kjølekravene er hentet fra den
|
||||
oppdiktede Eksempelvirksomhetens egne standarder med årstall. En produksjons-deployer erstatter
|
||||
dette laget med sin egen anleggsdatabase.
|
||||
|
||||
Driftssenteret har **to serverhaller à 2 400 m², hver med egen kjølekrets**, i **driftsklasse
|
||||
80**, med **IT-last(10) under 4 000 kWh/døgn**. Geometrien er ikke tilfeldig: den er valgt slik
|
||||
at den faller innenfor referanseanlegget konsernprosjektet ENTR D2.1 modellerer på
|
||||
(`>500 m², 2 haller, 2 kretser`), slik at det ene eksterne kryss-sjekk-tallet vi har, faktisk
|
||||
gjelder samme anleggstype. Se [kilder-kjoling-realisering.md](kilder-kjoling-realisering.md).
|
||||
|
||||
## Soneinndeling
|
||||
|
||||
Driftsstandard DS-09 (2021) § 9.2: «Kjøleteknisk sett inndeles en serverhall i høylastsone,
|
||||
overgangssone, lavlastsone og utløpssone». Høylastsonens dybde er lik avstanden fra
|
||||
kjøleaggregatet til målepunktet for utetemperaturen — **99 m² ved driftsklasse 80** (DS-09
|
||||
tabell 9.1).
|
||||
|
||||
| Sone | Utstrekning | Merknad |
|
||||
|---|---|---|
|
||||
| Høylast- + overgangssone («hovedkjølingen») | **300 m² per hall**, 2 haller = 600 m² | [I] høylastsone 99 m² [V] + overgangssone; DS-09 § 9.6.1 styrer dem som **ett** objekt |
|
||||
| Lavlastsone + utløpssone | 2 100 m² per hall, 2 haller = 4 200 m² | beregnet: 2 400 − 300 |
|
||||
|
||||
**Hovedkjølingen er den eneste sonen som er utetemperaturavhengig,** og derfor den eneste der en
|
||||
styringsforbedring kan hente energi. Det er også der nesten all installert effekt sitter.
|
||||
|
||||
## Energibaseline
|
||||
|
||||
| Størrelse | Verdi | Merknad |
|
||||
|---|---|---|
|
||||
| Kjølemoduler, hovedkjøling | 300 à **200 W** = **60 kW** | [I] illustrativt (én rad per hall, ca. hver 4. rackplass i to rekker) |
|
||||
| Viftemoduler, lavlast-/utløpssone | 350 à **60 W** = **21 kW** | [I] illustrativt (ca. hver 12. rackplass) |
|
||||
| Timer høylasttrinn aktivt | **4 500 t/år** | [I-avledet] se «Om de 4 500 timene» under |
|
||||
| Timer natt-/lavlastdrift | 4 260 t/år | beregnet: 8 760 − 4 500 |
|
||||
| **Hovedkjøling, slik den drives i dag (3-trinn)** | **180 000 kWh/år** | beregnet: 60 kW × 2/3 × 4 500 t |
|
||||
| **Lavlastsone + utløpssone** | **139 230 kWh/år** | beregnet: 21 kW × (4 500 t × 1,00 + 4 260 t × 0,50) |
|
||||
| **Øvrige tekniske anlegg** | **16 020 kWh/år** | [I] pumper, adgangskontroll, nødlys, SD-anlegg, UPS-tap, periodisk avfuktingsdrift |
|
||||
| **TOTALT ELFORBRUK** | **335 250 kWh/år** | beregnet: sum |
|
||||
| Variabel energikostnad | **1,00 NOK/kWh** ekskl. mva | [V-forankret] kraftpris + nettleie energiledd + elavgift |
|
||||
| **Total årlig energikostnad** | **335 250 NOK/år** | beregnet |
|
||||
|
||||
Faktoren **2/3** på hovedkjølingen er ikke en reguleringsinnstilling — det er **midlere servert
|
||||
nivå** for et 3-trinns kontaktorstyrt anlegg. Utledningen står i
|
||||
[tiltak-trinnstyring-kjoling.md](tiltak-trinnstyring-kjoling.md); det er
|
||||
nettopp den faktoren tiltaket angriper.
|
||||
|
||||
Nattnivået i lavlastsonen er satt til 50 % fordi DS-09 tabell 9.4 halverer kravet: 1,00 dag
|
||||
mot 0,50 natt (relativ kjøleleveranse) for denne last- og driftsklassen.
|
||||
|
||||
### Om de 4 500 timene — og hvorfor de er merket [I], ikke [V]
|
||||
|
||||
Høylasttrinnet er aktivt når utetemperaturen ligger over frikjølingsgrensen. I virksomhetens
|
||||
klimasone er det omtrent halve året, altså ≈ **4 380 t/år**, og sikkerhetsmarginen rundt
|
||||
grensen der hovedkjølingen fortsatt trenger forhøyet nivå ligger oppå det. **4 500 t/år er valgt
|
||||
innenfor det båndet.**
|
||||
|
||||
Valget er ikke nøytralt, og det skal stå: det er tatt slik at
|
||||
`realiseringsgrad × modellert besparelse` **lukker i heltall**. Det er samme konvensjon som
|
||||
klientpark-bundelen brukte da den valgte antall arbeidsstasjoner, og den hører hjemme i teksten,
|
||||
ikke i en fotnote. **Ingen kilde i materialet gir en målt timekurve for høylasttrinnet i
|
||||
driftssenteret.**
|
||||
|
||||
## Rammer (constraints)
|
||||
|
||||
- **Tilluftmengden i høylastsonen skal ikke være under 50 m³/s** (DS-09 tabell 9.4, merknad;
|
||||
normativ kilde Byggstandard B-500 «Tekniske rom»). Det er et hardt gulv — ingen besparelse kan
|
||||
hentes under det.
|
||||
- **Kjølekrav i høylastsonen = 3,00 % av IT-lasten per grad over frikjølingsgrensen** for
|
||||
IT-last(10) < 4 000 i driftsklasse 80 (DS-09 tabell 9.4). Nivået er altså ikke fast, men
|
||||
**følger T20, utetemperaturen ved luftinntaket** — det er hele grunnen til at sonen kan
|
||||
trappes ned, og hele grunnen til at gevinsten avhenger av hvor godt styringen følger kurven.
|
||||
- **Utetemperaturen skal kontinuerlig måles med kalibrert temperaturmåler** (DS-09 § 9.6,
|
||||
normativ kilde B-500). Måleren finnes altså allerede — men den måler **inngangssignalet**, ikke
|
||||
energien. Se [metode-ipmvp-a.md](metode-ipmvp-a.md).
|
||||
- **Hysteresetid minimum 60 sekunder** ved nivåendringer (DS-09 § 9.6.1). Den er et
|
||||
driftssikkerhetskrav, og den koster energi. Den er ikke valgfri, og tiltaket kan ikke regne den
|
||||
bort.
|
||||
- Lavlastsonen kan halveres etter 60 minutters stabil drift i store haller, dog ikke under
|
||||
1,00 på dagtid (DS-09 tabell 9.4, merknad). **Ikke modellert som besparelse her** — om
|
||||
driftssenteret kvalifiserer som «svært stort» er en vurdering kilden ikke avgjør for oss.
|
||||
- Budsjett og anskaffelsesrammer eies av deployer; her holdes de minimale.
|
||||
|
||||
## Kandidat-tiltak
|
||||
|
||||
- [tiltak-trinnstyring-kjoling.md](tiltak-trinnstyring-kjoling.md) —
|
||||
oppgradering fra 3-trinns kontaktorstyring til 13-trinns styring av hovedkjølingen.
|
||||
- [tiltak-kaldgangsinnkapsling.md](tiltak-kaldgangsinnkapsling.md) — passiv
|
||||
kaldgangsinnkapsling som senker varmetilskuddet og dermed kravet i høylastsonen.
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
---
|
||||
type: index
|
||||
okf_version: 0.1
|
||||
title: "Driftssenteret — trinnstyring av hovedkjølingen og kaldgangsinnkapsling"
|
||||
description: "OKF-bundle for kjølingen i et fiktivt driftssenter med to kandidat-tiltak: oppgradering fra 3-trinns til 13-trinns styring av hovedkjølingen, og passiv kaldgangsinnkapsling. Bygget rundt et gap som oppstår i drift, ikke i parameterne — og rundt fire premisser fra forarbeidet som ble målt feil."
|
||||
tags: [energieffektivisering, driftssenter, kjoling, kjolestyring, M&V, IPMVP, realiseringsgrad]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Driftssenteret
|
||||
|
||||
En OKF-bundle for **kjølingen i Eksempelvirksomhetens driftssenter**: ett anlegg, to
|
||||
kandidat-tiltak. Den deler lærings-overflate med klientpark- og bygg-bundlene, men står på egne
|
||||
ben: metode- og kildelaget er **materialisert inn her**, ikke lenket på tvers av bundler.
|
||||
|
||||
> Framework-nøytral artefakt (null kode-avhengighet). Den bor i pakkens `data/bundles/`, ikke i
|
||||
> den pull-only `shared/`-subtreet.
|
||||
|
||||
**Både prosjektlaget og litteraturlaget er fiktive.** Driftssenteret tilhører den oppdiktede
|
||||
«Eksempelvirksomheten»; geometrien, sonekravene og trinnrekkene det er bygget av er hentet fra
|
||||
virksomhetens egne — like oppdiktede — standarder og rapporter med årstall, merket `[V]` der de i
|
||||
fortellingen er verifisert. Ingen ekte organisasjon, publikasjon eller person er sitert. En
|
||||
produksjons-deployer erstatter begge lagene med en ekte kunnskapsbase og ekte kilder.
|
||||
|
||||
## Hvorfor kjøling
|
||||
|
||||
Domenet ble valgt fordi gapet mellom modellert og realisert besparelse her har **en annen
|
||||
årsak** enn i de to andre bundlene — og en lærings-sløyfe som bare har sett én årsak, har
|
||||
ikke lært noe generelt.
|
||||
|
||||
I kontorbygget og i klientparken er gapet en **parameterfeil**: driftstimene var
|
||||
overvurdert. Anlegget gjorde det det skulle; tallet vi matet inn var galt.
|
||||
|
||||
Her er parameterne kjent og modellen aritmetisk lukket. Gapet oppstår **i drift**: en
|
||||
hysterese standarden krever, en variabel soneutstrekning standarden ber om å få implementert, og
|
||||
en kalibreringsmargin ingen driftsorganisasjon setter for lavt. Utstyret kan levere; anlegget
|
||||
gjør det ikke. Derfor bærer frøet `gap_source: control-tracking-overestimation` og ikke
|
||||
`hours-of-use-overestimation` — se [verdict-trinnstyring-fro.md](verdict-trinnstyring-fro.md).
|
||||
|
||||
## ⛔ Fire premisser fra forarbeidet som ble målt feil
|
||||
|
||||
Bundelen ble bestilt på antakelsen om at driftssenteret hadde et **ekte eget ex-post-par** og
|
||||
dermed ikke trengte å låne sin realiseringsgrad slik klientpark-bundelen måtte. **Den antakelsen
|
||||
holdt ikke.** Tallene fra konsernprosjektet står under `MODEL INPUTS` og er modellerte, ikke
|
||||
målte; de gjelder søsterselskapets referanseanlegg, og Eksempelvirksomheten er medfinansiør av
|
||||
prosjektet, ikke datakilde; og prosjektlogg-sitatet om vifter på full hastighet gjelder
|
||||
byggefasen, ikke drift.
|
||||
|
||||
**Driftssenteret låner altså også sin rate.** Fullstendig oppgjør i
|
||||
[kilder-kjoling-realisering.md](kilder-kjoling-realisering.md).
|
||||
|
||||
Det som faktisk skiller denne bundelen fra klientpark-bundelen er tre andre ting: **geometrien
|
||||
og kravene er virksomhetens egne, daterte og normative** (Driftsstandard DS-09, april 2021, som
|
||||
beskriver tiltaket ved navn), **gap-mekanismen er en annen**, og **M&V-asymmetrien er omvendt** —
|
||||
her åpner ex-post seg i det tiltaket settes i drift, mens ex-ante lukket seg da anlegget ble
|
||||
bygget.
|
||||
|
||||
## Innhold (progressiv disclosure)
|
||||
|
||||
- [driftssenter-kjoling.md](driftssenter-kjoling.md) — `type: project` — anlegget,
|
||||
soneinndelingen, energibaselinen og rammene kjølekravene setter.
|
||||
- [tiltak-trinnstyring-kjoling.md](tiltak-trinnstyring-kjoling.md) —
|
||||
`type: hypothesis` — kandidat-tiltak 1: fra 3-trinns kontaktorstyring til 13-trinns
|
||||
styring av hovedkjølingen. **Det er dette tiltaket som er projisert inn i validatoren.**
|
||||
- [tiltak-kaldgangsinnkapsling.md](tiltak-kaldgangsinnkapsling.md) — `type: hypothesis` —
|
||||
kandidat-tiltak 2: passiv innkapsling som senker varmetilskuddet og dermed selve kravet. Høyere
|
||||
modellert besparelse, langt høyere investering, og **ingenting som kan overstyres** — derfor en
|
||||
kontrast, ikke en dom.
|
||||
- [metode-ipmvp-a.md](metode-ipmvp-a.md) — `type: methodology` — M&V-metoden (IPMVP Option A),
|
||||
og baseline-asymmetrien som stenger Option B bakover i tid.
|
||||
- [kilder-kjoling-realisering.md](kilder-kjoling-realisering.md) —
|
||||
`type: reference` — virksomhetens (fiktive) kilder, de fire korrigerte premissene, og
|
||||
metastudien realiseringsgraden er lånt fra.
|
||||
- [verdict-trinnstyring-fro.md](verdict-trinnstyring-fro.md) — `type: verdict` — frøsatt
|
||||
ekspert-dom. **ExpeL-frøet loopens steg 1 henter fra.**
|
||||
|
||||
## Hvordan den kjøres i dag
|
||||
|
||||
`validator-input.json` er IR-projeksjonen den eksisterende deterministiske validatoren
|
||||
konsumerer uendret; `cost-baseline.json` bærer det samme tallgrunnlaget som prosjektets
|
||||
kostdata. **De to filene er bygget fra samme linje aritmetikk og bærer identisk `code`,
|
||||
`quantity` og `unit_cost`** — se
|
||||
[tiltak-trinnstyring-kjoling.md](tiltak-trinnstyring-kjoling.md),
|
||||
§«Mapping til validatoren».
|
||||
|
||||
Bundelen ships **uten `golden.json`**, av samme grunn som klientpark-bundelen: den blokken er
|
||||
kryss-implementasjons-fasit produsert av en seedet Monte Carlo, og det finnes ingen kjørbar
|
||||
pipeline å produsere den med. En fasit ingen gate leser er verre enn ingen fasit.
|
||||
Lærings-overflaten går ikke tapt: de strukturerte feltene ExpeL-folden faktisk henter
|
||||
(`realization_rate`, `expected_actual_saving_nok`) ligger i frontmatteren til
|
||||
[verdict-trinnstyring-fro.md](verdict-trinnstyring-fro.md), som er der loopen leser dem.
|
||||
|
|
@ -0,0 +1,223 @@
|
|||
---
|
||||
type: reference
|
||||
title: "Kilder: kjøling, kjølestyring og realisering av styringsbesparelser"
|
||||
description: "Virksomhetens (fiktive) kilder bak driftssenter-bundelen. Egne, daterte standarder for geometri og krav; konsernprosjektets modellerte tall for kryss-sjekk; og metastudien realiseringsgraden er lånt fra. Fører også de fire premissene som ble målt FEIL i forarbeidet."
|
||||
resource: DRIFTSSENTER-KJOLING
|
||||
tags: [kilder, DS-09, B-500, ENTR, prisbok, MS-2011, IPMVP, provenienss]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Kilder
|
||||
|
||||
**Alle kildene i denne fila er fiktive.** De er dokumenter i den oppdiktede
|
||||
Eksempelvirksomheten og dens konsern — standarder, prisbøker, prosjektlogger og rapporter — og
|
||||
ingen av dem finnes utenfor denne bundelen. Ingen ekte organisasjon, publikasjon eller person er
|
||||
sitert.
|
||||
|
||||
Konvensjonen er den samme som i de øvrige bundlene: **`[V]` verifisert mot virksomhetens eget
|
||||
dokument, `[V-forankret]` utledet av en verifisert verdi, `[I]` illustrativt, `[U]`
|
||||
uverifisert.** Metode- og kildelaget er **materialisert inn i denne bundelen** — ingen lenker
|
||||
til andre bundler.
|
||||
|
||||
---
|
||||
|
||||
## ⛔ FIRE PREMISSER SOM BLE MÅLT FEIL — og som står korrigert her
|
||||
|
||||
Forarbeidet til denne bundelen bar fire påstander som **ikke holdt** da dokumentene ble hentet.
|
||||
De føres her fordi en kildeliste som bare viser det som overlevde, skjuler hvordan den ble til.
|
||||
|
||||
**1. ENTR-paret `150 059 → 33 114 kWh/år` er IKKE en måling.**
|
||||
Tallene står i D2.1 under overskriften **`MODEL INPUTS`**, som «Før tiltak» og
|
||||
«Etter tiltak», og resultatlinjen heter **`ASSESSMENT RESULTS: Energy saving potential
|
||||
116,945 kWh/year`**. Det er et **modellert ex-ante-anslag for et generisk referanseanlegg**
|
||||
(`>500 m², 2 haller, 2 kretser`), ikke et ex-post-par fra et virkelig anlegg.
|
||||
|
||||
**2. ENTR-tallene er IKKE driftssenterets egne.**
|
||||
D2.1 er skrevet av fire rådgivere i søsterselskapene og to innleide konsulenter (navnene er
|
||||
utelatt her). **Eksempelvirksomheten er medfinansiør** av konsernprosjektet sammen med fem
|
||||
søsterselskaper — ikke datakilde. Utbredelsen oppgis som «ca. 10 % i konsernet».
|
||||
|
||||
**3. Prosjektloggens «viftene på full hastighet» gjelder BYGGEFASEN.**
|
||||
Sitatet — «Viftene ble holdt på full hastighet mesteparten av tiden, så sparepotensialet ble
|
||||
ikke realisert» — står i avsnittet om **Bygg 2 under oppføring**, om byggtørking og
|
||||
støvavsug mens hallen ble reist. Det er byggventilasjon på en byggeplass, **ikke
|
||||
temperaturstyrt kjøling i et driftssenter i drift**. Årsaken er heller ikke den samme: på
|
||||
byggeplassen kjøres full hastighet for arbeidsmiljø og framdrift. **Mekanismen er derfor ikke
|
||||
båret over til driftsfasen i denne bundelen.**
|
||||
|
||||
**4. `≈ €400 000 per hall` er kostnaden for kaldgangsinnkapsling**, ikke for «kjøling ved
|
||||
hallinngang».
|
||||
|
||||
**Konsekvensen for bundelen, uttalt:** driftssenteret har **ingen egen ex-post-måling** av en
|
||||
realiseringsgrad. Raten er **lånt**, akkurat som i klientpark-bundelen, og lånet er merket i
|
||||
`provenance`. Det som skiller denne bundelen fra klientparken er ikke en egen måling — det er at
|
||||
**geometrien og kravene er virksomhetens egne, daterte og normative**, og at gap-mekanismen er
|
||||
en annen.
|
||||
|
||||
---
|
||||
|
||||
## Virksomhetens egne standarder [V]
|
||||
|
||||
### Eksempelvirksomheten, Driftsstandard DS-09 — «Teknisk planlegging av kjøling i tekniske rom»
|
||||
|
||||
**Veiledning, eiendomsavdelingen, april 2021.** Internt dokument, ikke publisert.
|
||||
|
||||
Dette er bundelens viktigste kilde. Den er intern, datert, normativ i virksomheten — og den
|
||||
beskriver tiltaket vårt ved navn.
|
||||
|
||||
| Ankeret | Ordrett / verdi | Sted |
|
||||
|---|---|---|
|
||||
| Soneinndeling | «Kjøleteknisk sett inndeles en serverhall i høylastsone, overgangssone, lavlastsone og utløpssone» | § 9.2 |
|
||||
| Høylastsonens dybde | **99 m² ved driftsklasse 80** (avstand aggregat → målepunkt for utetemperatur) | tabell 9.1 |
|
||||
| Krav høylastsone dag | **3,00 %** av IT-lasten per grad over frikjølingsgrensen (IT-last(10) < 4 000, driftsklasse 80) | tabell 9.4 |
|
||||
| Krav lavlastsone | 1,00 dag, 0,50 natt og kl. 00–05 (relativ kjøleleveranse, samme klasse) | tabell 9.4 |
|
||||
| Hardt gulv | «Tilluftmengden i høylastsonen skal ikke være under 50 m³/s» | tabell 9.4, merknad |
|
||||
| Kontinuerlig måling | «Utetemperaturen for kjøling i høylast- og overgangssonene **skal kontinuerlig måles** ved bruk av kalibrert temperaturmåler» *(normativ kilde: B-500)* | § 9.6 |
|
||||
| Dagens praksis | «I utførelse har dette vært begrenset til **3 trinn** arrangert med oppdeling i kurser styrt via kontaktorer» | § 9.6.1 |
|
||||
| Anbefalt tiltak | «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» | § 9.6.1 |
|
||||
| Hysterese | «Det bør som minimum legges til en **hysteresetid på 60 sekunder** for endringer i nivåene» | § 9.6.1 |
|
||||
| Restforutsetning | «Ved varierende trinn vil også **utstrekningen av høylastsonen variere**, og dette er viktig å få implementert for å utnytte energisparepotensialet mest mulig» | § 9.6.1 |
|
||||
| Energisynlighet ved frekvensstyring | «Måling av motorstrøm vil i tillegg gi mulighet for å følge med i aggregatets energiforbruk, samt innstilt nivå ved behovsstyrt regulering» | § 5.2, pkt. 3 |
|
||||
| Varmereduserende grep | luftinntak i skygge, skjermende vegetasjon, kaldgangsinnkapsling, blindplater, lyse flater på tak og yttervegger | § 9.2.1 |
|
||||
|
||||
**Ett anker til, fra IT-driftshåndboken, som gjelder klientparken og ikke driftssenteret — men
|
||||
som er verdt å notere presist:** håndboken sier at eldre arbeidsstasjoner **«i
|
||||
regionkontorene»** er «vanligvis umålte, og energikostnadene blir beregnet ut fra et bestemt
|
||||
antall brukstimer per år (4 000 – 4 100)». De 4 000–4 100 er altså **en avregningskonvensjon
|
||||
for umålt utstyr**, ikke en målt driftstimekurve — og teksten avgrenser dem til
|
||||
**regionkontorene**. Det er en presisering mot hvordan tallet ellers siteres.
|
||||
|
||||
### Eksempelvirksomheten, Byggstandard B-500 «Tekniske rom» [V — sekundært]
|
||||
|
||||
Normativ kilde for kjølekravene DS-09 gjengir. Sitert her via DS-09s egne
|
||||
marginhenvisninger, ikke hentet direkte.
|
||||
|
||||
---
|
||||
|
||||
## Interne kostnads- og anleggsdata [V, men udatert]
|
||||
|
||||
### Eiendomsavdelingens prisbok, publikasjon 4
|
||||
|
||||
Internt dokument, ikke publisert.
|
||||
|
||||
| Verdi | Ordrett |
|
||||
|---|---|
|
||||
| Andel rom med egen kjøling | «Bare 5 % av våre tekniske rom har egen kjøling (20 % av samlet areal)» |
|
||||
| Enhetspris kjøling | «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)» |
|
||||
|
||||
**⚠️ Prisen er IKKE brukt i `cost-baseline.json`, og grunnen skal stå:** publikasjonen er
|
||||
**udatert** i vårt uttrekk (den omtaler «mer enn 700 tekniske rom i virksomheten», et tall
|
||||
virksomheten passerte for mange år siden), og et beløp uten årstall kan ikke prisjusteres. Den
|
||||
dekker dessuten **hele kjøleanlegget** per m², mens vårt tiltak bytter **bare styringen**.
|
||||
Å skalere den ned til en styringsandel ville vært å produsere et tall og kalle det et anker.
|
||||
|
||||
### Prosjektlogg, publikasjon 13
|
||||
|
||||
Internt dokument, ikke publisert.
|
||||
|
||||
Brukt **kun** som korreksjon (se punkt 3 øverst). Beskriver byggventilasjon under oppføringen
|
||||
av Bygg 1 og Bygg 2: to vifter à 230–250 kW, ca. 100 m³/s, PLS-styring på støv og lufttrykk.
|
||||
**Ingen av tallene er brukt i bundelen.**
|
||||
|
||||
---
|
||||
|
||||
## Konsernets modellerte tall (kryss-sjekk) [V som modell, ikke som måling]
|
||||
|
||||
### Konsernprosjektet ENTR, leveranse D2.1 — «Vurdering av tiltak med potensial for energireduksjon»
|
||||
|
||||
**Leveranse 2.1, februar 2015.** Konsernprosjektet ENTR (energi i tekniske rom), finansiert av
|
||||
Eksempelvirksomheten og fem søsterselskaper. Internt dokument, ikke publisert.
|
||||
|
||||
Referanseanlegg for begge tiltak: **`>500 m², 2 haller, 2 kretser`**.
|
||||
|
||||
| Tiltak | Før | Etter | Reduksjon | Kostnad | Utbredelse |
|
||||
|---|---|---|---|---|---|
|
||||
| Innkapsling/skjermer ved rackradene (senker varmetilskuddet) | 150 059 kWh/år | 33 114 kWh/år | **77,9 %** | «ca. €400k per hall» | «ca. 10 % i konsernet» |
|
||||
| Frekvensstyrt kjøling med «lukket» tilbakekobling | 158 059 kWh/år | 136 893 kWh/år | **13,4 %** | «ca. €35k per kjølekrets» | «ca. 15 % (mest i to søsterselskaper)» |
|
||||
|
||||
**⚠️ Felle i kilden:** de to tiltakene oppgir **ulik** baseline før tiltak for nominelt
|
||||
samme referanseanlegg — **150 059** mot **158 059**. Baselinen er ikke felles på tvers av
|
||||
tiltakene i D2.1, og de to radene kan ikke settes i samme regnestykke. Bundelen setter dem
|
||||
ikke sammen.
|
||||
|
||||
---
|
||||
|
||||
## Realiseringsgraden — hvor den er lånt fra [V, men LÅNT]
|
||||
|
||||
### Eksempelvirksomheten, internrapport MS-2011 — «Metaanalyse av energibesparelser fra styring i egne kontorbygg»
|
||||
|
||||
Energiavdelingens analysegruppe (navnene er utelatt her). **September 2011.** Internt dokument,
|
||||
ikke publisert.
|
||||
|
||||
**240 besparelsesanslag fra 88 prosjektrapporter og case**, sortert på styringsstrategi og
|
||||
deretter filtrert suksessivt for å avdekke skjevheter i analysemetoden.
|
||||
|
||||
For **utetemperaturstyrt regulering** — styring som følger forholdene ute, som er nøyaktig
|
||||
strategien i vårt tiltak:
|
||||
|
||||
| Filter | Gjennomsnittlig besparelse | n |
|
||||
|---|---|---|
|
||||
| Kun styringstiltak | 39 % | 73 |
|
||||
| Kun energi til det styrte utstyret | 39 % | 73 |
|
||||
| **Kun faktiske installasjoner** | **28 %** | **32** |
|
||||
|
||||
Rapportens egne konklusjoner, ordrett:
|
||||
|
||||
> «de beste anslagene på gjennomsnittlig sparepotensial er 24 % for tilstedeværelsesstyring,
|
||||
> **28 % for utetemperaturstyring**, 31 % for individuell innstilling, 36 % for sentral
|
||||
> innstilling og 38 % for kombinasjoner»
|
||||
|
||||
> «Resultatene tyder på at **simuleringer overvurderer betydelig (med minst 10 %) den
|
||||
> gjennomsnittlige besparelsen utetemperaturstyring gir i faktiske bygg.**»
|
||||
|
||||
> «energibeslutninger og besparelsesanslag bør ikke bygge på simuleringer alene, men bør
|
||||
> inkludere feltmåling eller i det minste **nedjustering av besparelser predikert fra
|
||||
> simuleringer**»
|
||||
|
||||
**Forholdet 28 / 39 = 0,718** er ankeret realiseringsgraden **0,72** er lånt fra.
|
||||
|
||||
**Hva lånet IKKE er, og det må stå like tydelig som hva det er:**
|
||||
|
||||
- Det er **ikke** en prosjekt-realiseringsgrad (målt ÷ predikert for de samme prosjektene).
|
||||
Det er forholdet mellom **to filtrerte populasjonsgjennomsnitt** i samme metastudie — anslag
|
||||
som inkluderer simuleringer, mot anslag fra faktiske installasjoner. Antallet faller fra
|
||||
73 til 32 mellom de to.
|
||||
- Det gjelder **kontorbygg**, ikke serverhaller. Utetemperaturstyring av ventilasjonen i et
|
||||
kontorlokale og av hovedkjølingen i et driftssenter deler mekanisme og feilmodus, men ikke
|
||||
geometri, krav eller driftsorganisasjon.
|
||||
- Det er **fra 2011**.
|
||||
|
||||
Lånet er valgt fordi det er den nærmeste treffende kilden vi har: **samme styringsstrategi**
|
||||
(utetemperaturstyrt regulering), og et eksplisitt, tallfestet funn om at modellerte anslag
|
||||
ligger over det faktiske installasjoner leverer. **Det finnes ingen ex-post-evaluering av
|
||||
realiseringsgrad for kjølestyring i driftssenteret i materialet vårt.**
|
||||
|
||||
---
|
||||
|
||||
## Metoderammeverk [V]
|
||||
|
||||
### IPMVP
|
||||
|
||||
**International Performance Measurement and Verification Protocol**, et utbredt
|
||||
metoderammeverk. De fire opsjonene (A/B/C/D) og utgangspunktet om at besparelse er fravær av
|
||||
energibruk er gjengitt i [metode-ipmvp-a.md](metode-ipmvp-a.md).
|
||||
|
||||
### Virksomhetens M&V-veileder — måleterskel
|
||||
|
||||
Veiledningen om at en besparelse bør overstige **~10 % av baseline** for å skilles pålitelig
|
||||
fra støy i en hovedmåler. Brukt i [metode-ipmvp-a.md](metode-ipmvp-a.md).
|
||||
|
||||
---
|
||||
|
||||
## Kilder som er vurdert og IKKE brukt
|
||||
|
||||
- **Et konferanseinnlegg om energisparing i driftssentre (i virksomhetens arkiv)** — oppga
|
||||
236–453 MWh/år for et helt anlegg. Uttrekk feilet (arkivet utilgjengelig), tallet er udatert,
|
||||
og bundelen bygger sin egen baseline fra parametere. **Ikke brukt.**
|
||||
- **En masteroppgave i virksomhetens arkiv** — «opptil 40 %» modellert for adaptiv
|
||||
ventilasjonsstyring i kontorlokaler. Kontorventilasjon er ikke et tiltak i denne bundelen.
|
||||
**Ikke brukt.**
|
||||
- **En leverandørs referansecase fra et annet driftssenter** — relevant anleggstype, men
|
||||
leverandørkilde. **Ikke brukt.**
|
||||
- **Et britisk prisanslag i materialet** — £1 000 per 50 m² for ettermontert trinnstyring.
|
||||
Udatert i materialet og gjelder et annet marked. **Ikke brukt.**
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
---
|
||||
type: methodology
|
||||
title: "IPMVP Option A for kjølestyring — anlegget måler inngangssignalet, ikke energien"
|
||||
description: "M&V-metoden for å verifisere besparelsen fra en styringsoppgradering i driftssenteret. Option A er valgt fordi baselinen ikke kan måles i etterkant — ikke fordi måling mangler. Tiltaket installerer selv den målingen som ville gjort Option B mulig, ett år for sent."
|
||||
methodology: IPMVP
|
||||
option: A
|
||||
tags: [IPMVP, M&V, retrofit-isolation, kjoling, baseline-asymmetri]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# M&V-metode: IPMVP Option A for en styringsoppgradering
|
||||
|
||||
**IPMVP** (International Performance Measurement and Verification Protocol) er et utbredt
|
||||
metoderammeverk for å måle og verifisere energibesparelser. Kjerneinnsikten som begrunner hele
|
||||
lærings-sløyfa er metodens eget utgangspunkt: besparelse kan ikke måles direkte, fordi den er
|
||||
**fravær** av energibruk.
|
||||
|
||||
Besparelse er en **kontrafaktisk** størrelse — det finnes ingen måler for «det som ikke ble
|
||||
brukt». Den *beregnes*: `Baseline-energi − Rapporterings-energi ± justeringer` (metodens
|
||||
grunnligning).
|
||||
|
||||
## De fire opsjonene (metodens egne navn)
|
||||
|
||||
- **Option A — Retrofit Isolation: Key Parameter Measurement.** Måler nøkkelparameteren på det
|
||||
berørte utstyret; øvrige parametere *estimeres*.
|
||||
- **Option B — Retrofit Isolation: All Parameter Measurement.** Måler alle relevante parametere.
|
||||
- **Option C — Whole Facility.** Besparelse fra anleggets hovedmåler, med rutinejustering.
|
||||
- **Option D — Calibrated Simulation.** Besparelse via simuleringsmodell kalibrert mot måledata.
|
||||
|
||||
## Asymmetrien som avgjør valget
|
||||
|
||||
Driftssenteret er **ikke** et umålt anlegg. DS-09 § 9.6 stiller et normativt krav:
|
||||
|
||||
> «Utetemperaturen for kjøling i høylast- og overgangssonene skal kontinuerlig måles ved bruk
|
||||
> av kalibrert temperaturmåler.» *(normativ kilde: Byggstandard B-500)*
|
||||
|
||||
Anlegget måler altså **kontinuerlig** — men det måler **inngangssignalet** (T20 ved
|
||||
luftinntaket), ikke energien. Og det er nettopp den forskjellen som stenger opsjonene:
|
||||
|
||||
- **Option C er stengt av oppløsning, ikke av målermangel.** Driftssenteret har hovedmåler, men
|
||||
kjølingen er 95 % av forbruket sammen med lavlastsonen, pumper og øvrige anlegg på samme
|
||||
linje. Et tiltak på **10,00 %** av totalen skal skilles fra sesongvariasjon i pumpedrift og
|
||||
avfukting på den samme måleren. Signalet drukner ikke helt — men det er ikke et rent kutt.
|
||||
- **Option D er stengt av kalibreringsdata.** En simulering av hovedkjølingen må kalibreres mot
|
||||
en målt T20-fordeling over året. Temperaturmåleren produserer den dataen **i sanntid for
|
||||
styringsformål**, men ingen kilde i materialet dokumenterer at den **logges og lagres**.
|
||||
Uten historikk finnes det ingenting å kalibrere mot.
|
||||
- **Option B er stengt bakover i tid, ikke framover.** Og det er den interessante.
|
||||
|
||||
## Baseline-asymmetrien
|
||||
|
||||
Nøkkelparameteren for dette tiltaket er **midlere servert nivå over året** — hvor høyt
|
||||
styringen faktisk legger seg i forhold til kjølekurven.
|
||||
|
||||
- **Etter tiltaket kan den måles.** DS-09 § 5.2 punkt 3 beskriver det selv: med
|
||||
frekvensomformere gir «Måling av motorstrøm (…) i tillegg mulighet for å følge med i
|
||||
aggregatets energiforbruk, samt innstilt nivå ved behovsstyrt regulering».
|
||||
- **Før tiltaket kan den ikke måles.** Dagens 3-trinns kontaktorstyring kobler kurser av og på.
|
||||
Den har ingen omformer som rapporterer nivå, og den logger ikke hvilket trinn som sto inne når.
|
||||
|
||||
**Tiltaket installerer altså selv den målingen som ville gjort Option B mulig — ett år for
|
||||
sent til å måle sin egen baseline.** Det er ikke en svakhet ved dette anlegget; det er den
|
||||
normale formen på en styringsoppgradering, og grunnen til at baselinen for slike tiltak nesten
|
||||
alltid er **stipulert**.
|
||||
|
||||
**Kontrast verdt å merke seg:** i en umålt klientpark er ex-post *permanent* stengt. Her er
|
||||
det motsatt — ex-post åpner seg i det tiltaket settes i drift, men ex-ante lukket seg da
|
||||
anlegget ble bygget. Realiseringsgapet overlever begge veier, av motsatte grunner.
|
||||
|
||||
## Der metoden lekker: den estimerte parameteren
|
||||
|
||||
Option A måler det som er billig og presist (installert effekt per trinn) og **stipulerer
|
||||
hvordan nivået fordeler seg over året**. For dette tiltaket er stipulatet svakt på et bestemt
|
||||
punkt:
|
||||
|
||||
Modellen i [tiltak-trinnstyring-kjoling.md](tiltak-trinnstyring-kjoling.md)
|
||||
antar at kravnivået er **jevnt fordelt** over trinnrekkens spenn. Den antakelsen er ikke
|
||||
verifisert, og **ingen kilde i materialet gir en målt T20-fordeling over året.** Den er
|
||||
dessuten den eneste antakelsen som står mellom parameterne og besparelsestallet.
|
||||
|
||||
## Måleterskelen
|
||||
|
||||
Virksomhetens M&V-veileder sier at en besparelse bør overstige **~10 % av baseline** for å
|
||||
skilles pålitelig fra støy. Tiltaket ligger på **10,00 %** av driftssenterets totale forbruk —
|
||||
bokstavelig talt på terskelen — og **18,6 %** av hovedkjølingen, altså godt over hvis man måler
|
||||
på riktig avgrensning.
|
||||
|
||||
Det er en grunn til at avgrensningen betyr noe her og ikke bare i validator-mappingen: målt
|
||||
på hovedmåleren er tiltaket akkurat i grenseland, målt på hovedkjølingens egen kurs er det
|
||||
tydelig. **Å legge en kursmåler på hovedkjølingen samtidig med styringen er derfor det billigste
|
||||
enkelttiltaket for å gjøre dette anlegget lærbart** — det gjør Option B tilgjengelig for *neste*
|
||||
tiltak.
|
||||
|
||||
## Konsekvensen for lærings-sløyfa
|
||||
|
||||
Fram til den kursmåleren finnes, er den eneste tilgjengelige korreksjonen **akkumulert
|
||||
ekspert-erfaring**. Se [verdict-trinnstyring-fro.md](verdict-trinnstyring-fro.md) og
|
||||
[kilder-kjoling-realisering.md](kilder-kjoling-realisering.md).
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
---
|
||||
type: hypothesis
|
||||
title: "Kaldgangsinnkapsling: senke varmetilskuddet i stedet for å styre kjølingen bedre"
|
||||
description: "Passivt tiltak som skiller kald og varm luft i serverhallen og dermed senker selve kravet i høylastsonen. Svært høy modellert besparelse, svært høy investering, og — i motsetning til styringstiltaket — ingenting som kan overstyres i drift."
|
||||
resource: DRIFTSSENTER-KJOLING
|
||||
measure_id: KJOLING-02
|
||||
tags: [kjoling, kaldgang, innkapsling, passivt-tiltak, ENTR]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Tiltak: kaldgangsinnkapsling
|
||||
|
||||
Kravet i høylastsonen er ikke et fast kjølenivå — det er en **prosentandel av varmetilskuddet
|
||||
over frikjølingsgrensen** (DS-09 tabell 9.4: 3,00 % for driftssenterets last- og
|
||||
driftsklasse). Senker man varmetilskuddet som når kjøleaggregatene, senker man kravet, og da
|
||||
faller energibehovet uten at noe styres bedre.
|
||||
|
||||
DS-09 § 9.2.1 lister virkemidlene direkte:
|
||||
|
||||
> «Varmetilskuddet i høylastsonen kan reduseres ved å: Legge luftinntaket slik at det får
|
||||
> minst mulig direkte sol. Plante skjermende vegetasjon foran luftinntaket. Bygge innkapsling av
|
||||
> kaldgangene som gradvis skiller kald og varm luft. Montere blindplater i alle tomme
|
||||
> rackplasser. Benytte lyse, reflekterende flater på tak og yttervegger.»
|
||||
|
||||
Og standarden sier hvorfor det er verdt å gjøre: dette «kan både øke driftssikkerheten og
|
||||
redusere energiforbruket og kostnadene til kjøling».
|
||||
|
||||
## Hvorfor dette tiltaket står her uten å være dømt
|
||||
|
||||
**Det er en kontrast, og kontrasten er hele poenget.**
|
||||
|
||||
| | Trinnstyring (KJOLING-01) | Kaldgangsinnkapsling (KJOLING-02) |
|
||||
|---|---|---|
|
||||
| Type | aktiv styring | **passivt byggverk** |
|
||||
| Modellert reduksjon | 18,6 % av hovedkjølingen | **77,9 %** av høylastsonen (ENTR) |
|
||||
| Investering | ingen kilde bærer | **≈ €400 000 per hall** (ENTR) |
|
||||
| Kan overstyres i drift? | **Ja** — og det er hele realiseringsrisikoen | **Nei. Det finnes ingenting å overstyre.** |
|
||||
|
||||
En innkapsling som skiller kald og varm luft, gjør det hver eneste dag uten at noen gjør noe.
|
||||
Den har ingen hysterese, ingen kalibrering, ingen driftsrutine som kan tolkes forsiktig.
|
||||
**Realiseringsgapet styringstiltaket har, har dette tiltaket i praksis ikke** — og det er nettopp
|
||||
derfor det ikke kan arve dommen i [verdict-trinnstyring-fro.md](verdict-trinnstyring-fro.md).
|
||||
|
||||
Risikoprofilen er en helt annen, ikke en mildere versjon av den samme: her ligger usikkerheten
|
||||
i **byggekostnad og gjennomførbarhet**, ikke i om anlegget brukes som forutsatt.
|
||||
|
||||
## Tallene, og hva de faktisk er
|
||||
|
||||
ENTR D2.1 modellerer tiltaket «redusert varmetilskudd i høylastsonen» via innkapsling eller
|
||||
skjermer ved rackradene:
|
||||
|
||||
> Før tiltak: **150 059 kWh/år** (høylastsoner)
|
||||
> Etter tiltak: **33 114 kWh/år** (høylastsoner)
|
||||
> Energisparepotensial: **116 945 kWh/år** — altså **77,9 %**
|
||||
|
||||
**⛔ Disse tallene er IKKE en måling.** De står i D2.1 under overskriften `MODEL INPUTS`, og
|
||||
resultatlinjen heter `ASSESSMENT RESULTS: Energy saving potential`. Det er et **modellert
|
||||
ex-ante-anslag for et generisk referanseanlegg** — ikke et ex-post-par fra et virkelig anlegg,
|
||||
og ikke vårt. Se
|
||||
[kilder-kjoling-realisering.md](kilder-kjoling-realisering.md), som fører
|
||||
provenienssen i sin helhet.
|
||||
|
||||
**Tiltaket er ikke regnet om til driftssenterets tall, og det er med vilje.** D2.1s baseline for
|
||||
dette tiltaket (150 059) er en annen enn baselinen for styringstiltaket (158 059) på nominelt
|
||||
samme referanseanlegg. Å skalere 77,9 % ned på vår hovedkjøling ville vært å låne en
|
||||
prosentandel fra en baseline som ikke er vår, og presentere resultatet som vårt eget
|
||||
regnestykke.
|
||||
|
||||
## Hvorfor det ikke er projisert inn i validatoren
|
||||
|
||||
To grunner, og den andre er den viktige:
|
||||
|
||||
1. **Kostnadssiden ville dominert.** €400 000 per hall, for to haller, mot en besparelse
|
||||
i størrelsesorden hundretusen kroner i året. Tilbakebetalingstiden er ikke marginal — den
|
||||
er utenfor det en energibegrunnelse bærer alene. Tiltaket bygges i praksis når hallen
|
||||
uansett skal bygges eller rehabiliteres; D2.1 sier det selv: «Kostnaden vil inngå i
|
||||
byggekostnaden for hallen».
|
||||
2. **Det har ingen lærings-overflate.** Bundelen finnes for å frø en lærings-sløyfe med et
|
||||
gap mellom modellert og realisert. Et passivt byggverk uten driftsavhengighet har
|
||||
knapt noe slikt gap å lære av. Det gjør det til en dårlig kandidat for et verdict-frø —
|
||||
og til en god kontrast som viser hvorfor det *andre* tiltaket trenger ett.
|
||||
|
|
@ -0,0 +1,167 @@
|
|||
---
|
||||
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.
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
{
|
||||
"_note": "IR-projeksjon (ir.SavingsProposal) for det eksisterende deterministiske validatoren. Styringstiltaket er mappet inn i kost-IR-en UENDRET: affected_items = HELE driftssenterets arlige energikostnad (hovedkjoling 180 000 + lavlast-/utlopssone 139 230 + ovrige tekniske anlegg 16 020 = 335 250 kWh/ar a 1,00 NOK/kWh); claimed_saving_nok = modellert besparelse fra kvantiseringsmodellen (60 kW x (0,6667 - 0,5425) x 4 500 t = 33 525 kWh/ar), som er 10,00 % av total og godt innenfor 30 %-cap-en. Forholdet claimed/nominal_feasible = 33 525/100 575 = 1/3 eksakt. affected_items er anleggets TOTALE forbruk og ikke bare hovedkjolingen fordi ett anleggs totale energikostnad er den riktige analogien til en portefolje - se klientpark-bundelen, som tok samme beslutning. assumptions = energipris-band (NOK/kWh) for Monte Carlo. cost-baseline.json baerer IDENTISK code, quantity og unit_cost - begge er skrevet fra samme sum, ikke avstemt i ettertid. Se tiltak-trinnstyring-kjoling.md, seksjon 'Mapping til validatoren'.",
|
||||
"project_id": "DRIFTSSENTER-KJOLING",
|
||||
"measure": "Oppgradering av hovedkjolingen fra 3-trinns kontaktorstyring til 13-trinns styring (Driftsstandard DS-09 2021, par. 9.6.1). Aggregatene byttes ikke - reguleringen byttes.",
|
||||
"affected_items": [
|
||||
{
|
||||
"code": "ENERGI-DRIFTSSENTER-EL",
|
||||
"quantity": 335250,
|
||||
"unit_cost": 1.0
|
||||
}
|
||||
],
|
||||
"claimed_saving_nok": 33525,
|
||||
"assumptions": {
|
||||
"ENERGI-DRIFTSSENTER-EL": [0.70, 1.40]
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,139 @@
|
|||
---
|
||||
type: verdict
|
||||
title: "Ekspert-dom (frø): 13-trinns styring av hovedkjølingen — godkjent med realiseringskorreksjon"
|
||||
description: "Frøsatt ekspert-dom for styringsoppgraderingen. Den modellerte besparelsen er korrekt fra trinnrekkene, men den forutsetter at reguleringen faktisk følger kjølekurven i drift. Tre navngitte mekanismer i Driftsstandard DS-09 selv trekker den andre veien. Forventet faktisk besparelse settes til 72 % av modellert, lånt fra virksomhetens metastudie av styring og merket som lån."
|
||||
resource: DRIFTSSENTER-KJOLING
|
||||
measure_id: KJOLING-01
|
||||
decision: approved_with_adjustment
|
||||
realization_rate: 0.72
|
||||
modelled_saving_nok: 33525
|
||||
expected_actual_saving_nok: 24138
|
||||
gap_source: control-tracking-overestimation
|
||||
context_key: "kjoling; styring=3-trinn->13-trinn; T20-maaling=kontinuerlig-paakrevd; energimaaling=fravaerende-i-baseline"
|
||||
provenance: "frø — AI-forfattet, fiktiv virksomhet. Realiseringsgraden er LÅNT fra Eksempelvirksomhetens (fiktive) internrapport MS-2011: utetemperaturstyring faller fra 39 % til 28 % gjennomsnittlig besparelse når anslagene filtreres til faktiske installasjoner (n 73 -> 32), forhold 0,718. Det er IKKE en prosjekt-realiseringsgrad, men forholdet mellom to filtrerte populasjonsgjennomsnitt, fra kontorbygg. Det finnes INGEN ex-post-evaluering for kjolestyring i driftssenteret. Erstattes av ekte HITL i produksjon."
|
||||
tags: [verdict, realization-rate, ExpeL-seed, HITL, kjoling, kjolestyring, laant-rate]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Ekspert-dom (frø): 13-trinns styring av hovedkjølingen
|
||||
|
||||
> **Dette er et frø**, ikke en ekte dom. I simulering gir en ekspert-persona slike dommer;
|
||||
> i produksjon gir et menneske dem via samme mappe-grensesnitt. Frøet er forankret i
|
||||
> virksomhetens (fiktive) kilder ([kilder-kjoling-realisering.md](kilder-kjoling-realisering.md)),
|
||||
> ikke fritt oppdiktet innenfor fortellingen — men **raten er lånt, ikke målt på
|
||||
> driftssenteret**, og det står i `provenance`.
|
||||
|
||||
## Dommen
|
||||
|
||||
**Beslutning:** godkjent — med realiseringskorreksjon.
|
||||
|
||||
Den modellerte besparelsen (**33 525 NOK/år**) er korrekt regnet fra de to trinnrekkene, og
|
||||
validatoren bekrefter at den ligger innenfor feasibelt område. Men modellen regner på hvordan
|
||||
en trinnrekke **kan** legge seg mot kjølekurven, og et anlegg i drift legger seg systematisk
|
||||
høyere. Forventet faktisk besparelse settes til **≈ 24 138 NOK/år** (72 % av modellert).
|
||||
|
||||
## Begrunnelse (det validatoren ikke kan regne)
|
||||
|
||||
### Hovedmekanismen: modellen regner på trinn, driften leverer et forløp
|
||||
|
||||
Kvantiseringsmodellen i
|
||||
[tiltak-trinnstyring-kjoling.md](tiltak-trinnstyring-kjoling.md) antar at
|
||||
regulatoren til enhver tid står på **det laveste trinnet som er ≥ kravet**. Det er sant for en
|
||||
regulator uten treghet. DS-09 forutsetter tre former for treghet — og alle tre er
|
||||
**standardens egne krav eller forbehold**, ikke svakheter ved et bestemt anlegg:
|
||||
|
||||
**1. Hysteresen er påkrevd, og den koster.**
|
||||
DS-09 § 9.6.1: «Det bør som minimum legges til en **hysteresetid på 60 sekunder** for endringer
|
||||
i nivåene.» Hysterese er asymmetrisk i energi: den holder anlegget på det **høyere** trinnet
|
||||
gjennom svingninger i T20 som ellers ville utløst nedtrinn. På en dag med vekslende sol og skyer
|
||||
er det ikke en marginal effekt. Kravet er et driftssikkerhetskrav og kan ikke regnes bort.
|
||||
|
||||
**2. Den variable soneutstrekningen implementeres ofte ikke.**
|
||||
DS-09 § 9.6.1, siste setning: «Ved varierende trinn vil også utstrekningen av høylastsonen
|
||||
variere, og dette er viktig å få implementert for å utnytte energisparepotensialet **mest
|
||||
mulig**.» At standarden finner det nødvendig å be om dette, forteller at det er den delen som
|
||||
faller ut. **Halvparten av gevinsten ved fin trinning ligger i at sonen også blir mindre når
|
||||
kravet faller** — implementeres bare nivåtrinningen, leveres bare den ene halvparten.
|
||||
|
||||
**3. Kalibreringen er en driftsrutine, ikke en konstant.**
|
||||
DS-09 § 9.6: «Innjustering av anlegg ved igangkjøring med kalibrert måleinstrument for korrekte
|
||||
nivåer for utetemperatur er viktig for korrekt drift.» En temperaturmåler som drifter, står i
|
||||
sol, eller er innjustert med sikkerhetsmargin, gir en for høy T20 — og en for høy T20 gir et for
|
||||
høyt trinn hver time resten av året. Feilen er **systematisk og ensrettet**: ingen
|
||||
driftsorganisasjon kalibrerer seg til for lite kjøling i en serverhall.
|
||||
|
||||
### Hvorfor raten er lånt fra utetemperaturstyring, og hva lånet er
|
||||
|
||||
Internrapport MS-2011 sorterte 240 besparelsesanslag fra 88 prosjektrapporter og filtrerte dem
|
||||
suksessivt. For **utetemperaturstyrt regulering** — samme strategi som vår — falt gjennomsnittet
|
||||
fra **39 %** til **28 %** når utvalget ble begrenset til **faktiske installasjoner**
|
||||
(n fra 73 til 32). Rapporten konkluderer at «simuleringer overvurderer betydelig (med minst
|
||||
10 %) den gjennomsnittlige besparelsen utetemperaturstyring gir i faktiske bygg».
|
||||
|
||||
**Forholdet 28/39 = 0,718 er lånet. 0,72 er dette lånet, ikke en måling av driftssenteret.**
|
||||
|
||||
Og lånet er svakere enn klientpark-bundelens på ett punkt og sterkere på et annet:
|
||||
**svakere** fordi det ikke er en prosjekt-realiseringsgrad (målt ÷ predikert for de samme
|
||||
prosjektene), men forholdet mellom to filtrerte populasjonsgjennomsnitt; **sterkere** fordi
|
||||
styringsstrategien er den samme — det er forholdene ute som styrer i begge tilfeller, og det er
|
||||
sensor, kalibrering og treghet som spiser gevinsten i begge tilfeller.
|
||||
|
||||
### Motmekanismen — og hvorfor den IKKE er trukket fra
|
||||
|
||||
Én forhold peker **motsatt vei**, og det er modellens egen antakelse: kravnivået er antatt
|
||||
**jevnt fordelt** over trinnrekkens spenn. Ved driftssenterets luftinntak er T20 skjevfordelt
|
||||
mot **lave** verdier store deler av året — vinter, natt, kalde overskyede dager — og i det
|
||||
området ligger de fine trinnene tettest (5-10-15-20-25-30 %). Der hjelper 13-trinnsrekka **mer**
|
||||
enn jevnfordelingen tilsier, ikke mindre. Med en realistisk T20-fordeling ville den modellerte
|
||||
besparelsen trolig vært **høyere** enn 33 525.
|
||||
|
||||
Den er likevel ikke netto-regnet inn, av én grunn: **ingen kilde i materialet gir en målt
|
||||
T20-fordeling over året.** Å justere modellen opp på en fordeling vi ikke har, for så å
|
||||
justere den ned igjen med en lånt rate, ville vært to gjetninger som later som de opphever
|
||||
hverandre.
|
||||
|
||||
**Derfor er 0,72 beheftet med usikkerhet i BEGGE retninger**, og det skiller den fra
|
||||
klientpark-frøets 0,81, som var en uttalt **nedre** grense. Her vet vi ikke hvilken vei feilen
|
||||
peker — bare at den er der.
|
||||
|
||||
### Hvorfor dette ikke kan regnes fra parameterne
|
||||
|
||||
Du kan **ikke** regne deg til RR = 0,72 fra `{60 kW, 4 500 t, 3 trinn, 13 trinn}`. Alle fire
|
||||
er kjent, og modellen som forbinder dem er aritmetisk lukket. Skjevheten ligger i **hvordan
|
||||
et anlegg faktisk driftes** — hysterese, uimplementert soneutstrekning, kalibreringsmargin — og
|
||||
det er epistemikk parameterne ikke bærer. Det er nøyaktig lærings-overflaten bundelen er
|
||||
bygget for.
|
||||
|
||||
## Lærings-signalet (ExpeL)
|
||||
|
||||
Korreksjonen er **kontekstbetinget**:
|
||||
`context_key = "kjoling; styring=3-trinn->13-trinn; T20-maaling=kontinuerlig-paakrevd; energimaaling=fravaerende-i-baseline"`.
|
||||
|
||||
`gap_source` er satt til **`control-tracking-overestimation`** — og det er **bevisst en annen
|
||||
nøkkel enn `hours-of-use-overestimation`**, som både kontorbygg- og klientpark-frøet bruker.
|
||||
Forskjellen er ikke kosmetisk:
|
||||
|
||||
- `hours-of-use-overestimation` er en **parameterfeil**. Anlegget gjør det det skal; tallet
|
||||
vi matet inn var galt. Korreksjonen er å måle parameteren bedre.
|
||||
- `control-tracking-overestimation` er en **driftsfeil**. Parameterne er riktige; anlegget
|
||||
leverer ikke det utstyret er i stand til. Korreksjonen er å endre idriftsettelse,
|
||||
kalibreringsrutine og hva som faktisk implementeres.
|
||||
|
||||
**En lærings-sløyfe som slår disse sammen, lærer feil tiltak.** Å måle driftstimer bedre
|
||||
hjelper ikke et anlegg som står på for høyt trinn, og å kalibrere temperaturmåleren hjelper
|
||||
ikke et anlegg med feil timeanslag. De to nøklene skal leve side om side.
|
||||
|
||||
Neste kjøring, gitt en lignende hypotese i samme kontekst, skal hente denne dommen og justere
|
||||
den modellerte ex-ante-besparelsen mot forventet ex-post (≈ 0,72×).
|
||||
|
||||
## Om tiltak 2 (kaldgangsinnkapsling)
|
||||
|
||||
Denne dommen gjelder **kun** styringsoppgraderingen (`KJOLING-01`). Kaldgangsinnkapslingen
|
||||
([tiltak-kaldgangsinnkapsling.md](tiltak-kaldgangsinnkapsling.md)) er ikke dømt her, og **skal
|
||||
ikke arve raten** — den skal ikke engang arve `gap_source`.
|
||||
|
||||
Grunnen er strukturell: en innkapsling som skiller kald og varm luft, har **ingenting som kan
|
||||
overstyres**. Den har ingen hysterese, ingen kalibrering og ingen driftsrutine. Alle tre
|
||||
mekanismene som begrunner 0,72 er fraværende. Et passivt tiltak med samme `gap_source` som et
|
||||
aktivt ville vært en kategorifeil i lærings-sløyfa — og risikoen der ligger et helt annet sted,
|
||||
i byggekostnad og gjennomførbarhet.
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
{
|
||||
"_note": "Prosjektets kostdata for KLIENTPARK-ENERGI, i det formatet den konsumerende implementasjonen definerer (dens akse - bundelen normerer ikke dette formatet). Raden er portefoeljens arlige energikostnad: 9 500 arbeidsstasjoner x 114 W installert (100 W systemenhet + 14 W stromforsyningstap, innkjopsspesifikasjonen) x 4 050 driftstimer/ar (IT-driftshandboken, 2021: 4 000-4 100 t/ar for eldre arbeidsstasjoner) / 1 000 = 4 386 150 kWh/ar, a 1,00 NOK/kWh eks. mva. quantity og unit_cost er BYTE-IDENTISKE med affected_items-raden i validator-input.json fordi begge filene er skrevet fra denne ene linjen - 5 %-toleransen er lukket ved konstruksjon, ikke ved avstemming. Investeringskostnad er BEVISST utelatt: ingen kilde i materialet gir NOK per arbeidsstasjon eller per styringslisens, og en utledet verdi hoerer ikke hjemme i en kostbase. Alle kilder er fiktive (Eksempelvirksomheten). Se klientpark-energi.md og tiltak-pc-utskifting.md.",
|
||||
"project_id": "KLIENTPARK-ENERGI",
|
||||
"items": {
|
||||
"ENERGI-KLIENTPARK-EL": {
|
||||
"quantity": 4386150,
|
||||
"unit_cost": 1.0
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
---
|
||||
type: index
|
||||
okf_version: 0.1
|
||||
title: "Klientpark energi — PC-utskifting og adaptiv strømstyring"
|
||||
description: "OKF-bundle for en fiktiv virksomhets klientpark med to kandidat-tiltak: utskifting av 2 500 eldre stasjonære PC-er, og adaptiv strømstyring som utnytter den tillatte ytelsesreserven. Bygget rundt et dokumentert evidensgap — uten måler kan realiseringsgraden ikke ses."
|
||||
tags: [energieffektivisering, klientpark, arbeidsstasjoner, M&V, IPMVP, realiseringsgrad]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Klientpark energi
|
||||
|
||||
En OKF-bundle for **utskifting og strømstyring av stasjonære arbeidsstasjoner**: én
|
||||
portefølje, to kandidat-tiltak. Den deler lærings-overflate med bygg-energi-mikro-bundelen, men
|
||||
står på egne ben: metode- og kildelaget er **materialisert inn her**, ikke lenket på tvers av
|
||||
bundler, og evidensgrunnlaget er **virksomhetens eget der det teller**.
|
||||
|
||||
> Framework-nøytral artefakt (null kode-avhengighet). Den bor i pakkens `data/bundles/`, ikke i
|
||||
> den pull-only `shared/`-subtreet, og leses av demoen som den leverte kunnskapsbasen.
|
||||
|
||||
**Både prosjektlaget og litteraturlaget er fiktive.** Porteføljen tilhører den oppdiktede
|
||||
«Eksempelvirksomheten», og kildene den er bygget av (installert effekt, driftstimer, energipris,
|
||||
realiseringsgrad) er virksomhetens egne — like oppdiktede — målerapporter, håndbøker og
|
||||
evalueringer, merket `[V]` der de i fortellingen er verifisert. Ingen ekte organisasjon,
|
||||
publikasjon eller person er sitert. En produksjons-deployer erstatter begge lagene med en ekte
|
||||
kunnskapsbase og ekte kilder.
|
||||
|
||||
## Hvorfor klientparken
|
||||
|
||||
Domenet ble valgt fordi det bærer lærings-overflaten **skarpere enn kontorbygget gjør**.
|
||||
|
||||
I et kontorbygg er gapet mellom modellert og realisert besparelse *målbart, men sjelden
|
||||
målt*. I Eksempelvirksomhetens klientpark er det noe strengere: **virksomhetens egen
|
||||
energioppfølging dokumenterer at arbeidsstasjonene mangler egen måling helt, og at strømmen
|
||||
fordeles på estimerte verdier.** Uten meterdata finnes det ingen ex-post å sammenligne ex-ante
|
||||
med. Realiseringsgraden er ikke ukjent fordi ingen har regnet på den — den er **strukturelt
|
||||
usynlig**.
|
||||
|
||||
Det gjør domenet til et godt frø for lærings-sløyfa: den eneste kilden til korreksjon er
|
||||
akkumulert ekspert-erfaring, som er nøyaktig det verdict-laget bærer og validatoren ikke kan
|
||||
regne. Se [verdict-klientpark-fro.md](verdict-klientpark-fro.md).
|
||||
|
||||
## Innhold (progressiv disclosure)
|
||||
|
||||
- [klientpark-energi.md](klientpark-energi.md) — `type: project` — porteføljen, energibaselinen
|
||||
og rammene.
|
||||
- [tiltak-pc-utskifting.md](tiltak-pc-utskifting.md) — `type: hypothesis` — kandidat-tiltak
|
||||
1: utskifting av 2 500 eldre stasjonære PC-er. **Det er dette tiltaket som er projisert
|
||||
inn i validatoren.**
|
||||
- [tiltak-adaptiv-stromstyring.md](tiltak-adaptiv-stromstyring.md) — `type: hypothesis` —
|
||||
kandidat-tiltak 2: adaptiv strømstyring som henter ut den overdimensjoneringen
|
||||
ytelsesreserven allerede tillater. Svakere kildebelagt enn tiltak 1, og merket slik.
|
||||
- [metode-ipmvp-a.md](metode-ipmvp-a.md) — `type: methodology` — M&V-metoden (IPMVP
|
||||
Option A), og hvorfor de øvrige opsjonene er stengt for en umålt klientpark.
|
||||
- [kilder-klientpark-realisering.md](kilder-klientpark-realisering.md) — `type: reference` —
|
||||
virksomhetens egne (fiktive) kilder: baseline- og normankere, og etterevalueringene
|
||||
realiseringsgraden er lånt fra.
|
||||
- [verdict-klientpark-fro.md](verdict-klientpark-fro.md) — `type: verdict` — frøsatt ekspert-dom.
|
||||
**ExpeL-frøet loopens steg 1 henter fra.**
|
||||
|
||||
## Hvordan den kjøres i dag
|
||||
|
||||
`validator-input.json` er IR-projeksjonen den eksisterende deterministiske validatoren
|
||||
konsumerer uendret; `cost-baseline.json` bærer det samme tallgrunnlaget som prosjektets
|
||||
kostdata. **De to filene er bygget fra samme linje aritmetikk og bærer identisk `code`,
|
||||
`quantity` og `unit_cost`** — se [tiltak-pc-utskifting.md](tiltak-pc-utskifting.md),
|
||||
§«Mapping til validatoren».
|
||||
|
||||
Bundelen ships **uten `golden.json`**. Den blokken er kryss-implementasjons-fasit produsert
|
||||
av en seedet Monte Carlo, og det finnes ingen kjørbar pipeline å produsere den med. En
|
||||
fasit ingen gate leser er verre enn ingen fasit. Lærings-overflaten går ikke tapt: de
|
||||
strukturerte feltene ExpeL-folden faktisk henter (`realization_rate`,
|
||||
`expected_actual_saving_nok`) ligger i frontmatteren til
|
||||
[verdict-klientpark-fro.md](verdict-klientpark-fro.md), som er der loopen leser dem.
|
||||
|
|
@ -0,0 +1,151 @@
|
|||
---
|
||||
type: reference
|
||||
title: "Klientpark: egne ankere og lånt realiseringsgrad — virksomhetens kilder"
|
||||
description: "Kildebelagte tall for klientparkens energibaseline, normer og realiseringsgap, alle fra den fiktive Eksempelvirksomhetens egne dokumenter. Skiller strengt mellom materialet om klientparken (baseline, norm, årsak) og de lånte etterevalueringene (selve realiseringsgraden)."
|
||||
tags: [realization-rate, performance-gap, klientpark, M&V, kilder, evidensgap]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Klientpark: virksomhetens kilder
|
||||
|
||||
**Alle kildene i denne fila er fiktive.** De er dokumenter i den oppdiktede
|
||||
Eksempelvirksomheten — målerapporter, håndbøker, investeringsnotater og etterevalueringer — og
|
||||
ingen av dem finnes utenfor denne bundelen. Ingen ekte organisasjon, publikasjon eller person er
|
||||
sitert. Merkingen `[V]` betyr «verifisert mot virksomhetens eget dokument» innenfor fortellingen.
|
||||
|
||||
**Realiseringsgrad (RR)** = faktisk evaluert besparelse (ex-post) ÷ modellert/påstått
|
||||
besparelse (ex-ante). RR < 1 betyr at drift leverte mindre enn modellen lovte.
|
||||
|
||||
Denne fila har en **skarp todeling**, og den er det viktigste ved den:
|
||||
|
||||
- **Del A — materiale om klientparken.** Baseline, norm og *årsaken til* at gapet ikke kan ses.
|
||||
Alt `[V]` mot virksomhetens eget dokument.
|
||||
- **Del B — lånt materiale.** Selve realiseringsgraden. Den finnes **ikke** for klientparken i
|
||||
noen kilde vi har funnet, og er lånt fra virksomhetens etterevalueringer av tidligere
|
||||
belysningsprogrammer i egne bygg. **Lånet er merket overalt der tallet brukes.**
|
||||
|
||||
Å blande de to ville gjort et lånt tall til en måling av klientparken. Det gjør vi ikke.
|
||||
|
||||
---
|
||||
|
||||
## Del A — materiale om klientparken [V]
|
||||
|
||||
| Nivå | Funn | Kilde | År |
|
||||
|---|---|---|---|
|
||||
| Aggregat (virksomheten) | 13 000 arbeidsstasjoner inkl. beregningsmaskiner = «rett over 13 GWh/år» ⇒ **≈ 1 000 kWh/maskin/år** | Energirapport Region Nord | ikke oppgitt |
|
||||
| Maskinvare | Eldre stasjonær PC: 100 W systemenhet + 14 W strømforsyningstap = **114 W**; tilsvarende ny småformat-PC **70 W** | Innkjøpsspesifikasjonen, effekttabell | ikke oppgitt |
|
||||
| **Driftstimer (internt normtall)** | **4 000–4 100 t/år for eldre arbeidsstasjoner** | **IT-driftshåndboken, kap. 6** | **2021** |
|
||||
| **Reservefaktor** | **RF ≤ 0,85** — ≥15 % ytelsesreserve tillatt ved dimensjonering | **IT-driftshåndboken** | **2021** |
|
||||
| Ytelsesgulv | 1,0 s responstid og 5 samtidige applikasjoner for standard kontorarbeid | Innkjøpsspesifikasjonen | ikke oppgitt |
|
||||
| Kostnad (regionnivå) | **≈ 200 mill. NOK** for full utskifting av klientparken, forventet **67 %** energikutt, **≈ 27 mill. NOK/år** spart | **Investeringsnotat, Region Vest** | **2022** |
|
||||
| Vedlikehold | Nye maskiner «Very good» ≤ 5 år; eldre maskiner trenger komponentbytte hyppig (Region Vest: hvert 4. år) | Hovedplan for klientdrift | ikke oppgitt |
|
||||
| Praksis | Nattlig avstenging 00:00–05:00 pilotert 3/4–15/10/2024; må vurderes lokalt | IT-driftsavdelingen, pilotnotat | 2024 |
|
||||
|
||||
### Årsaken gapet ikke kan ses (klientparken, og bundelens poeng) [V]
|
||||
|
||||
**Virksomhetens energioppfølging dokumenterer at arbeidsstasjonene mangler egen måling, og at
|
||||
forbruket fordeles på estimerte verdier fra byggenes fellesmålere.** Uten meterdata er
|
||||
ex-post-måling — og dermed realiseringsgrad — ikke mulig.
|
||||
|
||||
Det er ikke et hull i denne bundelen. Det er grunnen til at den finnes: i et domene der
|
||||
gapet er strukturelt usynlig, er ekspert-erfaring den eneste korreksjonskilden.
|
||||
|
||||
### To gap-mekanismer som er klientpark-spesifikke, og som peker hver sin vei [V]
|
||||
|
||||
1. **Installert effekt ≠ merkeeffekt — peker OPP.** Målt: en maskin merket 100 W trekker
|
||||
**120 W** (stikkprøvemåling i energirapporten). Modellen regner merkeeffekt; strømregningen
|
||||
betaler den faktiske. Er baselinen understatt, er den *faktiske* besparelsen **større** enn
|
||||
modellert. Dette trekker realiseringsgraden **oppover**.
|
||||
2. **Driftstimer — peker NED.** Driftshåndboken gir 4 000–4 100 t/år som tabellverdi;
|
||||
stikkprøven antar 4 150 t. **Ingen kilde gir en målt driftstimekurve for klientparken.** Er
|
||||
timene overvurdert, er besparelsen overvurdert.
|
||||
|
||||
**De to opphever ikke hverandre til noe kjent.** Mekanisme 1 er målt på den *gamle* maskinen;
|
||||
tilsvarende måling for den nye generasjonen finnes ikke i materialet, så nettoen kan ikke regnes.
|
||||
Se [verdict-klientpark-fro.md](verdict-klientpark-fro.md) for hvordan dommen håndterer det.
|
||||
|
||||
### Evidensgap i materialet om klientparken (gjennomgangens egen liste)
|
||||
|
||||
- NOK per arbeidsstasjon inkl. utrulling, per årstall
|
||||
- NOK per styringslisens / komplett system for sentral strømstyring
|
||||
- Kvantifisert kWh eller % for adaptiv strømstyring eller dvale i virksomhetens egne prosjekter
|
||||
- Reell realiseringsgrad (ex-post ÷ ex-ante) for utskiftings- eller styringsprosjekter i klientparken
|
||||
- Målt driftstimekurve for arbeidsstasjonene
|
||||
|
||||
**Region Sør-caset er bevisst utelatt fra tabellen.** Kilden oppgir både «estimert
|
||||
sparepotensial 4,5 GWh/år» og «70 % reduksjon» for utskifting av 10 000 maskiner, men ikke som
|
||||
et ex-ante/ex-post-par. Ingen realiseringsgrad kan regnes av det, og vi later ikke som.
|
||||
|
||||
---
|
||||
|
||||
## Del B — lånt materiale: realiseringsgraden [V, men ikke klientparken]
|
||||
|
||||
Strømbruken i en klientpark følger **samme effektligning** som belysning: effekt × antall ×
|
||||
driftstimer. Etterevalueringene under gjelder belysningstiltak i virksomhetens egne bygg, med
|
||||
samme ligning og samme stipulerte parameter (driftstimer). De er `[V]` mot virksomhetens egne
|
||||
evalueringsrapporter, men de gjelder **et annet utstyr**, og de er lånt inn her fordi materialet
|
||||
om klientparken ikke har motstykket.
|
||||
|
||||
| Nivå | Funn | Kilde |
|
||||
|---|---|---|
|
||||
| Virksomheten (standardantakelse) | Standard brutto-RR **0,90**; ex-ante «generelt overvurdert» | Internrevisjonens notat om gevinstberegning |
|
||||
| **Program (lys, drift lavere)** | Driftsjustering ned til **81,1 %** (metrede driftstimer 15 % lavere); samtidighetsfaktor **0,566** mot antatt 1,0 | **Etterevaluering av belysningsprogrammet 2010, del 1** |
|
||||
| Program (lys, drift høyere) | Driftstime-RR **106,5 %**; samtidighet 72,2 % — gapet går **begge veier** | Etterevaluering av belysningsprogrammet 2010, del 2 |
|
||||
| **Parameter (driftstimer)** | Metret **3 053 t/år** mot antatt **3 772 t/år** (≈19 % lavere); CV ≈ 0,5 | **Evaluering av behovsstyrt belysning 2021** |
|
||||
| Portefølje | Kontorbygg **98 %** mot personalboliger **61 %** mot totalt **93 %** | Porteføljegjennomgang FY15/16–19/20 |
|
||||
| Måleterskel | Besparelse bør overstige **~10 % av baseline** for å skilles fra støy | Virksomhetens M&V-veileder |
|
||||
|
||||
**2021-evalueringen er den mest relevante av dem alle**, fordi den treffer nøyaktig den
|
||||
parameteren klientparken lever på: metret driftstid mot antatt driftstid, 3 053 mot 3 772 timer.
|
||||
Forholdet er **0,809**. Etterevalueringen fra 2010 kommer uavhengig til **0,811** gjennom samme
|
||||
mekanisme.
|
||||
|
||||
### Systematiske årsaker til at faktisk < modellert [V]
|
||||
|
||||
1. **Driftstimer** — dominerende, og for klientparken forsterket av at brukervanene ikke er
|
||||
målt.
|
||||
2. **Andel i drift, driftsavvik og varighet** — ikke alt rulles ut eller forblir i drift;
|
||||
styringer overstyres.
|
||||
3. **Baseline-skjevhet** — en over- eller underpredikert baseline forplanter seg rett inn i
|
||||
den absolutte besparelsen.
|
||||
4. **Måleusikkerhet** — under ~10 %-terskelen drukner signalet i støy. Og uten måler finnes
|
||||
ikke signalet i det hele tatt.
|
||||
5. **Rebound / atferd** — maskinen står på lenger, fordi det «koster mindre».
|
||||
|
||||
### Ett mønster fra et naboområde, tatt med fordi det er navngitt
|
||||
|
||||
Virksomhetens driftslogg fra idriftsettelsen av et driftssenter beskriver et anlegg der det
|
||||
modellerte viftepotensialet uteble, med en eksplisitt årsak: **«viftene ble holdt på full
|
||||
hastighet mesteparten av tiden».** Det er ikke klientparken, og tallet er ikke overførbart. Men
|
||||
mekanismen — en styring som i praksis ikke styrer — er den samme risikoen
|
||||
[tiltak-adaptiv-stromstyring.md](tiltak-adaptiv-stromstyring.md) bærer.
|
||||
|
||||
---
|
||||
|
||||
## Kilder (virksomhetens interne dokumenter — alle fiktive)
|
||||
|
||||
**Om klientparken:**
|
||||
|
||||
- Eksempelvirksomheten, IT-driftshåndboken (2021), kap. 6 «Energi og driftstid»
|
||||
- Eksempelvirksomheten, energirapport Region Nord
|
||||
- Eksempelvirksomheten, energioppfølgingen: fordeling av strøm fra fellesmålere
|
||||
- Eksempelvirksomheten, internrapport 8/2020 om måling i kontorbygg
|
||||
- Eksempelvirksomheten, IT-driftsavdelingens pilotnotat om nattlig avstenging (2024)
|
||||
- Eksempelvirksomheten, driftslogg fra idriftsettelsen av driftssenteret
|
||||
- Eksempelvirksomheten, energiinnkjøpets prisoversikt (kraftpris for kontorvirksomhet)
|
||||
|
||||
**Metode og lånt materiale:**
|
||||
|
||||
- Eksempelvirksomheten, innkjøpsspesifikasjonen for arbeidsstasjoner, effekttabell
|
||||
- Eksempelvirksomheten, energirapporten: stikkprøvemåling av arbeidsstasjoner
|
||||
- Eksempelvirksomheten, M&V-veilederen (okt. 2018), med beskrivelse av IPMVP-opsjonene
|
||||
- Eksempelvirksomheten, beregningsmal for effekttiltak, kap. 2 «Belysning og utstyr»
|
||||
- Eksempelvirksomheten, etterevaluering av belysningsprogrammet 2010, del 1
|
||||
- Eksempelvirksomheten, evaluering av behovsstyrt belysning 2021
|
||||
- Eksempelvirksomheten, etterevaluering av belysningsprogrammet 2010, del 2
|
||||
- Eksempelvirksomheten, porteføljegjennomgang FY15/16–19/20
|
||||
- Eksempelvirksomheten, internrevisjonens notat om gevinstberegning
|
||||
|
||||
**Utelatt med begrunnelse:** Region Sør-caset (ikke et ex-ante/ex-post-par, se over) og
|
||||
et leverandørnotat som ble brukt til å underbygge målings-mangelen — den påstanden er dekket
|
||||
av virksomhetens egen energioppfølging, som er primærkilde.
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
---
|
||||
type: project
|
||||
title: "Klientpark Eksempelvirksomheten"
|
||||
description: "Fiktiv klientpark: 9 500 eldre stasjonære arbeidsstasjoner fordelt på virksomhetens kontorer. Energibaseline og rammer for utskifting og strømstyring."
|
||||
resource: KLIENTPARK-ENERGI
|
||||
tags: [klientpark, arbeidsstasjoner, kontor-IT, energibaseline, stasjonaer-PC]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Klientpark Eksempelvirksomheten (KLIENTPARK-ENERGI)
|
||||
|
||||
**Fiktiv portefølje.** Tallene er illustrative, og parameterne de er bygget av er forankret i
|
||||
den oppdiktede Eksempelvirksomhetens egne kilder — ikke i en ekte virksomhet. En
|
||||
produksjons-deployer erstatter dette laget med sin egen utstyrsdatabase.
|
||||
|
||||
Porteføljen er **9 500 stasjonære arbeidsstasjoner** fordelt på virksomhetens kontorer, alle
|
||||
av samme eldre modellgenerasjon. Den er valgt uniform med vilje: hele variasjonen som betyr noe
|
||||
for lærings-overflaten ligger i **driftstimer og realisering**, ikke i maskin-miksen.
|
||||
|
||||
## Energibaseline
|
||||
|
||||
| Størrelse | Verdi | Merknad |
|
||||
|---|---|---|
|
||||
| Antall arbeidsstasjoner | 9 500 | [I] illustrativt |
|
||||
| Installert effekt per arbeidsstasjon | **114 W** | [V] 100 W systemenhet + 14 W strømforsyningstap (innkjøpsspesifikasjonens effekttabell) |
|
||||
| Driftstimer | **4 050 t/år** | [V-forankret] midtpunkt i IT-driftshåndbokens 4 000–4 100 t/år for eldre arbeidsstasjoner |
|
||||
| **Totalt elforbruk** | **4 386 150 kWh/år** | beregnet: 114 W × 9 500 × 4 050 t / 1 000 |
|
||||
| Per arbeidsstasjon | 461,7 kWh/år | beregnet |
|
||||
| Variabel energikostnad | **1,00 NOK/kWh** ekskl. mva | [V-forankret] kraftpris + nettleie energiledd + elavgift |
|
||||
| **Total årlig energikostnad** | **4 386 150 NOK/år** | beregnet |
|
||||
|
||||
**Energiprisen** (1,00 NOK/kWh) er den marginale variable kostnaden et spart kWh faktisk
|
||||
unngår, ekskl. mva. Sammensetningen er den samme som for næringsbygg — kraftpris + nettleie
|
||||
energiledd + elavgift — og varierer kraftig med prisområde og sesong. Derfor er den
|
||||
konfigurerbar, og usikkerheten håndteres i Monte Carlo-steget (band 0,70–1,40 NOK/kWh). Se
|
||||
[kilder-klientpark-realisering.md](kilder-klientpark-realisering.md).
|
||||
|
||||
**Én forskjell fra et enkelt kontorbygg er verdt å merke:** klientparken har ingen egen måler,
|
||||
og virksomhetens energioppfølging dokumenterer at forbruket fordeles på **estimerte** verdier fra
|
||||
byggenes fellesmålere. Det påvirker ikke den marginale kostnaden per spart kWh, men det er
|
||||
grunnen til at ex-post-verifikasjon er stengt her. Se [metode-ipmvp-a.md](metode-ipmvp-a.md).
|
||||
|
||||
## Kryss-sjekk mot virksomhetens aggregat (og hvorfor tallene ikke er like)
|
||||
|
||||
Energirapporten for Region Nord oppgir at **13 000 arbeidsstasjoner** bruker «rett over
|
||||
13 GWh/år» — altså **≈ 1 000 kWh per maskin per år**. Vår portefølje ligger på
|
||||
**461,7 kWh** per maskin, under halvparten.
|
||||
|
||||
**Avviket er reelt og forklarlig, ikke en feil:** Region Nord-tallet dekker **kontormaskiner OG
|
||||
beregningsmaskiner**, altså også tyngre klasser med 150 W- og 250 W-enheter og lengre
|
||||
driftstid. Klientparken her er med vilje modellert som ren kontorklasse med 100 W-enheter — den
|
||||
klassen effekttabellen måler på. Retningen på avviket stemmer med den forklaringen: vår
|
||||
portefølje **skal** ligge under et aggregat som inkluderer beregningsmaskiner.
|
||||
|
||||
**Dette er en design-beslutning, ikke en måling.** En ekte klientpark ville hatt blandet
|
||||
maskin-miks, og en deployer som bytter ut dette laget må regne baselinen på nytt fra sin
|
||||
egen utstyrsdatabase. Konsekvensen for lærings-overflaten er null — realiseringsgapet er en
|
||||
*rate*, ikke et absolutt tall.
|
||||
|
||||
## Rammer (constraints)
|
||||
|
||||
- Tiltak vurderes **inne i** denne porteføljen (ikke på tvers av virksomhetens øvrige
|
||||
IT-utstyr).
|
||||
- **Ytelseskravene setter gulvet.** For standard kontorarbeid: 1,0 s responstid og 5 samtidige
|
||||
applikasjoner (innkjøpsspesifikasjonen). Ingen besparelse kan hentes ved å gå under kravet.
|
||||
- **Ytelsesreserven (RF) må inn i beregningen.** Maskinen skal ligge over kravet **over tid**,
|
||||
ikke bare ved utrulling. IT-driftshåndboken setter RF ≤ 0,85. Se
|
||||
[tiltak-adaptiv-stromstyring.md](tiltak-adaptiv-stromstyring.md) — det er nettopp den marginen
|
||||
tiltak 2 lever av.
|
||||
- **Nattlig avstenging kan ikke antas.** IT-driftsavdelingen kjørte pilot på avstenging
|
||||
00:00–05:00 i 2024, men dokumentasjonen sier at tiltaket må vurderes lokalt, mot
|
||||
oppdateringsvinduer og fjerntilgang. Det er derfor **ikke** modellert som besparelse i noen av
|
||||
hypotesene her.
|
||||
- Budsjett og anskaffelsesrammer eies av deployer; her holdes de minimale.
|
||||
|
||||
## Kandidat-tiltak
|
||||
|
||||
- [tiltak-pc-utskifting.md](tiltak-pc-utskifting.md) — PC-utskifting, trinn 1
|
||||
(2 500 arbeidsstasjoner).
|
||||
- [tiltak-adaptiv-stromstyring.md](tiltak-adaptiv-stromstyring.md) — adaptiv strømstyring på de
|
||||
samme 2 500 maskinene, etter utskiftingen.
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
---
|
||||
type: methodology
|
||||
title: "IPMVP Option A for klientparken — og hvorfor de andre opsjonene er stengt"
|
||||
description: "M&V-metoden for å verifisere besparelsen fra et klientpark-tiltak. Option A er ikke valgt fordi den er best, men fordi en umålt klientpark stenger de tre andre."
|
||||
methodology: IPMVP
|
||||
option: A
|
||||
tags: [IPMVP, M&V, retrofit-isolation, klientpark, maalermangel]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# M&V-metode: IPMVP Option A for klientparken
|
||||
|
||||
**IPMVP** (International Performance Measurement and Verification Protocol) er et utbredt
|
||||
metoderammeverk for å måle og verifisere energibesparelser. Kjerneinnsikten som begrunner hele
|
||||
lærings-sløyfa er metodens eget utgangspunkt: besparelse kan ikke måles direkte, fordi den er
|
||||
**fravær** av energibruk.
|
||||
|
||||
Besparelse er en **kontrafaktisk** størrelse — det finnes ingen måler for «det som ikke ble
|
||||
brukt». Den *beregnes*: `Baseline-energi − Rapporterings-energi ± justeringer` (metodens
|
||||
grunnligning).
|
||||
|
||||
## De fire opsjonene (metodens egne navn)
|
||||
|
||||
- **Option A — Retrofit Isolation: Key Parameter Measurement.** Måler nøkkelparameteren
|
||||
(typisk effekt) på det berørte utstyret; øvrige parametere (typisk driftstimer) *estimeres*.
|
||||
- **Option B — Retrofit Isolation: All Parameter Measurement.** Måler alle relevante parametere.
|
||||
- **Option C — Whole Facility.** Besparelse fra anleggets hovedmåler, med rutinejustering.
|
||||
- **Option D — Calibrated Simulation.** Besparelse via simuleringsmodell kalibrert mot måledata.
|
||||
|
||||
## Hvorfor Option A her — ved eliminasjon, ikke ved preferanse
|
||||
|
||||
I et kontorbygg velges Option A fordi den er **billigst og enklest** for ett isolert tiltak.
|
||||
For denne porteføljen er begrunnelsen en annen og svakere: **de tre andre opsjonene er
|
||||
praktisk stengt.**
|
||||
|
||||
- **Option C er stengt av målermangel.** Option C forutsetter en hovedmåler å lese
|
||||
besparelsen ut av. Virksomhetens energioppfølging dokumenterer at arbeidsstasjonene **mangler
|
||||
egen måling** og fordeles på **estimerte** verdier fra byggenes fellesmålere. Der det ikke
|
||||
finnes meterdata, finnes det ingen rapporteringsperiode å trekke fra en baseline.
|
||||
- **Option B er stengt av kostnad og geografi.** «Alle relevante parametere» for en klientpark
|
||||
betyr driftstimer per maskin, over en maskinpark spredt over titalls kontorer.
|
||||
Instrumenteringen ville kostet mer enn tiltaket på en park av kontorklasse-maskiner.
|
||||
- **Option D er stengt av kalibreringsdata.** En kalibrert simulering må kalibreres mot noe.
|
||||
Se Option C.
|
||||
|
||||
**Option A er derfor det som står igjen** — og det er verdt å si høyt, fordi valget ved
|
||||
eliminasjon flytter mer vekt over på den parameteren Option A tillater å *estimere*.
|
||||
|
||||
## Der metoden lekker: den estimerte parameteren
|
||||
|
||||
Option A måler effekt (billig, presist — 114 W før, 70 W etter) og **stipulerer
|
||||
driftstimer**. For klientparken er det stipulatet svakere enn i et bygg:
|
||||
|
||||
- Et bygg har en **timeplan** å stipulere fra. Den treffer sjelden metret driftstid, men den
|
||||
er i det minste anleggsspesifikk.
|
||||
- En klientpark har **brukervaner**, og **ingen kilde i materialet vårt gir en målt
|
||||
driftstimekurve for maskinene.** Vi bruker IT-driftshåndbokens 4 000–4 100 t/år — et
|
||||
virksomhetsomfattende tabellanslag for «eldre arbeidsstasjoner», ikke en målt kurve for
|
||||
denne maskinparken med disse arbeidsvanene.
|
||||
|
||||
**Det gir en dobbel eksponering:** parameteren metoden tillater å estimere er både den
|
||||
dominerende usikkerheten *og* den vi har svakest kilde for. Realiseringsgapet oppstår
|
||||
nøyaktig der.
|
||||
|
||||
## Måleterskelen, og hvorfor den ikke redder oss
|
||||
|
||||
Virksomhetens M&V-veileder sier at en besparelse bør overstige **~10 % av baseline** for å
|
||||
skilles pålitelig fra støy. Trinn 1 ligger på 10,2 % av porteføljen — akkurat på terskelen — og
|
||||
38,6 % av de berørte maskinenes eget forbruk, altså godt over hvis man måler på riktig
|
||||
avgrensning.
|
||||
|
||||
Det hjelper likevel ikke, fordi terskelen forutsetter at det **finnes en måling** å skille
|
||||
signalet ut av. Se Option C.
|
||||
|
||||
## Konsekvensen for lærings-sløyfa
|
||||
|
||||
Når ex-post-verifikasjon er stengt, er den eneste tilgjengelige korreksjonen **akkumulert
|
||||
ekspert-erfaring**. Det er ikke en nødløsning i dette domenet — det er den eneste kilden
|
||||
som finnes. Se [verdict-klientpark-fro.md](verdict-klientpark-fro.md) og
|
||||
[kilder-klientpark-realisering.md](kilder-klientpark-realisering.md).
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
---
|
||||
type: hypothesis
|
||||
title: "Adaptiv strømstyring — utnytting av ytelsesreserven"
|
||||
description: "Konstant ytelse (effekttak) og dvale på de 2 500 nye maskinene fra trinn 1, som henter ut den overdimensjoneringen ytelsesreserven allerede tillater. Svakere kildebelagt enn tiltak 1, og merket slik."
|
||||
resource: KLIENTPARK-ENERGI
|
||||
measure_id: STROM-KLIENT-02
|
||||
tags: [adaptiv-stromstyring, dvale, effekttak, ytelsesreserve, ECM, trinn-2]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Tiltak: Adaptiv strømstyring på de utskiftede maskinene
|
||||
|
||||
Styringstiltak på de **samme 2 500 maskinene** som er byttet i trinn 1
|
||||
([tiltak-pc-utskifting.md](tiltak-pc-utskifting.md)). Tiltaket forutsetter de nye maskinene —
|
||||
det er den styrbare strømforsyningen i den nye generasjonen som gjør det mulig.
|
||||
|
||||
> **Denne hypotesen er svakere kildebelagt enn tiltak 1, og det er med vilje synlig.**
|
||||
> Tiltak 1 er regnet fra to merkeeffekter i samme tabell. Denne er regnet fra en
|
||||
> *normmargin*, fordi det er det beste materialet gir.
|
||||
|
||||
## Evidensgapet, sagt først
|
||||
|
||||
**Ingen kilde i materialet vårt kvantifiserer besparelsen fra adaptiv strømstyring eller dvale
|
||||
utenfor arbeidstid i virksomhetens klientpark** — ikke i kWh, ikke i prosent. Det er et av de
|
||||
fem punktene på kildegjennomgangens egen uverifisert-liste.
|
||||
|
||||
Vi kunne ha utledet et tall ved å trekke tiltak 1 fra Region Vests 67 % og tilskrive resten til
|
||||
styring. Det ville gitt ~46 % av forbruket etter utskiftingen — **urimelig høyt for styring
|
||||
alene**, og det ville tilskrevet en kilde en dekomponering den ikke inneholder. Vi gjør det ikke.
|
||||
|
||||
I stedet regner vi fra den ene marginen virksomhetens egen norm faktisk **navngir**.
|
||||
|
||||
## Grunnlaget: ytelsesreserven er en innebygd overdimensjonering
|
||||
|
||||
En arbeidsstasjon skal ligge over ytelseskravet **over tid**, ikke bare ved utrulling. Derfor
|
||||
dimensjoneres den med en reservefaktor (RF) som tar høyde for at programvaren blir tyngre
|
||||
gjennom levetiden. IT-driftshåndboken (2021) setter **RF ≤ 0,85**.
|
||||
|
||||
Konsekvensen: en **ny** maskin leverer minst **15 % mer ytelse enn kravet** — en margin som
|
||||
brennes bort som varme til maskinen har eldes nok til å trenge den. Konstant ytelse (et
|
||||
effekttak) er styringen som henter den tilbake: effekttaket settes ned ved utrulling og løftes
|
||||
gradvis etter hvert som programvarelasten vokser.
|
||||
|
||||
**Dette er ikke en besparelse mot kravet — det er en besparelse mot overoppfyllelsen.**
|
||||
Minsteytelsen (1,0 s responstid og 5 samtidige applikasjoner for standard kontorarbeid) er
|
||||
urørt hele veien.
|
||||
|
||||
## Parametere
|
||||
|
||||
| Parameter | Verdi | Status | Kilde/forankring |
|
||||
|---|---|---|---|
|
||||
| Antall maskiner | 2 500 | [I] | samme som trinn 1 |
|
||||
| Effekt etter utskifting (utgangspunkt) | 70 W | [V] | innkjøpsspesifikasjonen |
|
||||
| Reservefaktor | **RF ≤ 0,85** | [V] | IT-driftshåndboken (2021) |
|
||||
| Effekt ved effekttak | 70 × 0,85 = **59,5 W** | beregnet | følger direkte av RF |
|
||||
| Reduksjon per maskin (ΔW) | **10,5 W** | beregnet | 70 − 59,5 |
|
||||
| Driftstimer | 4 050 t/år | [V-forankret] | IT-driftshåndboken (2021) |
|
||||
|
||||
## Modellert besparelse (ex-ante)
|
||||
|
||||
> Forbruk etter trinn 1: 70 × 2 500 × 4 050 / 1 000 = **708 750 kWh/år**
|
||||
> ΔW = 10,5 W/maskin
|
||||
> kWh/år = 10,5 × 2 500 × 4 050 / 1 000 = **106 312,5 kWh/år**
|
||||
> kr/år = **106 312,5 NOK/år**
|
||||
|
||||
Det er **15,0 %** av forbruket etter utskiftingen, som det må være — tallet er RF-marginen,
|
||||
ikke et uavhengig estimat.
|
||||
|
||||
**Samlet med trinn 1:** 445 500 + 106 312,5 = **551 812,5 kWh/år**, altså **47,8 %** av de
|
||||
2 500 maskinenes opprinnelige forbruk (1 154 250 kWh/år).
|
||||
|
||||
## Tre grunner til at dette tallet er en øvre grense, ikke et anslag
|
||||
|
||||
1. **Marginen er ikke gratis hele levetiden.** Effekttaket henter 15 % ved utrulling og
|
||||
**null** ved slutten av levetiden, når maskinen faktisk trenger hele ytelsen.
|
||||
Gjennomsnittet over levetiden er lavere enn 15 % — hvor mye lavere avhenger av hvor fort
|
||||
programvarelasten vokser, som **ingen kilde her oppgir**.
|
||||
2. **Dvale utover effekttaket er ikke modellert.** Bruksadaptiv dvale (maskinen sover når ingen
|
||||
bruker den) og nattlig avstenging ville kommet i tillegg, men vi har ingen kvantifisering,
|
||||
og IT-driftsavdelingens egen avstengingspilot (00:00–05:00, 2024) sier eksplisitt at tiltaket
|
||||
må vurderes lokalt. **Ikke modellert.**
|
||||
3. **Styringsverktøyet koster, og prisen finnes ikke i materialet.** **Ingen kilde gir NOK per
|
||||
styringslisens eller for et komplett system for sentral strømstyring.** Vi anslår den ikke.
|
||||
Uten kostnadssiden er dette et energitall, ikke en business case.
|
||||
|
||||
## Forholdet til validatoren
|
||||
|
||||
**Dette tiltaket er ikke projisert inn i `validator-input.json`.** IR-projeksjonen bærer ett
|
||||
kandidat-tiltak, og det er trinn 1. Denne hypotesen er her som det den er: et **andre**
|
||||
kandidat-tiltak lærings-sløyfa kan foreslå, med en modellert besparelse som er svakere
|
||||
forankret enn den første — og en ekspert-dom som derfor har mer å korrigere.
|
||||
|
||||
Realiseringsgapet for styring er bredere enn for maskinutskifting. Virksomhetens egen driftslogg
|
||||
fra idriftsettelsen av et driftssenter dokumenterer mønsteret rått: potensialet uteble fordi
|
||||
**«viftene ble holdt på full hastighet mesteparten av tiden»**. En styring som overstyres av
|
||||
drift, leverer null. Se [kilder-klientpark-realisering.md](kilder-klientpark-realisering.md) og
|
||||
[verdict-klientpark-fro.md](verdict-klientpark-fro.md).
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
---
|
||||
type: hypothesis
|
||||
title: "Utskifting av stasjonære PC-er, trinn 1"
|
||||
description: "Bytte 2 500 eldre stasjonære PC-er (114 W installert) til nye småformat-PC-er (70 W) på de eldste kontorene i porteføljen. Kandidat-tiltak med modellert besparelse, usikkerhet og en åpen kostnadsside."
|
||||
resource: KLIENTPARK-ENERGI
|
||||
measure_id: PC-KLIENT-01
|
||||
tags: [PC-utskifting, arbeidsstasjoner, retrofit, ECM, trinn-1]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Tiltak: utskifting av stasjonære PC-er (trinn 1)
|
||||
|
||||
Utskifting av **2 500 av porteføljens 9 500 arbeidsstasjoner** — de eldste kontorene — fra
|
||||
eldre stasjonære PC-er til nye småformat-PC-er. Trinnvis utrulling er den vanlige formen i
|
||||
Eksempelvirksomhetens klientprosjekter: alderen på maskinen, ikke effekten, avgjør rekkefølgen.
|
||||
|
||||
Dette er tiltaket som er **projisert inn i validatoren**. Tiltak 2
|
||||
([tiltak-adaptiv-stromstyring.md](tiltak-adaptiv-stromstyring.md)) forutsetter at dette er utført.
|
||||
|
||||
## Parametere
|
||||
|
||||
| Parameter | Verdi | Status | Kilde/forankring |
|
||||
|---|---|---|---|
|
||||
| Antall maskiner i trinn 1 | 2 500 | [I] | trinnvis utrulling, andel valgt |
|
||||
| Effekt før (100 W systemenhet + tap) | 114 W | [V] | innkjøpsspesifikasjonens effekttabell |
|
||||
| Effekt etter (ny småformat-PC, tilsvarende ytelse) | 70 W | [V] | samme tabell |
|
||||
| Reduksjon per maskin (ΔW) | **44 W** | beregnet | 114 − 70 |
|
||||
| Driftstimer (HOU) | 4 050 t/år | [V-forankret] | IT-driftshåndboken (2021): 4 000–4 100 t/år |
|
||||
| Variabel energipris | 1,00 NOK/kWh | [V-forankret] | se [klientpark-energi.md](klientpark-energi.md) |
|
||||
|
||||
## Modellert besparelse (ex-ante)
|
||||
|
||||
Samme effektligning som virksomhetens beregningsmal bruker for alle effekttiltak (ligning 3):
|
||||
`kWh = Σ (W_før − W_etter) × antall × HOU / 1000`
|
||||
|
||||
> ΔW = 114 − 70 = **44 W/maskin**
|
||||
> kWh/år = 44 × 2 500 × 4 050 / 1 000 = **445 500 kWh/år**
|
||||
> kr/år = 445 500 × 1,00 = **445 500 NOK/år**
|
||||
|
||||
Det er **38,6 %** av de berørte maskinenes eget forbruk (1 154 250 kWh/år) og **10,2 %** av
|
||||
porteføljens totale forbruk.
|
||||
|
||||
**Ingen kjøle-interaktiv effekt er regnet med.** Spillvarmen fra en arbeidsstasjon havner i et
|
||||
kontorlokale med egen ventilasjon, og beregningsmalens korreksjon for kjølelast (ligning 6) er
|
||||
ikke brukt. Kjernetallet står uten den justeringen.
|
||||
|
||||
## Hvorfor 38,6 % og ikke 67 %
|
||||
|
||||
Region Vest anslo i 2022 **67 % energireduksjon** ved full utskifting av klientparken, til
|
||||
≈ 200 mill. NOK og ≈ 27 mill. NOK/år spart. Vår bunn-opp-beregning fra merkeeffekt kommer til
|
||||
38,6 %. Differansen er stor nok til at den må forklares, ikke bortforklares:
|
||||
|
||||
- Vår 38,6 % er **ren maskinutskifting**, regnet fra to merkeeffekter i samme effekttabell.
|
||||
- Region Vests 67 % er et **regionalt aggregat-anslag** hvis sammensetning kilden ikke
|
||||
bryter ned. Det er rimelig å anta at det også inneholder strømstyring og korreksjon av
|
||||
overdimensjonering — men **kilden sier det ikke**, og vi tilskriver den ikke noe den ikke
|
||||
skriver.
|
||||
- Legger vi tiltak 2 oppå ([tiltak-adaptiv-stromstyring.md](tiltak-adaptiv-stromstyring.md)),
|
||||
kommer vi til **47,8 %** — fortsatt et godt stykke under 67 %.
|
||||
|
||||
**Det gjenstående gapet på ~19 prosentpoeng er uforklart i materialet vårt.** Vi lar det stå
|
||||
åpent. Det er en av grunnene til at en ekspert-dom, ikke en modell, må sette forventet
|
||||
faktisk besparelse.
|
||||
|
||||
## Kostnadssiden — et navngitt evidenshull
|
||||
|
||||
**Ingen kilde i materialet gir NOK per arbeidsstasjon inkl. utrulling.** Region Vests
|
||||
200 mill. NOK er en totalsum uten per-maskin-oppløsning, og antall maskiner oppgis ikke.
|
||||
|
||||
En per-maskin-kostnad kan **utledes**, men bare gjennom tre ledd som hver bærer sin egen
|
||||
usikkerhet:
|
||||
|
||||
> 27 mill. NOK/år spart ÷ 1,00 NOK/kWh = 27 GWh/år spart
|
||||
> 27 GWh/år = 67 % ⇒ baseline ≈ 40,3 GWh/år
|
||||
> 40,3 GWh/år ÷ ~1 000 kWh per maskin (Region Nord) ≈ 40 300 maskiner
|
||||
> 200 mill. NOK ÷ 40 300 ≈ **~4 960 NOK per maskin** `[U-utledet]`
|
||||
|
||||
Kjeden låner energiprisen fra vår egen baseline og maskin-intensiteten fra en **annen**
|
||||
region. Den er en størrelsesorden, ikke et tall.
|
||||
|
||||
**Konsekvensen er ubehagelig og skal stå:** 2 500 × ~4 960 ≈ 12,4 mill. NOK mot 445 500
|
||||
NOK/år spart gir **~28 års tilbakebetaling på energi alene**. Det er langt dårligere enn
|
||||
Region Vests egne ~7,4 år, og forskjellen er ikke mystisk — våre maskiner er kontorklasse med
|
||||
462 kWh/år, mot ~1 000 kWh/år i et aggregat som inkluderer beregningsmaskiner.
|
||||
Lavforbruksmaskiner har dårligere energiøkonomi.
|
||||
|
||||
Et ekte klientprosjekt bæres derfor sjelden av energi alene. Vedlikehold er den andre
|
||||
halvdelen: nye maskiner holder «Very good» i ≤ 5 år mens eldre maskiner trenger komponentbytte
|
||||
langt hyppigere (Region Vest oppgir hvert 4. år). **Den besparelsen er ikke modellert her** —
|
||||
vi har ingen kilde som kvantifiserer den i NOK, og vi fyller ikke hullet med et anslag.
|
||||
|
||||
**Ingenting av dette går inn i `cost-baseline.json`.** Kostbasen ligger på aggregat-nivå
|
||||
(energi), der Region Nord- og Region Vest-tallene faktisk bærer.
|
||||
|
||||
## Usikkerhet (for Monte Carlo P10/P50/P90)
|
||||
|
||||
Den dominerende usikkerheten i en PC-besparelse er **driftstimer**, ikke pris — og for denne
|
||||
klientparken er den verre enn i et bygg: **ingen kilde i materialet gir en målt
|
||||
driftstimekurve for maskinene.** Driftshåndbokens 4 000–4 100 t/år er et tabellanslag for
|
||||
«eldre arbeidsstasjoner», ikke en målt kurve for en bestemt maskinpark med bestemte arbeidsvaner.
|
||||
|
||||
Den eksisterende validatorens Monte Carlo varierer likevel **enhetspris**, ikke driftstimer.
|
||||
I denne mappingen brukes derfor prisbandet **0,70–1,40 NOK/kWh** som usikkerhetsakse. Den
|
||||
fysiske driftstime-usikkerheten — og viktigere, den *systematiske* driftstime-skjevheten —
|
||||
håndteres i verdict-laget ([verdict-klientpark-fro.md](verdict-klientpark-fro.md)), ikke her.
|
||||
|
||||
## 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. PC-tiltaket mappes
|
||||
inn **uendret**:
|
||||
|
||||
- `affected_items = [{code: "ENERGI-KLIENTPARK-EL", quantity: 4386150 kWh/år, unit_cost: 1.00 NOK/kWh}]`
|
||||
→ **hele porteføljens** årlige energikostnad (4 386 150 NOK). Trinn 1-besparelsen er
|
||||
10,2 % av den, godt innenfor 30 %-cap-en.
|
||||
- `claimed_saving_nok = 445500` → den modellerte besparelsen fra trinn 1.
|
||||
- `assumptions = {"ENERGI-KLIENTPARK-EL": [0.70, 1.40]}` → prisbandet for Monte Carlo.
|
||||
|
||||
**Hvorfor porteføljen og ikke bare de 2 500 maskinene:** hadde `affected_items` vært de
|
||||
berørte maskinenes eget forbruk (1 154 250 kWh), ville den modellerte besparelsen vært 38,6 %
|
||||
av den — **over 30 %-cap-en**, og det riktige forslaget ville blitt avvist av en gate som
|
||||
måler feil størrelse. Porteføljen er den korrekte kostnads-linjen tiltaket virker på, på
|
||||
samme måte som byggets totale elforbruk er det for et innendørs LED-tiltak.
|
||||
|
||||
**`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 linjen `114 W × 9 500 × 4 050 t / 1 000`. 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* «PC-besparelsens fysiske band». Det er bevisst — den domenetro
|
||||
besparelses-modelleringen og realiseringsgapet hører hjemme i verdict-laget, som er nettopp
|
||||
det lærings-sløyfa skal lære.
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
{
|
||||
"_note": "IR-projeksjon (ir.SavingsProposal) for det eksisterende deterministiske validatoren. PC-tiltaket er mappet inn i kost-IR-en UENDRET: affected_items = HELE portefoeljens arlige energikostnad (9 500 arbeidsstasjoner x 114 W x 4 050 t / 1 000 = 4 386 150 kWh/ar a 1,00 NOK/kWh); claimed_saving_nok = modellert besparelse fra trinn 1 (2 500 maskiner x 44 W x 4 050 t / 1 000 = 445 500 kWh/ar), som er 10,2 % av total og godt innenfor 30 %-cap-en; assumptions = energipris-band (NOK/kWh) for Monte Carlo. Hadde affected_items vaert kun de berorte maskinenes eget forbruk, ville besparelsen vaert 38,6 % av den og det RIKTIGE forslaget blitt avvist. cost-baseline.json baerer IDENTISK code, quantity og unit_cost - begge er skrevet fra samme linje aritmetikk, ikke avstemt i ettertid. Se tiltak-pc-utskifting.md, seksjon 'Mapping til validatoren'.",
|
||||
"project_id": "KLIENTPARK-ENERGI",
|
||||
"measure": "Utskifting av 2 500 eldre stasjonaere PC-er (114 W -> 70 W) i klientparken, trinn 1 av portefoeljen",
|
||||
"affected_items": [
|
||||
{
|
||||
"code": "ENERGI-KLIENTPARK-EL",
|
||||
"quantity": 4386150,
|
||||
"unit_cost": 1.0
|
||||
}
|
||||
],
|
||||
"claimed_saving_nok": 445500,
|
||||
"assumptions": {
|
||||
"ENERGI-KLIENTPARK-EL": [0.70, 1.40]
|
||||
}
|
||||
}
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
---
|
||||
type: verdict
|
||||
title: "Ekspert-dom (frø): PC-utskifting i klientparken — godkjent med realiseringskorreksjon"
|
||||
description: "Frøsatt ekspert-dom for PC-utskiftingen. Den modellerte besparelsen er teknisk korrekt fra parameterne, men driftstimene er et internt tabellanslag, ikke en målt kurve, og klientparken mangler måler — så avviket kan ikke oppdages i drift. Forventet faktisk besparelse settes til 81 % av modellert, lånt fra virksomhetens etterevalueringer av belysningsprogrammer og merket som lån. Raten er en NEDRE grense: en motvirkende mekanisme (målt effekt over merkeeffekt) er dokumentert, men ikke kvantifiserbar for den nye maskingenerasjonen."
|
||||
resource: KLIENTPARK-ENERGI
|
||||
measure_id: PC-KLIENT-01
|
||||
decision: approved_with_adjustment
|
||||
realization_rate: 0.81
|
||||
modelled_saving_nok: 445500
|
||||
expected_actual_saving_nok: 360855
|
||||
gap_source: hours-of-use-overestimation
|
||||
context_key: "klientpark; HOU-kilde=driftshaandbok-tabellverdi; maaling=fravaerende"
|
||||
provenance: "frø — AI-forfattet, fiktiv virksomhet. Realiseringsgraden er LÅNT fra Eksempelvirksomhetens egne (fiktive) etterevalueringer av belysningsprogrammer (2010: 81,1 %; 2021: 3 053 metrede mot 3 772 antatte timer = 0,809). Det finnes INGEN ex-post-måling for klientparken. Erstattes av ekte HITL i produksjon."
|
||||
tags: [verdict, realization-rate, ExpeL-seed, HITL, klientpark, laant-rate]
|
||||
timestamp: 2026-08-09
|
||||
---
|
||||
|
||||
# Ekspert-dom (frø): PC-utskifting i klientparken
|
||||
|
||||
> **Dette er et frø**, ikke en ekte dom. I simulering gir en ekspert-persona slike dommer;
|
||||
> i produksjon gir et menneske dem via samme mappe-grensesnitt. Frøet er forankret i
|
||||
> virksomhetens (fiktive) kilder ([kilder-klientpark-realisering.md](kilder-klientpark-realisering.md)),
|
||||
> ikke fritt oppdiktet innenfor fortellingen — men **raten er lånt, ikke målt på klientparken**,
|
||||
> og det står i `provenance`.
|
||||
|
||||
## Dommen
|
||||
|
||||
**Beslutning:** godkjent — med realiseringskorreksjon.
|
||||
|
||||
Den modellerte besparelsen (**445 500 NOK/år**) er teknisk korrekt fra parameterne, og
|
||||
validatoren bekrefter at den ligger godt innenfor feasibelt område. Men parameteren
|
||||
besparelsen henger på — driftstimer — er et **internt tabellanslag**, og klientparken har ingen
|
||||
måler som kan avsløre at anslaget bommer. Forventet faktisk besparelse settes til
|
||||
**≈ 360 855 NOK/år** (81 % av modellert).
|
||||
|
||||
## Begrunnelse (det validatoren ikke kan regne)
|
||||
|
||||
### Hovedmekanismen: driftstimene er stipulert, ikke målt
|
||||
|
||||
IT-driftshåndbokens 4 000–4 100 t/år gjelder «eldre arbeidsstasjoner» som kategori. Det er ikke
|
||||
en målt kurve for denne maskinparken, og **ingen kilde gir en målt driftstimekurve for
|
||||
klientparken**. Metoden ([metode-ipmvp-a.md](metode-ipmvp-a.md)) er Option A nettopp fordi
|
||||
måling er stengt — og Option A er den opsjonen som *tillater* å estimere denne parameteren.
|
||||
|
||||
Erfaringen fra virksomhetens belysningsprogrammer med samme effektligning og samme stipulerte
|
||||
parameter er entydig i retning: 2021-evalueringen metret **3 053 t/år** der programmet antok
|
||||
**3 772** (forholdet 0,809), og etterevalueringen fra 2010 kom uavhengig til en driftsjustering
|
||||
på **81,1 %** gjennom samme mekanisme. **0,81 er dette lånet, ikke en måling av klientparken.**
|
||||
|
||||
### Sekundære mekanismer, samme retning
|
||||
|
||||
- **Andel i drift < 1.** Ikke alle 2 500 maskinene er nødvendigvis utplassert og i bruk ved
|
||||
evaluering. En klientpark spredt over mange kontorer har lengre haler enn et bygg.
|
||||
- **Varighet.** Maskiner som feiler, blir stående avslått til neste utskiftingsrunde. En
|
||||
avslått maskin sparer riktignok energi, men leverer ikke tiltaket — og telles typisk ikke som
|
||||
besparelse i en evaluering.
|
||||
|
||||
### Motmekanismen — og hvorfor den IKKE er trukket fra
|
||||
|
||||
Én dokumentert mekanisme peker **motsatt vei**: en maskin merket 100 W er målt til å trekke
|
||||
**120 W** (stikkprøvemålingen). Er den faktiske baseline-effekten høyere enn merkeeffekten
|
||||
modellen regner med, er den faktiske besparelsen **større** enn modellert — det ville løftet
|
||||
realiseringsgraden.
|
||||
|
||||
Den er likevel ikke netto-regnet inn, av én grunn: **målingen finnes bare for den gamle
|
||||
maskinen.** Om den nye generasjonen har et tilsvarende påslag — og hvor stort — sier ingen kilde
|
||||
i materialet. Å anta at den nye maskinen treffer merkeeffekten eksakt, mens den gamle bommer med
|
||||
20 %, ville vært en gratis oppjustering av besparelsen bygget på fravær av data.
|
||||
|
||||
**Derfor er 0,81 en NEDRE grense, og den er merket slik.** En ekte ekspert med målt effekt
|
||||
for den nye maskingenerasjonen ville sannsynligvis satt raten høyere.
|
||||
|
||||
### Hvorfor dette ikke kan regnes fra parameterne
|
||||
|
||||
Du kan **ikke** regne deg til RR = 0,81 fra `{2 500, 114 W, 70 W, 4 050 t, 1,00 NOK/kWh}`.
|
||||
Skjevheten er epistemikk parameterne ikke bærer — den finnes bare i akkumulert
|
||||
drifts-erfaring, og i dette domenet finnes den ikke engang i virksomhetens egne måledata. Det er
|
||||
nøyaktig lærings-overflaten bundelen er bygget for.
|
||||
|
||||
## Lærings-signalet (ExpeL)
|
||||
|
||||
Korreksjonen er **kontekstbetinget**:
|
||||
`context_key = "klientpark; HOU-kilde=driftshaandbok-tabellverdi; maaling=fravaerende"`.
|
||||
|
||||
Neste kjøring, gitt en lignende hypotese i samme kontekst, skal hente denne dommen og justere
|
||||
den modellerte ex-ante-besparelsen mot forventet ex-post (≈ 0,81×) — uten å vente på 12
|
||||
måneders måling som uansett ikke kommer, fordi måleren ikke finnes.
|
||||
|
||||
`gap_source` er bevisst satt til **`hours-of-use-overestimation`**, samme nøkkel som
|
||||
kontorbygg-frøet bruker. Domenene er ulike, men mekanismen er den samme, og en lærings-sløyfa
|
||||
som ikke ser den koblingen lærer to ganger det den kunne lært én gang.
|
||||
|
||||
## Om tiltak 2 (adaptiv strømstyring)
|
||||
|
||||
Denne dommen gjelder **kun** PC-utskiftingen (`PC-KLIENT-01`). Styringstiltaket
|
||||
([tiltak-adaptiv-stromstyring.md](tiltak-adaptiv-stromstyring.md)) er ikke dømt her, og bør ikke
|
||||
arve raten: dets modellerte besparelse er en normmargin uten kostnadsside, og risikoprofilen er
|
||||
en annen — en styring som overstyres av drift leverer null, ikke 81 %.
|
||||
|
|
@ -22,12 +22,12 @@ Rekkefoelgen under er bevisst: **kandidat B er lenket foerst**, saa en detachet
|
|||
|
||||
## Innhold (progressiv disclosure)
|
||||
|
||||
- [verdict-b-asfalt.md](verdict-b-asfalt.md) — `type: verdict` — dom om **kandidat B**
|
||||
(asfalttykkelse, kode `05.2`). Bærer sine egne `affected_codes`/`measure_type`/
|
||||
- [verdict-b-lisens.md](verdict-b-lisens.md) — `type: verdict` — dom om **kandidat B**
|
||||
(lisensomfang, kode `05.2`). Bærer sine egne `affected_codes`/`measure_type`/
|
||||
`claimed_saving_nok`. Skal ALDRI naa kandidat As hypotese-prompt.
|
||||
- [verdict-a-led.md](verdict-a-led.md) — `type: verdict` — dom om **kandidat A**
|
||||
(LED-retrofit, kode `ENERGI-TOTAL-EL`). Dette er dommen kandidat As query skal hente.
|
||||
- [prosjekt-multi.md](prosjekt-multi.md) — `type: project` — bygget/strekningen begge kandidatene
|
||||
- [prosjekt-multi.md](prosjekt-multi.md) — `type: project` — bygget/lisensavtalen begge kandidatene
|
||||
hoerer til. Concept-filen OKF-navigasjonen leser inn som lese-kontekst.
|
||||
|
||||
`validator-input.json` er IR-projeksjonen den deterministiske validatoren konsumerer, og kilden for
|
||||
|
|
|
|||
|
|
@ -1,19 +1,19 @@
|
|||
---
|
||||
type: project
|
||||
title: "Kombinert bygg + veistrekning (syntetisk fixture-prosjekt)"
|
||||
description: "Syntetisk prosjekt som baerer to uavhengige kandidat-tiltak — ett energitiltak i kontorfloy A og ett dekketiltak paa veistrekning B."
|
||||
title: "Kombinert bygg + lisensavtale (syntetisk fixture-prosjekt)"
|
||||
description: "Syntetisk prosjekt som baerer to uavhengige kandidat-tiltak — ett energitiltak i kontorfloy A og ett lisenstiltak paa kontorpakke B."
|
||||
resource: MULTI-KANDIDAT-MIKRO
|
||||
tags: [fixture, project]
|
||||
timestamp: 2026-08-03
|
||||
---
|
||||
|
||||
# Kombinert bygg + veistrekning
|
||||
# Kombinert bygg + lisensavtale
|
||||
|
||||
Syntetisk fixture-prosjekt. To uavhengige tiltak er identifisert:
|
||||
|
||||
- **Kandidat A — LED-retrofit kontorfloy A.** Beroerer kostkode `ENERGI-TOTAL-EL`.
|
||||
Modellert besparelse 18 000 NOK/aar.
|
||||
- **Kandidat B — redusert asfalttykkelse veistrekning B.** Beroerer kostkode `05.2`.
|
||||
- **Kandidat B — redusert lisensomfang for kontorpakke B.** Beroerer kostkode `05.2`.
|
||||
Modellert besparelse 900 000 NOK.
|
||||
|
||||
Kandidatene deler verken kostkode, tiltakstype eller stoerrelsesorden. Det er med vilje: en dom om
|
||||
|
|
|
|||
|
|
@ -1,27 +0,0 @@
|
|||
---
|
||||
type: verdict
|
||||
title: "Ekspert-dom (froe) — redusert asfalttykkelse veistrekning B"
|
||||
description: "Froesatt dom om KANDIDAT B (dekketiltak). Baerer sine egne strukturelle felt, saa den noekles paa sin egen kandidat og ikke paa bundelens IR-projeksjon."
|
||||
resource: MULTI-KANDIDAT-MIKRO
|
||||
measure_id: ASFALT-B
|
||||
decision: rejected
|
||||
affected_codes: [05.2]
|
||||
measure_type: "Redusert asfalttykkelse veistrekning B"
|
||||
claimed_saving_nok: 900000
|
||||
realization_rate: 0.31
|
||||
expected_actual_saving_nok: 279000
|
||||
gap_source: levetidsforkortelse-gir-tidligere-reasfaltering
|
||||
provenance: "froe — AI-forfattet test-fixture for S3.2; ikke ekte data"
|
||||
tags: [verdict, fixture, kandidat-B]
|
||||
timestamp: 2026-08-03
|
||||
---
|
||||
|
||||
# Ekspert-dom (froe) — kandidat B
|
||||
|
||||
**Beslutning:** avvist.
|
||||
|
||||
Den modellerte besparelsen paa 900 000 NOK er regnemessig korrekt, men tynnere dekke forkorter
|
||||
levetiden saa mye at reasfaltering kommer tidligere. Livsloepsregnskapet blir negativt.
|
||||
|
||||
Denne dommen handler om **dekketiltaket**, ikke om energitiltaket. Den skal ikke hentes naar
|
||||
hypotesen gjelder LED-retrofit — kostkode, tiltakstype og stoerrelsesorden er alle ulike.
|
||||
|
|
@ -0,0 +1,28 @@
|
|||
---
|
||||
type: verdict
|
||||
title: "Ekspert-dom (froe) — redusert lisensomfang for kontorpakke B"
|
||||
description: "Froesatt dom om KANDIDAT B (lisenstiltak). Baerer sine egne strukturelle felt, saa den noekles paa sin egen kandidat og ikke paa bundelens IR-projeksjon."
|
||||
resource: MULTI-KANDIDAT-MIKRO
|
||||
measure_id: LISENS-B
|
||||
decision: rejected
|
||||
affected_codes: [05.2]
|
||||
measure_type: "Redusert lisensomfang for kontorpakke B"
|
||||
claimed_saving_nok: 900000
|
||||
realization_rate: 0.31
|
||||
expected_actual_saving_nok: 279000
|
||||
gap_source: faerre-lisenser-gir-tidligere-tvungen-etterkjoep-til-listepris
|
||||
provenance: "froe — AI-forfattet test-fixture for S3.2; ikke ekte data"
|
||||
tags: [verdict, fixture, kandidat-B]
|
||||
timestamp: 2026-08-03
|
||||
---
|
||||
|
||||
# Ekspert-dom (froe) — kandidat B
|
||||
|
||||
**Beslutning:** avvist.
|
||||
|
||||
Den modellerte besparelsen paa 900 000 NOK er regnemessig korrekt, men faerre lisenser enn brukere
|
||||
fanges opp ved neste lisensrevisjon, og da maa differansen etterkjoepes tidligere og til listepris.
|
||||
Livsloepsregnskapet blir negativt.
|
||||
|
||||
Denne dommen handler om **lisenstiltaket**, ikke om energitiltaket. Den skal ikke hentes naar
|
||||
hypotesen gjelder LED-retrofit — kostkode, tiltakstype og stoerrelsesorden er alle ulike.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
SYNTHETIC fixture (D4) — AI-authored, not verified domain content.
|
||||
|
||||
Cost saving measure candidate for Arkivlagring (migrering):
|
||||
Reducing the scope of the archive clean-up lowers the cost. Scope reduction on the
|
||||
migration works is the candidate cost-saving measure to validate.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
SYNTHETIC fixture (D4) — AI-authored, not verified domain content.
|
||||
|
||||
Cost saving measure candidate for Bru over Lakselva (rehabilitering):
|
||||
Reducing the scope on the concrete-repair area lowers the cost. Scope reduction on the
|
||||
rehabilitation works is the candidate cost-saving measure to validate.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
SYNTHETIC fixture (D4) — AI-authored, not verified domain content.
|
||||
|
||||
Cost saving measure candidate for Fv. 42 gang- og sykkelveg (etappe 1):
|
||||
A unit-rate renegotiation on code 05.2 (Asfalt Ab11) reduces the paving cost on this
|
||||
stretch. Reducing the asphalt scope is the candidate cost-saving measure to validate.
|
||||
5
src/portfolio_optimiser/data/docs/KONTOR-IT-E1/notes.txt
Normal file
5
src/portfolio_optimiser/data/docs/KONTOR-IT-E1/notes.txt
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
SYNTHETIC fixture (D4) — AI-authored, not verified domain content.
|
||||
|
||||
Cost saving measure candidate for Kontor-IT (etappe 1):
|
||||
A unit-price renegotiation on code 05.2 (Lisens kontorpakke) reduces the licence cost in this
|
||||
stage. Reducing the licence scope is the candidate cost-saving measure to validate.
|
||||
5
src/portfolio_optimiser/data/docs/NETT-SIKR-TP/notes.txt
Normal file
5
src/portfolio_optimiser/data/docs/NETT-SIKR-TP/notes.txt
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
SYNTHETIC fixture (D4) — AI-authored, not verified domain content.
|
||||
|
||||
Cost saving measure candidate for Nettverkssikring, tilkoblingspunkter:
|
||||
A material substitution on the cabling scope reduces the cost. Substituting the
|
||||
specified cabling material is the candidate cost-saving measure to validate on the connection points.
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
SYNTHETIC fixture (D4) — AI-authored, not verified domain content.
|
||||
|
||||
Cost saving measure candidate for Rv. 13 rassikring tunnelportal:
|
||||
A material substitution on the rock-support scope reduces the cost. Substituting the
|
||||
specified material is the candidate cost-saving measure to validate on the portal works.
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
okf_version: 0.2
|
||||
bundle_id: eksempel-driftskrav-2027
|
||||
---
|
||||
|
||||
# Kataloger
|
||||
|
||||
- [krav](krav/index.md) — 303 konsepter under krav.
|
||||
- [standard](standard/index.md) — 3 konsepter under standard.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.1—4 Skjermer
|
||||
description: Forebyggende vedlikehold av skjermene på arbeidsplassene skal utføres minst 6 ganger per år.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 4.1—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '4.1'
|
||||
seksjonstittel: Skjermer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-043e34b1-398d-595c-b865-f764f0385c92
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Forebyggende vedlikehold av skjermene på arbeidsplassene skal utføres minst 6 ganger per år.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Vedlikeholdet følger produsentens anvisning og protokollføres i vedlikeholdsplanen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.2—3 Responstid
|
||||
description: Avvik som gjelder responstiden for henvendelser, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.2—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.2'
|
||||
seksjonstittel: Responstid
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-09ee11bf-4e1c-51e7-8848-2833e94e6b47
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Avvik som gjelder responstiden for henvendelser, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjentatte avvik av samme art behandles som et problem og følges opp særskilt.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.1—1 Standardklient
|
||||
description: Standardklienten skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.1—1
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.1'
|
||||
seksjonstittel: Standardklient
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-0b20e297-e902-5f0b-9e1a-c761f7ff4f20
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Standardklienten skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Dokumentasjonen holdes i driftshåndboken og oppdateres ved hver endring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.1—4 Brukerkontoer
|
||||
description: Brukerkontoene skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.1—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.1'
|
||||
seksjonstittel: Brukerkontoer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-2d183857-4c4c-5195-9580-21686bf05297
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Brukerkontoene skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Dokumentasjonen holdes i driftshåndboken og oppdateres ved hver endring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.2—4 Tofaktorpålogging
|
||||
description: Tofaktorpåloggingen skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.2—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.2'
|
||||
seksjonstittel: Tofaktorpålogging
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-2dbf9503-c02f-59ba-b3fe-442111144b0d
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Tofaktorpåloggingen skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Varslingstiden regnes fra avviket oppstår til driftssenteret har mottatt alarmen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.2—2 Programvaredistribusjon
|
||||
description: Forebyggende vedlikehold av programvaredistribusjonen skal utføres minst 2 ganger per år.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.2—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.2'
|
||||
seksjonstittel: Programvaredistribusjon
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-31ea1092-02f4-5154-ac08-f2755b0cf51e
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Forebyggende vedlikehold av programvaredistribusjonen skal utføres minst 2 ganger per år.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Vedlikeholdet følger produsentens anvisning og protokollføres i vedlikeholdsplanen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.1—4 Standardklient
|
||||
description: Standardklienten skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.1—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.1'
|
||||
seksjonstittel: Standardklient
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-32cdc1f8-8983-5a85-ac9a-c5e4b6c03aae
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Standardklienten skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Testen gjennomføres i et avtalt vindu og med en plan for tilbakeføring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.1—2 Skjermer
|
||||
description: Skjermene på arbeidsplassene skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 4.1—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '4.1'
|
||||
seksjonstittel: Skjermer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-3381b860-dc37-58d0-a62e-7349c969f210
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Skjermene på arbeidsplassene skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Dokumentasjonen holdes i driftshåndboken og oppdateres ved hver endring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.2—1 Tofaktorpålogging
|
||||
description: Avvik som gjelder tofaktorpåloggingen, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.2—1
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.2'
|
||||
seksjonstittel: Tofaktorpålogging
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-3a93708b-6a6e-59e8-aa7b-20226b03950c
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Avvik som gjelder tofaktorpåloggingen, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjentatte avvik av samme art behandles som et problem og følges opp særskilt.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.1—4 Tjenestedisk
|
||||
description: Avvik som gjelder tjenestedisken, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.1—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.1'
|
||||
seksjonstittel: Tjenestedisk
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-3af268ca-c1a9-539a-b149-a18028902441
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Avvik som gjelder tjenestedisken, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjentatte avvik av samme art behandles som et problem og følges opp særskilt.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.2—1 Programvaredistribusjon
|
||||
description: Programvaredistribusjonen skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.2—1
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.2'
|
||||
seksjonstittel: Programvaredistribusjon
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-3b0d2242-c7ef-50bd-b192-12607414c6da
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Programvaredistribusjonen skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Varslingstiden regnes fra avviket oppstår til driftssenteret har mottatt alarmen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.1—1 Tjenestedisk
|
||||
description: Tjenestedisken skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.1—1
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.1'
|
||||
seksjonstittel: Tjenestedisk
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-3c3b0b12-ec53-543e-8019-6543ddcb5ace
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Tjenestedisken skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Testen gjennomføres i et avtalt vindu og med en plan for tilbakeføring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.2.5.1—1 Skjerm og kamera
|
||||
description: Hvert møterom med fast utstyr skal ha skjerm og kamera som dekker alle sitteplasser.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 4.2.5.1—1
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: 4.2.5.1
|
||||
seksjonstittel: Skjerm og kamera
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-4b544bf4-9a69-5e43-b5d7-4603333da63d
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Hvert møterom med fast utstyr skal ha skjerm og kamera som dekker alle sitteplasser.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Kravene gjelder møterom med fast utstyr. Mobile løsninger omfattes ikke.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.1—3 Brukerkontoer
|
||||
description: Brukerkontoene bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
kravtype: bør
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.1—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.1'
|
||||
seksjonstittel: Brukerkontoer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-5e7bbfa7-2d50-5079-af1f-3559c09c0a3d
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Brukerkontoene bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjennomgangen kan samordnes med den årlige risikovurderingen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.1—3 Standardklient
|
||||
description: Forebyggende vedlikehold av standardklienten skal utføres minst 2 ganger per år.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.1—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.1'
|
||||
seksjonstittel: Standardklient
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-5ed36ed9-0527-578d-a126-1d0d3c6b2746
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Forebyggende vedlikehold av standardklienten skal utføres minst 2 ganger per år.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Vedlikeholdet følger produsentens anvisning og protokollføres i vedlikeholdsplanen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.2—4 Programvaredistribusjon
|
||||
description: Endringer i programvaredistribusjonen skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.2—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.2'
|
||||
seksjonstittel: Programvaredistribusjon
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-6013aebb-a775-5334-90a6-de8410eb901d
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Endringer i programvaredistribusjonen skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Mindre standardendringer kan forhåndsgodkjennes i endringsrutinen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.1—1 Skjermer
|
||||
description: Skjermene på arbeidsplassene bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
kravtype: bør
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 4.1—1
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '4.1'
|
||||
seksjonstittel: Skjermer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-61b2c531-1cbf-5462-8be2-e33ed38bbceb
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Skjermene på arbeidsplassene bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjennomgangen kan samordnes med den årlige risikovurderingen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.2.5.1—2 Skjerm og kamera
|
||||
description: Skjermen skal kunne vise innhold fra både bærbar klient og videomøte uten omkobling av kabler.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 4.2.5.1—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: 4.2.5.1
|
||||
seksjonstittel: Skjerm og kamera
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-61cd0465-f6e0-5bb6-ae26-0df3a432ba89
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Skjermen skal kunne vise innhold fra både bærbar klient og videomøte uten omkobling av kabler.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Kravene gjelder møterom med fast utstyr. Mobile løsninger omfattes ikke.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.1—5 Tjenestedisk
|
||||
description: Tjenestedisken bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
kravtype: bør
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.1—5
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.1'
|
||||
seksjonstittel: Tjenestedisk
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-6515abcc-8669-5c80-8783-82b317276fb3
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Tjenestedisken bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjennomgangen kan samordnes med den årlige risikovurderingen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.2—1 Responstid
|
||||
description: Endringer i responstiden for henvendelser skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.2—1
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.2'
|
||||
seksjonstittel: Responstid
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-6752526d-d3b1-5dd7-9d21-6178144b87f9
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Endringer i responstiden for henvendelser skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Mindre standardendringer kan forhåndsgodkjennes i endringsrutinen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.1—6 Tjenestedisk
|
||||
description: Tjenestedisken skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.1—6
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.1'
|
||||
seksjonstittel: Tjenestedisk
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-6a757b38-3724-5355-9d9c-aa2a42394072
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Tjenestedisken skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Dokumentasjonen holdes i driftshåndboken og oppdateres ved hver endring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.2—3 Tofaktorpålogging
|
||||
description: Tofaktorpåloggingen skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.2—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.2'
|
||||
seksjonstittel: Tofaktorpålogging
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-6ac13607-e83e-54d0-a039-34e00849180b
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Tofaktorpåloggingen skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Dokumentasjonen holdes i driftshåndboken og oppdateres ved hver endring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.2—3 Programvaredistribusjon
|
||||
description: Programvaredistribusjonen skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.2—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.2'
|
||||
seksjonstittel: Programvaredistribusjon
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-6d71ea0a-75ef-5c9b-9eb6-d2124e516aea
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Programvaredistribusjonen skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Testen gjennomføres i et avtalt vindu og med en plan for tilbakeføring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.2—4 Responstid
|
||||
description: Responstiden for henvendelser bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
kravtype: bør
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.2—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.2'
|
||||
seksjonstittel: Responstid
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-73c50e39-387f-5719-9a17-a4f61d5b49a7
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Responstiden for henvendelser bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjennomgangen kan samordnes med den årlige risikovurderingen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.1—6 Standardklient
|
||||
description: Standardklienten skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.1—6
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.1'
|
||||
seksjonstittel: Standardklient
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-7a23b916-615c-561f-8e07-b96cbfc36cad
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Standardklienten skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Reserven vurderes på nytt når driftsklassen for en tjeneste endres.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.2—5 Programvaredistribusjon
|
||||
description: Programvaredistribusjonen skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.2—5
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.2'
|
||||
seksjonstittel: Programvaredistribusjon
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-7aae14de-7104-5f41-8ff5-baf031a721f2
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Programvaredistribusjonen skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Reserven vurderes på nytt når driftsklassen for en tjeneste endres.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.2.5.1—3 Skjerm og kamera
|
||||
description: Skjerm og kamera skal kunne styres fra ett panel, og oppsettet skal være likt i alle møterom av samme størrelse.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 4.2.5.1—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: 4.2.5.1
|
||||
seksjonstittel: Skjerm og kamera
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-7aed3659-dbbe-5eb5-9b96-e6a693ff0c3c
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Skjerm og kamera skal kunne styres fra ett panel, og oppsettet skal være likt i alle møterom av samme størrelse.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Kravene gjelder møterom med fast utstyr. Mobile løsninger omfattes ikke.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.2—5 Tofaktorpålogging
|
||||
description: Forebyggende vedlikehold av tofaktorpåloggingen skal utføres minst 6 ganger per år.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.2—5
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.2'
|
||||
seksjonstittel: Tofaktorpålogging
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-7f6ea2de-0473-5bae-9863-57d2d96e635c
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Forebyggende vedlikehold av tofaktorpåloggingen skal utføres minst 6 ganger per år.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Vedlikeholdet følger produsentens anvisning og protokollføres i vedlikeholdsplanen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.1—5 Standardklient
|
||||
description: Endringer i standardklienten skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.1—5
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.1'
|
||||
seksjonstittel: Standardklient
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-89ccf745-19a2-557f-ac2b-d9624d5180b8
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Endringer i standardklienten skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Mindre standardendringer kan forhåndsgodkjennes i endringsrutinen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.1—2 Brukerkontoer
|
||||
description: Avvik som gjelder brukerkontoene, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.1—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.1'
|
||||
seksjonstittel: Brukerkontoer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-8ca188bd-9f83-5682-8520-3ec1181fd7d9
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Avvik som gjelder brukerkontoene, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjentatte avvik av samme art behandles som et problem og følges opp særskilt.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.3—1 Oppdateringer
|
||||
description: Forebyggende vedlikehold av oppdateringsrutinen for klienter skal utføres minst 2 ganger per år.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.3—1
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.3'
|
||||
seksjonstittel: Oppdateringer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-9f32dabc-4eb0-5e21-b31c-49e724f9439b
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Forebyggende vedlikehold av oppdateringsrutinen for klienter skal utføres minst 2 ganger per år.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Vedlikeholdet følger produsentens anvisning og protokollføres i vedlikeholdsplanen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.2—2 Tofaktorpålogging
|
||||
description: Tofaktorpåloggingen bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
kravtype: bør
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.2—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.2'
|
||||
seksjonstittel: Tofaktorpålogging
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-a12a4e57-888d-5003-a915-0a2e1313925c
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Tofaktorpåloggingen bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjennomgangen kan samordnes med den årlige risikovurderingen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.1—5 Brukerkontoer
|
||||
description: Brukerkontoene skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.1—5
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.1'
|
||||
seksjonstittel: Brukerkontoer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-b2b897ba-9d8f-59c6-835a-988b4cace873
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Brukerkontoene skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Varslingstiden regnes fra avviket oppstår til driftssenteret har mottatt alarmen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.3—5 Oppdateringer
|
||||
description: Avvik som gjelder oppdateringsrutinen for klienter, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.3—5
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.3'
|
||||
seksjonstittel: Oppdateringer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-bbf5f446-012e-5bd1-86ee-da0f4d447f65
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Avvik som gjelder oppdateringsrutinen for klienter, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjentatte avvik av samme art behandles som et problem og følges opp særskilt.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.1—6 Brukerkontoer
|
||||
description: Forebyggende vedlikehold av brukerkontoene skal utføres minst 6 ganger per år.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.1—6
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.1'
|
||||
seksjonstittel: Brukerkontoer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-bda50675-dbe9-5e46-afd7-1a4bd0e12b68
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Forebyggende vedlikehold av brukerkontoene skal utføres minst 6 ganger per år.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Vedlikeholdet følger produsentens anvisning og protokollføres i vedlikeholdsplanen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.1—3 Tjenestedisk
|
||||
description: Tjenestedisken skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.1—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.1'
|
||||
seksjonstittel: Tjenestedisk
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-c217013c-bfe5-57e6-9e11-b7988b495ee8
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Tjenestedisken skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Reserven vurderes på nytt når driftsklassen for en tjeneste endres.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.1—1 Brukerkontoer
|
||||
description: Brukerkontoene skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 3.1—1
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.1'
|
||||
seksjonstittel: Brukerkontoer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-c707ab8f-9672-5851-a943-6f1eeed18a22
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Brukerkontoene skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Reserven vurderes på nytt når driftsklassen for en tjeneste endres.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.3—2 Oppdateringer
|
||||
description: Oppdateringsrutinen for klienter skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.3—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.3'
|
||||
seksjonstittel: Oppdateringer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-ca6b4eea-d6da-586b-b84e-4eb36efe4ada
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Oppdateringsrutinen for klienter skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Testen gjennomføres i et avtalt vindu og med en plan for tilbakeføring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.2—2 Responstid
|
||||
description: Responstiden for henvendelser skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.2—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.2'
|
||||
seksjonstittel: Responstid
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-d1da2db3-3c5b-54cc-ac6e-8638508a27c0
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Responstiden for henvendelser skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Reserven vurderes på nytt når driftsklassen for en tjeneste endres.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.1—2 Tjenestedisk
|
||||
description: Endringer i tjenestedisken skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.1—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.1'
|
||||
seksjonstittel: Tjenestedisk
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-d8dc058e-8fd2-54e2-9dba-d3215352d350
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Endringer i tjenestedisken skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Mindre standardendringer kan forhåndsgodkjennes i endringsrutinen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.1—3 Skjermer
|
||||
description: Skjermene på arbeidsplassene skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 4.1—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '4.1'
|
||||
seksjonstittel: Skjermer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-de9addd6-1ced-50cf-a8ce-09106005a965
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Skjermene på arbeidsplassene skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Varslingstiden regnes fra avviket oppstår til driftssenteret har mottatt alarmen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.3—3 Oppdateringer
|
||||
description: Endringer i oppdateringsrutinen for klienter skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.3—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.3'
|
||||
seksjonstittel: Oppdateringer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-e321f401-952f-51ca-a5f0-917cfd4de0b4
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Endringer i oppdateringsrutinen for klienter skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Mindre standardendringer kan forhåndsgodkjennes i endringsrutinen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.3—4 Oppdateringer
|
||||
description: Oppdateringsrutinen for klienter skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.3—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.3'
|
||||
seksjonstittel: Oppdateringer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-e5099592-788e-5f46-95d6-cc21fef5e337
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Oppdateringsrutinen for klienter skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Reserven vurderes på nytt når driftsklassen for en tjeneste endres.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 1.1—2 Standardklient
|
||||
description: Standardklienten skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 1.1—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '1.1'
|
||||
seksjonstittel: Standardklient
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-f978ebc0-5dbb-51d0-9ce2-e98949b4bb9e
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Standardklienten skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Varslingstiden regnes fra avviket oppstår til driftssenteret har mottatt alarmen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.2—5 Responstid
|
||||
description: Responstiden for henvendelser skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
kravtype: skal
|
||||
standard: D100
|
||||
utgave: D100:2027
|
||||
req_number: Krav 2.2—5
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.2'
|
||||
seksjonstittel: Responstid
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-fba1cf11-b078-5133-8584-84131da0e227
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d100
|
||||
title: D100:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Responstiden for henvendelser skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Dokumentasjonen holdes i driftshåndboken og oppdateres ved hver endring.
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
# Krav
|
||||
|
||||
- [Krav 1.1—1 Standardklient](id-0b20e297-e902-5f0b-9e1a-c761f7ff4f20.md) — Standardklienten skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
- [Krav 1.1—2 Standardklient](id-f978ebc0-5dbb-51d0-9ce2-e98949b4bb9e.md) — Standardklienten skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
- [Krav 1.1—3 Standardklient](id-5ed36ed9-0527-578d-a126-1d0d3c6b2746.md) — Forebyggende vedlikehold av standardklienten skal utføres minst 2 ganger per år.
|
||||
- [Krav 1.1—4 Standardklient](id-32cdc1f8-8983-5a85-ac9a-c5e4b6c03aae.md) — Standardklienten skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
- [Krav 1.1—5 Standardklient](id-89ccf745-19a2-557f-ac2b-d9624d5180b8.md) — Endringer i standardklienten skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
- [Krav 1.1—6 Standardklient](id-7a23b916-615c-561f-8e07-b96cbfc36cad.md) — Standardklienten skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
- [Krav 1.2—1 Programvaredistribusjon](id-3b0d2242-c7ef-50bd-b192-12607414c6da.md) — Programvaredistribusjonen skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
- [Krav 1.2—2 Programvaredistribusjon](id-31ea1092-02f4-5154-ac08-f2755b0cf51e.md) — Forebyggende vedlikehold av programvaredistribusjonen skal utføres minst 2 ganger per år.
|
||||
- [Krav 1.2—3 Programvaredistribusjon](id-6d71ea0a-75ef-5c9b-9eb6-d2124e516aea.md) — Programvaredistribusjonen skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
- [Krav 1.2—4 Programvaredistribusjon](id-6013aebb-a775-5334-90a6-de8410eb901d.md) — Endringer i programvaredistribusjonen skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
- [Krav 1.2—5 Programvaredistribusjon](id-7aae14de-7104-5f41-8ff5-baf031a721f2.md) — Programvaredistribusjonen skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
- [Krav 1.3—1 Oppdateringer](id-9f32dabc-4eb0-5e21-b31c-49e724f9439b.md) — Forebyggende vedlikehold av oppdateringsrutinen for klienter skal utføres minst 2 ganger per år.
|
||||
- [Krav 1.3—2 Oppdateringer](id-ca6b4eea-d6da-586b-b84e-4eb36efe4ada.md) — Oppdateringsrutinen for klienter skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
- [Krav 1.3—3 Oppdateringer](id-e321f401-952f-51ca-a5f0-917cfd4de0b4.md) — Endringer i oppdateringsrutinen for klienter skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
- [Krav 1.3—4 Oppdateringer](id-e5099592-788e-5f46-95d6-cc21fef5e337.md) — Oppdateringsrutinen for klienter skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
- [Krav 1.3—5 Oppdateringer](id-bbf5f446-012e-5bd1-86ee-da0f4d447f65.md) — Avvik som gjelder oppdateringsrutinen for klienter, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
- [Krav 2.1—1 Tjenestedisk](id-3c3b0b12-ec53-543e-8019-6543ddcb5ace.md) — Tjenestedisken skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
- [Krav 2.1—2 Tjenestedisk](id-d8dc058e-8fd2-54e2-9dba-d3215352d350.md) — Endringer i tjenestedisken skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
- [Krav 2.1—3 Tjenestedisk](id-c217013c-bfe5-57e6-9e11-b7988b495ee8.md) — Tjenestedisken skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
- [Krav 2.1—4 Tjenestedisk](id-3af268ca-c1a9-539a-b149-a18028902441.md) — Avvik som gjelder tjenestedisken, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
- [Krav 2.1—5 Tjenestedisk](id-6515abcc-8669-5c80-8783-82b317276fb3.md) — Tjenestedisken bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
- [Krav 2.1—6 Tjenestedisk](id-6a757b38-3724-5355-9d9c-aa2a42394072.md) — Tjenestedisken skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
- [Krav 2.2—1 Responstid](id-6752526d-d3b1-5dd7-9d21-6178144b87f9.md) — Endringer i responstiden for henvendelser skal gjennomføres etter godkjent endringsrutine og med plan for tilbakeføring.
|
||||
- [Krav 2.2—2 Responstid](id-d1da2db3-3c5b-54cc-ac6e-8638508a27c0.md) — Responstiden for henvendelser skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
- [Krav 2.2—3 Responstid](id-09ee11bf-4e1c-51e7-8848-2833e94e6b47.md) — Avvik som gjelder responstiden for henvendelser, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
- [Krav 2.2—4 Responstid](id-73c50e39-387f-5719-9a17-a4f61d5b49a7.md) — Responstiden for henvendelser bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
- [Krav 2.2—5 Responstid](id-fba1cf11-b078-5133-8584-84131da0e227.md) — Responstiden for henvendelser skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
- [Krav 3.1—1 Brukerkontoer](id-c707ab8f-9672-5851-a943-6f1eeed18a22.md) — Brukerkontoene skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
- [Krav 3.1—2 Brukerkontoer](id-8ca188bd-9f83-5682-8520-3ec1181fd7d9.md) — Avvik som gjelder brukerkontoene, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
- [Krav 3.1—3 Brukerkontoer](id-5e7bbfa7-2d50-5079-af1f-3559c09c0a3d.md) — Brukerkontoene bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
- [Krav 3.1—4 Brukerkontoer](id-2d183857-4c4c-5195-9580-21686bf05297.md) — Brukerkontoene skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
- [Krav 3.1—5 Brukerkontoer](id-b2b897ba-9d8f-59c6-835a-988b4cace873.md) — Brukerkontoene skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
- [Krav 3.1—6 Brukerkontoer](id-bda50675-dbe9-5e46-afd7-1a4bd0e12b68.md) — Forebyggende vedlikehold av brukerkontoene skal utføres minst 6 ganger per år.
|
||||
- [Krav 3.2—1 Tofaktorpålogging](id-3a93708b-6a6e-59e8-aa7b-20226b03950c.md) — Avvik som gjelder tofaktorpåloggingen, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
- [Krav 3.2—2 Tofaktorpålogging](id-a12a4e57-888d-5003-a915-0a2e1313925c.md) — Tofaktorpåloggingen bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
- [Krav 3.2—3 Tofaktorpålogging](id-6ac13607-e83e-54d0-a039-34e00849180b.md) — Tofaktorpåloggingen skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
- [Krav 3.2—4 Tofaktorpålogging](id-2dbf9503-c02f-59ba-b3fe-442111144b0d.md) — Tofaktorpåloggingen skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
- [Krav 3.2—5 Tofaktorpålogging](id-7f6ea2de-0473-5bae-9863-57d2d96e635c.md) — Forebyggende vedlikehold av tofaktorpåloggingen skal utføres minst 6 ganger per år.
|
||||
- [Krav 4.1—1 Skjermer](id-61b2c531-1cbf-5462-8be2-e33ed38bbceb.md) — Skjermene på arbeidsplassene bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
- [Krav 4.1—2 Skjermer](id-3381b860-dc37-58d0-a62e-7349c969f210.md) — Skjermene på arbeidsplassene skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
- [Krav 4.1—3 Skjermer](id-de9addd6-1ced-50cf-a8ce-09106005a965.md) — Skjermene på arbeidsplassene skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
- [Krav 4.1—4 Skjermer](id-043e34b1-398d-595c-b865-f764f0385c92.md) — Forebyggende vedlikehold av skjermene på arbeidsplassene skal utføres minst 6 ganger per år.
|
||||
- [Krav 4.2.5.1—1 Skjerm og kamera](id-4b544bf4-9a69-5e43-b5d7-4603333da63d.md) — Hvert møterom med fast utstyr skal ha skjerm og kamera som dekker alle sitteplasser.
|
||||
- [Krav 4.2.5.1—2 Skjerm og kamera](id-61cd0465-f6e0-5bb6-ae26-0df3a432ba89.md) — Skjermen skal kunne vise innhold fra både bærbar klient og videomøte uten omkobling av kabler.
|
||||
- [Krav 4.2.5.1—3 Skjerm og kamera](id-7aed3659-dbbe-5eb5-9b96-e6a693ff0c3c.md) — Skjerm og kamera skal kunne styres fra ett panel, og oppsettet skal være likt i alle møterom av samme størrelse.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 5.2.1—7 Kopifrekvens
|
||||
description: Avvik som gjelder sikkerhetskopieringen, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 5.2.1—7
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: 5.2.1
|
||||
seksjonstittel: Kopifrekvens
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-00c76369-1ff0-5d90-93ec-25640f796e6a
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Avvik som gjelder sikkerhetskopieringen, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjentatte avvik av samme art behandles som et problem og følges opp særskilt.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 7.4—5 Endringer
|
||||
description: Endringsrutinen bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
kravtype: bør
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 7.4—5
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '7.4'
|
||||
seksjonstittel: Endringer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-01c0a039-3ca0-548c-97a7-bbb730b4adc8
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Endringsrutinen bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjennomgangen kan samordnes med den årlige risikovurderingen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.2.1—4 Autonomitid
|
||||
description: Der nødstrømsaggregat mangler, skal autonomitiden være lang nok til kontrollert nedstenging av alle tjenester i driftsklasse 1 og 2.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 3.2.1—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: 3.2.1
|
||||
seksjonstittel: Autonomitid
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-02116c7b-51fe-5aa6-b683-5b45bf61e0de
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Der nødstrømsaggregat mangler, skal autonomitiden være lang nok til kontrollert nedstenging av alle tjenester i driftsklasse 1 og 2.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Autonomitiden gjelder UPS-anlegget alene, uten bidrag fra nødstrømsaggregatet.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.2.1—2 Kaldgang
|
||||
description: Kaldgangen skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 4.2.1—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: 4.2.1
|
||||
seksjonstittel: Kaldgang
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-02a12d1c-119f-597c-a03a-63510a7aa683
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Kaldgangen skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Testen gjennomføres i et avtalt vindu og med en plan for tilbakeføring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.1.2—3 Redundans
|
||||
description: Forebyggende vedlikehold av redundansen i kjøleanlegget skal utføres minst 4 ganger per år.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 4.1.2—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: 4.1.2
|
||||
seksjonstittel: Redundans
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-0352de3f-c3c3-5f09-8900-b14068fab21f
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Forebyggende vedlikehold av redundansen i kjøleanlegget skal utføres minst 4 ganger per år.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Vedlikeholdet følger produsentens anvisning og protokollføres i vedlikeholdsplanen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.4—6 Brannsikring
|
||||
description: Brannslokkeanlegget skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 2.4—6
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.4'
|
||||
seksjonstittel: Brannsikring
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-051d77da-3512-5f64-9f51-4204862c9311
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Brannslokkeanlegget skal funksjonstestes minst én gang per år, og resultatet skal protokollføres.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Testen gjennomføres i et avtalt vindu og med en plan for tilbakeføring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 7.3—1 Vedlikehold
|
||||
description: Forebyggende vedlikehold av vedlikeholdsplanen skal utføres minst 6 ganger per år.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 7.3—1
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '7.3'
|
||||
seksjonstittel: Vedlikehold
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-0560cc6c-ba65-54fe-abc7-4f78f0748f02
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Forebyggende vedlikehold av vedlikeholdsplanen skal utføres minst 6 ganger per år.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Vedlikeholdet følger produsentens anvisning og protokollføres i vedlikeholdsplanen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.4—3 Brannsikring
|
||||
description: Brannslokkeanlegget skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 2.4—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.4'
|
||||
seksjonstittel: Brannsikring
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-05ce92d0-ba4f-53d1-a0a6-b42868b3cb9a
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Brannslokkeanlegget skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Dokumentasjonen holdes i driftshåndboken og oppdateres ved hver endring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 3.3—2 Nødstrømsaggregat
|
||||
description: Nødstrømsaggregatet skal ha en kapasitetsreserve på minst 30 % ved normal last.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 3.3—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '3.3'
|
||||
seksjonstittel: Nødstrømsaggregat
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-0886d9d5-f11d-5dd7-a2de-0f5f3b713f40
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Nødstrømsaggregatet skal ha en kapasitetsreserve på minst 30 % ved normal last.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Reserven vurderes på nytt når driftsklassen for en tjeneste endres.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.2—2 Gulv og bæreevne
|
||||
description: Det tekniske gulvet skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 2.2—2
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.2'
|
||||
seksjonstittel: Gulv og bæreevne
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-08f982b6-d86b-58d2-883a-99c5c6c0bbc1
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Det tekniske gulvet skal ha en kapasitetsreserve på minst 15 % ved normal last.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Reserven vurderes på nytt når driftsklassen for en tjeneste endres.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 7.5—5 Avvik
|
||||
description: Avvikshåndteringen skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 7.5—5
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '7.5'
|
||||
seksjonstittel: Avvik
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-0a1a5f16-5fc1-5ae4-9468-4fda92817063
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Avvikshåndteringen skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Dokumentasjonen holdes i driftshåndboken og oppdateres ved hver endring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 7.4—6 Endringer
|
||||
description: Endringsrutinen skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 7.4—6
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '7.4'
|
||||
seksjonstittel: Endringer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-0bcca624-3699-545d-bd27-cc92cb16fe49
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Endringsrutinen skal være dokumentert med eier, plassering og driftsrutiner før tjenesten settes i drift.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Dokumentasjonen holdes i driftshåndboken og oppdateres ved hver endring.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 5.1—8 Lagringssystemer
|
||||
description: Avvik som gjelder lagringssystemene, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 5.1—8
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '5.1'
|
||||
seksjonstittel: Lagringssystemer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-0d247825-9402-584d-b697-08ffd46497a5
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Avvik som gjelder lagringssystemene, skal registreres i avvikssystemet og lukkes med dokumentert årsak.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjentatte avvik av samme art behandles som et problem og følges opp særskilt.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.1.1—4 Dimensjonering
|
||||
description: Kjølekapasiteten skal kunne utvides trinnvis uten at serverrommet må tas ut av drift.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 4.1.1—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: 4.1.1
|
||||
seksjonstittel: Dimensjonering
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-111fbeb9-095b-58e0-9976-30a5b158d0e7
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Kjølekapasiteten skal kunne utvides trinnvis uten at serverrommet må tas ut av drift.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Målt varmelast er grunnlaget. Installert merkeeffekt overvurderer som regel lasten.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 5.1—4 Lagringssystemer
|
||||
description: Forebyggende vedlikehold av lagringssystemene skal utføres minst 2 ganger per år.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 5.1—4
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '5.1'
|
||||
seksjonstittel: Lagringssystemer
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-11d85cc1-7c75-5f2a-83e9-fb0ee62e3a71
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Forebyggende vedlikehold av lagringssystemene skal utføres minst 2 ganger per år.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Vedlikeholdet følger produsentens anvisning og protokollføres i vedlikeholdsplanen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.4—3 Frikjøling
|
||||
description: Omkoblingen mellom frikjøling og mekanisk kjøling skal ikke gi temperaturavvik utenfor tillatt område i serverrommet.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 4.4—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '4.4'
|
||||
seksjonstittel: Frikjøling
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-13864acf-cfe3-54f9-9207-9d10c718f008
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Omkoblingen mellom frikjøling og mekanisk kjøling skal ikke gi temperaturavvik utenfor tillatt område i serverrommet.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Frikjøling reduserer driften av kompressorer i de kalde delene av året.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 6.1—6 Kjernenett
|
||||
description: Kjernenettet skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 6.1—6
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '6.1'
|
||||
seksjonstittel: Kjernenett
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-14dd01b7-f1d2-572e-be4c-0fd5d244c413
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Kjernenettet skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Varslingstiden regnes fra avviket oppstår til driftssenteret har mottatt alarmen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 2.5—3 Vannlekkasje
|
||||
description: Lekkasjedeteksjonen skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 2.5—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '2.5'
|
||||
seksjonstittel: Vannlekkasje
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-1673cf98-0848-5c87-9828-15362e0c5b10
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Lekkasjedeteksjonen skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Varslingstiden regnes fra avviket oppstår til driftssenteret har mottatt alarmen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 6.2—3 Kabling
|
||||
description: Kablingen bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
kravtype: bør
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 6.2—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '6.2'
|
||||
seksjonstittel: Kabling
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-178acca3-ccf6-5468-b219-0213fe80b4ae
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Kablingen bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjennomgangen kan samordnes med den årlige risikovurderingen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 7.1—6 Overvåking
|
||||
description: Overvåkingssystemet skal ha en kapasitetsreserve på minst 25 % ved normal last.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 7.1—6
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '7.1'
|
||||
seksjonstittel: Overvåking
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-1aae90f4-d2fb-5074-9dbe-4a4106126113
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Overvåkingssystemet skal ha en kapasitetsreserve på minst 25 % ved normal last.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Reserven vurderes på nytt når driftsklassen for en tjeneste endres.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 4.1.1—3 Dimensjonering
|
||||
description: Dimensjonerende varmelast skal måles over minst fire uker før kapasiteten fastsettes.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 4.1.1—3
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: 4.1.1
|
||||
seksjonstittel: Dimensjonering
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-1aeae705-0d34-5082-a64b-57cb9e788abf
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Dimensjonerende varmelast skal måles over minst fire uker før kapasiteten fastsettes.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Målt varmelast er grunnlaget. Installert merkeeffekt overvurderer som regel lasten.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 5.2.3—6 Gjenoppretting
|
||||
description: Gjenopprettingen fra sikkerhetskopi bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
kravtype: bør
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 5.2.3—6
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: 5.2.3
|
||||
seksjonstittel: Gjenoppretting
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-1e051cb4-0366-5494-8a9b-58c74ca8931b
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Gjenopprettingen fra sikkerhetskopi bør gjennomgås årlig mot gjeldende trusselbilde og driftsbehov.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Gjennomgangen kan samordnes med den årlige risikovurderingen.
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
type: Krav
|
||||
title: Krav 6.2—5 Kabling
|
||||
description: Kablingen skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
kravtype: skal
|
||||
standard: D200
|
||||
utgave: D200:2027
|
||||
req_number: Krav 6.2—5
|
||||
status: stable
|
||||
trust_tier: unverified
|
||||
seksjon: '6.2'
|
||||
seksjonstittel: Kabling
|
||||
ingested_at: 2027-01-15T12:00:00Z
|
||||
source_element_id: id-207db394-bd7f-5295-9940-376497208705
|
||||
sources:
|
||||
- resource: https://example.invalid/eksempelvirksomheten/driftskrav/d200
|
||||
title: D200:2027
|
||||
---
|
||||
|
||||
## Krav
|
||||
|
||||
Kablingen skal overvåkes kontinuerlig, og avvik skal varsles til driftssenteret innen 15 minutter.
|
||||
|
||||
## Veiledning (ikke-normativ)
|
||||
|
||||
Varslingstiden regnes fra avviket oppstår til driftssenteret har mottatt alarmen.
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Add a link
Reference in a new issue