Datamodellen forklart

Modellen er delt i to lag som forvaltes ulikt:

Skillet er det som gjør data sammenlignbare på tvers av kontrakter, entreprenører og år.

System        Drenering, strekning X       ← funksjonell kjede
  └─ Inspeksjonsobjekt    Stikkrenne Ø300 (VD-04)      ← vedlikeholdsobjekt
       └─ Komponent  innløp / rør / grøft  ← delobjekt med egen TG

TG registreres på komponent, aggregeres til inspeksjonsobjekt (inspeksjonsobjekt-TG = max(komponent-TG)), og vurderes selvstendig på system. System-TG kan være høyere enn samtlige inspeksjonsobjekt-TG – da ligger årsaken utenfor katalogen (sideterreng, bekkefar, grunnforhold).

• Prosesskoder – forankring i håndbokverket (R610, PK).
• Tilstandskriterier – hva skiller TG1 / TG2 / TG3.
• Metrikker – hva som måles: enhet, datatype, geometritype, krav-ref, NVDB-kobling.
• Jobb & materiell – prisbyggeklossene.
• Tiltakspakker – navngitt tiltak = sum(jobb + materiell) + forventet levetid, koblet til inspeksjonsobjekt og TG.

Hver registrering lagrer et snapshot: valgt tiltakspakke, enhetspris og levetid slik de var på registreringstidspunktet. Bevisst denormalisering – senere katalogendringer omskriver ikke historikk.

Sletting er erstattet av arkivering (arkivert + arkivert_at) på både inspeksjonsobjekter og registreringer, slik at revisjonssporet består.

systemtype 1──* systeminstans 1──* systeminstans_modul *──1 registrering
                     │                                        │
                     └──* systeminspeksjon 1──* funn          ├──* skade *──1 skadeårsak
                                    │                          │
                                    └──1 systemkriterium       └──1 modul 1──* tiltakspakke (per TG)
                                    └──0..1 systemtiltak                        └──* jobb / materiell

Merk kardinaliteten som ofte overraskes over: én inspeksjonsobjekt har flere tiltakspakker på samme TG – de er alternative metoder, ikke addisjon.

TG_eff = max(TG, ST, SA)
SK_eff = clamp(SK + kritikalitetsjustering, 1, 3)
risiko = matrise[TG_eff][SK_eff]           (3×3)
tiltakstype = map(risiko)                  Forebyggende → Akutt
kostnad = tiltakspakke(TG_eff).enhetspris × mengde

Kjeden er deterministisk og reproduserbar. Skjønnet ligger i registreringen, ikke i beregningen.

enhetspris(pakke) = Σ(jobb.enhetspris × mengde) + Σ(materiell.enhetspris × mengde)
tiltakskostnad    = enhetspris(pakke) × registrert mengde

Flere pakker på samme TG sammenlignes side om side (pris, levetid, årskost) i «Sammenlign metoder» – valget blir dokumentert og etterprøvbart.

Full modell legges ved siden av light, ikke i stedet for – light-tallene må kunne reproduseres bakover i tid.

• Per kontrakt → budsjett og prognose
• Per system → funksjonell prioritering
• Per modultype → hvor pengene faktisk går
• Per risikoklasse → akutt vs. planlagt

Fordi hver linje har både kostnad, levetid og årskost, kan porteføljen sorteres etter effekt per krone i stedet for absolutt pris.

Prosesskoder følger håndbokverket, krav følger R610:2025, og metrikker kan kobles til NVDB objekt- og egenskapstyper med direktelenker til Datakatalogen. Det gir validering mot en nasjonal referanse.

Neste arkitektursteg er å eksponere katalogene som masterdata via API med versjonering og abonnement – men det bør valideres i workshops med etatene før det bygges.

• Komponenthierarki er tekstliste, ikke strukturert RDS/ISO 81346.
• LCC er light – ingen diskontering eller restverdi ennå.
• Prisdata indeksreguleres ikke automatisk.
• API-lag for masterdata er ikke bygget.

Ingen av disse blokkerer bruk i dag, men de hører hjemme på veikartet før modellen skaleres nasjonalt.