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

27 Figur 9 I CCS forholder man sig til et objekts udvikling ved at forsøge at lave en stabil klassifikation, som bliver opbygget af egenskabsdata, og ikke som man traditionelt har gjort hvor man starter med en kode og slutter med en anden. Det CCS forsøger at gøre er at når objektet først har fået en kode bliver den ved med at have den kode, og så opbygger man objektet med egenskaber efter hvor meget man kender til objektet. F.eks. bliver en væg, som er kodet i CCS med AB Vægkonstruktion, defineret med egenskaber om det er en indervæg eller en ydervæg. 12 ( (19:00-20:16 Del 2) Se figur 10 Figur 10 26

28 Det overordnede formål med informationsniveauer er at kunne definere en entydig aftale om leverancer af informationerne på bygge- og anlægsprojekter. I vejledningen til IKT bekendtgørelsen 118, stk , beskrives at informationsniveauer bl.a. skal bruges til at beskrive indholdet i digitale bygningsmodeller og bygningsdele samt indholdet af egenskabsdata. Informationsniveauerne skal bruges som krav så at digitale objekter har den nødvendige detaljering og at der undgås unødig detaljering. Til sidst i vejledningen henvises der til Cunecos Metode og struktur for Informationsniveauer for at hente inspiration. 8 ( ). Udviklingen af informationsniveaumetoden og fastlæggelsen af informationsniveauer for objekter er kommet på grund af et behov der er i byggebranchen om at kunne indgå aftaler om grupper af informationer, og at informationerne ikke nødvendigvis har samme detaljering og omfang på et givent tidspunkt i byggeprocessen. Udviklingen af informationsniveaumetoden skaber mulighed for at aftaler kan differentieres på tværs af typer af information. Man anvender informationsniveaumetoden til at specificere, hvem der leverer hvilken information på et givent tidspunkt og på hvilket informationsniveau. Se figur 11 (Birch. P, K. & Spille, S.) Figur 11 Er det et større og mere komplekst projekt man skal lave leverancespecifikationerne til, kan der være behov for at informationsniveauerne fastlæggelses pr. bygningsdel eller tekniske systemer i et af projektets faser. Her kan man lave en leverancespecifikation hvor man ønsker bygningen på informationsniveau 5 men laver en afvigelse på f.eks. vægsystemerne i bygningen som ligger på informationsniveau 4. Se figur 12 (Birch. P, K. & Spille, S.) 27

29 Figur 12 Man har i CCS udviklet 7 informationsniveauer, som skal kunne angive niveauet for de informationer, der knytter sig til et objekt. Det laveste niveau er niveau 1, det højeste er niveau 7. Informationerne og konkretiseringen vil øges i takt med at byggeprocessen går fra ide til drift, hvor niveau 1 er der man ved mindst og niveau 7 er hvor man ved mest. Informationsniveauerne knytter sig til objekter, som kan være bygværker, fysiske rum, brugsrum, bygningsdele og materiel. Det er muligt at differentiere det niveau, som informationerne befinder sig på fra byggeriets enkelte dele, ved at knytte informationsniveauerne til objekter. Informationsniveauerne kan anvendes til at definere de informationer, der skal afleveres/modtages i mellem byggeriets aktører. Se figur 13. (Birch. P, K. & Spille, S.) 28

30 Figur 13 På figur 14 kan man se hvordan CCS definerer informationsniveau 2. På figur 15 kan man se hvordan de definerer informationsniveau 5. 29

31 Informationsniveau 2 Definition: Skitse af et løsningsforslag. Note 1: Løsningsforslaget er resultatet af bearbejdningen af ideen. Note 2: Løsningsforslagets form og placering er beskrevet og illustreret ved en indikation af arealer, voluminer, lokalisering, orientering samt relation til omgivelser. Note 3: Løsningsforslaget er beskrevet ved forventede oplevelsesmæssige forhold og funktion. Note 4: Løsningsforslaget er beskrevet ved forventet økonomi og tid. Note 5: Normalt betragtes alene objektet bygværk. Figur 14 Informationsniveau 5 Definition: Specifikation af en fysisk realiserbar løsning. Note 1: Ved fysisk realiserbar forstås en entydig detaljeret specifikation af løsningen, der kan danne grundlag for udførelse, anvendelse og vedligeholdelse. Note 2: I specifikationen er den endelige form, placering og relation til øvrige relevante objekter beskrevet og illustreret. Note 3: I specifikationen er fastlagt løsningens økonomi, tid, aftaler og myndighedsforhold. Note 4: I specifikationen er funktions-, ydeevne-, og materialemæssige løsninger og sammenhænge endelig beskrevet. Note 5: I specifikationen er løsningens anvendelse og vedligeholdelse beskrevet. Figur 15 Note 6: For bygningsdele er alle væsentlige komponenterfastlagt.

32 Spile udtaler: Hvis vi kigger på bygningsdele, er der lavet en klassifikation, som definerer bygningsdelen. Er det en væg, en dør, en ventil eller en kabelbakke? Vi har laver noget, der matcher buildingsmart rimelig meget. Det niveau vi betragter objektet på, er meget det niveau, man betragter objekter på i buildingsmart, og dermed også det niveau, man definerer objekter på inden i en bygningsmodel. Så en bygningsdel, den opererer med et begreb man kender, som er en væg, og der har vi jo tilsvarende en klasse i vores system på samme niveau. Så det vi gør er at definerer en egenskab på objekterne som siger, hvilken klasse de tilhører. Når vi kommer ud over det og f.eks. kigger på, om det er bærende eller ikke-bærende vægge, er det indvendige vægge eller er det udvendige vægge, så håndterer vi det som egenskaber, som gør at alle vægge en fælles specifikation, der siger, at de er vægge. Og der ud over, så har de nogle egenskaber, der siger, hvad det er for nogle vægge. Og der ligger vi os pænt op af den systematik, man bruger i buildingsmart, hvor man f.eks. har en egenskab, der hedder External, og man har en egenskab, der hedder Loadbearing, og det bruger den så til at styre objekterne. Så det vi lægger op til, det er jo egentlig at på samme måde, som man har i buildingsmart, så har vi nogle fælles retningslinjer for, hvad vi kalder de her egenskaber, som vi kan bruge til at gruppere vores bygningsobjekter. (Spile 04:08-05:57) Tuxsen Lyck tage udgangspunkt i den vejledning han er ved at udarbejde, hvor formålet er at sikrer informationerne om byggeobjekternes egenskaber helt overordnet. Og for at tage udgangspunkt i Bygningsstyrelsen så har vi en udfordring i forhold til de informationer, der ligger i vores bygningsmodeller når vi modtager dem i projekteringen og når de skal overgå til drift. Dels fordi vi ikke håndterer i egne rækker her i huset, i vores vedligeholdeslse og drift håndterer vi ikke modeller det vil sige at det stadig er dokumentbaseret, det er bygningsdelskort osv. Så udfordringen hos os ligger at sikre at modellen er struktureret og at objekterne er klassificeret og indeholder de egenskaber vi ønsker, så vi rent faktisk kan have et grundlag for at kunne håndtere modeller i driftsfasen, altså driftmodeller. Det er vores tanke med en bedre struktur på bygningsmodeller. (Tuxsen Lyck 02:10-03:13) Klitgaard udtaler, at man i Cuneco har set et behov for at lave et system, som kan kobles med det regelsæt der eksisterer i dag i form af ydelsesbeskrivelserne, som går ind og gør det nemmere at definere hvilke data en model skal indeholde og hvilke krav, som kan stilles til de projekterendes modeller på forskellige niveauer. Videre siger Klitgaard: Vi har været vidt omkring i arbejdet med informationsniveauerne, men at lande på det niveau hvor vi har defineret syv niveauer, fra den helt tidlige, rene konceptuelle model, og så til den meget meget detaljerede maskinelæsningskode i forhold til produktionen af 31

33 materialer. Rigtig, rigtig meget projektering kommer til at ligge ind imellem de to niveauer. Vi er landet på et set-up, hvor vi opererer med nogle overordnede definitioner og så i et ret detaljeret note-værk der detaljerer de her definitioner på de enkelte informationsniveauer.. Det arbejde vi er i gang med lige nu så hvor den lander 100% det tør jeg ikke sige. (Klitgaard 20:00 22:00) Klitgaard uddyber: Informationsniveauerne er et sæt af definitioner på hvilke data der bør indgå, eller hvilke overordnede niveauer der bør kobles til hvilke data. Dermed kobles hele den forståelse af stade og data til de projekterendes ydelsesbeskrivelser og dermed også honorar-regler, som vi kender dem fra i dag.( Klitgaard 22:50 23:36) 6.1. Delkonklusion: Som Tuxsen Lyck udtaler er formålet at sikre informationerne om byggeobjekternes egenskaber helt overordnet for at have et grundlag for at kunne håndtere modeller i driftsfasen. Det der er godt ved CCS s håndtering af egenskaber er at de bygger på den systematik, man bruger i buildingsmart som at kendt af dem, der arbejder med BIM modeller i dag og ikke mindst det at buildingsmart understøtter IFC. Da informationsniveauer ikke er afprøvet endnu men er under udarbejdelse er det svært at sige om værktøjet vil skabe værdi. Men det ser ud til, at det vil give en mulighed for at få defineret niveauer af informationsdata, man ønsker leveret, på en mere spiselig måde end man f.eks. får ved ydelsesbeskrivelsen. 7. CCS som et lovkrav I den forhenværende IKT bekendtgørelse BEK nr af 11/12/2006 (historisk) blev der stillet der krav i 6. om at bygherren i relevant omfang skulle sikre anvendelse af Dansk Bygge Klassifikation (DBK). 2 ( I den nuværende vejledning til IKT bekendtgørelsen VEJ nr af 06/02/2013 (gældende) i skt : Inspiration til krav om navngivning, kodning, klassifikation og identifikation, stilles der krav i en given byggesag til navngivning, kodning, klassifikation og identifikation, og at disse bør tage udgangspunkt i ISO-standarderne ISO og ISO/PAS 16739:2005 (IFC) og følge principperne heri. På det konkrete plan, anbefaler vejledningen til IKT-bekendtgørelsen, at bygherrer lader sig inspirere af nedennævnte systemer, der inden er kendt i byggeriet gennem en årrække, eller som CCS der er under udvikling. Det drejer sig om følgende klassifikationssystemer, der foreligger på dansk: SfB-systemet

34 CCS (Cuneco Classification System) der er under udvikling som erstatning for Dansk Bygge Klassifikation (DBK). Forvaltnings Klassifikation, version 2.0 som benyttes fra 2012 i forbindelse med forvaltning af almene boliger 8 ( Om CCS skal være et konkret krav i den næste IKT bekendtgørelse udtaler Klitgaard: Ja det vil jeg sagtens kunne se, men jeg ville også kunne se det stik modsatte. Jeg tror man skal vare sig meget ved at tro at næste revision af bekendtgørelsen bliver endnu skarpere i forhold til sin kravstillelse. Det kan gå begge veje, så jeg vil ikke udtale mig konkret om hvor det går hen ad. Vi har tidligere set en udvikling der hed at; DBK var indskrevet som et krav i den tidligere bekendtgørelse (tilbage fra 2007), og den seneste revision har man taget kravet ud konkret i forhold til at understøtte metodefriheden. Der er et ønske i branchen omkring metodefrihed og hvis man lytter til det ønske, så vil det medføre at bekendtgørelsen bliver blødere. Jeg tror dog at der er en stemning for at man fra offentlig side stiller krav der sætter arbejdet i en ganske bestemt retning, og det er det jeg mener man har nået med det bekendtgørelses-sæt der ligger i dag. Jeg tror ikke at CCS vil blive nævnt ved navn, det ville undre mig hvis det gjorde. Det er vi dybest set heller ikke interesseret i. Jeg vil hellere bevise at CCS faktisk skaber værdi i sig selv. Jeg ser hellere at virksomhederne benytter CCS, fordi de ser en værdi i det, snarere end at det er et krav. Jeg tror flere og flere bygherrer vil kræve CCS og det vil de fordi de kan se at CCS faktisk er et fornuftigt klassifikationssystem. Hvorvidt man får en bekendtgørelse i ryggen der kræver det ved navn, det har jeg min tvivl om. Selvfølgelig vil vi gerne have det til at stå med fede typer i en bekendtgørelse, men det tror jeg ikke tiden er til. En beskrivelse af hvad man gerne vil opnå, men så lægge metodefrihed ind under vejs, så man styrer på resultatet frem for med krav 'up front'. (Klitgaard 31:34 34:11) Tuxsen Lyck kan mærke at han i hans job har nogle langt bedre argumenter, når det står sort på hvidt, med nogle helt faste lovgivningskrav. Tuxsen Lyck udtaler: Det er meget sort og hvidt og firkantet og alt muligt, men helt klart. Der kan vi mærke at lovgivningen eller bekendtgørelsen er med til at fremme det her samarbejde. Helt klart. (Tuxsen Lyck 24:12-:25:45) Tuxsen Lyck oplever at branchen kan være meget konservativ og samarbejde ikke er det der ligger først. Han tage udgangspunkt i hans eget job, der handler om IKT-ledelse og udtaler: Så handler det om at man får sat sig ned ved et bord og får snakket det her igennem, og det er jo ikke værre end at en driftsorganisation der har nogle afleveringskrav der og projekterende der skal sørge for at få indlejret det i en model som det er lige nu. Men der kan tit være boksekampe. Hvilket niveau, hvilket informationsniveau vil man 33

35 projektere til og hvad har man behov for. Og det er stadigvæk nogle termer som i vores situation og vores sager stadig er lidt konfus på en måde. Et informationsniveau 4 er ikke tydeligt for alle og bestemt ikke for et driftspersonale der går rundt ude i rummet og...og det er klart. Det er derfor at der er brug for IKT. Men bare det her med at få parterne placeret ved et bord og vi får talt om de her ting er en udfordring i sig selv. (Tuxsen Lyck 22:23-24:12) Valentin udtaler om CCS som et lovkrav: De har ikke skrevet det ind i den nyeste bekendtgørelse fordi de ikke har testet CCS ordentligt endnu. De har ikke helt vidst om det egentlig duede. Det kan være at de skriver det ind næste gang i bekendtgørelsen. De kan sagtens gøre det men de skal være sikre på at det er noget som branchen kan bruge. Det er måske mere det som man er i tvivl om. Hvis alle var enige om at det fungerede fint, så skulle man jo selvfølgelig gøre det. For så var det klart at så ville det accelerere brugen af det helt fra projekteringen af og ud i udførelsen. Det er klart at så snart staten går ind og definerer de her bekendtgørelser så flytter branchen sig også det kan man se ved 3D projektering, aflevering i IFC filer og kollationskontrol, når staten definerer de her ting og bruger sådan en lokomotiveffekt så flytter branchen sig. Man kan også gøre det inden for brugen af CCS. De skal bare sikre sig at det er noget der hjælper branchen og ikke er for kompliceret. (Valentin 16:00-17:09) 7.1. Delkonklusion: Det at der er et ønske i branchen omkring metodefrihed gør at den nuværende bekendtgørelse stiller krav der peger i en bestemt retning, som gør at man har det bekendtgørelsessæt der ligger i dag. Men at opfylde branchens ønske om metodefrihed er ikke nødvendigvis en god ide, fordi at branchen kan være meget konservativ og have svært ved at se andres aktørers behov. Når man fra offentlig side stiller krav via bekendtgørelsen som står sort på hvidt er der mindre diskussioner og langt bedre argumenter der fremmer samarbejdet i branchen. Det er allerede bevist med krav om aflevering i IFC filer. Så snart staten går ind og definerer krav i Bekendtgørelsen så flytter branchen sig. Man skal bare være sikre på at det er noget som branchen kan bruge. Så om CCS skal indskrives som et konkret lovkrav må afvente et par år til at CCS er afprøvet og har bevist at den kan skabe værdi for byggebranchens værdi kæde. 8. Konklusion I dette afsnit vil jeg svare på min problemformulering som er: Hvilke strukturer bør fastlægges for at skabe gavnlige BIM objekter som kan skabe værdi fra projektering til udførelse til drift? 34

36 En af de strukturere der bør fastlægges er at opdele objekt informationerne i klasser og systemer. Det giver god mening, da der i byggebranchen er forskellige behov, som f.eks. Valentin 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 er et overordnet behov for at opdele en bygning i systemer og få klassificeret de forskellige objekter så de er målrettet til dem der skal bruge dem. Klassifikationerne og klassifikationstabellerne i CCS 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. En anden struktur er at man skal kunne identificere objekter igennem standardiseret navngivnings metoder. 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, kan have været medskyldig i at der er givet tilbud på halve bygninger fordi at strukturen har været for ringe i bygningsmodellen og at SfB er 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, men kun hvis alle byggeriets aktører har implementeret værktøjet. En tredje struktur er at man skal kunne styre den mængde af informationer, til nogle forudbestemte niveauer i de enkelte objekter og i BIM modellen. Som Tuxsen Lyck udtaler er formålet at sikre informationerne om byggeobjekternes egenskaber helt overordnet for at have et grundlag for at kunne håndtere modeller i driftsfasen. Det der er godt ved CCS s håndtering af egenskaber er at de bygger på den systematik, man bruger i buildingsmart som at kendt af dem, der arbejder med BIM modeller i dag og ikke mindst det at buildingsmart understøtter IFC. Da informationsniveauer ikke er afprøvet endnu men er under udarbejdelse er det svært at sige om værktøjet vil skabe værdi. Men det ser ud til, at 35

37 det vil give en mulighed for at få defineret niveauer af informationsdata, man ønsker leveret, på en mere spiselig måde. Lovgivningen kan være med til at fremme en gavnlig struktur imellem byggeriets aktører. Det at der er et ønske i branchen omkring metodefrihed gør at den nuværende bekendtgørelse stiller krav der peger i en bestemt retning, som gør at man har det bekendtgørelsessæt der ligger i dag. At opfylde branchens ønske om metodefrihed er ikke nødvendigvis en god ide, fordi branchen kan være meget konservativ og have svært ved at se andres aktørers behov. Når man fra offentlig side stiller krav via bekendtgørelsen som står sort på hvidt er der mindre diskussioner og langt bedre argumenter der fremmer samarbejdet i branchen. Det er allerede bevist med krav om aflevering i IFC filer. Så snart staten går ind og definerer krav i Bekendtgørelsen så flytter branchen sig. Man skal bare være sikker på at det er noget som branchen kan bruge. Så om CCS skal indskrives som et konkret lovkrav må afvente et par år til at CCS er afprøvet og har bevist at den kan skabe værdi for byggebranchens værdi kæde. Og til sidst for endeligt at svare på mit problemformuleringsspørgsmål tror jeg på at CCS vil kan være det værktøj der i løbet af nogle år vil være det fundament som vil skabe gavnlige BIM objekter med værdi for hele byggeriets værdikæde fra ide til drift. Det kræver dog at hele værdikæden implementerer CCS s værktøjer for at det kan give en værdi. Indtil da vil det nok komme til at blive ret dyrt for de aktører, som f.eks. de projekterende, der vil komme til at skulle styre en del deres Tekniske systemer med egenskabsdata. 36

38 Kildeliste Bøger: Wad, L. J. & Stolberg, B.J. mf. dec.2013, bips 214 Guide om objekter, bips. Kvale S 1997 Interview en introduktion til det kvalitative forskningsinterview, Hans Reitzels København. Hegner C. J.& Følsgaard G. V HFB Byggecentrum Rapporter: Birch. P, K. & Spille, S. & Nybo, E. jan Klassifikation af information, egenskaber, informationsniveauer og formålsgrupper Høringsudgave, Cuneco center for produktivitet i byggeriet Cuneco CCS Identifikation Regler, definitioner og eksempler Cuneco center for produktivitet i byggeriet Internetsider: 1 ( Set den ( BEK nr 1365 af 11/12/2006 Historiskset set den ( 4 ( IKT Bekentgørelsen nr ( set den ( set den ( 8 ( vejledning til IKT Bekendtgørelsen nr ( BIM konference - Cuneco og Spine 11. dec På VIAUC Horsens med Søren Spile Cuneco 10 ( 11 ( set den

39 12 ( Del 1 og 2 d. 4/ ( 14 ( 15 ( præsentation af strukturering af bygningsdele på bips konferencen 2013 set den

40 Jonathan Noer Tlf: Interview spørgsmål til Henrik Tuxen Lyck, Byggestyrelsen 1) Hvad er det overordnede formål med IKT - bekendtgørelsen specifikt omkring paragraf 4. 2) Mener I at CCS kan opfylde kravene omkring en ensartet struktur på de informationer som indgår i objekterne, som er beskrevet i paragraf 4? 3) Kan CCS i forhold til klassificering af informationer i BIM objekter overholde kravet i paragraf 4? 4) I forhold til de andre nævnte standarder i vejledningen til IKTbekendtgørelsen, kan CCS så opfylde kravet om navngivning og ensartet kodning af de enkelte objekter, så at alle byggeriets aktører kan identificere objekterne igennem hele byggesagen? 5) Vil CCS være et godt bud på et redskab til at styre byggeobjekternes informationsniveauer i den rigtige detaljeringsgrad? 6) Er det jeres oplevelse at CCS kan være det fælles grundlag, som kan skabe en ensartet kommunikation imellem de forskellige parter fra projektets ide til drift? 7) Ville et lovkrav i IKT- bekendtgørelsen om brug af CCS standarderne kunne opfylde paragraf 4? 8) Er der noget andet I vil tilføje omkring arbejdet med IKT bekendtgørelsen i forhold til CCS?

41 Jonathan Noer Tlf: Følgebrev Afsender: Jeg er bygningskonstruktør studerende på 7.semester og er i gang med at skrive mit afsluttende speciale. Formålet med interviewet: Jeg vil i mit speciale prøve at finde ud af på hvilke strukturer der bør fastlægges for at kunne skabe gavnlige BIM objekter, som kan skabe værdi fra projektering til udførelse til drift. Jeg har valgt at se på 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 (IKT-bekendtgørelsen) til bygherrer i offentlige byggerier. Anden aktør er bygherrers rådgivere, som er dem der skal hjælpe bygherre med at opfylde de stillede krav, der er i lovgivningen. 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 Hvorfor jer: Jeg har valgt at ville interviewe jer fordi I arbejder for Byggestyrelsen og arbejder med IKTbekendtgørelsen. Hvad sker der med dataene, hvem ser dem: Interviewet med dig vil blive inddraget i mit speciale og i det dette speciale er studierelateret, vil det blive set af dem, der skal evaluere mig. Derudover vil jeg tilbyde at sende specialet til de personer, som har medvirket til interviews. Så hvis du er interesseret i det kan vi aftale at du får tilsendt det færdige produkt. Hvor lang tid tager interviewet: Selve interviewet vil tage fra 30-60min. Ser frem til interviewet, med venlig hilsen: Jeg ser frem til interviewet vi skal have tirsdag den 25/2 kl ved Byggestyrelsen, Valby. I er altid velkommen til at kontakte mig inden, hvis I har nogle spørgsmål. Med venlig hilsen Jonathan Noer

42 Jonathan Noer Tlf: Interview spørgsmål til Mads Valentin, Arkitema 1) Hvad har været jeres overordnede mål med at afprøve CCS på Gødstrup projektet? 2) Ved brug af CCS har det så været lettere at holde en ensartet struktur på de informationer som indgår i objekterne? 3) Kan du beskrive hvordan det i projektet har været at klassificere informationerne i BIM objekter ved at bruge CCS? Hvilke fordele og ulemper har der været? 4) Hvordan har man i Gødstrup projektet navngivet de enkelte objekter, så at byggeriets aktører alle har kunnet identificere objekterne? 5) På hvilken måde har det været muligt i Gødstrup projektet at kode objekters informationer ensartet ved brug af CCS? 6) Har det været muligt at holde informationsniveauerne i den rigtige detaljeringsgrad ved brug af CCS? Hvilke fordele og ulemper har der været? 7) Er det din oplevelse at CCS kan være det fælles grundlag, som kan skabe en ensartet kommunikation imellem de forskellige parter fra projektets ide til drift? 8) Ville du kunne se CCS som et konkret lovkrav i IKT - bekendtgørelsen? 9) Er der noget andet du vil tilføje omkring arbejdet med CCS i Gødstrup projektet?

43 Jonathan Noer Tlf: Følgebrev Afsender: Jeg er bygningskonstruktør studerende på 7.semester og er i gang med at skrive mit afsluttende speciale. Formålet med interviewet: Jeg vil i mit speciale prøve at finde ud af på hvilke strukturer der bør fastlægges for at kunne skabe gavnlige BIM objekter, som kan skabe værdi fra projektering til udførelse til drift. Jeg har valgt at se på 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 (IKT-bekendtgørelsen) til bygherrer i offentlige byggerier. Anden aktør er bygherrers rådgivere, som er dem der skal hjælpe bygherre med at opfylde de stillede krav, der er i lovgivningen. 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 Hvorfor dig: Jeg har valgt at ville interviewe dig fordi du er BIM-koordinator på Gødstrup projektet, og i det jeg ved at Gødstrup er et af de pilotprojekter hvor man har afprøvet CCS, er det højst relevant i forhold til mit speciale. Hvad sker der med dataene, hvem ser dem: Interviewet med dig vil blive inddraget i mit speciale og i det dette speciale er studierelateret, vil det blive set af dem, der skal evaluere mig. Derudover vil jeg tilbyde at sende specialet til de personer, som har medvirket til interviews. Så hvis du er interesseret i det kan vi aftale at du får tilsendt det færdige produkt. Hvor lang tid tager interviewet: Selve interviewet vil tage fra 30-60min. Ser frem til interviewet, med venlig hilsen: Jeg ser frem til interviewet vi skal have torsdag den 20/2 kl på Arkitema. Du er altid velkommen til at kontakte mig inden, hvis du har nogle spørgsmål. Med venlig hilsen Jonathan Noer

44 Jonathan Noer Tlf: Interview spørgsmål til Torben Klitgaard og Søren Spile Cuneco 1) Hvad har været jeres overordnede mål med at udarbejde CCS standarder? 2) Hvor har der været problemer med at udvikle en ensartet struktur på de informationer som indgår i objekterne? Hvad har I gjort for at løse dem? 3) Kan du beskrive hvad I har gjort i CCS for at klassificere informationerne i BIM objekter? Hvilke fordele og ulemper ser du? 4) Hvad har I gjort for at navngive de enkelte objekter, så at byggeriets aktører alle har kunnet identificere objekterne? 5) Hvad gør I for at kode objekters informationer ensartet ved brug af CCS? 6) Hvad går i for at informationer og egenskaber kan forvaltes i drift og vedligehold 7) Hvordan holder I informationsniveauerne i den rigtige detaljeringsgrad ved brug af CCS? Er der fordele og ulemper i forhold til DBK? 8) Er det din oplevelse at CCS kan være det fælles grundlag, som kan skabe en ensartet kommunikation imellem de forskellige parter fra projektets ide til drift? 9) Ville du kunne se CCS som et konkret lovkrav i IKT - bekendtgørelsen? Er der noget andet du vil tilføje omkring arbejdet med CCS?

45 Jonathan Noer Tlf: Følgebrev Afsender: Jeg er bygningskonstruktør studerende på 7.semester og er i gang med at skrive mit afsluttende speciale. Formålet med interviewet: Jeg vil i mit speciale prøve at finde ud af på hvilke strukturer der bør fastlægges for at kunne skabe gavnlige BIM objekter, som kan skabe værdi fra projektering til udførelse til drift. Jeg har valgt at se på 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 (IKT-bekendtgørelsen) til bygherrer i offentlige byggerier. Anden aktør er bygherrers rådgivere, som er dem der skal hjælpe bygherre med at opfylde de stillede krav, der er i lovgivningen. 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 Hvorfor dig: Jeg har valgt at ville interviewe jer idet at I er projektdirektør og projektchef for Cuneco og har været medudvikler af CCS standarderne. Hvad sker der med dataene, hvem ser dem: Interviewet med dig vil blive inddraget i mit speciale og i det dette speciale er studierelateret, vil det blive set af dem, der skal evaluere mig. Derudover vil jeg tilbyde at sende specialet til de personer, som har medvirket til interviews. Så hvis du er interesseret i det kan vi aftale at du får tilsendt det færdige produkt. Hvor lang tid tager interviewet: Selve interviewet vil tage fra 30-60min. Ser frem til interviewet, med venlig hilsen: Jeg ser frem til interviewet vi skal have mandag den 3/3 kl på Skype. Du er altid velkommen til at kontakte mig inden, hvis du har nogle spørgsmål. Med venlig hilsen Jonathan Noer

46 Bilag Komentering Kommentering Søren Spile Figur 3 Koderne er opdaterede i CCS Klassifikation af bygningsdele R0 fra den 17. marts 2014 Figur 4 I denne syntaks er der gået over til at anvende [ ] i stedet for <> Side 19 Der er efterfølgende kommet et Sammensat Type-ID til med præfix Figur7 Denne mapping baserer sig på høringsversionen af CCS bygningsdelsklassifikation. Det vil være lidt anderledes i forhold til den nye klassifikation. Side 23 Det er lige hårdt nok - der er fx 3 klasser under (57) Ventilation - Forsyning, Distribution og Forbrug Kommentering Henrik Tuxen Lyck Hej Jonathan Vi hedder BygningsstyrelsenJ Jeg arbejder ikke direkte med IKT-bekendtgørelsen det kunne være fedt hvis jeg gjordej Jeg arbejder som IKT-leder og med udvikling af det digitale byggeri i Bygningsstyrelsen. Ud over det kan jeg stadig godt stå inde for kommentarernej Jeg læser selvfølgelig rapporten igennem i løbet af i morgen! Mvh. Henrik Tuxen Lyck Ps. er blevet tilrette