Denne case er udarbejdet af:
Simon Fredenslund er IKT-koordinator på Aarhus Universitet
FAKTA
Foto: Lars Kruse / AU Foto
- Drift: Aarhus Universitet
- 700.000 m2
Denne case er udarbejdet af:
Simon Fredenslund er IKT-koordinator på Aarhus Universitet
FAKTA
Foto: Lars Kruse / AU Foto
Som udgangspunkt er der ofte en kløft imellem driften og rådgiverens forestilling om driften. Én ting er, hvad der teoretisk set er teknisk muligt med 3D-modeller og en anden ting er, hvad der i virkeligheden fungerer og hvad der er behov for. Selvom der ofte stilles krav om 3D-modeller i projektafleveringerne, så bliver de ikke brugt i driften, hvor det primære behov er arealstyring og huslejebetaling.
Reelt har vi et 2D- informationsbehov, selvom der afleveres en 3D-model. Derudover er vi mest interesserede i specifikke informationer om tekniske anlæg og komponenter herunder deres placering. Driften bliver derfor i princippet præsenteret for en overflod af informationer, og det er naivt at tro, at man bare kan hive alt ud af modellerne og så kører driften bare. Derfor er vores store udfordring at skære ind til benet og få fat i de informationer, som vi reelt har brug for i driften, som ofte vil være simpel geometri og informationer om teknik.
CCS-klassifikationen kan hjælpe os med at filtrere den overflødige information fra, ved at koble de relevante egenskaber, som vi er blevet enige om, at vi har behov for i driften, med CCS-klassifikationen i vores driftssystem. Det er fx bygningsnumre, rumnumre, anlægstyper, forsyningsområde, flow, effekt, filtertype, tavlenumre mv. Således får vi hvad vi har brug for, i et format vi kan bruge.
Grundlæggende er CCS velegnet til vores behov, fordi der i kodernes systematik er fokus på funktionen og den funktionelle sammenhæng gennem funktionID. Systematikken bag CCS-koderne tager udspring i, hvilken funktion et objekt har, fremfor hvordan objektet er opbygget eller hvordan der projekteres. Og det er et mere anvendeligt udgangspunkt i forhold til driften. Dog er det kun klassifikationen, vi bruger, og ikke løbe- eller typenumre, da vi kobler egenskaberne til klassifikationen og fordi projektspecifikke numre ikke er værdiskabende i vores driftsverden.
Al overflødig information er med til at forstyrre driften. Vi har ikke behov for at kunne identificere alle objekter. Fx er døre, vinduer og konstruktive bygningsdele ikke særlig interessante for os, som de ellers er i projekteringen af et byggeprojekt. Det giver ingen mening for os at kunne identificere et specifikt vindue. For det første kræver et vindue meget lidt vedligehold og for det andet er vores driftsfolk kompetente nok til at kunne smøre hængslerne uden brug af IT-systemer.
Når det derimod gælder vores tekniske tunge anlæg, så har vi brug for langt højere grad af identifikation. Her har vi brug for at identificere de enkelte dele i systemerne og koble de egenskaber på, der gør den enkelte del unik. Vi benytter et system til digital aflevering, hvor man genererer bygningsdelskort på type- eller forekomstniveau, som indeholder de informationer, vi har behov for og ikke mindst placeringen af bygningsdelene. Bygningsdelskortet genereres på baggrund af klassifikationen (CCS-kode) og indeholder de egenskaber som fx objektnummer og ruminformationer, der fortæller os, om der er tale om et unikt objekt. Så klassifikationen er vigtig, for at vi kan tildele de rette egenskaber til netop dette objekt.
Det er derfor i princippet vores egne egenskaber, der gør bygningsdelen unik, og klassifikationen som sørger for, at det er de korrekte egenskaber, der kommer på.
En af de vigtigste øvelser ved en digital aflevering, er at skære ind til benet og undgå, at vi får flere informationer at håndtere end dem, vi har brug for.
Med CCS-klassifikation får vi velstrukturerede data, afleveret på en måde, så vi kan finde rundt i data og i et omfang, der matcher vores behov. Desuden giver det os et fælles sprog og en fælles forståelse af, hvad vi taler om.
Denne artikel blev offentliggjort første gang 20. september 2020