Samarbejde omkring informationer forebygger fejl

Transkript

1 2014 Samarbejde omkring informationer forebygger fejl Figur 1 CCS (Cuneco Classification System) Jonathan Noer Bygningskonstruktørstuderende VIA.U.C. Horsens Vejleder: Morten Brunsborg Lauritsen

2 TEKNISK-MERKANTIL HØJSKOLE TITELBLAD RAPPORT TITEL: Samarbejde omkring informationer forebygger fejl VEJLEDER: Morten Brunsborg Lauritsen FORFATTER: Jonathan Noer DATO/UNDERSKRIFT: 02/ STUDIENUMMER: OPLAG: 5 SIDETAL (à 2400 anslag): 28 sider 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!

3 Forord Denne rapport er en del af den afsluttende eksamen på bygningskonstruktør uddannelsen. Den omhandler samarbejde omkring informationer og tager udgangspunkt i hvilke strukturer, der skal til for at kode objekter entydigt så de er til gavn helt fra byggeriets ide til drift. Jeg har igennem anvendelse af teori og empiri, i form af kvalitative interviews, fundet frem til en konklusion på min problemformulering. Jeg har igennem rapporten anvendt billeder fra Cuneco s hjemmeside som illustrationer, for at understøtte teksten. Tak til Cuneco for at jeg har kunnet anvende dem. Jeg vil også gerne udtrykke en stor tak til de mennesker, der har været med til at bidrage til min rapport. Især stor tak til Mads Valentin, Henrik Tuxen-lyck, Søren Spile og Torben Klitgaard for at deltage i interviews. Også tak til min vejleder på VIA Horsens, Morten Brunsborg Lauridsen, for hans konstruktive kritik igennem udviklingen af rapporten. 2

4 Abstract This report referred to cooperation on information to see which structures is needed to code BIM objects clearly so that information in the BIM objects could benefit the construction from concept to operation. My problem statement has been. Which structures should be set to create beneficial BIM objects that can create value from design to construction to operation? One of the structures should be established is to divide the object information in the classes and systems. This makes sense, since in the construction industry has different needs, such as. The architect typically uses technical systems and the engineer may need to work with components. Another structure is being able to identify objects through standardized naming methods. A third structure is being able to control the amount of information in a predetermined level in the BIM model and in the individual objects. 3

5 Indholdsfortegnelse 1. Indledning med problemformulering Baggrundsinformation og præsentation af emnet Begrundelse for emnevalg og fagligt formål Problemformuleringsspørgsmål Afgrænsning Valg af teoretisk grundlag og kilder Valg af metode og empiri Rapportens struktur og argumentation Lovkrav og digitalisering Hvad er CCS og dets formål: Klassificering og Strukturering af BIM objekter Delkonklusion: Ensartet Navngivning, kodning og identificering af BIM objekter Delkonklusion: Informationer og egenskaber i en bestemt detaljeringsgrad i BIM objekterne Delkonklusion: CCS som et lovkrav Delkonklusion: Konklusion Kildeliste 10. Bilag Billedliste: Figur 1: Figur 2-6 og 8-15 : Figur 7: Egen illustration. 4

6 1. Indledning med problemformulering 1.1. Baggrundsinformation og præsentation af emnet Dette er mit speciale på 7 semester på bygningskonstruktør uddannelsen. Denne rapport omhandler hvordan et fælles grundlag af informationer på BIM objekter kan deles, fra ide til drift, når byggeriets parter skal arbejde sammen. 1.2 Begrundelse for emnevalg og fagligt formål Helt fra Aristoteles ( f.kr), der var en af oldtidens filosoffer, har mennesker arbejdet med hvordan de kan strukturere og navngive objekter. Hvad det vil sige, at en ting netop er denne ting og ikke noget ganske andet og hvad det i det hele taget vil sige, at noget er, dette er spørgsmål som Aristoteles behandler i metafysikken 1 ( Tanker, om strukturering og navngivning af objekter arbejdes der stadig med også i byggebranchen. I et byggeproces er der mange faggrupper som f.eks. projekterende, udførende, bygherre og driftsherre, der skal kunne samarbejde. Her er der fokus på hvordan de forskellige faggrupper kan tale samme sprog og få defineret objekterne i byggeriet, så alle implicerede parter får en forståelse af at et objekt, som f.eks. et vindue, netop er dette vindue. I mit praktikforløbe har jeg netop oplevet hvor problematisk det kan være at tale samme sprog faggrupperne imellem og dermed få den samme forståelse for et specifikt objekt. Det viser mig at der mangler en standardisering for deling af informationer af objekter i byggesektoren Efter at den danske regering i 2007 satte lovkrav til byggebranchen om digitalisering er behovet for standardisering blevet større. Lovkravet om digitalisering blev udformet i IKTbekendtgørelsen. IKT står for Informations og KommunikationsTeknologi. Formålet med IKT er at effektivisere den danske byggesektor igennem statslig kravstillelse. I IKT bekendtgørelsen nr 1365 fra 2007, stilles der krav til anvendelse af 3D bygningsmodeller, som er objektbaseret, i projekteringen af offentlige byggerier 2 ( Ovenstående krav har skabt et behov for udvikling af 3D objektbaseret bygningsmodeller, som blev starten på øget anvendelse af BIM. BIM står for Building Information Model og defineres som: Building Information Modeling (BIM) is a digital representation of physical and functional characteristics of a facility. A BIM is a shared knowledge resource for information about a facility forming a reliable basis for decisions during its life-cycle; defined as existing from earliest conception to demolition 3 ( Jeg har i mit praktikforløb i arkitektfirmaet Arkitema, lagt mærke at der er mange forskellige måder, der løses problemstillinger på i et og samme firma. En af disse problemstillinger er 5

7 hvordan der forsøges at trække informationer ud af BIM modeller. En anden problemstilling er opbygningen af BIM objekter samt på hvilken måde at der implementeres informationerne i objekterne. Det er en meget væsentlig problemstilling, da en bygning er opbygget af mange objekter, som til sidst gerne skulle stå som en færdig enhed/bygning. Det er det samme med BIM objekter, de skal kunne stå som en digital enhed til sidst eller som beskrevet i Bips c214: Objekterne er de byggesten, BIM- modellen bygges op af (Wad, L. J. & Stolberg, B.J. mf. dec.2013, s. 6). I den nye IKT bekendtgørelse nr. 118 fra 2013 har man skærpet kravene til digitale byggeobjekters informationer. Formålet er at byggeobjekters informationer kan håndteres og anvendes igennem hele byggeprojektets forløb, det vil sige at informationerne i objekterne skal kunne anvendes fra ide til projektering til udførelse og drift, der igen skaber et behov for øget samarbejde imellem de forskellige faggrupper. Derfor har jeg en undren og en ide om at der mangler et grundlag, som skal kunne effektivisere og strukturere informationer i objekter så de kan bruges af statslige bygherrer i henhold til IKT bekendtgørelsen. 4 ( Dette bringer mig til følgende problemformuleringsspørgsmål: 1.3. Problemformuleringsspørgsmål Hvilke strukturer bør fastlægges for at skabe gavnlige BIM objekter som kan skabe værdi fra projektering til udførelse til drift? 1.4. Afgrænsning Jeg vil i denne rapport ikke se på objekternes opbygning, men kun på hvordan man deler informationerne i objekter imellem de forskellige faggrupper fra ide til drift. I vejledningen for IKT-bekendtgørelsen 4.4.3: Inspiration til krav om navngivning, kodning, klassifikation og identifikation, forligger følgende klassifikationssystemer på dansk som inspiration. SfB-systemet 1988 CCS (Cuneco Classification System) der er under udvikling som en erstatning for Dansk Bygge Klassifikation (DBK) Forvaltnings Klassifikation, version 2.0 som benyttes fra 2012 i forbindelse med forvaltning af almene boliger. Jeg har valgt at se på CCS fordi Cuneco center for produktivitet i byggeriet en del af bips, fik i 2011 en opgave om at opbygge et nyt informationshåndteringssystem der skal støtte op om byggeriets IKT-anvendelse. Hensigten med CCS er at den skal kunne indeholde bl.a. klassifikation, identifikation, og strukturering af egenskaber til understøttelse af vedligehold og udveksling af informationer igennem hele byggeriets værdikæde. 4 ( 6

8 Min begrundelse for kun at fokusere på CCS er at dette speciale udløser 10 ECTS- point og svare til 222 timers arbejde og jeg derfor kun kan se på den lille del problematikkerne der omhandler gavnlige BIM objekter Valg af teoretisk grundlag og kilder Jeg har valgt at anvende materialer fra Cuneco. Cuneco center for produktivitet i byggeriet er en del af bips, det er dem der har udarbejdet CCS siden Meget af deres materiale er i høring på nuværende tidspunkt. Jeg vil gennemgå deres høringsmateriale samt foredrag og oplæg, desuden har jeg fået tilladelse til at anvende illustrationer fra deres hjemmeside Jeg har valgt at anvende Steinar Kvale som grundlag for hvordan jeg indsamler min empiri. Steinar Kvale er professor i pædagogisk psykologi og leder af Center for Kvalitativ metodeudvikling ved universitet i Århus. Han har skrevet flere bøger omkring dataindsamlings metoder, her iblandt også hvordan man laver kvalitative interviews. Jeg har valgt at se på IKT bekendtgørelser der omhandler byggeobjekters informationer her vil jeg bruge på retsinformation.dk da det er dem der har en portal, der indeholder love, administrative forskrifter, og lovforslag Valg af metode og empiri Jeg har valgt at lave kvalitative interviews til at indsamle empiri til udarbejdelse af mit speciale. Kvalitative interviews bliver anvendt som forskningsinterviews og defineres af Steinar Kvale, som Et interview der har til udgangspunkt at indhente beskrivelser af den interviewedes livsverden med henblik på at fortolke betydningen af de beskrevne fænomener (Kvale s.19). Forskningsinterviewet er baseret på dagliglivets samtaler og er en professionel samtale. (Kvale s.19) Forskningsinterviewet er ikke en samtale mellem ligestillede parter, eftersom forskeren definerer og kontrollerer situationen. Det er forskeren, der introducerer interviewemnet og kritiske forfølger subjektets svar på spørgsmålene (Kvale, s.19) Jeg har valgt at anvende metoden med kvalitative interviews idet jeg forventer at få et mere dybdegående og beskrivende materiale. Interviews kan være meget forskellige i deres grad af struktur. De kan være fuldt ud struktureret hvor der er en række standardformulerede spørgsmål, til helt åbne, hvor der ikke er specifikke spørgsmål, men kun temaer der er vejledende (Kvale, s.131). Jeg, har valgt i dette speciale, at anvende den strukturerede form i interviewspørgsmålene da jeg som person kan have svært ved at holde en struktur og hurtigt kan lade mig rive med og derved komme for langt væk fra mit oprindelige mål. Jo mere struktureret interviewsituationen er, desto nemmere vil den senere analytiske strukturering 7

9 af interviewet være. (Kvale, s.134). Jeg har dog en forventning til at interviewene alligevel ender med at blive semistruktureret, da jeg gerne vil uddybe relevante emner der evt. kommer frem som jeg ikke selv har haft i mine overvejelser. Jeg vil forsøge at opfylde de kvalifikations kriterier som Steinar Kvale beskriver, at intervieweren helst skal besidde. Kvalifikationskriterierne er, at intervieweren er velinformeret, strukturerende, klar, venlig, sensitiv, åben, styrende, kritisk, huskende og fortolkende (Kvale s ) En anden ting, der kan have indflydelse er hvordan jeg placerer mig i forhold til den interviewede, men da jeg ikke kender omgivelserne, idet at interviewene foregår på den interviewendes arbejdsplads, må jeg forsøge at få det bedste ud af den givende situation Jeg har valgt at interviewe tre aktører med hver deres rolle i struktureringen af BIM objekter. Den første af aktørerne er Byggestyrelsen, som er dem der stiller krav via lovgivningen (IKTbekendtgørelsen) som i 4. stiller krav omkring standardisering af BIM objekter til bygherrer i offentlige byggerier. Her har jeg valgt at ville interviewe Henrik Tuxen Lyck, han er bygningskonstruktør og er IKT-leder for Bygningsstyrelse Anden aktør er bygherrers rådgivere, der skal hjælpe bygherre med at opfylde de stillede krav, der er i lovgivningen. Her har jeg valgt at ville interviewe Mads Valentin, der arbejder på Arkitema. Han repræsenterer bygherres rådgiver idet han er BIM-koordinator på nuværende byggeri af Gødstrup sygehus. Gødstrup er et af de pilotprojekter hvor man har afprøvet CCS standarderne, derfor er det højst relevant i forhold til mit speciale. Den tredje aktør er Cuneco, der foreslår redskabet CCS til bygherrers rådgivere som et løsningsforslag på hvordan rådgiveren kan opfylde lovgivningens krav via standarder. Her har jeg valgt at ville interviewe Torben Klitgaard, idet han er projektdirektør for Cuneco og er medudvikler af CCS standarderne, Og Søren Spile der er projektchef i Cuneco som hovedsageligt arbejder med den faglige vinkel af CCS standarderne Før jeg lavede mine interviews sendte jeg mine spørgsmål og et følgebreve til alle tre aktører (Bilag nr. 1,2,3). Efter færdig udarbejdet rapport har jeg sendt rapporten til alle tre aktører til kommentering på deres egne udtalelser for at gøre rapporten mere valid Rapportens struktur og argumentation Denne rapports struktur er opbygget over IKT bekendtgørelsen nr. 118, paragraf 4. I begyndelsen af hovedafsnit vil jeg udlægge IKT bekendtgørelsen med fokus på paragraf 4, derefter vil jeg definere hvad en BIM model er. Hvorefter jeg vil opdele mit hovedafsnit i 5 underafsnit hvoraf de 4 sidste indeholder en delkonklusion. Den første er: Hvad er CCS og dets formål, her vil jeg definere CCS samt forklare hvorfor man har udviklet CCS. Den anden er: Klassificering og Strukturering af BIM objekter her vil jeg først forklare hvad klassifikation er og hvordan man bruger klassifikation til at strukturer objekt klasser, Den tredje er: Ensartet Navngivning, kodning og identificering af BIM objekter, her vil jeg forklare hvordan 8

10 man i CCS kan identificerer et objekt via den kodning/navngivning som ligger i klassificeringen. Den fjerde er: Informationer og egenskaber i en bestemt detaljeringsgrad i BIM objekterne, først vil jeg beskriver hvad egenskaber er, derefter vil jeg beskrive hvordan egenskaber i CCS delfineres i en bestemt detaljeringsgrad så de kan anvendes fra ide til drift. Den sidste er: CCS som et lovkrav, her vil jeg se om CCS burde eller ikke burde være indskrevet i IKT bekendtgørelsen. Løbende i mine afsnit vil jeg lægge empiri ind under min data som for- eller modargumentation, og uddrage delkonklusioner heraf. Til sidst vil jeg sammenfatte alle mine delkonklusioner til en endelig konklusion på problemformuleringsspørgsmålet. 2. Lovkrav og digitalisering De større krav til objekternes informationer er kommet til både pga. den hurtige udvikling af BIM projektering og den nye IKT-bekendtgørelse nr. 118 af for offentlige byggerier og bekendtgørelse nr. 119 af for alment byggeri. Her beskrives en række krav som omfatter de digitale bygherrer krav. Disse krav er fordelt inden for følgende områder: IKT koordinering Håndtering af digitale byggeobjekter Digital kommunikation og projektweb Anvendelse af digitale objektbaseret bygningsmodeller i forbindelse med projektkonkurrencer, projektering og udførelse Digitalt udbud og tilbud, herunder udbud med mængder Digital leverance ved byggeriets aflevering Digital mangelinformation 5 ( Under området: Håndtering af digitale byggeobjekter, står der i paragraf 4: 4. Bygherren skal stille krav om, at digitale byggeobjekter gennem hele byggesagen struktureres, klassificeres, navngives, kodes og identificeres ensartet i en nærmere bestemt detaljeringsgrad. Bygherren skal i den forbindelse stille krav om, at byggeobjekterne forsynes med de informationer og egenskaber, der er relevante for den efterfølgende forvaltning, drift og vedligehold. Stk. 2. Bygherren skal sikre, at der fastsættes retningslinjer for håndteringen af digitale byggeobjekter gennem hele byggesagens forløb. 4 ( Videre i paragraf 6 og 7 stilles der krav til objektbaseret bygningsmodellers visualisering, modellens funktionelle og tekniske forhold i et nærmere bestemt informationsniveau. 9

11 Bygningsmodellen skal afleveres i et IFC format. IFC står for Industry Foundation Classes og er et modelgrundlag for deling og udveksling af data. IFC er udviklet af Building Smart. buildingsmart er et åbent og neutralt internationalt samarbejde om bl.a. udvikling og anvendelse af åbne standarder for BIM (Building Information Modelling). 4 ( 6 ( Digitaliseringen har skabt nye roller og behov for nye kompetencer hvor buildingsmart bidrager til et mere bæredygtig byggede miljø gennem smartere informationsdelinger og kommunikation ved hjælp af åbne internationale standarder i byggebranchen, både for private og offentlige byggerier. Nogle af deres mål er at udvikle og opretholde åbne internationale standarder for BIM, Give netværksmuligheder, specifikationer og skriftlig vejledning, løse problematikker der hindre dataudvekslinger og Bips der har været en central medspiller med deres publikationer, som har til formål at samle de digitale tråde. Bipses mange publikationer har vist at de enkelte organisationer over tid har lært at bruge standarder. BIPS står for byggeri, informationsteknologi, produktivitet og samarbejde. De er en forening der er stiftet i Målet med foreningen er at udarbejde fælles værktøjer og metoder hvormed at byggebranchen kan arbejde på tværs af faggrupper. De har udarbejdet CAD - manualer og en række beskrivelses værktøjer. Mange af disse værktøjer er dem man bruger i dag til at strukturere informationer i en BIM model 7 ( En BIM model er opbygget af objekter, som er de byggesten man bruger i modellens geometriske struktur. Til hvert objekt knytter man en række egenskaber og informationer, som for eksempel kan være objektets styrke, materiale og egenskaber. Disse egenskaber knytter man til parametre så at det er muligt at opnå relation til andre BIM objekter. Det er vigtigt at de enkelte objekter indeholder muligheder for at være fleksible, som for eksempel en væg, der har mulighed for at ændre størrelse på isoleringstykkelser og højder. Alt dette skal der til for at opnå et BIM objekt, som man kan kalde for intelligent. BIM objekter behøver ikke alene at være geometriske genstande men kan også være geometrier som er skabt af objekterne, som f.eks. rum, der skal kunne have de samme egenskaber som de geometriske genstande. (Wad, L. J. & Stolberg, B.J. mf. dec.2013 s. 6) Formålet med kravet i 4. er at sikre, at byggeobjekters informationer og deres egenskaber er til rådighed for bygherren og alle hans aktører i helle byggeprocessen, og at dataudvekslingen kan ske, så uhindret som muligt. Driftsrelevante objekters informationer og deres egenskaber skal til sidst står til rådighed for driftsherrens, ved byggeriets overdragelse i et nærmere specificeret omfang. Dette er for at i størst muligt omfang at udnytte fordelene ved objektbaseret modellering, fra den forhenværende dokumentbaserede arbejdsmetode. Dette fordrer at Byggeobjekter i bygningsmodellen er entydigt identificeret og navngivet. Denne entydige identifikation af objekter skal tilgodeses, også selv om der arbejdes med flere klassifikationssystemer. 8 ( 10

12 I næste afsnit vil jeg beskrive CCS og dets formål. 3. Hvad er CCS og dets formål: CCS (Cuneco Classification System) er et struktureret system, der skal kunne håndtere informationer om det byggede miljø. Det der ligger i det er, at man gerne vil dele informationer med hinanden i byggebranchen, det kan f.eks. være de informationer man har i en proces og som man gerne vil dele i andre processer. Det man forsøger at lave i Cuneco er at man vil kunne dele og strukturere informationerne i analogi så at mennesker kan forstå dem, men også så at IT systemerne kan læse dem. Analogi er overensstemmelse med noget andet på væsentlige punkter, som gør det muligt at forklare det ene ved at sammenligne med det andet. Altså overensstemmelse, ligheder. (Politikens Nudansk Ordbog 4 udgave). Problematikken er at når IT systemer skal overføre informationer imellem hinanden så fjerner man denne menneskelige forståelse som når man deler en pdf. imellem to personer hvor at personerne kan tage telefonen og ringe for at afklare misforståelser, dette er ikke muligt når det er imellem IT systemer der udveksles. Derfor skal tingene være langt mere præcise når man udveksler i IT systemer. I Cuneco har man lavet en klassifikation som skal kunne dække hele byggemiljøet så at systemet kan bruges hele vejen igennem byggeprocessen fra ide til drift. Derfor kunne Cuneco lige så godt hedde Cuneco Collebration System eller Cuneco Conceptual System fordi CCS handler om samarbejde og fordi det er et koncept. Målet for CCS er at kunne styrke udnyttelsen af informationer i byggeriet så at byggeprocessen får en bedre produktivitet og byggeriet får bedre kvalitet. De gevinster der menes at vindes i produktiviteten, når man bruger CCS, er at informationerne, der overdrages imellem de forskellige aktører i værdikæden, ikke skal laves flere gange og at der er mindre informationer der går tabt i processen. Det vil styrke kvaliteten fordi der er mere tid til at kvalitetssikker sine data og at man bedre kan se sit eget grundlag af data. Det gør at man bliver mere bevist om hvad det er man leverer af informationer til de andre aktører. CCS skal være med til at sikre at man får det man skal have, og at det har den kvalitet som det skal have. 9 ( 06:26-13:33) CCS består af 9 værktøjer der alle har til formål at styrke udnyttelsen af informationer i objekter: 1. Klassifikation: Der skal kunne adskille objekter. 2. Identifikation: Der skal sikres at der tales om det samme objekt. 3. Egenskaber: Som skal hjælpe med at knytte informationer til et objekt. 4. Måleregler: Der skal sikres at det er de samme mål der er tale om. 5. Formålsgrupper: Som skal knytte informationer til et bestemt formål. 6. Standardiseret tilbudslister: Så tilbudslister lettere kan udfyldes og læses. 7. Klasser af 11

13 Information: 8. Informationsniveau: 9. Prissætningsregler: Som skal hjælpe med at adskille informationer. Som skal kunne angive niveauet for de informationer, og den detaljering der knytter sig til et objekt på et givent tidspunkt i byggeprocessen. Der skal hjælpe med at sikre at der er tale om de samme mængder og ydelser. 16 ( (se figur 2) Figur 2 Klitgaard, projektdirektør for Cuneco, udtaler at CCS helt fra starten, og helt grundlæggende er tænkt som noget der skal understøtte den digitale infrastruktur på tværs af aktørerne. Det vil sige på tværs af alle involverede aktører i byggeprocessen. Klitgaard udtaler at sådan er hverken SfB eller DBK født, men det er CCS. Han mener også at man kan diskutere hvor langt de i Cuneco er kommet i forhold til deres vision, men visionen, som Cuneco viser i deres lille tre minutters introduktionsvideo, er det CCS er bygget op omkring. (07:13-08:32 Klitgaard) SfB systemet, som Klitgaard omtaler, er et af de mest anvendte systemer inden for klassificering og kodning af bygningsdele i Danmark i dag SfB systemet (SfB=Samarbetskomitén för Byggnadsfrågor) blev oprindeligt udviklet for klassificering og kodning af den svenske standardbeskrivelse Bygg- AMA, og anvendtes her første gang i Systemet vandt hurtigt stor udbredelse, også i andre lande, bl.a. i forbindelse med byggevareregistrering, især fordi det i 1972 blev internationalt anerkendt af 12

14 CIB (Commission Internationale Batiment) i Rotterdam. En anden medvirkende årsag er, at SfB-systemets principper har vist sig velegnet til opbygning af kodningssystemer i forbindelse med it-behandling af byggesagers data, suppleret med frie symboler. (Hegner C. J.& Følsgaard G. V 2011) SfB er blevet anvendt igennem mange år, hvor CCS er en videreudvikling af DBK. Videreudviklingen har fundet sted fra i regi af Cuneco - center for produktivitet i byggeriet - som er et projekt ledet af bips. DBK står for Dansk Bygge Klassifikation. DBK er det første bud på et sammenhængende klassifikationssystem for byggeriet i Danmark, og resultatet er baseret på en række internationale standarder. 7 ( De tre væsentligste pinde der udgør at Klitgaard tror på at CCS er en del af fremtiden er: 1. Visionen om branchens infrastruktur 2. Visionen om en standard, der kan integreres ind i IT-systemerne 3. bips, som projektudvikler, er den organisation der kan vedligeholde og drifte selve CCS-klassifikationen og hele CCS-systemet. (Klitgaard 15:52-16:25) Man har afprøvet dele af CCS på byggeprojektet Det ny Hospital i Vest (DNV) også omtalt som supersygehuset i Gødstrup nord for Herning. Her har man i udbudsmaterialet angivet totalrådgiveren hvilke processer og digitale metoder man har tænkt for at efterleve de statslige IKT bekendtgørelser. Formålet er at den digitale data skal kunne anvendes efter aflevering af både drift, vedligehold og ejendomsforvaltningen derfor har projektledelsen for DNV indgået en aftale med Cuneco center for produktion for at implementere og afprøve nye digitale metoder. Projektchefen på DNV er gået med til at afprøve CCS fordi han tror på at forudsætningen for at effektiviser byggeprocessen, er de digitale metoder, og at en fælles digital platform vil kunne mindske kommunikations misforståelser imellem rådgivere og entreprenører og give de efterfølgende drifts og vedligehold af byggeriet informationerne digitalt 11 ( I næste afsnit vil jeg tage fat i Klassificering og Strukturering af BIM objekter hvor jeg vil se på om CCS s værktøj Klassifikation kan skabe værdi fra projektering til udførelse til drift. 4. Klassificering og Strukturering af BIM objekter Grundlæggende bruger man klassifikation til at kunne adskille bygningsdele fra hinanden så de bliver genkendelige af mennesker og IT. I CCS har man opdelt bygningsdelene i tre klasser den første klasse er Funktionelle systemer, der er opdelt i 14 systemer og vises i CCS som et 13

15 bogstav (X). Funktionelle systemer er systemer, som skal kunne beskrive en overordnet funktion på et bygværk, eller f.eks. systemer der kan skifte luften i et hus. Det er de systemer der skal kunne opfylde en nødvendig funktion for at bygningen kan fungere. F.eks. defineres et vægsystem i CCS database som (B) som har funktionsbeskrivelsen: Samling af bygningsdele betragtet som en helhed der danner og adskiller rum. Den anden er Tekniske systemer, og er opdelt i 64 systemer. Den vises i CCS som to bogstaver (XX). Tekniske systemer er systemer der skal kunne beskrive den tekniske løsning for ovennævnte behov. Det kan f.eks. være en vægkonstruktion defineret i CCS database som (AB) som har funktionsbeskrivelsen: Samling af indbyrdes tilpassede bygningsdele der danner den konstruktive opbygning af en væg. Den tredje er Komponenter som indeholder 397 komponenter og vises i CCS som tre bogstaver (XXX). Komponenter er de enkelte dele der tilsammen danner et teknisk system. F.eks. definerer man en søjle i CCS database som (ULE) som har funktionsbeskrivelsen: Konstruktiv bygningsdel i form af et aflangt element som primært overfører aksiallast. Alle komponenter i alle tre klasser er definerede i CCS s database, det er for at give brugeren en bedre forståelse af hvad der menes for både klasser og de enkelte komponenter. 9 ( 30:46-32:30) se figur 3 Førhen hed disse tre klasser Hovedsystemer, Delsystemer, og Komponenter det er blevet ændret til ovenstående fordi det skabte forvirring for brugene. Se kommentering fra Spile i Bilag Figur 3 14

16 Disse definitioner i databasen som f.eks. en dør QQC, Bygningsdel der åbner og lukker for personers adgang gennem et hul, kalder man i CCS for Egenfunktion, som er et objekts iboende tekniske funktion. Denne definition gør at man kan holde, den samme dør inden for en bestemt objektklasse (klassifikation). Når man har fastlagt, hvad for et af disse systemer man, vil arbejde med kan man bruge klassifikationstabellen til at definere hvad for en klasse af objekt der er tale om. Det kunne f.eks. være en dør der skal benævnes som et komponent, og vil få bogstavet D for at definere at det er en bygningsdel der er tale om, herefter kapsles koden ind i ulighedstegn, <D> efterfulgt af koden for en søjle. ULE og derefter opbygge søjlen med de egenskabsdata som er nødvendig for at specificere søjlen, dette er for at undgå at skifte klassifikationskoder på søjlen igennem projektforløbet. De fordele man får ved at kode for klasser af egenfunktion er enkle og let genkendelige koder for IT og mennesker, som bliver ved med at være stabile 12 ( 08:23-16:22 Del 1) 9 ( 21:52-39:44) Se figur 4 Se kommentering fra Spile i Bilag Figur 4 Spile, der er projektchef i Cuneco udtaler: Det vi har gjort i CCS i forhold til vores bygningsklassifikation er i stedet for at gå ind og kigge på, hvad man bruger bygningsdelene til, så vil vi kigge på, hvad bygningsdelene gør. Så vi har lavet nogle definitioner på de her bygningsdele, der for eksempel siger, at en dør er en bygningsdel, der åbnes og lukkes og giver mulighed for adgang, og et 15

17 vindue er en bygningsdel, der slipper lys ind og tilsvarende også med installationsbygningsdelene. Det, det gør, er jo, at vi mener, at vi har lavet et specifikationssystem, der er konsistent ved at vi har brugt den samme måde at kigge på bygningsdelene over hele billetten, og dermed mener vi også, at vi får noget, som er mere velegnet i forhold til de forskellige faggrupper. Så det er sådan den ene ting, når vi kigger på bygningsdelene. Det andet sted er, når vi kigger på altså vi har jo lavet klassifikationer af bygningsdelene, og så har vi f.eks. også lavet klassifikationer af bygværker og rum, og der er afgørende forskel på en bygningsdel og et rum. En bygningsdel har nogle karakteristika, der gør og afgør, hvad den kan bruges til. Altså for at en dør kan bruges til en dør, så skal den kunne åbnes og lukkes, og man skal kunne gå igennem den. Sådan forholder det sig ikke med rum. Rum kan man jo faktisk bruge til hvad som helst, man kan sagtens lave noget, som man starter med at synes skal være et kontor og så på et tidspunkt bruge det til mødelokale og så senere finde ud af, at man også kan bruge det som depotrum. Det ændrer jo ikke på selve rummet. Så derfor har vi egentlig valgt en anden måde at gå til rum og bygværker og bygningsdele på. Når vi siger rum, der er det ikke selve rummet, vi klassificerer, der er det anvendelsen af rummet, vi udarbejder en klassifikation for. Så der har vi også brugt den forskelligartethed, der er i tingene, til at lave nogle klassifikationer, der er målrettet til det, man rent faktisk skal bruge det til. (Spile 01:56-03:50) Valentin som er IKT leder på DNV har været med til at sætte rammerne for hvordan man har implementeret CCS standarderne i DNV sammen med en arbejdsgruppe. Valentin mener ikke Cuneco har forholdt sig til praksis, i forhold til det man plejer at gøre. Et eksempel er de tre klasser som ifølge Valentin ikke er nødvendige: Hovedsystemer, (Funktionelle systemer) Delsystemer (Tekniske systemer) og komponenter. Skal vi bruge komponenter eller delsystemer? Spørger Valentin, der har svært ved at se fordelene ved at bruge de 3 systemer. Endvidere udtaler Valentin: Fra arkitektens side vil vi gerne bruge delsystemer, det kan man sige i hvert fald bredt over en kam at det er vores systemer. Så kan man sige at producenter og leverandører muligvis kan arbejde i komponenter. Men der skal vi slet ikke ned som rådgiver når vi udbyder. Vi skal ikke ud og udbyde på komponentniveau det bliver alt for dyrt for os det er ikke noget vi får noget for. Vi skal udbyde på bygningsdeltype niveau, det er noget af det vigtigste man skal prøve at få forklaret branchen. Det kan være lidt anderledes for ingeniøren de har nogle mindre komponenter, de vil gerne dele deres systemer op i fittings. Vi skal ikke ud i at definere løbende meter fuge på et vindue, vi skal definere vinduet i en arbejdsbeskrivelse. (Valentin 10:00-11:19) Valentin kan kun udtale sig for de fag, der har siddet og arbejdet på DNV, Men det at de har kodet materialet med CCS, har de ikke hørt nogle tilbagemeldinger på. Det tolker Valentin som om det er lige meget hvilke systemer de bruger i forhold til modtageren og 16

18 entreprenøren. Modtageren og entreprenøren ser det mere bare som et nummer de skal prissætte og kigger måske på en tekst af bygningsdelen. Valentin udtaler: Vi har ikke hørt at det skulle være et problem, så det er jo godt nok. Men jeg ved at førhen har entreprenøren sagt: jeg kan se at I bruger SfB system og det er fint for det kender vi i branchen, men det er et spørgsmål om tilvænning og det vil ikke tage lang tid. Det tror jeg ikke. (Valentin 12:40-13:30) Om CCS kan opfylde kravet i 4. om en ensartet struktur, udtaler Tuxsen Lyck IKT-leder i Bygningsstyrelsen: CCS bygger på et stabilitetsprincip, mit indtryk er JA, for hvis vi i Bygningsstyrelsen skulle lave vores eget klassifikationssystem der skulle opfylde kravene i 4. ville det kun fungere i vores egne ejendomme. Nej selvfølgelig er vi med på denne her. (Tuxsen Lyck 11:44-12:42) Tuxsen Lyck udtaler: Lige nu har vi et afprøvningsprojekt på brugsrum på et universitetet, som handler om rumkategorier og rumnavne osv. Universitetet har nogle specifikke behov i deres drift, og der har vi været i gang med at mærke med Cuneco s brugsrum klassifikation. Kan det lade sig gøre overhovedet? Giver det mening at klassificer med CCS hvis driftsorganisationen på universitetet i sidste ende modtager noget som de skal til at omlægge eller skubbe til en side og så ellers klassificere rummene fra ny. Det er et projekt der er i gang lige nu. Så resultatet er ikke kommet endnu. For Tuxsen Lyck er dette interessant fordi Bygningsstyrelsen, lige som andre store bygherrer har svært ved at få konstant data ud på rummet, hvor mange kvadratmeter er der, hvad skal rummet bruges til, hvordan er det navngivet osv. (Tuxsen Lyck 12:42-14:25) 4.1 Delkonklusion: Det at opdele klassifikationerne i systemer giver meget god mening, da der i byggebranchen er forskellige behov. Som Valentin F.eks. udtaler bruger rådgivere i et arkitektprojekt typisk Tekniske systemer og Ingeniøren og andre aktører kan have behov for at arbejde med komponenter. Dette viser at der et overordnet behov for at opdele en bygning i systemer og få klassificeret de forskellige objekter så de er målrettet til det man skal bruge dem til. Klassifikationerne og klassifikationstabellerne skaber den nødvendige struktur ved at BIM objekternes informationer er konsistente, så at byg og driftsherre kan få den data ud af modellerne på det objektniveau de har behov for. I næste afsnit vil jeg tage fat i Ensartet kodning og identificering af BIM objekter hvor jeg vil se på om CCS s værktøj Identifikation kan skabe værdi fra projektering til udførelse til drift. 5. Ensartet Navngivning, kodning og identificering af BIM objekter Formålet med identifikation og navngivning af BIM objekter gennem byggesags processer er, at undgå at objekter har forskellige navngivninger hos de forskellige aktører, fagområder og 17

19 IT systemer. Så der igennem hele byggesagen kan holdes styr på alle BIM objekter via en ensartet kodning på en sådan måde, at der undgås tab af information, og at der kan udveksles mellem parterne og deres forskellige IT systemer. Hvis man f.eks. skal beregne en væg som kommer fra en BIM model i et beregningsprogram, så skal koden eller navngivningen være ens så at begge programmer kan identificere væggen. 9 ( 39:44-43:42) Der er forskellige måder man kan identificere et objekt på via it-systemer et eksempel kunne være en GUID (Globally Unigue Identifier) det er et unik referencenummer der genereres i computersoftware som et entydigt universelt id 13 ( Ulemperne ved GUID referencenummer er at de er meget lange og svære at huske. De er også svære at styre, fordi man i en proces kan få et behov for at skulle skifte et objekt ud, som derved også skifter id. Derfor har man i Cuneco lavet et system, hvor man forsøger at undgå at miste koblingerne til det oprindelige objekt hvor man også ved og kan forstå hvordan nummeret er opstået. Det man har gjort er at lave nogle nøgler (præfiks) som kendes i musikverdenen Hver node i nodesystemet repræsenter en af stamtonerne. For at fastlægge hvilken tone de enkelte noder svare til, bruger man en nøgle. Nøgler noteres altid i begyndelsen af nodesystemet. 14 ( disse præfiks (nøgler) skal hjælpe med at man kan forstå hvad der kommer efterfølgende, de skal være en indgangsinformation til det man skal til at læse. 9 ( 39:44-43:42) Figur 5 18

20 I CCS bruges præfiks for at identificere den enkelte bygningsdel i et projekt. Disse præfiks er der fem af: Type-id (%) Produkt-id (#) Sammensat Produkt-id (-) Funktions-id (=) Placerings-id (+) Se kommentering fra Spile i Bilag Et eksempel kan være, at man har en bygning med 50 vinduer, som er opdelt i 3 typer og nu vil man gerne identificere vindue nummer 33 som er af typen nummer 2. Det man gør i CCS er at bruge klassifikationen for et vindue som er QQA og sætter præfikset produkt-id (#) foran og så nummeret, som i dette tilfælde er 33 og placeres bagved klassifikationen. Derefter adskiller man koden med en skråstreg (/) og gentage så processen med præfikset for Type-id (%) resultatet ville komme til at se sådan ud #QQA33/%QQA2 det er vigtigt at man forstår at det er nummereringen der har gjort koden projektspecifik 15 ( 12:22-21:22) (Cuneco ) se figur.6 Figur 6 Valentin udtaler: Det er et nyt system så man skal lige vænne sig til det. Når man så har gjort det finder man hurtigt ud af hvor enkelt det er. En af grundene til at det er let forståeligt er at man har hjemmesiden hvor man kan skrive vindue, og så kommer CCS koden for vinduet. Men for Valentin er det ikke godt nok. Han 19

21 efterlyser en løbenummerstruktur hos Cuneco. De har på DNV opdelt i faggrupper eller inden for bærende vægge, lette vægge så de ved at hvis det er inden for det interval af tal så er det en gips væg. Det Valentin synes der mangler er en måde hvor på man skaber mere genkendelighed. Han mener at problemet med CCS er at der ikke er nok intervaller fordi en væg i CCS bare hedder AB. Det han kan lide ved SfB er at man kan differentiere om det er en vægoverflade, en vægkomplementering eller en vægkonstruktion i og med at de ligger i 20, 30, 40 intervaller. Det mener han gør det nemmere for brugeren at forstå hvad det er for en bygningsdel der tales om. Valentin mener desuden det er et problem at CCS mere er sat op til at det er en maskine der skal læse det. En anden ting han har hørt andre klager over ang. CCS er at man skal bruge præfiks som f.eks. Type-id (%) Produkt-id (#). Men det synes Mads at man hurtigt vænner sig til. (Valentin 06:57-08:39) Om den måde man identificerer bygningsdele udtaler Valentin: Vi har også det der hedder identifikation. Det er den måde CCS koder den enkelte bygningsdel og specifikke komponenter. Det er her at man bruger tegn som fx havelågen (#) eller procenttegn (%) foran bogstaverne. Det er også det vi har brugt på DNV, det er det der heder typeaspekter. Det der er interessant når man snakker projektering og udbud er at man koder bygningsdelen på type niveau, det er også det, man altid har gjort med SfB som fx kunne være %QQA for et vindue og så et løbenummer. Det Cuneco gerne vil er at lade løbenummeret blive genereret af computeren, men på DNV har vi valgt at ville kunne underopdele bygningsdelene i faggrupper med et nr. system hvor at alt der ligger inden for 1000 er arkitektens, 2000 er ingeniørens og 4000 er El osv. så man kan sikre sig at der ikke er bygningsdele der går på tværs af fagene. (Valentin 04: ) Klitgaard udtaler: At man her har at gøre med et system som i det omfang det er blevet afprøvet vil have folk f.eks. Valentin, der har skarpe holdninger til hvad der er godt og hvad der er skidt. Det der stadigvæk udstår, når vi snakker bygningsklassifikation, er at få alle egenskaber med. Vi har ikke i Gødstrup-projektet kun klassificere med egenskaber, fordi vi ikke har været der i udviklingsarbejdet. Derfor har man måtte lave nogle typeformuleringer, i DNV, som dybest set ikke er, den måde CCS vil håndtere det på. Det har bare været det der var mulighedernes kunst, og sådan er det når man laver sådan en form for udviklingsprojekter. (Klitgaard 40:59 41:53) Klitgaard fortsætter: CCS fødes med en driftsorganisation i ryggen, i form af bips og i form af de folk der videreudvikler og modificerer CCS. Det vil sige der vil komme løbende versioneringer af CCS. Omvendt er det vigtigt at man som projekterende er klar over hvilken version af CCS 20

22 man klassificerer ud fra, så man ikke skal kode om eller blive usikker på hvilket grundlag man projekterede på, her kommer juraen lynhurtigt ind. Det vil selvfølgelig være muligt at låse sin CCS anvendelse til en bestemt version og i øvrigt gå tilbage via opslag i vores server osv. osv. Hvordan var det tabellerne var og så ud, og hele begrebs-definitions delen, givet af version 1, 2, 3... (Klitgaard 42:18 43:20) Valentin giver udtryk for at man ikke vil lette alle arbejdsprocesser og BIM processer bare fordi man har en kodning på en bygningsdel. Det behøves ikke at være CCS der skal bruges, men kan lige så godt være SfB systemet. Det Cuneco mener der er godt ved deres system, er at CCS kan læses ind i databaser og kan maskingenereres. Valentin er mere tilhænger af SfBsystemet fordi SfB giver flere muligheder for at lægge ind i niveauer, på hovedkonstruktioner, komplettering og overflader. Han mener at CCS er for enkel fordi det ikke giver nok muligheder for at kunne opdele de forskellige vægtyper og på en anden måde kan CCS blive kompliceret ved brug af præfiks (Valentin 02:28-03:54) Som et eksempel på dette, har jeg stillet SfB koder op imod CCS koder vist på figur 7. Her ser man at SfBs koder for yder og indervæg er (21) og (22) og i CCS er koden den samme for begge væg konstruktioner(ab). Som en del af interviewet med Klitgaard har jeg vist ham min illustration. Han udtaler: når jeg nu sidder og siger at opdaterings- og videreudviklings-arbejdet baserer sig på branchens erfaringer så er det jo 'spot on' det her eksempel, for det er jo den feedback vi skal have. Vi har udviklet det med de projektfolk vi har haft, vi har haft noget af det i test, men nu skal det jo ud og ramme branchen, og hvis der er nogen der synes det er svært at finde forskel i definitionerne, og forskelle mellem indervægge og ydervægge og den måde CCS håndterer de to begreber, så er det den feedback vi skal have. Det kunne være der var en forklaring på det, det kan også være vi skal ind og have ændret noget i opbygningen af det. (Klitgaard 39:41 40:48) 21

23 Se kommentering fra Spile i Bilag Figur 7 22

24 Kritikken ved anvendelsen af SfB- systemet er det tit problematisk når man skal kode en byggevare. System koden består af cifre og bogstaver sammensat i en trefaset kode f.eks. (21) Ydervæg (Facade) som angiver bygningsdelen, (F) angiver konstruktionen murværk derefter g2 som angiver ressourcen (materialet) brændt ler. Den sammensatte kode kommer til at se sådan ud: (21)Fg2. Problematikken skyldes at systemet ikke alene er skabt med dette formål, og systemet er ikke blevet opdateret de sidst 18 år. I den tid er der kommet mange nye konstruktioner, anvendelser og materialer der gør at der mangler den fornødne detaljeringsgrad. (Hegner C. J.& Følsgaard G. V 2011) De problematikker Spile oplever ved det gamle SfB system er, at SfB systemet har været meget forskelligartet i forhold til hvem, der har kunnet bruge det. F.eks. har SfB været meget populært blandt arkitekter, fordi SfB-systemets bygningsdele er meget koncentreret omkring, hvordan en arkitekt tænker et hus, og ikke særligt populært blandt installationsingeniører. Det skyldes at der i SfB systemet kun er en gruppe, der hedder ventilationsanlæg eller vvs-anlæg, og så går det ikke så meget længere ned, og dermed bliver det alt for uspecifikt til nogen fagområder og velegnede til andre. (Spile 01:13-01:56) Se kommentering fra Spile i Bilag Klitgaard mener at problemet med at implementere SfB, i IT-systemerne er at SfB systemet er udviklet i en tid hvor der ikke var noget der hed BIM. Det er udviklet til en anden generation af systemer, men han vil heller ikke afvise at det ikke kan implementeres. Klitgaard udtaler: Jeg tror at hvis du spørger prominente arkitekter i dag så har de rent faktisk formået at gøre det. Men vi kommer op imod nogle af de visioner som CCS er tænkt ud fra, altså tænkt som en tværgående branche-standard. Du ville da sikkert kunne fine flere eksempler på måder at klassificere en BIM-model på eller 3D-baseret bygningsmodel på, som isoleret set kan producere det samme som CCS kan, måske endda nemmere. men som så mangler de resterende features som CCS har, altså i forhold til udveksling til andre, fordi det ikke giver mening for andre at arbejde SfB-koder ind i deres systemer. (Klitgaard 16:25-17:47) I forhold til om SfB kan levere det samme som CCS mener Tuxsen Lyck at tanken bag CCS er en stabil klassifikation, så der ikke længere skal være i tvivl om at et objekt findes med den navngivning. At der ikke længere skal være tvivl på en tilbudsliste i forhold til om det hele er med. Henrik har haft nogle situationer hvor der rent faktisk er blevet givet tilbud på halve bygninger fordi at strukturen har været for ringe i bygningsmodellen. Tuxsen Lyck udtaler: Så teoretisk, og med mit forholdsvise lille kendskab til CCS, så vil jeg sige ja altså hvis tanken er at det bliver stabilt og der ikke længere er tvivl om at strukturen er ens hele vejen igennem fra projekteringen til udførelse også videre i udførelse og drift, så er det klart at jeg kan se store fordele i det. (Tuxsen Lyck 06:04-07:14) 23

25 5.1. Delkonklusion: Der er ingen tvivl om at der har manglet en standard, der er mere fyldestgørende end de nuværende standarder der har skullet kode og identificere BIM objekter med en ensartet navngivning. Problematikker som at SfB f.eks. ikke har været opdateret i 18 år og kan have været medskyldig i at der er givet tilbud på halve bygninger fordi at strukturen har været for ringe i bygningsmodellen. Desuden er SfB udviklet i en tid hvor der ikke var noget der hed BIM, samt at systemet har været meget forskelligartet, i forhold til hvem, der har, kunne bruge det. Et af de problemer der er med CCS er at der ikke er nok intervaller hvor man kan differentiere bygningsdele og det giver ikke nok muligheder for at lægge ind i niveauer fordi koderne er sat op til at en maskine skal kunne læse dem. Et andet problem er kodningen på objekterne ikke bliver opdelt i faggrupper dette gør at CCS ikke er kompleks nok til visse faggrupper. Fordelende ved CCS er at CCS kan læses ind i databaser og kan maskingenereres, desuden er CCS tænkt som et grundlag på tværs af byggesektoren med en driftsorganisation i ryggen, i form af bips som kan videreudvikle og opdatere koder og bygningsdele løbende. Så på trods af at nogle af faggrupperne nok kommer til at bruge lidt flere timer på at kode deres BIM objekter, mener jeg på sigt at alle faggrupper vil få en positiv andel ikke mindst fordi man har hjemmesiden hvor man kan taste et vindue ind, og så kommer CCS koden. CCS værktøjet Identifikation vil være med til skabe værdi fra projektering til udførelse til drift, hvis alle byggeriets aktører har implementeret værktøjet I næste afsnit vil jeg tage fat i informationer og egenskaber i en bestemt detaljeringsgrad, hvor jeg vil se på om CCS s værktøjer Egenskaber og Informationsniveauer kan skabe værdi fra projektering til udførelse til drift. 6. Informationer og egenskaber i en bestemt detaljeringsgrad i BIM objekterne I vejledningen til IKT bekendtgørelsen 118 stk forstås et byggeobjekts egenskaber som dets iboende og funktionelle karakteristika samt relationer til andre objekter. Disse egenskaber kan f.eks. være fabrikat, produktnavn, placering, materiale og godkendelser. Disse skal hensigtsmæssigt placeres i en fastlagt struktur, som er ens gennem et helt projekt. Der skal stilles krav om tilstedeværelsen af egenskaber, som skal bruges til anvendelse i projektet eller egenskaber som skal anvendes af byg- og driftsherren, og her med fokus på driftsherrens processer og IT-systemer 8 ( Egenskaber i en bestemt detaljeringsgrad handler om at udveksle informationer imellem de forskellige aktører i byggeriet. Problematikken ved at udveksle informationer er at egenskaber kan hedde forskellige ting som f.eks. isoleringsevne og u-værdi. For mennesker er det muligt at få afklaret hvad der menes, men for IT-systemer kan det blive problematisk, især hvis IT-systemet tror, at det har forstået hvad det er at den skal arbejde med, og det så ikke er rigtigt. Derfor har man i Cuneco skabt en ramme og en struktur for egenskabsdata 24

26 som skal udveksles mellem byggeriets aktører, herunder hvordan egenskabsdata oprettes, navngives entydigt, vedligeholdes, og udveksles digitalt, så både mennesker og IT-systemer kan forstå og tolke egenskaber entydigt. Når der bliver brugt synonymer vil IT-systemet aflevere egenskaben med den rigtige betegnelse. Egenskaber er informationer om objekter. Egenskaber er f.eks. materiale, placering, form, bredde, højde og mål. For at en egenskab skal være relevant skal den være knyttet til et objekt. 9 ( 47:13-01:11:23) Se figur 8 Figur 8 Når man kigger på et objekt i en bygningsmodel kan det f.eks. være et vindue som indeholder en masse egenskaber. Hvis vi tager en af disse egenskaber ud vil den have et egenskabsnavn som i dette tilfælde er ThermalTrasmittance (isoleringsevne). Navnet på egenskaben kommer fra buildingsmart principper som understøtter IFC. Det er for at der skal være en sammenhæng til de standarder som der arbejdes med rundt omkring i verden og at IT systemerne kan læse og forstå navnet. Det betyder ikke at man ikke længere kan anvender navne som f.eks. Isoleringsevne og u-værdi i daglig tale, man skal bare være bevidst om at IT systemet kun forstår navnet ThermalTrasmittance. Denne egenskab har en egenskabsværdi og når man sætter dem sammen får man et egenskabsdataelement. Til et egenskabsdataelement knytter der sig altid Metadata, som er den enhed samt den referenceramme man beregner fra. Når man samler et objekts egenskabsdataelementer får man et egenskabs data sæt. Egenskabsværdien er projekt specifik, og egenskabsnavnet ligger i CCS s database. CCS forsøger ikke at lave alle egenskaber der findes i verden men en struktur hvorpå man kan strukturere egenskaber. 12 ( 01:41-04:28 Del 2) Se figur 9 25