CCS som klassifikationssystem

CCS som klassifikationssystem 7. Semester specialerapport udarbejdet af Martin Spence (179884) Hvilke fordele og ulemper er der ved at benytte sig af Cuneco Classification System til håndtering af data i BIM-modeller?

Martin Spence 179884 CCS som Klassifikationssystem 7. semester speciale Rapport afleveret 29/10/2014 1.0 Titelblad TEKNISK-MERKANTIL HØJSKOLE SPECIALE TITEL: CCS som klassifikationssystem VEJLEDER: Inger Margrethe Jensen FORFATTER: DATO/UNDERSKRIFT: Martin Alslev Spence 29/10-2014 STUDIENUMMER: 179884 OPLAG: Digital Publicering SIDETAL (à 2400 anslag) 28,8 sider (69075 anslag) GENEREL INFORMATION: All rights reserved - ingen del af denne publikation må gengives uden forudgående tilladelse fra forfatteren. BEMÆRK: Dette speciale er udarbejdet som en del af uddannelsen til bygningskonstruktør alt ansvar vedrørende rådgivning, instruktion eller konklusion fraskrives! 1

2.0 Forord Denne rapport er udarbejdet i forbindelse med afslutningen på bygningskonstruktøruddannelsen ved VIA i Aarhus. Rapporten er en videnskabsteoretisk specialerapport, som skal indeholde en teori og skal understøttes af indsamlet empiri i form af interviews, eller spørgeskemaer. Det har givet mig muligheden for at undersøge et emne, jeg har undret mig over eller få besvaret et relevant spørgsmål. Jeg har interesseret mig for Cunecos arbejde med udviklingen af CCS i længere tid, og derfor syntes jeg, at det var en oplagt mulig for at komme helt ind under huden på emnet. Rapporten udgør 1/3 del af semestrets ECTS point, som er 10 point. At udarbejde en specialerapport er en tidskrævende opgave. Jeg vil derfor rette et stort tak til min kæreste Carina, som den seneste tid har taget sig meget af vores lille søn, så jeg har haft ro til at skrive. Tak for forståelsen. Ud over det vil jeg takke de mennesker jeg har snakket med i forbindelse med udførelsen af rapporten: Marianne Friis, Schmidt Hammer Lassen Brian Kjær, Oluf Jørgensen Nicki Kristensen, Ingeniørgruppen Varde Uden deres besvarelser og input havde rapporten ikke været mulig. Sidst vil jeg rette en særlig tak til min vejleder, Inger Margrethe Jensen, for gode vejledningssamtaler, gode input og god opbakning. Tusind tak. 2

3.0 Abstract This thesis has been prepared in relation with the conclusive 7 th semester, at the bachelor education of architectural technology and construction management. The thesis have been written with the main subject being CCS as classification system where my problem statement has been Which pro s and con s are there, when using CCS for handling data in BIM models. The reasoning for me to pick this subject, was because I thought it was very interesting to get to know this new classification system, which potentially is what we will be using in the future. CCS is an abbreviation for Cuneco Classification System. A division within Bips called Cuneco has been in charge of developing the system since 2012, and it is now being implemented in various test projects. The classification system is being promoted, as the new thing and is supposed to replace older systems we know today for example SfB and DBK. This is the opinion of the creators, but not everyone in the industry are equally excited. Throughout this thesis I have thoroughly described the theory behind the usage of CCS and to back up the theory, I have tested the classification system as well on a simple Revit model to experience the usage myself. To get alternative perspectives on the matter, I also included opinions from people from the Danish construction business, by interviewing two people who are against the implementation of CCS at its current state, and a person who works with CCS on a daily basis. This lead to an interesting discussion. There is no doubt that there s been put a lot of effort into designing this new classification system, that actually includes a lot more, then just classification, but main opinions from the users that are against the implementation are, that the system is hard to figure out, the codes are complicated and computer like, and the predecessor to CCS, which is called DBK, was no success at all. So the general opinion is that, they don t want to invest before CCS is proven to be successful. My conclusion to the subject also showed, that while the system wasn t as hard to use, as I was initially told, it still doesn t have any distinctive benefits, compared to the other classification systems that are used today. But perhaps when the system is completely developed by the end of 2014, things might look different. 3

Indholdsfortegnelse 1.0 Titelblad... 1 2.0 Forord... 2 3.0 Abstract... 3 4.0 Billedliste... 6 5.0 Indledning... 7 5.1 Baggrundsinformation og præsentation af emnet... 7 5.2 Begrundelse for emnevalg og fagligt formål... 7 5.3 Problemformuleringens spørgsmål... 8 5.4 Afgrænsning... 8 5.5 Valg af teoretisk grundlag og kilder... 8 5.6 Valg af metode og empiri... 9 5.7 Rapportens struktur og argumentation... 10 6.0 Hovedafsnit... 11 6.1 Klassifikationssystemer... 11 6.1.1 Klassifikationssystemets oprindelse... 11 6.1.2 Udvikling af klassifikationssystemer... 13 6.1.3 Kendte Klassifikationssystemer... 14 6.1.4 Delkonklusion... 18 6.2 Cuneco og CCS... 19 6.2.1 Intro: Cuneco Center for produktivitet i byggeriet... 19 6.2.2 Tidslinje... 19 6.2.3 CCS Klassifikation... 21 6.2.4 CCS Identifikation... 23 6.2.5 CCS Informationsniveauer... 24 6.2.6 CCS i praksis... 25 6.2.7 Delkonklusion... 29 6.3 CCS som klassifikationssystem Holdninger fra branchen... 30 6.3.1 Diskussion... 30 6.3.2 Delkonklusion... 33 7.0 Konklusion... 34 8.0 Perspektivering... 36 9.0 Metodekritik... 36 4

Kildeliste... 38 Bilagsoversigt... 39 5

4.0 Billedliste Figur 1. Biologisk klassifikationsmodel af Linnés.... 11 Figur 2. Model der beskriver informationsstrømme mellem projekterende og udførende.... 12 Figur 3. SfB-Systemets facetter. (HFB 2011/2012)... 14 Figur 4. Tabel der viser aspekter i DBK-systemet. (HFB 2008)... 15 Figur 5. Tabel der viser domæner i DBK-systemet. (HFB 2008)... 15 Figur 6. Model over koncept ved DBK-kodning (HFB 2008)... 16 Figur 7. Kodning med brug af forvaltningsklassifikation.... 17 Figur 8. Oversigt over indholdet af Projekt Cuneco (Cuneco 2014).... 21 Figur 9. Et bygværk opdelt i funktionelle systemer, samt klassifikationsbetegnelser. (Cuneco 2014) 22 Figur 10. Viser to tekniske systemer, samt klassifikationsbetegnelse. (Cuneco 2014)... 22 Figur 11. Eksempel på klassificering af komponenter i en bygningsdel (KEA 2014)... 23 Figur 12. 3D-view af mit "prøvehus"... 26 Figur 13. CCS Komponenter... 26 Figur 14. CCS Tekniske systemer... 26 Figur 15. CCS Funktionelle systemer... 26 Figur 16. Træstrukturen fra Sigma ses i modellen.... 27 Figur 17. Sigmabiblioteket sættes til at læse i Revitmodellen... 27 Figur 18. Taget har fået tildelt en type kode, %BE401 og beskrivelse.... 27 Figur 19. Mængder eksporteret tilbage til Sigma, og jeg får min kalkulation.... 28 Figur 20. Objektegenskaber for et ovenlysvindue i prøvemodellen, med pris fra Sigma.... 29 6

5.0 Indledning Denne rapport er kulminationen på 3½ års skolegang på bygningskonstruktøruddannelsen ved VIA i Aarhus. Rapporten er en specialerapport, hvor jeg som studerende, har fået muligheden for, at overgive min nysgerrighed uden begrænsninger, til et selvvagt emne, jeg mener der har relevans for min fremtid i en hård og konkurrencepræget branche. 5.1 Baggrundsinformation og præsentation af emnet Emnet jeg har valgt at undersøge, omhandler introduktionen af Cunecos nyudviklede klassifikationssystem, Cuneco Classification System, også bedre kendt som CCS. I april 2014 blev de første endelige klassifikationstabeller offentliggjort, men systemet har været brugt på prøveprojekter (STARTprojekter 1* ) (Cuneco, www.cuneco.dk, 2014) siden sidste år. Bygningsstyrelsen har samtidig meldt ud, at der i fremtiden vil stilles krav om, at det er CCS der skal bruges i stedet for det nuværende DBK-system, hvis man vil være med i konkurrencer hvor staten er bygherre. Det skulle være et godt incitament for at få implementeret CCS ved de fleste større aktører i branchen, og dette gælder både rådgiver-, arkitekt- og entreprenørfirmaer, da det er meningen, at CCS-klassifikationerne skal kunne bruges aktivt fra idégrundlag til bygningens levetid ender. Det er dog ikke alle der er lige begejstrede for systemet, og der er aktører i branchen, der er tilbageholdende over for at implementere CCS. Som en del af min forudgående undersøgelse på emnet, har jeg læst flere artikler og diskussioner på diverse sociale medier, hjemmesider og fora. Her stiller folk spørgsmål ved holdbarheden på CCS fordi der tilsyneladende har været forvirring om hvem der skal forestå kodningen, og fordi kodningen ikke har været tilstrækkelig beskrivende. Modsvaret går på, at CCS er et helt nyt system der skal tilpasses, og at der stadig ligeledes forekommer utilstrækkeligheder i ældre allerede brugte systemer (Cuneco, www.linkedin.com). 5.2 Begrundelse for emnevalg og fagligt formål Bips-organisationen har brugt meget tid og ressourcer på at udvikle det nye system, og dette gør ikke diskussionen mindre interessant for mig. Hvis CCS vinder indtræf ved tegnestuerne og på ingeniørkontorerne i landet, mener jeg det kan være godt at prøve, at sætte sig ind i, hvordan systemet virker, da sandsynligheden for, at jeg selv kommer til at bruge det, bliver større og større. Hermed er der selvfølgelig også en personlig interesse i, at få en god forståelse af, hvordan CCS bruges, da der i fremtiden bliver brug for folk med kendskab til systemet. Derfor har jeg tænk mig i denne specialerapport, at eftervise hvordan CCS kan bruges og dermed også tilegne mig viden, jeg kan gøre brug af i fremtiden. Det faglige formål med rapporten er at undersøge, om der er fordele ved at konvertere fra ældre klassifikationssystemer til CCS. Jeg er klar over, at det kan være en utrolig dyr affære at skulle omlægge en IT-infrastruktur i et hvilket som helst firma. På en tegnestue bruges der 1 Et projekt hvor Cuneco tilbyder gratis konsulentbistand på CCS-kodningen. 7

typisk en form for kodning eller et system som alle er godt inde i, og hvis alle skal til manuelt at slå nye koder for bygningsdele op, kommer alle processer til at tage længere tid, når en model skal bygges op. Tid er som regel ikke noget man har for meget af, når der skal klargøres konkurrenceforslag, og derfor kan det være en skrammende tanke. Jeg har derfor sat mig for, at lave en simpel prøvemodel i Revit, kode den iht. CCS kodestrukturen, og trække mængder ud med Sigma. Jeg vil ud fra dette, som ny bruger af CCS, danne mig mit eget indtryk af, om jeg kan se fordele ved brugen af CCS. 5.3 Problemformuleringens spørgsmål Ud fra det faglige formål med opgaven, er jeg efterfølgende kommet frem til min overordnede problemformulering som lyder: Hvilke fordele og ulemper er der ved at benytte Cuneco Classification System til håndtering af data i BIM-modeller? For at komme frem til en besvarelse på mit problem, har jeg valgt at understøtte det med følgende uddybende spørgsmål: Hvorfor bruger aktører i byggebranchen klassifikationssystemer, hvilke systemer findes der? Hvad er CCS, hvad består det af og hvordan bruges CCS-kodningen i praksis? Hvilke holdninger er der til CCS i branchen, og er det et system der kommer til at blive brugt på længere sigt? 5.4 Afgrænsning Denne rapport skal læses som en undersøgelse af en problemstilling, eller en underen vedrørende fordele og ulemper ved brug af CCS. Rapporten er ikke tænkt til at skulle bruges som en komplet teknisk vejledning til forklaring og brug af kodningssystemet. Hvis man søger efter en decideret brugsvejledning vil jeg henvise til www.cuneco.dk/vaerktoejer, hvor jeg har fundet det materiale jeg arbejder ud fra. I min behandling af CCS-værktøjerne vil jeg begrænse mig til de dele, der er blevet udgivet, og som er testede. Jeg vil derfor i dette speciale kun beskrive og afprøve CCS Klassifikation, CCS Identifikation og CCS Informationsniveauer. Resten af Cunecos arbejde er stadig pågående, og derfor mener jeg ikke der er grundlag for, at have det med i denne rapport. 5.5 Valg af teoretisk grundlag og kilder Grundet unge alder på CCS, er der ikke meget teoretisk data at hente på systemet, ud over det der er at finde på Cunecos hjemmeside. Her vil jeg gøre brug af de værktøjer der er blevet gjort tilgængelige for aktører i byggebranchen, der ønsker at sætte sig ind i systemet. Dette indebærer de udarbejdede eksempelsamlinger, hvor selve kodningsstrukturen 8

forklares i detaljer, webbaserede hjælpemidler hvor man finder koderne, samt dokumenter vedrørende informationsniveauer og informationsklasser. Ud over Cunecos eget udviklede materiale, vil jeg gøre brug af data fra de få prøveprojekter der er blevet udført, og i den forbindelse vil jeg ligeledes udføre et interview med en ingeniør fra IGV, som har siddet med under kodningen af første etape på SDU men dette vil jeg komme nærmere ind på i næste afsnit. Jeg har, som et led i mit teoretiske grundlag, sat mig for at prøve klassifikationsmetoden af selv. Jeg er interesseret i, at undersøge om brugen er til at finde ud af for en der ikke har kendskab til CCS-kodning. Det vil være interessant at høre, om de tegnestuer jeg skal snakke med, argumenterer imod implementeringen af CCS, fordi det er for vanskeligt at sætte sig ind i et helt nyt og ret anderledes kodesystem, i forhold til det man ellers kender. Jeg har som bevismateriale tænkt mig at lave en simpel model i Revit, som jeg efterfølgende vil kode iht. CCS-vejledningen. På baggrund af egne erfaringer jeg gør mig med systemet, vil jeg prøve at argumentere fordele og ulemper på baggrund af den information jeg får fra mine interviews, og på den måde nå frem til en konklusion på mit overordnede problemformuleringsspørgsmål. 5.6 Valg af metode og empiri Som jeg var inde på i forrige afsnit, er det ikke muligt at finde større mængder data på brugen af CCS, og jeg har derfor ikke materiale til at starte en diskussion, vedrørende om det er en fordel at skifte klassifikationssystem, med mindre jeg selv prøver det af. Jeg ved at jeg ikke kan sammenligne min prøvekodning med, at implementere et nyt system på en hel tegnestue, men jeg mener godt, at jeg ud fra prøven, kan danne mig et validt indtryk af, hvordan CCS er at arbejde med, som ny bruger. Dette mener jeg godt kan kobles med hvordan det enkelte individ vil have det med at skulle sætte sig ind i et nyt system på en given tegnestue. For at kunne udføre min diskussion og dermed få svar på min problemformulering, har jeg også brug for noget kvalitativ empiri. Dette vil jeg indsamle ved at udføre interviews med aktører i byggebranchen, som til dagligt bruger BIM-modeller, og hvor kodning af bygningsdele, er en naturlig del af alle projekter, for at strukturere den data der skal samles i modellen. Jeg mener det er interessant at høre synspunkter fra aktører der ikke er udpræget begejstrede for CCS, da jeg kan bruge disse oplysninger til min diskussion. Til dette har jeg valgt at interviewe Marianne Friis, bygningskonstruktør og BIM-ansvarlig ved Schmidt Hammer Lassen og Brian Kjær, ingeniør og BIM-koordinator ved Oluf Jørgensen. Som modsvar vil jeg ligeledes lave et interview med en, der har direkte erfaring med brugen af CCS. Her har jeg valgt at interviewe Nicki Sturm Kristensen, uddannet bygningskonstruktør og er IKT ansvarlig ved IGV. Af andenhånds empiri har jeg et interview med Jacob Güldner, BIM-koordinator og modelansvarlig hos Grontmij. Han har forestået kodningen af DNV Gødstrup, hvor der ligeledes blev stillet krav om brug af CCS til klassificeringen af bygningsdele. 9

5.7 Rapportens struktur og argumentation Denne specialerapport er delt op i 3 hovedafsnit. Afsnit 1 er indledningen til emnet, hvor jeg resonerer for mit valg af emne og hvordan min overordnede problemformulering er fremkommet. Her forklarer og argumenterer jeg for, hvordan jeg gerne vil arbejde med dette emne, og hvordan jeg på realistisk vis, vil komme frem til nogle brugbare resultater, jeg kan konkludere ud fra. Afsnit 2 består af hoveddelen af rapporten. Det er i dette afsnit jeg vil besvare de underspørgsmål jeg har stillet, for i sidste ende at opnå et tilfredsstillende svar, på min overordnede problemstilling. Dette afsnit har ligeledes en struktureret opbygning, jeg har valgt, for at gøre rapporten så oplysende og informativ som mulig. Jeg vil starte med at beskrive hvor denne træng til at benytte sig af kodesystemer og træng til at sætte informationer i boks udspringer fra. Jeg vil herefter forklare lidt omkring de klassifikationssystemer vi ellers bruger i dag, hvor jeg vil prøve at beskrive de styrker og svagheder man kender til. Med dette afsnit vil jeg argumentere for, hvorfor udviklingen af et nyt klassifikationssystem er positivt. Det er også som en del af hovedafsnittet jeg har tænkt mig at prøver kræfter med CCS kodningen i en simpel prøvemodel jeg udarbejder. Her vil jeg gøre mine egne erfaringer med systemet, og prøve at beskrive styrker og eventuelle mangler. Det 3. afsnit af rapporten er konklusionsdelen. Her vil jeg sammenfatte mine resultater fra interviews, mine egne erfaringer med klassifikationsmetoden, og argumentere for og imod CCS. Der vil hele vejen igennem dette afsnit være en mindre indledning til underafsnit, samt en delkonklusion hvor jeg samler op på det gennemgåede materiale. 10

6.0 Hovedafsnit 6.1 Klassifikationssystemer I dette afsnit vil jeg præsentere lidt historie i forbindelse med, hvor klassifikationsmetoderne kommer fra, samt beskrive hvor værdien opstår i at anvende klassifikationssystemer. Jeg kommer kort ind på, hvilke spilleregler der gælder, når man i dag udvikler nye klassifikationssystemer til byggeriet, så man sikrer en international kommunikation er mulig, og sidst i afsnittet kommer jeg med en kort beskrivelse af nogle af de mest anvendte systemer i dag. 6.1.1 Klassifikationssystemets oprindelse En præcis definition på et klassifikationssystem kan være svær at komme med, da det kan være en ret variabel størrelse, hvor alle variabler skal ses i forhold til, hvad det der skal klassificeres. Det enkelte klassifikationssystem skal altså defineres ud fra et behov, hvor det betragtes hvilken funktion det skal kunne understøtte, for at være effektivt og værdiskabende. Man kan sige, at hvis systemet ikke har en positiv indvirkning på funktionen, og skaber en forbedret udvikling, må det anses som et system i afvikling ikke værdiskabende, og dermed et overflødigt stykke værktøj. Et klassifikationssystem kan i byggebrancheregi beskrives, som værende et organisatorisk værktøj, der hjælper med at holde styr på informationer, modeller, objekter, egenskaber, dokumenter osv. Det er mange store emner det dækker over, men fælles for alle emnerne er, at tankegangen med at inddele i kategorier, og sætte ting i kasser, er en meget naturlig måde for mennesket, at organisere data på. Når der kommer orden på tingene bliver alt mere overskueligt, og det ender dermed at blive brugbart. På grund af netop disse årsager, er det derfor muligt at spore typer af klassifikationssystemer helt tilbage til de græske filosoffers tid. I oldtidens Grækenland grundlagde og udviklede Aristoteles 2 (Wikipedia, Wikipedia, 2014) Scala Naturae, hvis funktion var at inddele organismer. Dette system blev brugt helt frem til 1700 tallet, hvor den svenske naturforsker, Carl Von Linné 3 (Wikipedia, 2014) videreudviklede systemet med det formål, at det også skulle bruges til klassificering af dyr og planter. Systemet kom til at hedde Systema Naturae. Systemet gjorde konsekvent brug af to latinske navne et navn for slægt og et navn for art. Han skabte dette hierarkiske system, hvor han først klassificerede efter ligheder mellem arter, som så blev samlet i slægter, og slægter i familier, som igen blev sorteret i orden, 2 Videnskabsmand og filosof, 384-322 f.kr. 3 Naturforsker med speciale i botanik, zoologi og medicin, 1707-1778. Figur 1. Biologisk klassifikationsmodel af Linnés. 11

klasse, række og rige. Hele rækken kan ses på figur 1 side 11, som i bund og grund er Linnés originale model. Senere blev klasserne domene og liv tilføjet modellen, og modellen er i dag stadig den der danner grundlaget for den biologiske klassifikation. Genistregen Linné bedrev og højst sandsynligt årsagen til, at systemet stadig anvendes i dag, er at han formåede at udarbejde et overskueligt system der i al sin enkelthed gav mening. Systemets funktion var at nedbryde en stor datamængde med relationer til hinanden i mindre bidder. Selvom Denne inddeling af arter ikke umiddelbart har ret meget til fælles med byggebranchen, er måden at håndtere data på alligevel interessant grundet systemets værdiskabelse. (Kristensen & Christensen, 2014) Ud over det biologiske klassifikationssystem, anvendes der til dagligt mange forskellige systemer, uden man tænker mere over det. F.eks. kan nævnes CPR-registret, bibliotekssystemer, systemer i den økonomiske verden, systemer til udarbejdelse af statistiske undersøgelser og i det hele taget hvor lagring og genfinding af information kan have en værdi. Fællesnævneren for alle disse systemer er, at de danner et fælles informationsgrundlag inden for hver deres område. Klassifikationen af data betyder, at informationen registreres på en fælles måde der gør, at man efterfølgende kan finde den igen, og ikke mindst genbruge den hvis det skulle være interessant. Dermed har man en måde, hvor man kan skabe overblik og sammenhæng mellem store mængder data, der ellers ville virke meget kaotisk og uoverskueligt at arbejde med. Klassifikationen giver ligeledes mulighed for at skabe uafhængighed mellem forskellige IT-systemer, eftersom det ikke er et must at der arbejdes med data på samme måde, da systemerne kan genkende hinanden, fordi det der arbejdes med, har den samme strukturelle opdeling. Relationerne beskrevet ovenfor kan sættes i sammenhæng med et hvilket som helst byggeprojekt af en hvis størrelse. Det vil altid være nødvendigt for en bygherre, arkitekt eller ingeniør at holde styr på sine objekter, samt det data der er tilknyttet, i en ensartet og fastlagt struktur, da aktøren ellers nemt mister overblikket, i en flod af informationer. Klassifikationen kan startes helt fra byggeprogram, og føres hele vejen Figur 2. Model der beskriver informationsstrømme mellem projekterende og udførende. 12

gennem projekteringen, udførelsen og ikke mindst efter byggerier er afleveret, til Facility management brug. Det er dog vigtigt, at man hele tiden har for øje, at arbejdet med struktureringen bliver ved med at skabe værdi, i forhold til hvad der stilles af krav. Derfor skal klassifikationssystemet være fleksibelt, så det kan tilpasses det enkelte projekts behov. Figur 2 er en model, der i grove træk, viser placeringen på et klassifikationssystem mellem byggeriets parter. Klassifikationssystemet er det der gør, at de projekterende og de udførende kan snakke samme sprog, selvom det de beskæftiger sig med er vidt forskelligt. Systemet kan være bygget op af helt overordnede klasser, der klassificerer bygninger, bygningsdele, rum. Disse klasser kan så igen inddeles i underklasser, hvor dataobjekter, eller komponenter, placeres. Alle klasser forsynes med et navn, en kode samt en struktur for beskrivelse af dataobjekternes egenskabsdata. (Kristensen & Christensen, 2014) 6.1.2 Udvikling af klassifikationssystemer Inden jeg gennemgår de mest gængse klassifikationssystemer, vil jeg i dette afsnit beskrive proceduren, når der udvikles nye klassifikationssystemer. Jagten på det perfekte klassifikationssystem foregår ikke kun i Danmark. Der er lige så vel brug for, at aktører kan kommunikere med hinanden på tværs af landegrænserne, såvel som internt. Samarbejde primært i Europa, men også i resten af verden, foregår hver dag, og der findes derfor et behov for standardiseringer som ISO 4 udvikler og publicerer. Dette sikrer en større fleksibilitet i brugen af f.eks. kommunikations- og IT-systemer og der skabes et pålideligt grundlag for deling og lagring af data. Det mest fremtrædende produkt der indtil nu er set fra ISO er ISO-12006 Building Construction Organization of information about construction works, som foreskriver struktureringen igennem de to kompendier: ISO 12006-2:2000 Building construction - Organization of information about construction works Part 2: Framework for classification of information. ISO 12006-3:2007 Building construction - Organization of information about construction works Part 3: Framework for object oriented information. Standardiseringerne fra ISO præsenterer en skabelon for, hvordan et klassifikationssystem skal se ud, og hvad det skal indeholde af information, på et overordnet niveau. Herved sikrer man sig, at kollegaer i andre lande, der ikke nødvendigvis kender til det specifikke system der er i brug, alligevel kan genkende og relatere til den struktur der er forelagt. En slags opskrift som man kan genkende. (Kristensen & Christensen, 2014) 4 International Organization for Standardization 13

6.1.3 Kendte Klassifikationssystemer SfB-Systemet: SfB, som står for Samarbetskomitén för Byggnadsfrågor, og blev i 1950 udviklet af den svenske standardbeskrivelse Bygg-AMA 5. Formålet med systemet var at have en standard til klassificering og kodning i byggebranchen, og systemet vandt hurtigt indpas, og ikke kun i Sverige. Andre lande fik også øjnene op for dette system bl.a. i forbindelse med byggevareregistrering, fordi det i 1972 blev internationalt anerkendt af CIB 6. En anden fordel der siden viste sig var, at systemet ligeledes samarbejdede godt i forbindelse med ITsystemer, der var et naturligt krav i udviklingen af systemer, og i takt med at byggeprojekter blev mere og mere IT-baserede. SfB-systemets koder er bygget op i en kombination af tal og bogstaver i en trefaset kode, der f.eks. kunne se således ud: (21) F g2. Her angiver første facet (21) bygningsdelen der er tale om, i dette tilfælde en ydervæg. Anden facet, F, beskriver konstruktionen der er tale om, i dette tilfælde er det en muret konstruktion. Tredje facet, g2, beskriver ressourcen, som kan være materiale, arbejdsydelse, administration, og er i dette tilfælde tegl. Så den samlede kode i eksemplet her beskriver altså en muret ydervægskonstruktion i tegl. En oversigt over facetterne kunne se ud som tabellen herunder: Facet Type Kodningsbeskrivelse 1 Bygningsdel Opbyggede med tocifrede tal i parenteser med 10 hovedgrupper der hver har 10 underdelinger. Skal opfattes som en funktion, og ikke som en konkret væg. 2 Konstruktion Beskrives med store bogstaver, og benyttes i forhold til, hvordan bygningsdelen er konstrueret. Denne kode har ingen relation til håndværket 3 Ressource Beskrives med små bogstaver, som kombineres med et tal fra 0-9. Tabellen omfatter de fire hovedtyper af ressourcer: administration, hjælpemidler, arbejde, operationer Figur 3. SfB-Systemets facetter. (HFB 2011/2012) 5 Et beskrivelsesværktøj der kommer fra Svensk Byggtjänst 6 Commission Internationale du Batiment, Rotterdam. 14

Ved kodning med dette system, aflæses de tre symboler i hver sin respektive tabel, og skal skrives i den fastlagte rækkefølge. På denne måde får man en ret præcis kodning af sin bygningsdel, konstruktion og materiale. I praksis kan der dog ofte være nogle problemer forbundet med at bruge SfB-systemet, da det ikke er blevet opdateret med nye konstruktionstyper og materialer de sidste 20 år. Dette bevirker, at man kan komme til at mangle den nødvendige detaljeringsgrad, for at få en præcis beskrivelse. De tegnestuer der i dag anvender SfB-systemet, har typisk selv givet det en opdatering, eller i hvert fald sat deres eget præg på anvendelsen. Ofte udelades en eller flere af facetterne, og i stedet kobles koderne med tegningsnumre der indeholder tegningstype og løbenummer. Et eksempel kunne være (21)3.01, som beskriver en ydervæg, der findes på en oversigtstegning, som er den første tegning på det pågældende niveau. En anden af svaghederne ved det gamle SfB-system, var brugen af 99-nummereringen, der blev anvendt som standardnummer, hver gang der herskede tvivl om klassificeringen. (HFB, 2011/2012) DBK-Systemet: DBK, der er en forkortelse for Dansk Bygge Klassifikation, var et projekt der blev startet op i 2003 og strakte sig frem til 2006. Dette var et storstilet projekt og udviklingsresultatet fra bips i samarbejde med Erhvervs- og Boligstyrelsen. Det var det første nationale forsøg på, at lave et altomfattende klassifikationssystem, hvor hovedformålet var, at koderne var gennemgående og entydige fra idégrundlag til drift, og at alle aktører dermed kunne drage nytte af det. Klassifikationssystemet blev profileret, som det nye system, der skulle være SfBsystemets afløser, og det blev udformet som det sjette statslige bygherrekrav i Det Digitale Byggeri. DBK er baseret på den tidligere omtalte internationale standard ISO 12006-2. Modsat SfB-systemet, varetager DBK ikke kun klassifikation af bygningsdele, men også aktører, dokumenter, processer osv. gennem hele bygningens livscyklus. DBK-systemets større detaljeringsgrad kommer til udtryk, når man ser på hvordan systemet behandler bygningsdele, hvor disse beskrives gennem aspekter og domæner: Aspekt Forklaring Produkt (præfiks -) Hvad et objekt består af Form (præfiks #) Hvordan et objekt ser ud Funktion (præfiks =) Hvordan et objekt anvendes Placering (præfiks +) Hvordan et objekt indbygges Figur 4. Tabel der viser aspekter i DBK-systemet. (HFB 2008) Domæne Resultat Proces Ressource Egenskab Figur 5. Tabel der viser domæner i DBK-systemet. (HFB 2008) Forklaring Slutprodukt f.eks. en bygning, bygningsdel Delprocessor der indgår i byggeriets faser Dokumenter, materialer, materiel, mandskab Egenskabsklassificering 15

DBKs kodningsprincipper er her illustreret på figur 5, som viser et samlet system, som indeholder flere bygningsdele i bygningsdelene. Huset indeholder et vægsystem(-205), og i vægsystemet finder man et vinduesparti (.02). Vinduespartiet består af flere vinduer(01.), men samtidig har vinduespartiet også en fuge (.08). Ved brug af DBK identifikationsmetoden introduceres regler som., hvor der sker en nedbrydning i strukturen til det næste niveau. Det øverste niveau har altid 3 cifre, hvor de efterfølgende niveauer har 2 cifre. Figur 6. Model over koncept ved DBK-kodning (HFB 2008) DBKs anskuelse ved klassifikation af bygningsdele var meget anderledes i forhold til SfB-systemet, der var og nok stadig er, det mest brugte system. Tanken om at inddrage hele byggeriets livscyklus var interessant, da klassifikationssystemet pludselig kunne give værdi for andre aktører, da den ensartede strukturering fremmede udvekslingen mellem alle parter og skabte entydighed. Modtagelsen af DBK var dog ikke kun positiv. Som det også er tilfældet med CCS, er DBK et system der er meget specifikt i kodningsstrukturen, hvilket også gør systemet mindre brugervenligt sammenlignet med f.eks. SfB, og kompleksiteten i koderne gjorde det samtidig problematisk at implementere systemet i software. I dag fases brugen af DBK ud, og det er meningen, at CCS på sigt skal erstatte DBK. (HFB, 2008) Forvaltningsklassifikation: Forvaltningsklassifikation er et system der blev udviklet i 2009 i et samarbejde mellem Landbyggefonden og Kommunernes Landsforening. Formålet med systemet er udelukkende, at det skal digitalisere ejendomsforvaltning i større ejendomsselskaber, så som Frederikshavns Ejendomscenter, Københavns Ejendomme mv. Dette system skiller sig derfor også ud fra SfB, DBK og CCS, da det ikke mynter sig på brug i projekterings- og udførelsesfasen. Systemet erstattede den tidligere bygningsdelstavle fra SfB, som ellers har dannet udgangspunkt for klassifikation af bygningsdele i en lang årrække. Grunden til, at 16

man på daværende tidspunk mente, at der var brug for et nyt klassifikationssystem der kunne varetage en digital forvaltning var, at DBK(2006) ikke blev fundet brugbart til denne fase af byggeriets levetid, og behovene en ejendomsforvaltning havde, blev ikke dækket. Forvaltningsklassifikationens beskrivelse af bygningsdele minder en del om SfBs, måde at klassificere på, men derudover indeholder den en systematisk beskrivelse af egenskabsdata, og en beskrivelse for det samlede produkt. Hermed flyttes informationerne fra den gammeldags dokumentbaserede verden, over i en digital ved at data kun eksisterer og opdateres et sted. Selve kodningen foregår ved, at alle bygningsdele er forsynet med en specifik bogstavskode, som relaterer sig til bygningsdelens placering i tavlens afsnit samt navn. Et eksempel kunne være en altan, jf. figur 6. Her angiver bk, at den hører til bygningsafsnittet bygning, og at den hører ind under konstruktion. alt er med til at danne objektnavnet altan, som i dette tilfælde er altan nummer 1, og derved får man koden bk.alt-01. Hvis der samtidig skulle være behov for at tilknytte objektet yderligere information, som f.eks. placering, angives det som egenskabsdata, som udgør punkt 2 ud af de 18 grupperinger objektklassen er udstyret med. Bygningsdele i bygning Bygning, konstruktion Altan Altangang Figur 7. Kodning med brug af forvaltningsklassifikation. b bk bk.alt bk.alg Styrkerne ved Forvaltningsklassifikationsmetoden er, at byggeriet bliver inddraget som en helhed der specielt egner sig godt til en driftsorganisation. I forhold til SfB-systemet er det ligeledes en smule enklere, da terræn og selve bygningen er blevet delt op, og der findes ikke 99-numre, som i SfB-regi anses som rodekassen, hvor uspecificerede dele ofte ender. Herved bliver alt specificeret korrekt. En klar ulempe ved dette system er dog, at det ikke kan bruges i projekterings- og udførelsesfasen. Dette betyder, at der er brug for et andet klassifikationssystem til at håndtere disse faser, f.eks. SfB eller CCS, og alt data skal derved efterfølgende konverteres. (Kristensen & Christensen, 2014) Omniclass: Omniclass, der i sit fulde navn hedder Omniclass Construction Classification System, også forkortet OCCS, er et relativt nyt system fra 2006. Systemet kan håndtere data i hele byggeprocessen samt byggeriets levetid, altså fra idégrundlag til nedrivning. Systemet er baseret på de internationale ISO-standarder 12006-2 og 12006-3, dog er Omniclass hovedsageligt anvendt i Nordamerika af AEC-industrien 7. 7 Architecture, Engineer, Construction 17

Omniclass er udviklet til at kombinere eksisterende klassifikationssystemer fra forskellige områder i byggebranchen, og samle al information ét sted. Systemet udvikles i takt med, at der kommer nye byggekomponenter til, men i dag består det af 15 hierarkiske tabeller, som hver repræsenterer en forskellig facet af byggeinformation. De kan både anvendes individuelt eller i samhørighed, hvis der er behov for klassificering af komplekse emner. Dette kan bl.a. gøres ved at inkorporere andre systemer i Omniclass, som beskriver et specifikt område. Her kan f.eks. nævnes Masterformat som er nummer 22 i Omniclasstabellen. Dette anvendes primært til at nedbryde f.eks. en bygning i bygningsdele, der derved letter beskrivelsen af konstruktionsprocesser og giver mere præcise priskalkulationer. (Kristensen & Christensen, 2014) 6.1.4 Delkonklusion Klassifikationssystemer kan spores helt tilbage til før Kristi tid, og har haft en stor betydning, når det kommer til, at holde orden i store mængder data. Hvilken form for data det er spiller en mindre rolle. Så længe et systems system kan skabe en værdi for brugeren, er det værd at bruge. Udviklingen af systemer er kommet langt fra det meget organiske systema natura til noget så koldt og teknisk som klassificering og systematisering af data i byggeobjekter, og vi vil ikke være i stand til at klare os uden disse systemer, og det er hvad enten om det hedder SfB, DBK eller CCS. Grundet størrelsen af de byggerier der udføres i dag, er det helt essentielt, at der forekommer en orden og en struktur når det kommer til informationsflow, og tendensen efter introduktionen af BIM i byggeriet, at man skal kunne snakke sammen gennem hele byggeprocessen, og genbruge data. Dette sparer tid og i sidste ende penge for når alt kommer til alt er det pengepungen det handler om. Som tidligere nævnt, skal vi også hele tiden have for øje, at det er byggeriet der skal være fokus på, når man er i byggebranchen. IT og klassifikationsværktøjer er et kæmpe hjælpeværktøj, men det skal altså stadig kun have en sekundær rolle. 18

6.2 Cuneco og CCS Efter jeg i forrige afsnit har gennemgået tilblivelsen af klassifikationssystemerne, og set lidt på de mest gængse vi bruger i dag, vil jeg i dette afsnit komme nærmere ind på hvad Cuneco Classification System er og hvad det består af. Jeg vil komme med eksempler på, hvordan koderedskaberne virker i praksis, ved at kode en egenproduceret bygning, og derved danne mig et indtryk af, om jeg selv kan se fordele ved dette system, frem for de andre systemer jeg har beskrevet i forrige afsnit. 6.2.1 Intro: Cuneco Center for produktivitet i byggeriet Cuneco er et udviklingsprojekt der er pågået siden maj 2011 og frem til ultimo 2014 udvikler, tester og implementerer fælles standarder, der letter udvekslingen af data gennem alle de faser et byggeri gennemgår fra idégrundlag og projektering, i tilbudsfasen, ved produktion og udførelse, og endelig ved drift og vedligehold. Det er tiltænkt, at systemet skal være brugervenligt, da det kan være krævende at skulle implementere et nyt system, og det skal ikke mindst være IT-minded modsat DBK, som er det system det skal afløse. Samtidig er det kompatibelt med både nationale og internationale standarder. Cunecoprojektet drives og ledes af foreningen bips, i et tæt samarbejde med flere store aktører i branchen, for at få så mange input med i udviklingen som muligt. Her kan bl.a. nævnes DTU og Aarhus Universitet, Dansk Standard og organisationsnetværket bestående af FRI, DANSKE ARK, Dansk Byggeri, TEKNIQ, Bygherreforeningen og BAT-Kartellet. Cuneco er et projekt der både bliver finansieret med offentlige midler fra EU s Regionalfond og Staten samt private investorer i form af Realdania og byggebranchens egenfinansiering. (Cuneco, 2012) 6.2.2 Tidslinje Startpunktet var egentlig helt tilbage i august 2006, da DBK blev frigivet. DBK havde en del børnesygdomme, og der var mange meninger om, at der var ting der skulle gøres anderledes, end det var tilfældet i DBK. Det blev samlet op i DIkonrapporten 8 fra januar 2010 som indeholdte forslag til rettelser, der kunne løfte og forbedre systemet, og som kunne skabe værdi for alle i byggebranchen. Indholdet fra DIkonrapporten sammenfattet med de diskussioner og debatter fra aktører i branchen der havde været omkring emnet, udmundede i Videncenterkontrakten fra juni 2010, som bips havde budt ind på og vandt forslaget. Erhvervs- og Byggestyrelsen besluttede, at der skulle bruges nogle midler, primært EU-midler, som skulle løse de problemer der var, vedrørende anvendelsen af klassifikation og generelt vedrørende standardisering af digitale arbejdsmetoder i byggeriet. Som yderligere input til forbedring af systemet, fik Erhvers- og Byggestyrelsen en svensk professor ved navn, Anders Ekholm 9, til at udarbejde en rapport, hvor også han konkluderede hvad der skulle laves af ændringer. 8 Rapport vedrørende afprøvning af DBK, udført af sammenslutningen Digital Konvergens. 9 Svensk professor med speciale i klassifikation og egenskaber. 19

Ved Cuneco samlede man op på alle disse input, og gik ret hurtigt i gang med, at udarbejde en behovsanalyse for at kortlægge hvad det var der skulle til af forbedringer i forhold til DBK. Ud fra behovsanalysen, blev der lavet en liste over de egenskaber CCS absolut skulle bygges op omkring (Cuneco, 2013): 1. Skal være IT-minded 2. Internationalt baseret og internationalt orienteret 3. I overensstemmelse med ISO 12006-2 4. Klassebetegnelse skal være stabil fra vugge til grav 5. Skal kunne bruges til ren klassifikation 6. Skal kunne bruges til identifikation 7. Der skal anvendes bogstaver til klassebetegnelse 8. Der skal laves ét fælles klassifikationssystem for alle fag 9. Skal være uafhængigt af aktør og faser i byggeriets livscyklus 10. Klar skillelinje til egenskabsdata 11. Hver klasse skal defineres og være distinkt fra andre klasser I løbet af lidt over et års arbejde udviklede Cuneco det der i dag er blevet Cuneco Classification System samt Cuneco Identification med tilhørende smartphone app samt en webbaseret opslagsdatabase, der skal hjælpe med selve kodningen. Resultatet blev fremlagt på et høringsmøde i april 2013, og i juni 2013 havde Cuneco en version 1.0 klar til brug. Sideløbende med udviklingen af systemet, havde det været prøvet af på forskellige byggerier, bl.a. flagskibet, DNV Gødstrup ved Herning. Her udtaler Thomas Hejnfelt, BIM og IKT Manager i konsortiet CuraVita, om deres fremskredne arbejde med CCS, med betaversionen: I den indledende fase af Gødstrup har vi klassificeret vores bygningsdele og det har været nemt at tildele objekter en klassifikationskode fra CCS. Vi har anvendt CCS typeidentifikation til projektspecifikke typer. I den nuværende fase afprøver vi hvordan CCS kan anvendes til at strukturere projektets udbudsmateriale. (Cuneco, 2013) Efterfølgende har Cuneco arbejdet videre på at få færdiggjort de næste tiltag i processen. For at gøre tilvendelsen lette for branchen, har Cuneco udarbejdet eksempelsamlinger, der simpelt forklarer hvordan de forskellige værktøjer skal anvendes. Der er ligeledes blevet udviklet mappingtabeller, der er tabeller der oversætter SFB-, Forvaltningskalssifikationsog DBK-sprog til CCS-sprog. 20

Figur 8. Oversigt over indholdet af Projekt Cuneco (Cuneco 2014). Ved udgangen af 2014 afsluttes Projekt Cuneco, med udgivelser af CCS måleregler, CCS tilbudslister, CCS Egenskabsdata, CCS Prissætningsregler samt CCS Klasser af information, mens de udgivelser der allerede har set dagens lys, stadig behandles, justeres og finpudses. 6.2.3 CCS Klassifikation Alle former for byggerier, hvad enten om der er enfamiliehuse eller megasygehuse, kan inddeles i mindre bidder i bygningsdele. En bygningsdel kan defineres som bestanddele af et bygværk med en karakteristisk funktion, form eller position 10 og kan bestå af større helheder som et vægsystem der igen består af flere mindre bygningsdele. Jo flere gange man inddeler bygningsdele i mindre bygningsdele, desto mere detaljeret bliver det udtryk man ender med. I CCS findes der ca. 600 klassificerede bygningsdele for byggeri og anlæg. Alle bygningsdele bliver med sin unikke kode og tilhørende definition, delt ind under de tre hovedklasser, som CCS arbejder med: Funktionelle systemer, som klassificeres med 1 stort bogstav Tekniske systemer, som klassificeres med 2 store bogstaver Komponenter, som klassificeres med 3 store bogstaver I CCS bruges store bogstaver fra alfabetet, men man har valgt ikke at gøre brug af Æ Ø og Å, da systemet skal kunne benyttes på et internationalt plan, og man har valgt ikke at gøre brug af I og O, da de hhv. kan forveksles med 1 og 0. Dette betyder, at man ved de funktionelle systemer har 24 kombinationer at gøre brug af, de tekniske systemer har 24 2 kombinationer, 10 CCS eksempelsamling for konstruktioner. 21

og komponenterne har 24 3 kombinationer at gøre brug af. Der skulle dermed være god mulighed for fremtidig udvidelse af systemet, f.eks. ved introduktion af nye byggematerialer. Definitionen på det funktionelle system er: Bygningsdel med karakteristika, der primært repræsenterer en overordnet egenfunktion 11. Denne klasse omfatter bygningsdele der har en overordnet egenfunktion, som udgør en funktionel helhed. Klassen har den funktion, at den opdeler hele bygværker i større dele, der hver har en egenfunktion. (Cuneco, 2014) Figur 9. Et bygværk opdelt i funktionelle systemer, samt klassifikationsbetegnelser. (Cuneco 2014) Det næste led i den hierarkiske inddeling af bygningsdele, er den tekniske. Definitionen på det tekniske system lyder: Bygningsdel med karakteristika, der primært repræsenterer en sammenhængende teknisk løsning med en egenfunktion 12. Denne klasse indeholder bygningsdele der udgør en teknisk helhed, f.eks. en vægkonstruktion, en tagopbygning eller en tagkonstruktion. Denne klasses funktion tjener det formål, at man hensigtsmæssigt kan håndtere større sammenvirkende systemer eller f.eks. at kunne skille ydelser af. Et eksempel kunne være hvis man skal have tømreren til at forestå opbyggelsen af en tagkonstruktion, men tagdækkeren skal forestå afslutningen opad til, i form af papdækning. (Cuneco, 2014) Figur 10. Viser to tekniske systemer, samt klassifikationsbetegnelse. (Cuneco 2014) 11 CCS eksempelsamling for konstruktioner. 12 CCS eksempelsamling for konstruktioner. 22

Nederst i hierarkiet finder vi komponenter. Komponenter er de bygningsdele, der opbygger tekniske systemer, og kan klassificeres helt selvstændigt, lige som det funktionelle og det tekniske system kan. Definitionen på en komponent er Bygningsdel med karakteristika, der primært repræsenterer en grundlæggende teknisk løsning med en egenfunktion 13. Nøgleordet i denne definition er grundlæggende, da denne gruppe bygningsdele indeholder alle de dele, der kan beskrive opbygningen af et teknisk system. Se eksempel nedenfor 14 : (Antonsen, 2014) Figur 11. Eksempel på klassificering af komponenter i en bygningsdel (KEA 2014) 6.2.4 CCS Identifikation Klassifikation af bygningsdele er en rigtig god metode til brug af sortering af objekter, men hvis man skal vide noget om et specifikt vindue det kunne f.eks. være placering, eller det kunne være at skelne mellem typer af vinduer så er man nødt til at benytte sig af identifikation. Ved at knytte et ID til en bygningsdel, kan man altså identificere enkelte forekomster af bygningsdele eller grupper af bygningsdele. Ud over at kunne identificere objekter, kan det ligeledes bruges til at identificere fysikske rum, brugsrum, aktører, materiel, byggevarer og dokumenter. Alle objekter, kan alt efter behov, gives et ID eller et fortegn der beskriver følgende aspekter (Cuneco, 2014): Type - som beskrives med præfikset % og som anvendes når man har med bygningsdele at gøre, der deler egenskaber. Dette kunne f.eks. være hvis der forekommer forskellige typer af vinduer i et bygværk. Der kan de identificeres som %QQA1 og %QQA2. Typeaspektet kan ligeledes bruges til at identificere brugsrum. Her bruges et %% og et eksempel kunne være, hvis der forekommer forskellige toiletter i en bygning. Så kan de skelnes ved at give dem forskellige type ID er: %%ABB1 og %%ABB2. 13 CCS eksempelsamling for konstruktioner. 14 Figur 11 er taget fra undervisningsmateriale vedrørende CCS på KEA. 23

Produkt som beskrives med præfikset # og anvendes når der er tale om simpel nummerering af objekter. Bruges hvis man har mange ens objekter, f.eks. #QQA1 og #QQA32 hhv. vindue nummer 1 og vindue nummer 32. Produkt-ID et kan som foregående ID anvendes til nummerering af rum, med samme egenskaber. Her bruges ## samt løbenummer. Sammensat produkt Dette ID beskrives med præfikset - og er lidt mere speciel. Dette ID anvendes til sammensætning af bygningsdele ved brug af funktionelle- og tekniske systemer og komponenter. I sådan en kode adskilles niveauer med et.. Et eksempel kan være vægsystem 1 med vinduesparti 1 med vindue 1: -B1.BA1.QQA1. Et -- kan igen anvendes i forbindelse med identifikation af brugsrum. Dette kræver dog, at brugsrummets placering er kendt. Jeg undlader i dette tilfælde at komme med et eksempel på en kode, da der vil indgå bogstaver i koden, hvis funktion jeg ikke har beskrevet, og koden vil derfor ikke give megen mening for læseren. Placering Beskrives med præfikset +, og anvendes til placering af en bygningsdel i en anden bygningsdel. Et eksempel kunne være placering af vindue 3 i vægsystem 1, som skrives +B1.QQA3. ++ kan ligeledes bruges til at identificere et brugsrum, en etage, et afsnit eller et bygværk. Funktion Beskrives med præfikset = og anvendes til at identificere bygningsdele ud fra deres funktionelle sammenhæng. Dette kunne f.eks. være ventilationssystem 1. varmeforsyningsanlæg 2. kontraventil 3, som beskrives med koden =J1.HD2.RMA3. Det dobbelte præfiks ==, bruges her til at sammensætte brugsrum ved deres tilhørsforhold til grupper af rum. Hvis man har brug for helt specifikke beskrivelser, man ikke synes bliver dækket af de udtryk som her er beskrevet, kan man i projektet indarbejde sine egne koder ved at bruge tredobbelt præfiks eller flere. For de projektspecifikke koder, er det vigtigt de er forklarede, og de må samtidig ikke kunne forveksles med andre koder, og der skal også ved disse koder, tages højde for, at CCS ikke gør brug af visse bogstaver i alfabetet. Et eksempel kunne være Badekabinemodul4.Vægkonstruktion1, som beskrives ved koden ---AA4.AB1. 6.2.5 CCS Informationsniveauer Informationsniveauet for et objekt, en bygningsdel eller et bygværk kan i CCS-opbygningen beskrives på 7 differentierede niveauer, hvor detaljeringsgraden er stigende i takt med niveauets numeriske værdi. Dvs. niveau 1 er det laveste, og dermed også det niveau med den simpleste detaljeringsgrad, og niveau 7 er det højeste, og har dermed den største detaljeringsgrad. 24

Detaljeringsgraden af bygværket vil naturligt stige i takt med, at byggeriet udvikler sig fra ide til komplettering, men da informationsniveauerne knytter sig til objekter i stedet for faser, kan informationsniveauet differentieres på de enkelte objekter, som både kan være bygværker, fysiske rum, brugsrum, bygningsdele og materiel. Dermed kan man vurderer hvor meget information der påkræves, for at det giver værdi for den aktør der skal modtage modellen videre i processen. Som eksempel kan nævnes, at det kan give værdi for en D & V organisation, at modtage en model, hvor overflader, eller genstande der slides hårdt på, f.eks. inventar, vinduer, gulvbelægning, er på et højt informationsniveau, da det typisk vil være disse der skal udskiftes, hvor denne organisation ikke har nogen interesse i at få højere informationsniveauer på bærende konstruktionsdele. Så man kan sige, at informationsniveauerne kan bruges til at definere den mængde af information, der skal afleveres eller modtages, ved en overgang mellem to aktører i en byggeproces. Herunder ses en oversigt over informationsniveauer med tilhørende illustration (kun til de første 5 niveauer) og definition 15 : Informationsniveau 1: Repræsentation af en idé Informationsniveau 2: Skitse af et løsningsforslag Informationsniveau 3: Koordineret repræsentation af et løsningsforslag Informationsniveau 4: Koordineret repræsentation af en konceptuel løsning Informationsniveau 5: Specifikation af em fysisk realiserbar løsning Informationsniveau 6: Detaljeret specifikation af en fysisk realiserbar løsning Informationsniveau 7: Detaljeret specifikation af en maskinel fysisk realiserbar løsning 6.2.6 CCS i praksis Som et led i min undersøgelse har jeg sat mig for, at jeg som et produkt, vil prøve CCS af på en Revit model, og på den måde danne mig et indtryk af, hvordan det er at arbejde med CCSkodningen. For en ting er at skrive om, hvordan CCS virker i teorien, da de vejledninger jeg har brugt, jo er udarbejdet af cuneco, der selvfølgelig mener, at systemet er nemt at bruge. Det er straks noget andet, når man faktisk skal bruge det i praksis. Ved at kode en model, vil jeg bedre kunne sætte mig ind i, hvordan det må være at sidde på en tegnestue, eller på et 15 CCS Informationsniveauer produktblad fra cuneco. Illustrationerne er ligeledes herfra. 25

ingeniørkontor, og så skulle lære at bruge et helt nyt system, der på ingen måde minder om noget jeg har brugt før, men som Nicki Kristen fra IGV, sagde da jeg spurgte ham om, hvordan de klarede det med selve implementeringen af CCS: Vi synes jo egentlig selv at vi kom godt fra start. Den eneste store udfordring vi faktisk havde, det var på de tekniske installationer og.. Vi lavede simpelthen en slags guide eller vejledning på det, og den brugte vi løbende faktisk, og udbyggede den stille og roligt, indtil den til sidst udgik, fordi man kunne køre det på rutinen... (Kristensen N., 2014) Selve processen vil jeg gribe an, som jeg har set det er blevet gjort på DNV Gødstrup, i en video fra Cunecos hjemmeside, hvor Jacob Güldner forklarer processen (Cuneco, 2013). Jeg starter med at opbygge mit Sigmabibliotek op med de bygningsdele jeg har i min model, ud fra CCS-strukturen med funktionelle systemer, tekniske systemer og komponenter hvor jeg mener det er nødvendigt. Det er ikke meningen, at jeg vil kode modellen til mindste detalje, men f.eks. går vinduer og døre ind under kategorien komponenter, så derfor har jeg lavet komponentunderpunkter ved de bygningsdele, hvor disse indgår. Resultatet kan ses forneden, hvor træstrukturen vises. På billede 1 kan man se opbygningen af biblioteket med de funktionelle systemer. Som den står her minder den om den struktur man kender fra Sigma, der normalt bruger SfBkodesystemet. Men på billede 2 skiller systemet sig allerede en del ud fra SfBopbygningen. Som eksempel kan nævnes fundamenter, der i SfB findes under Bygningsbasis, hvorimod det ved CCS Figur 12. 3D-view af mit "prøvehus" findes under klassificeringen AB, som er vægsystemer. I mit eksempel har jeg Figur 15. CCS Funktionelle systemer Figur 14. CCS Tekniske systemer Figur 13. CCS Komponenter 26

muligvis en gren for meget med i træstrukturen. Her refererer jeg til den der beskriver bygningsdelen med efterfølgende løbenummer eks. Fundament 201-209, men det er skrevet på denne måde, da det så giver mulighed for, at indtaste flere forskellige slags fundamentstyper, hvilket slet ikke er usandsynligt, hvis det drejer sig om et større byggeri. På billede 3 går inddelingen fra det tekniske system til komponentniveau, hvor jeg har indtastet og kodet vinduer, døre og glaspartier (curtainwalls), samt givet dem løbenumre der gør dem unikke. I tilfælde af, hvis jeg skulle skelne mellem ens vinduer, skulle komponenternes koder udvides. I dette hus findes der f.eks. 4 vinduer af typen "[%QQA212.1] Vindue 610x610 mm. Hvis det var vigtigt for mig at skelne imellem disse, skulle de kodes "[#QQA1/%QQA212.1], "[#QQA2/%QQA212.1] osv., hvor man bruger havelågen til at beskrive vinduets eget unikke nummer inden for den type af vinduer. Et af de tiltag der er gjort ved CCS i forhold til, at gøre det nemme at kode bygningsdele er, at man har bedt BetechData om at udvikle en Revit Add-In der hedder SPINE. Denne addin ligger sig som en del af Revit, og man kan så i modellen kode sine bygningsdele. I dette tilfælde koder jeg alle bygningsdelene i Sigmabiblioteket, og når så integreringen sker, bliver objekterne automatisk kodet, og gør derfor ikke brug af dette ekstra værktøj. Jeg har i stedet brugt Cunecos webbaserede opslagsdatabase, som har fungeret meget fint. Det er en stor hjælp, at man ikke skal slå koderne op i en PDF eller i et Excel ark, som det eller har foregået med andre systemer. Det man bare hele tiden skal have for øje, er hvilket niveau man er på. Altså er det funktionel, teknisk eller komponent man leder efter, og dermed altså 1, 2 eller 3 bogstaver. Modellen her er på det der svarer på informationsniveau 2, og er derfor ikke så kompliceret. Kodningen bliver muligvis mere besværlig som faserne går, og informationsniveauerne stiger. Dette kan jeg ikke kommentere på i denne forbindelse, da tiden ikke er til en mere detaljeret kodning af huset. Bygningsdelsbiblioteket er i denne omgang færdigt nok til at det kan føres sammen eller linkes til Revitmodellen: Figur 17. Sigmabiblioteket sættes til at læse i Revitmodellen Figur 16. Træstrukturen fra Sigma ses i modellen. Figur 18. Taget har fået tildelt en type kode, %BE401 og beskrivelse. 27

Denne proces udføres for alle bygningsdele man har i sin model. I komplekse modeller kan man lave et filter, der f.eks. midlertidigt farver alle kodede bygningsdele røde, så man kan se hvilke bygningsdele der har fået tildelt en kode. Det hele foregår på type-niveau, hvilket betyder, at man ikke skal kode hver enkelt væg eller hvert enkelt vindue. Alle typer der er ens, får alle sammen en kode, når det er gjort én gang. Denne kodningsproces er, ifølge Nicki Kristensen, ligeledes en glimrende måde at kvalitetssikre sin Revitmodel på: Jeg bruger det f.eks. også som en form for KS i min model når jeg sidder med projektering af ventilation. Så har jeg det sådan, at hvis jeg skal være sikker på, at jeg får det hele med fra min model over på tilbudslisten, jamen så har jeg delt det sådan op, at alt det der ikke har fået en CCS-kode, det skal ligge sig oppe i toppen så jeg kan se, at der er noget der mangler at blive kodet. For hvis det ikke er blevet kodet, ja så er det nok heller ikke med på min tilbudsliste. (Kristensen N., 2014) I denne lille prøve har jeg ikke sat et filter på, men i stedet gemmer jeg midlertidigt de bygningsdele der har fået en kode, og derved kan jeg holde styr på hvad jeg mangler. Når hele modellen er gemt objekt for objekt, ved jeg, at jeg har alt kodet. Herefter er jeg klar til at eksportere min model tilbage til Sigma, hvor programmet udfører kalkulationen ud fra de parametre jeg har sat op, mht. hhv. stk. for vinduer, løbende meter for fundament, kvadratmere for murværk osv. Sigma bygger selv træstrukturen op, som man kender den, og den tager mine beskrivelser med over, som jeg oprindeligt beskrev dem, da jeg startede mit bibliotek op. Nu er jeg klar til at opdatere min model med priser fra kalkulationen. Figur 19. Mængder eksporteret tilbage til Sigma, og jeg får min kalkulation. 28

Efter en synkronisering er udført, bliver identitetsdataen for alle objekter der har været en del af kalkulationen opdateret med prisen fra Sigma. Her ses f.eks. et ovenlysvindue med koden %QQA.401.1 med beskrivelse, samt pris pr. stk. på 8253.25 kr. Dette er også det sidste skridt i min prøve med brug af CCS-kodningen, og metoden til at få BIMprogrammerne til at kooperere, men herfra kunne man eksportere kalkulationen videre til MSProject, da det jo også er Figur 20. Objektegenskaber for et ovenlysvindue i prøvemodellen, med pris fra Sigma. interessant at få udarbejdet en tidsplan ud fra modellen, der dermed gør det til en 5D model. Der kunne ligeledes udføres en sammenfatning af alle disse oplysninger i et program som Navisworks, som vil kunne lave flere former for simulationer, på baggrund af den information der findes i modellen. Det kunne både være i form af en præsentationssimulering, hvor man ser modellen blive samlet over en tidslinje, mens man har omkostninger kørende sideløbende. Et stærkt præsentationsværktøj over for en bygherre, der meget nemmere vil kunne visualisere et stort byggeri for sig, inden det bliver opført. Det kunne også bruges til forskellige statiske tests, brandsimulationer, lyd- og energianalyse. 6.2.7 Delkonklusion Der er ingen tvivl om, at Cuneco og CCS er et spændende og storstilet projekt at følge. Der gøres brug af de nyeste tiltag man kender til i branchen, og der er sørget for, at klassifikationen kan snakke sammen, med alle de forskellige IT-platforme der bliver brugt, da det netop er udviklet i samarbejde med branchefolk både IT-udviklere og aktører der repræsenterer byggebranchens forskellige facetter. Det er omfattende at skulle udvikle et system, der skal kunne håndtere så meget forskellig data, i alle byggeriets faser, og der er postset mange penge i projektet. Som det ser ud nu, bliver der stadig set med kritiske øjne på CCS fra mange sider i branchen, da der er flere der mener, at det er et ufærdigt system, på trods af, at projektet bliver afsluttet om mindre end fire måneder. Jeg ser mig selv som en upartisk person når det kommer til brug af klassifikationssystemer, da jeg de sidste 3 semestre har befundet mig på entreprenørlinjen af denne uddannelse. Jeg er derfor ikke vant til at bruge et specifikt klassifikationssystem, og har derfor ingen præferencer. Jeg vil mene, at CCS ikke umiddelbart er mere besværligt at bruge eller forstå i forhold til f.eks. SfB. Hvis man som udefrakommende skal i gang med at bruge et helt nyt 29