Samarbejde mellem arkitekter og ingeniører i Revit

Transkript

1 VIA UNIVERSITY COLLEGE AARHUS Samarbejde mellem arkitekter og ingeniører i Revit Morten Aaskov

2 TITELBLAD TEKNISK-MERKANTIL HØJSKOLE SPECIALE TITEL: VEJLEDER: Stig Ilkrone FORFATTER: Morten Aaskov DATO/UNDERSKRIFT: STUDIENUMMER: OPLAG: To printede udgaver SIDETAL (à 2400 anslag): anslag = 25 sider 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 Som en del af 7. semester, på bygningskonstruktøruddannelsen, skal jeg skrive et speciale. Jeg vil, i den følgende rapport, skrive om, hvordan arkitekter og ingeniører samarbejder i Revit. Jeg vil beskrive teoretiske hjælpemidler, som kan danne grundlag for aftaler mellem disse parter i projekteringen. Som empiri vil jeg udføre interviews med arkitekter og ingeniører samt anvende tidligere rapporter, som jeg vil holde op mod teorien, hvorefter jeg vil analyserer og bidrage med min egen mening. Grunden til at jeg vil skrive om dette emne er, at jeg under mit praktikophold opdagede nogle problemstillinger, hvor arkitekter og ingeniører havde problemer med at samarbejde i en fælles bygningsmodel i Revit. Udfordringerne var bl.a., hvordan alle aktører kunne tilgå bygningsmodellens informationer. Udfordringerne var yderligere at tegnestuen havde svært ved at opdele forskellige arbejdsgange mellem arkitekt og ingeniør. Fx hvem der skulle være den ansvarlige når der skulle rettes i modellen? En særlig tak til Søren Sti Andersen (Aarhus Arkitekterne), Simon Andreas Arnbjerg (Schmidt/Hammer/Lassen architects) og Michael Porskær (Rådgivende ingeniørfirma Søren Jensen) for samarbejdet og de kvalificerede svar til interviewsne.

4 Abstract In this report I will examine how architects and engineers collaborate in Revit. During my internship I experienced several problems in terms of collaboration with the engineers that I want to clarify in this report. Including how to define architectural and engineering disciplines when a projected is created in a common building model? When does complications between architects and engineers arise in a common building model? At at last I want to know what tools are available for collaboration between architects and engineers in the design phase, when projected in a common building model? By construction projects over 20 million. DKK which is a government contractor, it is mandatory that displayed 3D visualizations. Therefore, it is necessary to enclose the building model in the level of detail and the visualization elements described in the competition material. This means that the demand of projects in Revit has grown, and several architectural firms implement Revit to meet these requirements for the design. It is a new way of projecting, and therefore there will be a lot of new challenges and barriers that drawing offices have to deal with. I will get much of the material for this report through the internet. It may be in the form of ICT guides and CAD Manual Furthermore, I will search for articles on the internet that deals with the topic on how other people obtain information from different orders. I can conclude that tools for collaboration between architects and engineers are few. What is used most often to describe levels of information is the CAD Manual 2008 and the other is where LOD describes information levels.

5 Indholdsfortegnelse Figur liste Indledning Baggrundsinformation og præsentation af emne Begrundelse for emnevalg og fagligt formål Problemformulering Afgrænsning Valg af teoretisk grundlag og kilder Valg metode og empiri Rapportens struktur og argumentation Begreber Hvad er BIM? Fællesmodel IKT Bekendtgørelsen IFC Bips CAD-manual BIM Execution Planning - LOD Teoriafsnit IKT anvendelse CAD-manual 2008 s Informationsniveauer Informationsniveau Informationsniveau Informationsniveau Informationsniveau Informationsniveau Informationsniveau Informationsniveau LOD LOD LOD LOD LOD

6 3.4.5 LOD Delkonklusion LOD ift. CAD-manual 2008 s informationsniveauer Delkonklusion Empiriafsnit Min erfaring af samarbejdet mellem arkitekt og ingeniør i Revit: Interview Delkonklusion Konklusion Perspektivering Kildeliste Bilag...46

7 Figur liste Figur 1 Illustration af hvad BIM indeholder...11 Figur 2 BIM projektering...11 Figur 3 Traditionel projektering...12 Figur 4 Projektering med fællesmodel...12 Figur 5 Eks. på udfyldt IKT-Ydelsesspecifikation...13 Figur 6 IFC model...14 Figur 7 BIPS opdeling...14 Figur 8 Kort beskrivelse af informationsniveauerne i LOD...16 Figur 9 BIPS F102 oversigt over beskrivelser og anvisninger...17 Figur 10 Eks. på udfyldt IKT-ydelsesspecifikation, omhandlende bygningsmodel...18 Figur 11 Eks. på udfyldt IKT-ydelsesspecifikation omhandlende særlige ydelser...19 Figur 12 CAD-manual 2008, informationsniveau Figur 13 CAD-manual 2008, informationsniveau Figur 14 CAD-manual 2008, informationsniveau Figur 15 CAD-manual 2008, informationsniveau Figur 16 CAD-manual 2008, informationsniveau Figur 17 CAD-manual 2008, informationsniveau Figur 18 CAD-manual 2008, informationsniveau Figur 19 Eks. på udfyldt IKT-ydelsesspecifikation omhandlende afvigelse fra CAD-manual Figur 20 LOD Figur 21 LOD Figur 22 LOD Figur 23 LOD Figur 24 LOD Figur 25 Eks. på detaljeringsgrad af vægge på forskellige informationsniveauer med LOD...30 Figur 26 Eks. på detaljeringsgrad af ventilationsrør på forskellige informationsniveauer med LOD

8 1 Indledning 1.1 Baggrundsinformation og præsentation af emne Som et led i det afsluttende 7. semester på bygningskonstruktøruddannelsen, skal jeg skrive et speciale om et valgfrit emne inden for faget. Jeg har valgt emnet BIM, hvor jeg vil undersøge hvordan arkitekter og ingeniører samarbejder i Revit. Som nævnt, i forordet, har jeg gennem praktikperioden arbejdet med Revit og fået kendskab til BIM og vigtigheden af samspillet mellem disse. Derfor mener jeg, at det er vigtigt, at en bygningskonstruktør har kendskab til BIM og Revit, og hvordan samarbejdet bedst hænger sammen, således man kan opnå en færre fejl og dermed en bedre projektering. 1.2 Begrundelse for emnevalg og fagligt formål Der bliver fra byggestyrelsen stillet større krav til projekteringen i dag end tidligere. Bygherren kan stille krav om, at aktørerne skal fremstille en bygningsmodel, der som minimum skal være af formatet IFC. Ved byggeprojekter over 20 mio. kr., hvor der er en statslig bygherre, er det obligatorisk, at der fremvises 3D visualiseringer. Derfor er det nødvendigt at vedlægge bygningsmodellen i den detaljeringsgrad og med de visualiseringselementer, der er beskrevet i konkurrencematerialet. Dette betyder at efterspørgslen af projekter i Revit er blevet større, og flere tegnestuer implementerer Revit for at imødekomme disse krav til projekteringen. Det er en ny måde at projektere på, derfor opstår der også en masse nye udfordringer og barrierer, som tegnestuerne skal forholde sig til. Dette oplevede jeg f.eks. på 6. semester, hvor jeg var 20 uger i praktik hos Arkitektfirmaet Rudolf Lolk A/S i Esbjerg. På tegnestuen var de ved at implementere Revit, hvilket medførte mange udfordringer. En af udfordringer ved implementeringen var samarbejdet med ingeniørerne, som også var ved at implementere Revit. I praksis oplevede jeg netop udfordringerne i samarbejdet mellem arkitekter og ingeniører. For eksempel var jeg tilknyttet et projekt, et hus, der skulle projekteres af begge parter i Revit, som gav en del problemer i bygningsmodellen. Udfordringerne var bl.a., hvordan alle aktører kunne tilgå bygningsmodellens informationer. Jeg erfarede at tegnestuen havde svært ved at opdele forskellige arbejdsgange mellem arkitekt og ingeniør. Fx hvem var den ansvarlige når der skulle rettes i modellen? Udover det, var der også problemer omkring, hvem der skulle lave hvad i modellen, til stor frustration på tegnestuen. Ingen af parterne havde erfaring i Revit, hvorfor det naturligt bare blev mere besværligt. 7

9 Ud fra mine erfaringer fra praksis, om manglende retningslinjer for samarbejdet, vil jeg, via indsamling af empiri, kigge nærmere på de to parters (arkitekter og ingeniørers) samarbejde i en fælles model. Herunder vil jeg se på, hvilke problemstillinger, der er forbundet ved modellen og hvilke retningslinjer de arbejder efter som udgangspunkt. 1.3 Problemformulering I min praktikperiode opstod der løbende problemstillinger i forbindelse med samarbejdet med ingeniørerne, som jeg ønsker at få belyst i denne rapport. Hvordan samarbejder arkitekter og ingeniører i projekteringsfasen i en bygningsmodel udarbejdet i Revit? Herunder: Hvornår opstår der komplikationer mellem arkitekter og ingeniører i en fælles bygningsmodel? Hvilke værktøjer er tilgængelige for samarbejdet mellem arkitekter og ingeniører, i projekteringsfasen, når der projekteres i en fælles bygningsmodel? Hvordan afgrænser arkitekter og ingeniører fagområderne når der projekteres i en fælles bygningsmodel? 1.4 Afgrænsning Da det primære formål er at afdække problemstillinger mellem arkitekter og ingeniører i en fælles bygningsmodel, er det ikke relevant at belyse andre problemstillinger i projekteringsfasen. Mit fokus bliver derfor projekteringsfasen med udgangspunkt i den fælles bygningsmodel. 1.5 Valg af teoretisk grundlag og kilder Jeg vil hente størstedelen af det teoretiske materiale via. Internettet. Det kan fx være i form af IKT vejledninger og CAD-manual Jeg vil endvidere søge artikler på nettet som omhandler emnet, hvor andre har draget erfaringer om dette samt Indhente information fra forskellige bekendtgørelser. Jeg vil forholde mig kritisk overfor kilder på internettet, jeg vil sørge for at kilder fra internettet er saglige, kompetente og ikke har nogle skjulte dagsordner. Jeg vil hente information fra internettet via flg. Hjemmesider

10 1.6 Valg metode og empiri Jeg vil hovedsageligt gøre brug af førstehåndskilder, hvor jeg vil indsamle empiri via interviews med arkitekttegnestuer og ingeniørvirksomheder. Jeg vil analysere og sammenholde kildernes udsagn og sammenligne dem med de teoretiske oplysninger, som jeg har indhentet. For at underbygge mit indsamlede empiri og teoretiske oplysninger, vil jeg ydermere gøre brug af sekundære data, i form af allerede udførte rapporter om emnet fra andre byggesager. Jeg vil forholde mig kritisk til, hvorvidt disse rapporter har relevans for denne rapports emne. Jeg vil foretage individuelle, strukturerede interviews med personer på tegnestuer som arbejder med BIM og Revit Søren Sti Anders, arkitekt MAA & BIM ansvarlig Aarhus arkitekterne Simon Andreas Arnbjerg, Architectural Technologist & BIM Model Manager Schmidt/Hammer/Lassen architects Michael Porskær, Ingeniør Søren Jensen rådgivende ingeniørfirma 9

11 1.7 Rapportens struktur og argumentation Rapporten inddeles efter følgende struktur. Indledning og problemformulering I dette afsnit beskrives, hvilke metoder jeg vil bruge for at få svar på spørgsmålene, som danner grundlag for rapporten. Hovedafsnit Hovedafsnittet er opdelt således, at jeg vil forklare om rapportens begreber, hvorefter jeg vil afdække den teoretiske del af emnet. Jeg vil derefter bruge min empiri, hvor jeg analyserer denne og sammenholder den med teorien. Konklusion Her vil jeg konkludere på spørgsmålene, fra problemformulering, ud fra de punkter som er opstillet i hovedafsnittet. 10

12 2 Begreber Jeg vil kort beskrive betydningen bag forskellige begreber, som hyppigt vil blive brugt i rapporten. 2.1 Hvad er BIM? Building Information Modelling (BIM) er en af de mest lovende værktøjer i udviklingen i arkitektur, ingeniørarbejde, konstruktion, byggeri og drift & vedligehold. BIM kan være en præcis virtuel model af en bygning, hvori alt information er tilgængelig i hele projekteringsfasen. BIM understøtter design gennem faserne, så der er bedre analyse og kontrol end ved manuelle processer. Når projekteringsfasen er Figur 1 Illustration af hvad BIM indeholder gennemført, kan disse computergenererede modeller indeholde præcis geometri og data, som er nødvendigt for at støtte byggeriet, fabrikationen af elementer, styklister, økonomi og tidsplaner, hvorigennem bygningen realiseres. I BIM er der også plads til mange af de funktioner, der er nødvendige for at angive livscyklussen af en bygning, der danner grundlag for drift & vedligeholdelsesplanen. Med andre ord, BIM kan bruges i hele processen fra ide til nedrivning, alt information kan trækkes ud af modellen og kan senere ændres når der gennemføres drift & vedligehold på bygningen. 2.2 Fællesmodel En fællesmodel er en model, der er oprettet af en af aktørerne som projekterer byggeriet. Det kan fx være arkitekten, der udformer en sådan model. Denne fællesmodel er alle aktørernes fagmodeller, som er samlet i én model. I fællesmodellen kan man fortage en kollisionstest, hvor man kan kontrollere om der er elementer i modellerne, som kolliderer med hinanden. Man kan nemt og hurtigt skabe sig et overblik Figur 2 BIM projektering 11

13 over forskellige rumudformninger mm. Det er muligt for alle aktører, at se de nødvendige informationer og der kan hurtigt skabes visualiseringer til bygherren eller andre rådgivere i projektet. Denne måde at projekterer på er forholdsvis ny og kræver, at man omstiller sig i projekteringsfasen, for arbejdsbyrden er væsentlig større i starten af fasen end, hvad man er vant til. Hvis konsekvenserne af BIM for projekteringen skal undersøges, så er det vigtigt at dette er på baggrund af et rigtigt byggeprojekt. Erfaringer fra Nyt Himmelev viser, at op til 70 % af beslutningerne skal tages på et tidligere stadie i projekteringen, end ved traditionel projektering. (Levring, Marts 2010) Dette uddrag støttes op af et interview jeg foretog med ingeniør, Michael Porskær i forbindelse med rapporten. Det er altid godt at komme tidligt på banen med løsninger. Man får hurtigere en hovedgeometri i et hus, der ikke tager lang tid at lave, når det udelukkende er konstruktion vi snakker om. Det laver vi ret tidligt, nogle gange allerede i konkurrencefasen, netop fordi det ikke er særlig tidskrævende. Det der er tidskrævende er detaljeringen, f.eks., hvor mødes en søjle med et dæk? Så ja, vi er tidligere på banen end før. (Porskær ING, 2012) Figur 3 Traditionel projektering Figur 4 Projektering med fællesmodel Figur 3 viser en traditionel måde at projekterer på, hvor der er meget korrespondance mellem de forskellige aktører. Det er der også når man projekterer med en fællesmodel, (som vist i figur 4) forskellen er blot, at alle informationerne er i fællesmodellen. Dvs. at alle aktører kan se den samme information i modellen. Det sikrer en langt bedre og mere fejlfri måde at projektere på. 12

14 2.3 IKT Bekendtgørelsen Informations- og kommunikationsteknologi (IKT) er aftalegrundlaget mellem bygherre og de projekterende. IKT-aftalen er en projektspecifik aftale, hvor bygherren og samtlige aktører i byggeriet bliver enige om, hvilke IKT-løsninger, der skal anvendes til byggeriet. Det er i denne aftale bygherren opstiller krav om, hvorvidt der ønskes digitalt udbud, anvendelse af bygningsmodeller, projektweb og digital aflevering. Den projektspecifikke IKT-aftale beskriver, hvilke ydelser der i byggeprojektet påhviler aktørerne i projekteringsfasen. Det følgende eksempel er et udsnit af IKTydelsesspecifikation for bygning 328 (DTU Campus), det viser hvilke retningslinjer, der skal følges ved 2- og 3D bygningsmodeller. Figur 5 Eks. på udfyldt IKT-Ydelsesspecifikation Figur 5 viser, hvilken CAD-teknisk specifikation der er valgt til projektet samt, hvem der er CAD-projektkoordinator. Yderligere viser figuren, at der er tilvalgt 3D-geometri og at bygningsmodellens byggeobjekter skal følge CAD-manual

15 2.4 IFC Der findes mange programmer der kan bruges til, at udforme en bygningsmodel og det er ikke altid, at arkitekter og ingeniører bruger samme program. Så for at disse kan udveksle modeller med hinanden, understøtter langt de fleste programmer filformatet Industry Foundation Classes (IFC). Dvs., at arkitekten som f.eks. arbejder i Revit, kan eksportere sin model til IFC format, således ingeniøren som f.eks. arbejder i TEKLA kan importere IFC modellen, fordi TEKLA understøtter IFC formatet. Figur 6 IFC model Dette gør at man i projektering kan udføre kollisionstest på de forskellige modeller og sikre, at de to modeller er identiske eller, at der ikke er nogen rørinstallationer, som ikke kan lade sig gøre. IFC formatet har den egenskab at lige meget, hvilket program arkitekter og ingeniør anvender, kan disse parter altid arbejde sammen. I Danmark er brug af IFC, fra 2014, obligatorisk i byggeprojekter, som er omfattet af IKT-bekendtgørelsen og de digitale bygherrekrav. (BIPS, 2012) 2.5 Bips Byggeri Information Produktivitet Samarbejde (BIPS) har til formål at standardisere og effektiviserer processerne i byggeriet, herunder også projekteringsfasen. BIPS udvikler fælles digitale strukturer og standarder for arbejdsmetoder, udvekslingsformater og andre værktøjer. De laver vejledninger og paradigmer hertil, således aktører i byggebranchen kan opnå det bedst mulige resultat. I figur 7 nedenfor, viser IKT specifikationen, hvordan denne opdeler parterne således det tydeligt fremgår, hvilke digitale ydelser disse skal udføre. Figur 7 BIPS opdeling 14

16 2.6 CAD-manual 2008 CAD-manual 2008 er et redskab udarbejdet af bips, som b.la. skal danne grundlag for samarbejdet mellem aktører i projekteringsfasen. Meningen med denne vejledning er, at skabe et fælles og entydigt grundlag i projekteringen, således disse faser af byggeriet effektiviseres. CAD-manual 2008 er opbygget i kapitler som i størst mulig omfang understøtter processen i projekteringen. Manualen fastlægger parternes grundlag for kendskabet til at bruge fil- og mappestruktur, sektionering, koordinatsystemer og tegnings- og modelskifte. Manualen beskriver, hvilke modeller, der udarbejdes og hvordan disse struktureres ift. lag, informationsniveauer, egenskabsdata, temaer og revisioner. Derudover skal der også tages højde for, hvordan modellerne refererer til hindanden samt, hvilke regler der skal følges. Den beskriver brugen af bygningsmodellerne, herunder simuleringer, konsistenskontrol, tegningsproduktion, mængdeudtræk og visualiseringer. Manualen beskriver videre, hvilken dokumentation, der skal udarbejdes i forbindelse med brug og udarbejdelse af bygningsmodeller. CAD-manual 2008 uddyber, hvor parterne skal udveksle fagmodeller og filer igennem projekteringen. Op til udveksling skal der udføres kontrol og kvalitetssikring, her beskriver manualen ligeledes, hvordan involverede parter kan udfører dette. 2.7 BIM Execution Planning - LOD BIM execution planning guide, er en guide opbygget i fire trin. De fire trin består af, at afklare de relevante BIM mål og anvendelser på et projekt samt designe BIM til udførelsen. For effektivt at integrere BIM i projekteringsfasen, er det vigtigt for de medvirkende, at udvikle en detaljeret gennemførelsesplan for implementeringen af BIM. En BIM Project Execution Plan (i det følgende benævnt som "BIM-plan ), skitserer den overordnede vision sammen med nærmere oplysninger om gennemførelsen som parterne skal følge gennem hele projektet. Det er nødvendigt at udvikle BIM-planen tidligt i projektet. Det er vigtigt at man løbende udvikler BIM-planen, der skal overvåges, opdateres og revideres efter behov i løbet af implementeringsfasen af projektet. Planen bør definere omfanget af BIM og den gennemførelse som er nødvendig for projektet. Processen skal identificeres for, hvilke BIM opgaver der er nødvendige, altså hvilke oplysninger de forskellige udvekslinger skal indeholde mellem parterne. Tilhørende til BIM-planen er yderligere, at beskrive bygningsmodellernes informationsniveau vha. Level Of Development LOD. LOD er af amerikansk oprindelse og fungerer på samme måde som informationsniveauer gør i CAD-manual Der findes ingen decideret dansk udgave af dette, men de firmaer der bruger det, bruger det i stedet for CAD-manual

17 LOD beskriver den detaljeringsgrad, som er modellens minimumskrav og som den opbygges efter. Udviklingsniveauet starter ved LOD 100, og bør altid startes på dette niveau. Ved udbud bør projektet være på niveau LOD 400. Figur 8 Kort beskrivelse af informationsniveauerne i LOD Figur 8 viser opdelingen af informationsniveauer i LOD. Modellen bliver gradvist mere og mere detaljeret og er opdelt i 5 niveauer. LOD 100 vil typisk være et konkurrenceprojekt, og afsluttende niveau vil være LOD 500 som er beregnet til drift & vedligehold. 16

18 3 Teoriafsnit Jeg vil i det teoretiske afsnit belyse, hvilke hjælpemidler der er til rådighed for optimering af samarbejdet mellem arkitekter og ingeniører. Samt vise eksempler på, hvordan disse er opbygget og udfyldt. 3.1 IKT anvendelse Som tidligere nævnt bruges IKT som aftale grundlag mellem bygherre og projekterende, men også mellem parterne i projekteringsfasen. BIPS F102 IKT specifikation er en vejledning som har til formål at understøtte byggebranchens parter, i den digitale håndtering af byggeprocessen. Strukturen i anvisningen er opdelt som vist i figur 9 nedenfor. Figur 9 BIPS F102 oversigt over beskrivelser og anvisninger Figur 9 viser Koncept for Byggeriets IKT-specifikationer. Den vandrette linje adskiller ydelser og teknik, mens den lodrette linje adskiller basisbeskrivelser og projektspecifikke beskrivelser. (BIPS, 2011) 17

19 Som vist i figur 9 findes der to beskrivelser, en basisbeskrivelse og en projektspecifik, det er begge beskrivelser der danner gundlag for den endelige aftale. Basisbeskrivelsen gælder for alle parter, uafhængigt af forskellige byggesager og fungerer derfor som et fælles grundlag, hvorimod den projektspecifikke beskrivelse gælder for den enkelt byggesag og gælder fremfor basisbeskrivelsen. IKT-ydelsesspecifikationen ligger som bilag til rådgiverkontrakten. Basisbeskrivelsen ændres ikke, med mindre bips sender opdateringer ud til denne, som følge af en række små opsamlinger eller ændringer i standarder, bekendtgørelser, anvisninger, etc. Det er i IKT ydelsesspecifikationen, at der står beskrevet, hvilken geometri man vælger at arbejde med, ved valg af 3D geometri, vælger man at følge bips lagstruktur 2005 og bips CAD-manual Hvis der i projektet, ønskes anvendelse af en anden struktur og manual angives det under særlige forhold, hvor der skal beskrives, hvilke andre dokumenter der er gældende. Som vist i figur 10 er 3D-geometri (3.3 ad stk. 2) valgt fremfor 2Dgeometri, det vil blot sige at der skal udarbejdes en 3D bygningsmodel. Figur 10 Eks. på udfyldt IKT-ydelsesspecifikation, omhandlende bygningsmodel Ved tilvalg af bygningsmodel med 3D-byggeobjekter (3.3 ad stk. 3) vælger man, at modellen skal kunne udveskles med databearbejdning, mængdeudtræk, diverse simuleringer og konsistenskontrol. Ved tilvalg af dette punkt vælges det yderligere, at alle parter i projekteringen udarbejder en fagmodel i 3D. Derudover udarbejdes der en eller flere fællesmodeller, som yderligere skal have en part, der står for koordineringen af konsistenskontroller gennem projekteringen. Bygherren skal stille krav om, at der skal anvendes digitale bygningsmodeller i 3D ved både ide- og projektkonkurrence samt ved gennførelsen af byggeriet. (BEK-1381, 2010). Ved tilvalg af klassifikation af bygningsmodeller (3.3 ad stk. 4) vælger man at bruge Dansk Bygge Klassifikation (DBK) af bygningsmodellen. DBK klassificerer bygningsmodellen således, at alle parter kan identificere en bygningsdel. Bygherren skal stille krav om, at der i relevant omfang anvendes Dansk Bygge Klassifikation (DBK), således at digital projektinformation struktureres og klassificeres ensartet i hele byggeprojektet. (BEK-1381, 2010). 18

20 Punkt 3.4 anvendelse af cad-modeller og bruges, hvis bygherren ønsker særlige ydelser implementeret i bygningsmodellen, men som under kontraktindgåelsen, ikke har kunne tage stilling til, hvem der skal påtage sig ydelsen. Dvs. at ydelsen vil blive pålagt en part senere i projektet, hvor ydelsen vil fremgå af en revideret udgave af den projektspecifikke IKTydelsesspecifikation. Figur 11 Eks. på udfyldt IKT-ydelsesspecifikation omhandlende særlige ydelser Figur 11 viser et udfyldt eksempel af punkt Digital konsistenskontrol. Her er bygherren i tvivl om, hvilken part der skal påtage sig ydelsen. Under dette punkt beskrives i første kolonne formål og omfang. Formålet kan være, at opdage fejlene på et tidligt stadie således det rent økonomisk vil være billigere at løse. Omfanget kan være, at konsistenstesten skal foretages på baggrund af hele projektet og ikke kun en del af projektet. I den anden kolonne, under fase, beskrives det i, hvilken fase det er aftalt at udføre konsistenstesten. I dette tilfælde er det i, hver fase fra disposotionsforslag til hovedprojekt. Under filformat angiver bygherren, hvordan parterne skal udveksle deres fagmodeller. I dette tilfælde er det filformattet IFC man udveksler i. Informationsniveau for udvekslingen angives også i denne kolonne. I CAD-manual 2008 fremgår det, hvilke informationsniveauer der knytter sig til de enkelte faser, således parterne har en ide om, hvor meget fagmodellen skal indeholde inden udveksling. Til sidst står det beskrevet, hvem der har ansvaret for at dette bliver udført. I dette tilfælde er det arkitekten, der skal koordinerer kollisionskontrollen med alle implmenterede parter. 19

21 3.2 CAD-manual 2008 s Informationsniveauer Som beskrevet tidligere, beskriver man i IKT-ydelsesspecifikationen, at der aftales, hvilket dokument man bruger som grundlag for bygningsmodellen ved tilvalg af 3D-geometri i pkt. 3.3 ad stk. 2. Den henviser til CAD-manual 2008, hvor alle informationsniveauerne står beskrevet. Det digitale byggeri beskriver kort de 7 niveauer således: 0. Kravmodel (bygherrens program, div. Krav og bindinger, terræn og byggegrund mv.) 1. Visualisering af løsningsforslag (volumen- og rummodeller) 2. Beslutningsmodel (funktionelle egenskaber og den bygningsfysiske løsning) 3. Myndighedsprojektet 4. Udbudsprojekt (grundlag for udbud, kalkulation og produktionsplanlægning) 5. Udførelsesprojektet (produktionsgrundlag for de udførende) 6. Som udført model (as built dokumentation til driftsherren) ( Informationsniveau 0 Dette niveau anvendes som en del af byggeprogrammet eller som konkurrencemateriale. niveauet indeholder en grov 3D model, som indeholder rumbehov og udformning, der understøtter kravene fra bygherren. Modellen indeholder eksempelvis terræn, infrastruktur, forsyningsnet, omkringliggende bebyggelse mm. Modellen indeholder ligeledes samfundsmæssige krav som f.eks. afstand til skel mm. Figur 12 CAD-manual 2008, informationsniveau 0 Figur 12 viser, hvordan en model kan se ud på informationsniveau 0. 20

22 3.2.2 Informationsniveau 1 Dette informationsniveau henvender sig til dispositionsforslaget, hvor bygningens form og udtryk samt funktionelle egenskaber fastlægges. Dette niveau kræver, at man kan trække arealer og volumener ud på et overordnet niveau således, man kan danne et overblik over brutto- og nettoarealer. På informationsniveau 1 kan modellen yderligere anvendes til, at foretage simulering af lys- og skyggeforhold ift. omgivelserne samt forespørgsler til myndighederne omkring planområdet. Modellen indeholder kun informationer om rum, der findes ikke informationer om enkelte bygningsdele. Figur 13 CAD-manual 2008, informationsniveau 1 Figur 13 viser, hvordan en model kan se ud på informationsniveau Informationsniveau 2 Dette niveau henvender sig til projektforslaget, hvor den grundlæggende stuktur og geometri opbygges således, man overordnet kan vurdere bygningens fysiske og funktionelle egenskaber. På dette niveau kan projektet sendes i tidligt udbud, modellen bliver så afleveret til entreprenøren som efterfølgende bringer projektet videre til de følgende informationsniveauer. De væsentlige bygningsdele, der definerer bygningens overordnede geometri, som tag, dæk, vægge og føringsveje skal opbygges således disse optræder 3D i modellen. Disse bygningsdele har en foreløbig placering og form som overholder funktionskrav inddelt i typer. På dette stadie arbejdes der med modulkomponenter (modulmål) da der ikke er taget højde for tolerancer, komponentopdeling og fugebredder. Der skal foretages en overordnet koordinering mellem parternes bidrag inden udgivelse af en model. 21

23 Figur 14 CAD-manual 2008, informationsniveau 2 Figur 14 viser, hvordan en model kan se ud på informationsniveau Informationsniveau 3 Informationsniveau 3 henvender sig til myndighedsprojektet, som danner grundlag for bygningens overordnede grundlag og opbygning, således myndighederne kan behandle projektet. De nødvendige byggeobjekter skal kunne trækkes ud af projektet med den nødvendige information. Denne information danner grundlag for tegningsmateriale, som er svarende til traditionelle oversigtstegninger, bygningsdelstegninger og hovedtegninger. Bygningsobjekterne indeholder en mere detaljeret egenskabsdata og modellen er tilsvarende mere detaljeret. Som nævnt i informationsniveau 2, skal der foretages en overordnet koordinering mellem parternes bidrag inden udgivelse af en model. På dette niveau skal der også fortages en kollisionskontrol. Figur 15 CAD-manual 2008, informationsniveau 3 Figur 15 viser, hvordan en model kan se ud på informationsniveau 3. 22

24 3.2.5 Informationsniveau 4 Informationsniveau 4 henvender sig til hoveprojektet, som også danner grundlag for udbudsmaterialet samt tidsplan for udførelse. Bygningsobjekter skal have den fornødne information, således dette kan danne grundlag for bygningsdelsbeskrivelser og mængdefortegnelser. I forhold til informationsniveau 3, har byggeobjekterne fået tilføjet flere detaljer som medfører, at disser har en mere præcis geometri. Konkretiseringsgraden i dette niveau er svarende til skala: 1:100, 1:50, 1:20 og 1:10 og hvor byggeobjekter kan suppleres med detaljetegninger. Udover detaljetegninger skal der også produceres tegningsmateriale med traditionelle bygningsdelstegninger, hovedtegninger og oversigttegninger. Ligesom informationsniveau 3 skal der foretages overordnede koordinering mellem parternes bidrag samt en kollisionskontrol. Figur 16 CAD-manual 2008, informationsniveau 4 Figur 16 viser, hvordan en model kan se ud på informationsniveau Informationsniveau 5 Informationsniveau 5 henvender sig til udførelsesfasen samt leverancen af byggevarer, og skal derfor indeholde tilstrækkeligt med information om bygningsdele, materialer og komponenter, således man kan planlægge leverancer til byggeriet. Dvs. at modellen skal være tilstrækkelig specifik så den kan danne grundlag for logistik, planlægning mv. Bygningsdele skal være specificeret så deres egenskaber indgår i produktionen (kan være nødvendige materialer). Modellen kan indeholde tidsplaner og økonomisk overslag. 23

25 Figur 17 CAD-manual 2008, informationsniveau 5 Figur 17 viser, hvordan en model kan se ud på informationsniveau Informationsniveau 6 Informationsniveau 6 er resultatet af den færdige bygning, hvor bygningsdele har den eksakte information som den udførte bygning. Der kan hentes data fra modellen som videre kan bruges til drift & vedligehold samt kommende renovering og om- og tilbygning. Modellen videregives til bygherren efter aftale, hvor modellen vil blive administreret af en driftsherre til efterfølgende drift & vedligeholdelse. Løbende med driften vil modellen blive opdateret som bygningsdele og komponenter bliver udskiftet eller renoveret. Figur 18 CAD-manual 2008, informationsniveau 6 Figur 18 viser, hvordan en model kan se ud på informationsniveau 6. 24

26 3.4 LOD Følgende eksempel er på en aftale, hvor LOD er involveret, og som angiver mængden af information i bygningsmodellen gennem projekteringen. Figur 19 viser IKT-ydelsesspecifikationen pkt. 3.3 Produktion. Tidligere beskrev jeg et eksempel hvor CAD-manual 2008 bliver anvendt som informationsniveau, hvor samme illustration er vist. Denne gang er der blot den forskel, at ud for bygningsmodel, 3D-geometri (3.3 ad stk. 2.) henviser den til en projektspecifik LOD aftale. Det gør, at den gælder frem for CADmanual 2008 som ellers ville have været gældende, hvis ikke der stod noget i feltet. Figur 19 Eks. på udfyldt IKT-ydelsesspecifikation omhandlende afvigelse fra CAD-manual LOD 100, som er første niveau, indebærer elementer som masser og anvendes blot til undersøgelse, som kan være arkitektonisk udformning. Yderligere er dette niveau forbeholdt analyser af placering af bygning, mængder som arealer og rumvolumen kan indsamles. Figur 20 LOD 100 Figur 20 viser bygningens elementer som en masse, og tilhørende kvadratmeter samt volumen. 25

27 3.4.2 LOD 200 er næste niveau, hvor modellens masser er erstattet med generiske komponenter. Analyser baseret på overordnede systemer kan udføres på dette niveau. Der kan ligeledes trækkes styklister ud på bygningselementer. Figur 21 LOD 200 Figur 21 viser de forskellige bygningselementers type, bredde, længde, areal og volumen. Fordelen ved dette er, at det er hurtigt at trække enkelte mængder ud LOD 300 er niveauet, hvor alle generiske komponenter er blevet udskiftet, med fuldt ud detaljeret bygningsdele, hvor der kan foretages specifikke analyser. Der kan på dette niveau trækkes specifikke styklister ud, som indeholder information om alle materialer i den enkelte bygningsdel. Figur 22 LOD 300 Figur 22 viser de forskellige bygningsdele, hvor alle materialer i denne er defineret, og der 26

28 derfor kan foretages et mere specifikt mængdeudtag. På dette niveau kan modellen også bruges til at udforme tegninger til leverandører. Modellen kan yderligere anvendes til at analysere energiforbrug, kollisioner og pris LOD 400 modellen indeholder elementer, som er præcise ift. størrelse, form, placering, antal og orientering med færdige detaljetegninger, hvor alt information fremgår. På dette niveau er der også andet udover 3D modellen med tekst, fx dimensioner, noter og 2D detaljer mm. Figur 23 LOD 400 Figur 23 viser en detalje, hvor der er placeret 2D tekst ovenpå en 3D model fra et snit. På dette niveau bruges modellen som repræsentation af de foreslåede elementer. Der kan yderligere foretages energianalyser, kollisionskontroller og planlægning med kalkuleret pris LOD 500 modellen indeholder elementer, som de tager sig ud i det faktiske byggeri. Elementer er modelleret i akkurat samme størrelse, form, placering og orientering. Alle ikkegeometriske eller fysiske udformninger er inkluderet som parametre tilknyttet til modellen. Dette niveau er det samme som LOD 400 dog med den undtagelse, at elementer er tegnet som bygningen er konstrueret. 27

29 Figur 24 LOD 500 Figur 24 viser på niveau LOD 500, er modellen forsynet med informationer om drift & vedligehold. Den viser bygningselementernes id samt, hvornår der sidst er udført inspektion og, hvornår fremtidig inspektion skal udføres. Yderligere viser figuren, hvilken prioritet den enkelte bygningsdel har og hvilken stand denne er i. 3.5 Delkonklusion Der er forskellige værktøjer, som er tilgængelige for aftale mellem arkitekter og ingeniører i projekteringsfasen, når der arbejdes i en bygningsmodel. De førnævnte metoder, CADmanual 2008 og LOD, er vidt forskellige og beskriver også informationsniveauer vidt forskelligt. Jeg kan konkludere ud fra de viste eksempler, at bips IKT-specifikationer med CAD-manual 2008 er den mest kendte og udbredte vejledning mellem parterne i en bygningsmodel. En aftale, hvor der anvendes LOD til at beskrive informationsniveauerne, er ikke så udbredt fordi den er af amerikansk oprindelse. Denne metode bliver fordansket og tilpasset til det enkelte projekt. Derudover er metoden med LOD mere specifik end CADmanual Udover disse metoder, som danner grundlag for aftalen mellem arkitekter og ingeniører, kan der også vedlægges en BIM-manual, som yderligere kan specificere, hvordan parterne skal forholde sig i en bygningsmodel. Disse BIM-manualer er vidt forskelige fra tegnestue til tegnestue og projekt til projekt. 28

30 3.6 LOD ift. CAD-manual 2008 s informationsniveauer Der findes forskellige måder, at beskrive informationsniveauerne på i en bygningsmodel. Jeg vil i dette afsnit analysere to måder, at beskrive informationsniveauer på, holde dem op mod hinanden og herefter beskrive fordele og ulemper. Jeg tager udgangspunkt i et projekt, hvor projekteringen er i hovedprojektsfasen. Når man skal sammenligne to metoder er det nødvendigt at man tager udgangspunkt i, at aftalerne bliver udformet på samme projekt. I dette tilfælde er der tale om et mellemstort fiktivt projekt. Når et projekt i projekteringsfasen er nået til hovedprojektet, svarer det til at være på informationsniveau 4 iht. CAD-manual CAD-manual 2008 beskriver informationsniveau 4 således: Informationsniveau 4 anvendes i forbindelse med hovedprojekt og tilbudsgivning til at skabe grundlag for udbud, kalkulation af pris, tilbudsgivning samt produktionsplanlægning. Al information om geometri, som er nødvendig for produktionsplanlægningen skal være til stede. Der skal produceres tegningsmateriale svarende til traditionelle hovedtegninger, oversigtstegninger og bygningsdelstegninger ud fra bygningsmodellen. Detailtegninger kan helt eller delvist produceres uden brug af bygningsmodellen. I forbindelse med tilbudsgivning skal der kunne udtrækkes grundlag for mængder til kalkulationer fra bygningsmodellerne. Byggeobjekter skal have en geometrisk konkretiseringsgrad svarende til skala: 1:100, 1:50, 1:20, 1:10, varierende i de enkelte parters bygningsmodeller. Byggeobjekter kan suppleres med detailtegninger, for at dokumentere den ønskede detaljering. Rum klassificeres efter funktion byggeobjekter efter type. Inden udgivelse af en bygningsmodel på informationsniveau 4 skal den endelige koordinering mellem parternes bidrag, herunder være udført konsistenskontrol. (CAD-manual2008) Fordele: Jeg mener det er en aftale, som standardiserer måden at opbygge en bygningsmodel på og hvad en model skal indeholde på forskellige niveauer. Jeg har indtryk af, at det er den mest udbredte aftale mellem parter i projekter, hvor der arbejdes med en bygningsmodel. Det gør at mange projekterende er kendt med aftalen og ved, hvordan den skal tolkes, som gør at parterne ender med samme resultat i informationsniveau 4. 29

31 Ulemper: CAD-manual 2008 beskriver informationsniveau 4 med, at projektet skal kunne skabe grundlag som udbudsmateriale. Iht. manualen skal al geometrisk information være til stede, som kan danne grundlag for produktionsplanlægningen. Det mener jeg kan være problematisk når man tænker på, at detaljeringen af et traditionelt udbudsmateriale kan variere meget fra tegnestue til tegnestue. I modsætning til LOD er denne manual ikke specifik nok til, at parterne kan opnå samme informationsniveau i fagmodellerne. Derfor opstår der nemmere uenighed om, hvilke informationer, der er nødvendigt i en bygningsmodel som danner grundlag for udbuddet, fordi det ikke er beskrevet specifikt nok i CAD-manual Et eksempel på at CAD-manual 2008 ikke er specifik nok, er f.eks. hvad en væg på informationsniveau 4 skal indeholde. Der står: Al information om geometri, som er nødvendig for produktionsplanlægningen skal være til stede. (CAD-manual2008). Som tidligere nævnt vil hver tegnestue tolke dette punkt forskelligt og skabe en uenighed i projekteringen. Dette kan i sidste ende skabe et ikke ensartet udbudsmateriale. Nedenfor i figur 25 er der et eksempel på LOD 400, det der svarer til CAD-manual 2008 s informationsniveau 4. Fordele: Jeg mener det er en meget specifik måde at fastlægge, hvad en bygningsmodel skal indeholde på hovedprojektsniveau. Den er tilpas specifik til at parterne ikke kan være i tvivl om, hvad deres fagmodel skal indeholde. Der kan evt. suppleres med ekstra punkter som bygherren eller parterne synes er vigtige for projektet. Måden den er bygget op på gør, at den er mere simpel at overskue. Det mener jeg er en fordel fremfor CAD-manual 2008 som ikke er ligeså specifik. Ulemper: Det er en meget specifik metode som kan tage lang tid at udfylde, hvilket dog kan være en fordel på den lange bane. Mit indtryk er, at der ikke er mange der har kendskab til denne form for aftale. Det kan skabe urolighed for nogle, som ikke har set det før, det kan være folk virker skræmte af at det er en ny aftale. Når der udspecificeres så mange punkter i en aftale, kan det medføre en meget større arbejdsmængde end hvad nødvendigt er. Det kan derfor være nødvendigt at revidere aftalen fra projekt til projekt. Som figur 25 viser, udvikler væggen sig gennem projekteringsfasen. I starten er væggen ikke udstyret Figur 25 Eks. på detaljeringsgrad af vægge på forskellige informationsniveauer med LOD 30

32 med særlig mange informationer. Men som projekteringen skrider frem og niveauerne stiger, stiger informationen på væggen ligeledes. Når projektet er på niveau 400 skal væggen kunne danne grundlag for udbudsmaterialet. Der kan altid diskuteres om, hvorvidt disse punkter danner grundlag for et udbudsmateriale, men der kan tilføjes eller fjernes punkter således alle parter i byggeriet er tilfredse med informationsniveauet Delkonklusion Ud fra de to eksempler mener jeg, at LOD er væsentlig mere konkret og derfor også bedre egnet som grundlag mellem arkitekter og ingeniører. Jeg tror LOD kan skabe en ensartethed for udbudsmateriale, som ellers på nuværende stadie kan være mangelfuldt og variere fra tegnestue til tegnestue. Dermed ikke sagt at CAD-manual 2008, ikke kan dette. Jeg mener blot at den er mere flyvsk i sin beskrivelse af informationsniveauet til en bygningsmodel. CAD-manual 2008 s informationsniveauer har sin fordel i, at det er en kendt aftale. Tegnestuerne kender den ud og ind og er måske med tiden begyndt at tolke niveauerne ens. Det er af min overbevisning, at dette er tilfældet for nogle tegnestuer, som anvender CADmanual 2008 og har gjort det igennem en del år. Hvis en tegnestue, der kender disse informationsniveauer godt, kan komme til at arbejde sammen med andre, som ikke har den samme erfaring, mener jeg, at der vil opstå problemer med at få udarbejdet et ensartet materiale. Jeg mener også, at det til en hver tid er nemmere, at klarlægge, hvem i projekteringen der ikke har udført sin ydelse som anført, i aftalen hvor der anvendes LOD. Derved er det i teorien også nemmere at følge op på problemerne. 31

33 4 Empiriafsnit 4.1 Min erfaring af samarbejdet mellem arkitekt og ingeniør i Revit: Min erfaring af samarbejdet mellem arkitekt og ingeniør er basseret på min praktik hos Arkitektfirmaet Rudolf Lolk A/S, her er implementeringen af Revit godt i gang, men dog med en del barrierer, der skal overvindes. Som tidligere dokumenteret, øges arbejdsmængden væsentlig mere i starten af projekteringen, fordi der projekteres i 3D fremfor 2D, og derfor er det nødvendigt at tage stilling til langt flere ting tidligere i forløbet, end hvad man er vant til. Der bliver brugt mange ressourcer på at oplære medarbejdere i Revit, og jeg oplevede at det var minimalt, hvad medarbejderne havde af erfaringer med samarbejdet i denne nye projekteringsform. Derfor opstod der større frustration over projekteringen end begejstring for, hvilke muligheder det kunne medbringe. Under min praktikperiode arbejdede jeg med et kompliceret enfamiliehus i Esbjerg, hvor arkitekten og ingeniøren brugte Revit. Det var i dette tilfælde det første projekt ingeniøren skulle bruge i Revit. Vi holdte nogle projekteringsmøder for at planlægge forløbet, hvor det blev bestemt at arkitekten skulle stå for Revit modellen. Jeg fik til opgave at stå for fagmodellerne, selvom jeg ikke tidligere havde prøvet at udveksle modeller med andre virksomheder. Jeg vidste heller ikke om man havde en fælles model liggende tilgængelig på en server eller lignende, hvorfra begge parter kunne tilgå modellen og opdatere, hver deres fagområde. Udover dette skulle bygningsdelene i modellen fyldes med informationer, og hvem skulle varetage denne opgave? Min erfaring er, at arkitekten udvekslede en model som ingeniøren blot brugte som underlag for deres egen model. Her mener jeg der kan opstå mange fejl og arbejdsgangen er meget længere, samtidig med at hele projektet blev mere besværligt, end hvad nødvendigt var. 32

34 4.2 Interview Min egen erfaring og det teoretiske grundlag for opgaven, ville jeg gerne underbygge med interviews fra virksomheder, som arbejder med dette til dagligt. Jeg udformede en interviewguide, der blev brugt som standart, i interviews med tre personer som til dagligt arbejder med dette. Jeg stillede spørgsmål til to personer, som arbejder i forskellige arkitektfirmaer, og en som er ansat i en ingeniørvirksomhed. Svarene vil jeg holde op mod hinanden og uddybe med min egen holdning hertil. Jeg er interesseret i at vide, hvilke aftaler de benytter sig af. Til spørgsmålet om de anvender IKT-ydelsesspecifikation som aftale grundlag mellem arkitekter og ingeniører? Svarede de således: Michael: - Ja, vi får som oftest en ydelsesspecifikation af bygherren, det skal lige siges, at vi laver rigtig meget offentligt byggeri. Dvs. at, de digitale bygherrekrav altid er gældende. De fleste af vores kunder lægger også en ydelsesspecifikation med, hvori der står hvad vi skal levere. Der er yderligere den Revittekniske del af det. Dette ligger jo nede i de tekniske specifikationer, og dem udarbejder vi sammen med arkitekten. Og det fungerer okay synes jeg. (Porskær ING, 2012) Simon: - Ja det gør vi, IKT-specifikationen bliver lavet sammen med bygherren, og der definerer bygherren hvad man skal aflevere. Ud fra det ligger der jo også i, hvad ingeniøren og arkitekten skal aflevere. Det er stadig en gråzone, for hvem afleverer hvad? Der er altid noget, hvor man siger at det her er ingeniørfagligt, det skal I aflevere. Vores erfaringer er, at man skal være meget mere specifik omkring, hvem der afleverer og, hvad man afleverer. Kan i bruge IKT og CAD-manual 2008 til det? - Vi har lavet et nyt dokument til at håndterer det, fordi det ellers ikke bliver specifikt nok. Det vi bruger hedder Level Of Development (LOD), hvor man siger, at på det her tidspunkt skal modellen være så veludviklet, og de her ting skal afleveres på det her informationsniveau. Vi vil også bruge det til at håndtere økonomi, for hvis vi skal håndtere noget ingeniørfagligt, så skal vi også honoreres for det da vi har så har ansvar for det. Så i vedlægger et ekstra dokument med dette? 33

35 - Ja, og det gør vi for at gøre det mere specifikt og for at kunne styre det. Vi har nogle erfaringer, hvor vi er kommet i en gråzone. F.eks. hvis ingeniøren ikke synes, at de skal modellere et element i bygningsmodellen, så er det nødvendigt at vi har noget dokumentation for at de skulle have modelleret det. Det er tit ved sammenfald der opstår de problemer, f.eks. ved sokler, hvor der er betongulve som er mere ingeniørfagligt end arkitektfagligt, hvordan håndterer man sådan nogle ting? Det er de gråzoner man skal have styr på. Det kan være et Excel ark hvor der står, at til den fase har man modelleret lofter, og hvem der har modelleret det. Det kan være i en konkurrence hvor vi har modelleret alle ingeniørens vægge og så skal de overtage det, men hvornår skal de overtage det? Det kan dette dokument styre. Det er lige så meget for os selv og lige så meget for dem, for at kunne styre processen bedre. (Arnbjerg ARK, 2012) Min tolkning af svarene: Michael Porskær synes IKT-aftalen fungerer okay, hvilket jeg tror, er fordi de har mange års erfaring i 3D projektering. Dette gør, at de er bekendt med, hvilke faktorer der er nødvendige for at danne grundlag for et fyldestgørende udbudsmateriale, hvor CAD-manual 2008 er anvendt til, at beskrive informationsniveauerne. Dermed ikke sagt, at der ikke opstår problemer omkring dette. Jeg synes, at Simon Arnbjergs svar understøtter min teori, som tidligere nævnt, om at CAD-manual 2008 ikke er specifik nok. Jeg tolker hans svar på den måde, at de er i tvivl om, hvilke ting der skal med i modellen i de pågældende faser, når der udelukkende er en aftale baseret på CAD-manual Netop derfor bruger de LOD til, at beskrive, hver enkelt informationsniveau i deres aftale. Dette leder mig videre til spørgsmålet om hvorvidt arbejdsbyrden ligger noget tidligere i projekteringen end ved traditionel projektering, og om det er en anden metode parterne skal projektere efter? Dertil svarer Søren således: Søren: - Ja lige præcis, det er en anden måde, ikke nødvendigvis at de skal lave mere arbejde, men en anden måde, de skal projektere på. Kort fortalt, kan man sige at ingeniørerne skal ind i projekteringen flere gange, men det skulle jo gerne lette deres arbejdsbyrde til sidst, fordi de har taget en masse delbeslutninger. Derfor skal de lære at gøre det på en anden måde. Det er tit det der er svært, for man skal gøre næsten det samme som man plejer at gøre og så er der nogle helt bestemte steder, hvor man skal gøre noget helt anderledes. 34

36 Så det er en proces man skal igennem? - Ja det er en proces. Man kan godt skrive det ned i et aftalegrundlag, men man skal næsten have prøvet det før man begynder at forstå det. Så er det tit at folk sidder bagefter nå, var det bare det? ja, men det er anderledes end det du gjorde før. (Andersen ARK, 2012) Min tolkning af svarene: Svarene underbygger et afsnit, tidligere nævnt i rapporten, hvor jeg har beskrevet at 70 % af alle beslutninger skal tages på et tidligere tidpunkt, end ved traditionel projektering. Dette underbygger yderligere min egen teori om, at det er en helt anden måde at projektere på. Som Søren svarer, så er det ikke nødvendigvis fordi man skal lave mere arbejde, det er blot en anden måde at projektere på. Jeg tror, at hvis man projekterer på den måde, hvor beslutningerne tages tidligt i et projekt, er det ligeledes lettere at rette fejlene. Det er f.eks. også billigere at ændre en væg i en 3D model end det er, at ændre væggen i et hovedprojekt eller ude på byggepladsen. Det leder mig videre til spørgsmålet om han kan komme med nogen eksempler på hvilke hyppige problemer de oplever, mellem arkitekter og ingeniører med hensyn til aftaler, eller omkring hvornår parterne skal have ting klar til? Søren: - Generelle problemer kan være på afklaringsniveau. Det der er super vigtigt er det vi kalder enkeltprojektering eller dobbeltprojektering. Særligt nu, hvor vi skal gøre rede for mængderne. Skal vi tegne søjler ind når ingeniøren i forvejen tegner deres søjler ind? Ingeniøren siger meget, nu om dage, at de skal tidligere og tidligere på banen, men det er jo modstridende med det, at de helst vil sidde og vente til det sidste, og så tegne søjlerne ind én gang. Hvis de vil tidligt på banen må de også accepterer at man melder sig ind i en proces, hvor man prøver tingene af flere gange, fordi man bliver klogere undervejs. Det er jo en forventningsafstemning som foregår over de her år. Så er der også noget med, at ventilationsingeniøren ikke skal detailprojektere et ventilationsanlæg helt fra starten af, så kvæler de sig selv i arbejde. Et eksempel på dette er, hvis vi har 2 rør som hver har en størrelse på ø400 mm. Så kan det være at de skal tegne 5-10 cm luft udenom, så de får en kasse som præsenterer en korridor. En korridor som er 50 cm høj og 1 m bred, som de to ventilationsrør kan være i, og så er der lidt tolerance udenom. I stedet for at tegne de to rør skal de lave et eller andet som repræsenterer de to rør i form af en kasse. Hvor de førhen har tegnet med en overstregningstusch, beder vi dem nu om at modellere i 3D, 35

37 hvilken højde og hvilken dimension den her korridor har. Det er ikke selve rørene de skal tegne, det er kun korridoren. (Andersen ARK, 2012) Min tolkning af svaret: Jeg mener problemet kan være, at ventilationsingeniøren skal begynde, at projektere på en ny måde. Jeg tolker det Søren forklarer ved, at de beder dem om at tegne en kasse, hvor rørene kan være i, i stedet for at detailprojektere rørene fra start. Derfor tror jeg, at det indirekte kan være fordi at CAD-manual 2008 ikke er specifik nok. Når CAD-manual 2008 ikke er specifik nok begynder folk at tolke forskelligt på, hvad den enkelte fagmodel skal indeholde. Derfor mener jeg, at de holder sig på sidelinjen indtil sidst i projektet. LOD beskriver f.eks. hvad et ventilationssystem skal indeholde på forskellige niveauer. LOD (Figur 26) beskriver, hvad en ventilationskanal skal indeholde i de enkelte faser. Jeg vurderer, at man skal have meget erfaring i CAD-manual 2008 og i at forstå denne, eller vedlægge en form for konkretiseret uddybelse af informationsniveauerne, for at kunne undgå de problemer som Søren snakker om. Figur 26 Eks. på detaljeringsgrad af ventilationsrør på forskellige informationsniveauer med LOD På baggrund af det vil jeg gerne spørge til, hvordan man afgrænser arkitektens og ingeniørens fagområder når, der projekteres i Revit? Simon: - Til at starte med er det nok lettere, at vi bare har det hele i vores model indtil designet er på plads. Så får ingeniøren en model, hvor vi fjerner vores søjler, hvorefter de kan tegne deres egne søjler ind. I den forbindelse er der også alle mulige forhold, som kalkulation og sammenbygning, som de skal forholde sig til, som vi ikke forholder os til. Det kan så godt være, at der kommer en lille korrektion i forhold til det oprindelige. Rent praktisk laver de en model for hver deres fag. F.eks. en for alt det bærende. Man kan også vælge at sige at arkitekten beholder alle de bærende vægge, hvor man så kan holde det op mod hinanden. Der kan man dog blive i tvivl om, hvem der ejer den pågældende væg. Hvis vi nu har lavet en beton væg som vi mener ingeniøren skal lave, og de så ikke laver den væg, så er det bare svært at 36

38 finde rundt i. Derfor fjerner vi det fra vores modeller så snart ingeniøren kommer med ind over. Det handler igen om økonomi, ingeniøren kan godt sige at det er lettere at vi modellerer væggen, som de så skal overtage senere, hvor de kopierer geometrien ind i deres model. Men det er meget vigtigt de overtager væggen, for når væggen er i deres model er det deres ansvar. Og det er lige netop der, der opstår mange gråzoner, og det er sådan noget det skal klarlægges i IKT-ydelsesspecifikationen. (Arnbjerg ARK, 2012) Michael: -Det har vi tumlet meget med, for er det noget arkitekten skal lave, eller skal vi lave det? Efterhånden er det blevet sådan, at vi har alt det der er bærende, og det har vi egentlig rimelig tidligt i forløbet. Så snart vi er med, så laver vi en konstruktionsmodel, hvor alle de bærende elementer fremgår. Dvs. at arkitekten skal have nogle tegninger der ser fornuftige ud, så de er også nødt til at have vores model med som underlag. Den eneste model der kan gå uden modeller, er sådan set konstruktionsmodellen. En installationsmodel med f.eks. ventilation eller el skal også bruge en arkitektmodel, og højst sandsynligt også en konstruktionsmodel for at give mening. Det plejer at være den måde det er aftalt på, at vi har alt det der vedrører det bærende system. Det ligger også lidt i hvordan man udbyder det, rent entreprisemæssigt. Så alt det konstruktionsingeniøren har ansvaret for, det bliver på normal vis udbudt til en entreprenør, f.eks. en råhus entreprenør, og alt det som arkitekten har ansvar for, er som regel en tømrer og måske en facadeentreprenør. Så det ligger egentlig meget i de entrepriser. Det giver egentlig meget god mening at dele det op på den måde. Det hænger også sammen med at vi er nødt til at have modeller adskilt så det der ligger i vores model er reelt det vi har ansvaret for. (Porskær ING, 2012) Min tolkning af svarene: Jeg tolker Simons svar som om, han mener, at ydelsesspecifikationen ikke er præcis nok til, at danne et tydeligt billede af hvordan arkitekter og ingeniører skal arbejde sammen. Når en væg først er ejet af arkitekten og bagefter af ingeniøren, skal det aftales hvornår og hvordan den overgår til ingeniøren. Lige netop dét problem, er en barriere for virksomhederne. Teorien underbygger Michaels svar, da han mener, at de også har tumlet en hel del med netop dette problem. Michael forklarer yderligere, at ingeniøren står for alt det bærende, og at de overtager dette med det samme de kommer ind i projektet. På baggrund af disse svar og teorien, mener jeg, der er steder i aftalen mellem arkitekter og 37

39 ingeniører, hvor det ikke fremgår tydeligt, hvem der skal lave hvad, og hvilken arbejdsmængde der skal lægges i modellerne, samt hvem der har ansvar for hvad, i den pågældende fase. Til sidst vil jeg gerne spørge, på hvilke områder de mener, man kan forbedrer samarbejdet mellem arkitekter og ingeniører? Søren: - Hvis man kunne arbejde sammen med de samme ingeniører en gang til, og måske en gang til osv. Som det er nu, når vi afleverer det igangværende projekt, så er vi næsten sikre på, at næste projekt bliver med en anden ingeniør, og et tredje projekt med en tredje ingeniør. Mangler der nogle faste rammer i aftalerne mellem arkitekt og ingeniør? - Nej det tror jeg sådan set vi er godt i gang med at hjælpe hinanden med at lave. Både med IKT-aftaler, hvor vi gør dem mere detaljerede, eksempelvis med CAD-manual 2008, hvor vi yderligere vedhæfter en BIMmanual. I denne manual står der, hvad man skal gøre i Revit og hvad man ikke skal gøre. Men det bliver også mange tusinde sider. Hvorfor ikke bare arbejde sammen med den samme ingeniør? Så kan man bare lægge den samme IKT-aftale på bordet og sige at vi gør ligesom vi gjorde sidst. I byggebranchen skifter man partner som man skifter undertøj. Tænk hvis man kunne arbejde sammen med de samme ingeniører de næste mange projekter. Hvis man de næste 5 år skulle arbejde sammen med den samme ingeniør, så ville man få et rigtigt godt samarbejde. Det er fint med IKTaftaler, men vi skifter ofte partnere, så det er faktisk som at starte fra nul igen hver gang. Jeg hylder den frie konkurrence, men når du spørger om hvad der kan forbedres, så er det altid de samme værktøjer, men med nye mennesker. Men det kræver at hver gang du sætter dig ned med nye mennesker, at du skaber en ny aftale. (Andersen ARK, 2012) Min tolkning af svaret: Dette underbygger min teori omkring det, at hver enkel person tolker informationsniveauerne på forskellige måder. Der er ikke en fast retningslinje for, hvad der skal udføres i en fase. I dette tilfælde vedlægger Søren en BIM-manual som fælles grundlag for modellen. Man kan måske få faste retningslinjer hvis man arbejder sammen med, samme ingeniør hver gang, fordi der opstår en fælles forståelse for ydelsen. Men det kan af gode grunde ikke lade sig gøre. Der burde måske være nogle andre retningslinjer. 38

40 Hvordan kan det ellers forbedres? Simon: - Det er at få synliggjort den LOD metode, og at få afklaret nogle ting. Der skal opstilles en fælles målsætning, af hvordan man afleverer et BIM projekt. Det kan jo godt være, at vi gerne vil levere et projekt med et rigtigt godt informationsniveau fordi vi bruger det til dagligt og er vant til at arbejde med det, men ingeniøren ikke har ressourcer, eller ikke har lyst. Så bliver det et problem i sidste ende, fordi man har lovet bygherre noget andet. Det mener jeg er noget man skal få koordineret fra start af. Så det handler meget og målsætningen? - Ja det gør det, men også hvordan kan man håndtere den målsætning. Jeg vil mene, ved brugen af LOD metoden vil man kunne gøre meget. Man kan godt sige at vi vil levere til informationsniveau 4, men hvad er informationsniveau 4? LOD er mere specifik ved at forklare at lofterne er så detaljeret på det niveau osv. (Arnbjerg ARK, 2012) Min tolkning af svaret: LOD kan måske bruges til at undgå misfortolkninger af informationsniveauer fordi denne metode er meget konkret. Jeg mener dog at en aftale med LOD kræver meget arbejde. Den skal tilpasses hvert projekt, hvor imod CAD-manual 2008 er et fast grundlag. Det skal dog siges at hvis der ønskes en yderligere specificering af CAD-manual 2008 skal dette også tilpasses til hvert projekt. Men hvor mener ingeniøren at samarbejdet kan optimeres? Michael: - Jeg tror at man, aftalemæssigt, skulle gøre noget mere ud af hvem der laver kollisionskontroller. Der kan også optimeres ift. opfølgning på projekteringsmøder, f.eks. en gang om ugen eller hver anden uge. Det er tit at f.eks. kollisionskontroller er en ekstra ydelse som man påtager sig. Hvis vi påtager os koordineringsansvaret, så føler vores projektledelse at de påtager sig en ekstra ydelse. Hvis vi arbejder sammen med en arkitekt, så har de som regel projekteringsledelsen, dvs. at de også har det overordnede koordineringsansvar. De har selvfølgelig ikke ansvaret for, at vores installationer er koordineret, men de har ansvar for at det er koordineret mellem arkitekter og ingeniører. (Porskær ING, 2012) 39

41 Min tolkning af svaret: Ingeniøren mener i dette tilfælde at der er nogle punkter i aftalen som burde være mere synlige. Det kan hænge sammen med, at aftalen ikke er specifik nok. Men som han rigtigt nok siger, så er det en ekstra ydelse i dette tilfælde, og så mener jeg at der automatisk vil opstå problemer i aftalegrundlaget. Der er jo ikke nogen der vil arbejde gratis. 4.3 Delkonklusion Der opstår komplikationer mellem arkitekter og ingeniører i en bygningsmodel når denne skal overgives til den anden part. Der opstår tvivl om hvem der overtager hvad i modellen. Jeg syntes det er et generelt problem, at CAD-manual 2008 ikke er specifik nok, og at der på den måde opstår udfordringer omkring samarbejde mellem arkitekter og ingeniører. Jeg mener derfor, der kan spares tid og penge ved et let overskueligt og specifikt aftalegrundlag for samarbejdet mellem arkitekter og ingeniører. 40

42 5 Konklusion Som opgaven har udformet sig, er jeg løbende blevet klogere på teorien omkring emnet, hvilket har gjort, at jeg ikke, fra start, har kunnet spørge kritisk ind til dele af den anvendte teori, i praksis, som har været ønsket. Det drejer sig specielt om LOD, som beskriver informationsniveauerne anderledes og umiddelbart mere specifikt end CAD-manual Det ville have givet en mere kritisk engangsvinkel til begge beskrivelser af informationsniveauerne. Jeg kan konkludere, at der som værktøjer til samarbejdet mellem arkitekter og ingeniører anvendes nogle stykker. Den som anvendes oftest til at beskrive informationsniveauer er CAD-manual 2008, og den anden er, hvor LOD beskriver informationsniveauerne. CADmanual 2008 er den aftale, af de to, hvor der er mest løse rammer for, hvad samarbejdet kan indeholde. Det er mit indtryk, ud fra teori og empiri, at der tolkes meget forskelligt på indholdet af CAD-manual 2008, hvorfor der også opstår komplikationer i projekteringsfasen. I modsætning til dette er LOD meget specifik, problemet er blot at denne metode ikke er lige så kendt som CAD-manual Der opstår flest komplikationer mellem arkitekter og ingeniører i en bygningsmodel, når denne skal videregives til den anden part. Det er ikke tydeligt klarlagt, hvilke elementer modparten overtager. Dette fremgår ikke af aftalen. Der er ligeledes problemer med informationsniveauerne, det fremgår ikke tydeligt af enkelte beskrivelser, hvilke ting en bygningsmodel skal indeholde. CAD-manual 2008 er simpelthen ikke tilstrækkelig specifik, og LOD er ikke udbredt nok, til at denne kan redde dette problem. Jeg konkluderer derfor at problemet ikke kun ligger i aftalerne, men også hos tegnestuerne, som burde gøre noget mere ud af disse aftaler, for at undgå uenigheder i en bygningsmodel. Der er ingen faste rammer for, hvordan arkitekter og ingeniører afgrænser deres fagområder i en bygningsmodel. Det er som regel arkitekten der tegner projektet op, fordi det er et konkurrenceprojekt. Herefter overgår modellen til ingeniørerne, således de kan lave deres egen fagmodel. Det er her udfordringerne opstår. Hvem skal have ansvar for hvad? Skal væggene deles op således, at den bærende del af en væg tilhører ingeniøren og designdelen tilhører arkitekten? Ud fra denne rapport kan jeg konkluderer, at det ikke fremgår tydeligt nogen steder og parterne ligeledes er i tvivl om dette. Alt i alt kan jeg konkludere at samarbejdet fungerer mellem disse parter i projekteringen, men det kan sagtens komme til at fungere mere optimalt vha. klare retningslinjer i en bygningsmodel. Dette vil give færre frustrationer og lettere arbejdsgange i projekterne når der ofte skiftes samarbejdspartnere. 41

43 6 Perspektivering Min vurdering er, at dette område hvor arkitekter og ingeniører samarbejder i Revit, er et område som der burde være mere fokus på at udvikle og optimere. Det er stadig i opstartsfasen, så der er mange erfaringer som skal gøres før dette kan forbedres. Specifikke beskrivelser, som LOD eller en mere udpenslet udgave af CAD-manual, mener jeg er vejen frem for et mere entydigt samarbejde mellem arkitekter og ingeniører. Jeg mener det er et område, hvis samarbejdet fungerer optimalt, hvor der kan spares meget tid og masser af penge. Det mener jeg fordi, at når der projekteres i 3D, kan man fange mange problemer som man førhen, først opdagede under byggeperioden. Derfor er det vigtigt at få alle problemer på banen så tidligt som muligt. Det mener jeg, at man kan hjælpe på vej, ved at lave en specifik aftale som grundlag mellem arkitekter og ingeniører. Eksempelvis kan man på uddannelserne gøre mere opmærksom på, hvilke værktøjer der kan anvendes til samarbejdet mellem arkitekter og ingeniører. Jeg har selv erfaret under vejs, på min uddannelse, at dette ikke er et område som er blevet undervist i. Jeg mener der er for lidt fokus på, ift. hvor udbredt Revit er, hvilke værktøjer der er og hvordan disse fungerer rent praktisk. Det kan man på uddannelserne undervise i, og ruste de studerende til arbejdsmarkedet bedst muligt. Herefter kommer de nyuddannede ud med værdifuld viden ift. kvalificering af samarbejdet, som kan videreformidles til de ældre generationer på arbejdsmarkedet. Et andet eksempel kunne være et bips-udvalg, som i forvejen udformer IKTspecifikationerne, i samarbejde med byggeriets aktører, udforme et fælles grundlag som er mere entydig og specifikt. Der arbejdes altid på at optimere anvisninger og aftalegrundlag, men jeg mener, at et bredere samarbejde mellem alle aktører i byggeriet fordi at finde det fælles grundlag er det nødvendigt, at der indsamles erfaringer fra så mange virksomheder som muligt. Problemerne bliver ikke løst i løbet af et par måneder eller et år. Det kræver mange erfaringer og meget samarbejde mellem alle aktører i byggebranchen for at dette skal optimeres. 42

44 7 Kildeliste Bøger: Wiley, John & Sons 2011, BIM Handbook 2nd Edition, John Wiley & Sons, Inc., Hoboken, New Jersey Artikler: Ukendt forfatter Behov for nye roller med BIM, Det Digitale Byggeri 2009 Publikationer: f102 IKT-specifikationer anvisning, f102 IKT-specifikationer basisbeskrivelse, C202 CAD-manual 2008 anvisning, C202 CAD-manual 2008 basisbeskrivelse, BIM Guidelines, New York City Department Of Design + Construction, Juli 2012 BIM Execution Planning Guide v1.0, BuildingSMART samarbejde, Oktober 2009 Georgia Tech BIM Execution Plan Template v.1.0, September 2001 Vejledning til Bekendtgørelse om krav til anvendelse af informations- og kommunikationsteknologi i byggeri nr af , Bekendtgørelser: BEK 1381, Bekendtgørelse om krav til anvendelse af informationsog kommunikationsteknologi i byggeri, Rapporter: Broe, Jens Jarl Gehrke, Rasmus Ulrik Hersing, Daniel Green - Lisborg, Asger, Procesunderstøttelse af Building Information Modelling, Roskilde Universitet Hansen, Thomas, Udvikling af IFC-kompatibelt dimensioneringsprogram, Dansk Tekniske Universitet, August

45 Miniguide: Levring, Asbjørn, Konsulent, BIM-implementering og praktisk projekthåndtering, Teknologisk Institut, Center for Byggeproces, Marts 2010, Fuglsig, Jan, Konsulent og Cand. Polyt. Ph.d, Bygherrens krav til brug af informations- og kommunikationsteknologi (IKT), Teknologisk Institut, Center for Byggeproces, September 2010, Internetsider: Interview: Søren Sti Anders, arkitekt MAA & BIM ansvarlig Aarhus arkitekterne, Oktober 2012 Simon Andreas Arnbjerg, Architectural Technologist & BIM Model Manager Schmidt/Hammer/Lassen architects, Oktober 2012 Michael Porskær, Ingeniør Søren Jensen rådgivende ingeniørfirma, Oktober

46 Figurer: Figur 1: BIM lab, Figur 2: BIM-implementering og praktisk projekthåndtering, Figur 5: IKT-ydelsesspecifikation, Figur 6: IFC model, Figur 7: f102 IKT-specifikationer anvisning, Figur 8: BIM Guidelines, New York City Department Of Design + Construction, Juli 2012, Figur 9: f102 IKT-specifikationer anvisning, Figur 11-18: CAD-manual 2008, Figur 20-24: BIM Guidelines, New York City Department Of Design + Construction, Juli 2012, Figur 25-26: BIM Guidelines, New York City Department Of Design + Construction, Juli 2012, 45

47 8 Bilag 46

48 7.1 Spørgsmål til ingeniør og arkitekter Interview med Michael Porskær, Søren Jensen rådgivende ingeniørfirma d Formålet med interviewet er at få belyst samarbejdet mellem arkitekter og ingeniører i Revit som du oplever det. Det er muligt at svarene, på nogle spørgsmål bliver besvaret tidligere end tiltænkt, men jeg forestiller mig at opstille interviewet i små delemner, som vi snakker om. Hvis du mener der er andre ting som er relevant for emnet er du meget velkommen til at byde ind med det. Revit: Opstart: Hvornår begyndte i at arbejde i Revit? Er det nyt for jer at arbejde med arkitekter i Revit? Har i påvirket arkitekter til at arbejde i Revit? Processen: Anvender i IKT ydelsesspecifikation og kan denne bruges som aftale grundlag mellem arkitekt og ingeniør i Revit? Og hvordan? Hvordan håndterer i Revit fagmodellerne i en fællesmodel, så modellerne ikke flytter sig forskelligt fra hinanden? Hvilke aftaler følger i? Hvordan afgrænser i jeres og arkitektens fagområder når, i projekterer i Revit? Oplever i ventetid i projekteringen pga. forskellige informationsniveauer mellem jer og ingeniøren? Eller fordi, i befinder jer på forskellige stadier i projekteringen. Hvilke problemer oplever i når, i arbejder sammen med arkitekten? Og hvad gør i for at løse disse problemer? Udveksling: Hvordan foregår samarbejdet hos jer, når der udveksles modeller i Revit? Er det vha. mail eller projektweb hvor alle kan tilgå hele projektet? Hvilke standarder benytter i, til jævnligt at kontrollerer fagmodellerne? Her tænker jeg på aftaler om hvor tit, der skal udveksles, og hvad der ligges vægt på ved den enkelte udveksling. Når noget skal rettes pga. kollisioner, hvordan sørger i så for at dette bliver rettet? Forbedringer: På hvilke områder mener du, man kan forbedrer samarbejdet mellem arkitekt og ingeniør? Og hvordan? Hvordan oplever i arkitektens arbejde i en Revit model?

49 Interview med Simon Andreas Arnbjerg fra Schmidt/Hammer/Lassen architects d Formålet med interviewet er at få belyst samarbejdet mellem arkitekter og ingeniører i Revit som du oplever det. Det er muligt at svarene, på nogle spørgsmål bliver besvaret tidligere end tiltænkt, men jeg forestiller mig at opstille interviewet i små delemner, som vi snakker om. Hvis du mener der er andre ting som er relevant for emnet er du meget velkommen til at byde ind med det. Revit: Opstart: Hvornår begyndte i at arbejde i Revit? Er det nyt for jer at arbejde med ingeniører i Revit? Har i påvirket ingeniøren til at arbejde i Revit? Processen: Anvender i IKT ydelsesspecifikation og kan denne bruges som aftale grundlag mellem arkitekt og ingeniør i Revit? Og hvordan? Hvordan håndterer i Revit fagmodellerne i en fællesmodel, så modellerne ikke flytter sig forskelligt fra hinanden? Hvilke aftaler følger i? Hvordan afgrænser i jeres og ingeniørers fagområder når, i projekterer i Revit? Oplever i ventetid i projekteringen pga. forskellige informationsniveauer mellem jer og ingeniøren? Eller fordi, i befinder jer på forskellige stadier i projekteringen. Hvilke problemer oplever i når, i arbejder sammen med ingeniøren? Og hvad gør i for at løse disse problemer? Udveksling: Hvordan foregår samarbejdet hos jer, når der udveksles modeller i Revit? Er det vha. mail eller projektweb hvor alle kan tilgå hele projektet? Hvilke standarder benytter i, til jævnligt at kontrollerer fagmodellerne? Her tænker jeg på aftaler om hvor tit, der skal udveksles, og hvad der ligges vægt på ved den enkelte udveksling. Når noget skal rettes pga. kollisioner, hvordan sørger i så for at dette bliver rettet? Forbedringer: På hvilke områder mener du, man kan forbedrer samarbejdet mellem arkitekt og ingeniør? Og hvordan? Hvordan oplever i ingeniørens samarbejde i en Revit model?

50 Interview med Søren Sti Andersen Aarhus Arkitekterne den Formålet med interviewet er at få belyst samarbejdet mellem arkitekter og ingeniører i Revit som du oplever det. Det er muligt at svarene, på nogle spørgsmål bliver besvaret tidligere end tiltænkt, men jeg forestiller mig at opstille interviewet i små delemner, som vi snakker om. Hvis du mener der er andre ting som er relevant for emnet er du meget velkommen til at byde ind med det. Revit: Opstart: Hvornår begyndte i at arbejde i Revit? Er det nyt for jer at arbejde med ingeniører i Revit? Har i påvirket ingeniøren til at arbejde i Revit? Processen: Anvender i IKT ydelsesspecifikation og kan denne bruges som aftale grundlag mellem arkitekt og ingeniør i Revit? Og hvordan? Hvordan håndterer i Revit fagmodellerne i en fællesmodel, så modellerne ikke flytter sig forskelligt fra hinanden? Hvilke aftaler følger i? Hvordan afgrænser i jeres og ingeniørers fagområder når, i projekterer i Revit? Oplever i ventetid i projekteringen pga. forskellige informationsniveauer mellem jer og ingeniøren? Eller fordi, i befinder jer på forskellige stadier i projekteringen. Hvilke problemer oplever i når, i arbejder sammen med ingeniøren? Og hvad gør i for at løse disse problemer? Udveksling: Hvordan foregår samarbejdet hos jer, når der udveksles modeller i Revit? Er det vha. mail eller projektweb hvor alle kan tilgå hele projektet? Hvilke standarder benytter i, til jævnligt at kontrollerer fagmodellerne? Her tænker jeg på aftaler om hvor tit, der skal udveksles, og hvad der ligges vægt på ved den enkelte udveksling. Når noget skal rettes pga. kollisioner, hvordan sørger i så for at dette bliver rettet? Forbedringer: På hvilke områder mener du, man kan forbedrer samarbejdet mellem arkitekt og ingeniør? Og hvordan? Hvordan oplever i ingeniørens samarbejde i en Revit model?

51 7.2 Uddrag fra interviews Interview med Søren Sti Andersen - Aarhus arkitekterne Hvordan håndtere i Revit fagmodellerne i en fællesmodel, så modellerne ikke flytter sig forskelligt for hinanden? Hvilke aftaler følger i? Der stå bl.a. i IKT-aftalen hvilket level der i hvilken kote, så vil det automatisk stå i programmet, når man åbner det, at ingeniøren har en 20mm højere kote en aftalt. Det er sådan nogle ting vi bruger IKT-aftalen til. Oplever i ventetid i projekteringen pga. forskellige informationsniveauer mellem jer og ingeniøren? Ja det har vi til dels gjort, ingeniører og arkitekter har forskellige vinkler på hvordan man arbejder og om det er BIM med Revit eller om det er klassisk samarbejde. Ingeniørens natur er at de arbejder en gang, hvorimod arkitekten undersøger en masse ting. Men man vil have aftalt tidspunkter i projektet hvor man skal have visse ting færdige til. Og så er man tilbage til ydelsesbeskrivelsen. Aftalegrundlag er vigtige. Kan du komme med nogen eksempler på hvilke problemer i oplever mest med ingeniøren med hensyn til aftaler, eller omkring hvornår i skal have ting klar til? Generelle problemer kan være på afklaringsniveau og det der er super vigtigt er også det vi kalder enkeltprojektering eller dobbeltprojektering særligt nu her hvor vi skal gøre rede for mængderne, skal vi tegne søjler ind når ingeniøren i forvejen tegner deres søjler ind. Ingeniøren siger meget nu om dage at de skal tidligere og tidligere på banen, men det er jo modstridende med det at de helst vil sidde og vente til aller sidst og så tegne søjlerne ind en gang. Hvis de vil tidligt på banen så må de jo tidligt frem, men så må de også accepterer at man melder sig ind i en proces hvor man prøver tingen af flere gange fordi man bliver klogere undervejs, og det er jo en forventningsafstemning som foregår over de her år. Så er der også noget med at ventilationsingeniøren skal jo ikke detailprojektere et ventilationsanlæg helt fra starten af, så kvæler de sig selv i arbejde. De bliver nødt til at sige, f.eks. hvis vi har 2 rør på en størrelse ø400 mm hver, så kan det være at de skal tegne 5-10 cm luft udenom, så de for en kasse som præsenterer en korridor som er 50 cm høj og 1 m bred, som de to ø400 rør kan være i, og så er der lidt tolerance udenom. Så i stedet for at tegne de to rør skal de lave et eller andet som repræsentere de to rør i form af en kasse. Hvor de før hen har tegnet med en overstregningstusch, ber vi dem nu om at modellerer i 3D hvilken højde og hvilken dimension den her korridor er, det er ikke selve rørene de skal tegne det er kun den her korridor.

52 Er der ikke for det meste problemer med at, ingeniøren vil have det mest funktionelle og arkitekten vil have det pæneste udtryk? Ja, og som arkitekt skal man lære ingeniøren, at ventilation og konstruktion skal med tideligt. Omvendt kræver det også at ingeniørerne ikke detailprojekterer men at de tegner lidt mere i principper. Og det gør de allerede fra starten af, dvs. at de skal flere gange indover projektet, hvor de tidligere, nogle gange er kommet ind senere i projektet, hvor de så har detailprojekterede. Arbejdsbyrden ligger noget tidligere i projekteringen end ved traditionel projektering, er det en anden metode parterne skal projektere efter? Ja lige præcis, det er en anden måde, ikke nødvendigvis at de skal lave mere arbejde, men en anden måde de skal gøre det på. Kort kan man sige at ingeniørerne skal ind to gange, ja men det skulle jo gerne lette det arbejde de skal lave til sidst fordi de har taget en masse del beslutninger. Derfor skal de lære at gøre det på en anden måde. Og det er tit det der er svært, for man skal gøre næsten det samme som man plejer at gøre, og så er der nogle helt bestemte steder hvor man skal gøre noget helt anderledes. Så det er en proces man skal igennem? Ja det er en proces. Man kan godt skrive det ned i et aftalegrundlag, men man skal næsten ha prøvet det før man begynder at forstå det. Og så er det tit at folk sidder bagefter nå, var det bare det? ja, men det er anderledes end det du gjorde før. På hvilke områder mener du, man kan forbedrer samarbejdet mellem arkitekter og ingeniører? Hvis man kunne arbejde sammen med de samme ingeniører en gang til, og måske en gang til osv. Som det er nu, så når vi aflevere det igangværende projekt, så er vi næsten sikker på at næste projekt bliver med en anden ingeniør, og et tredje projekt med en tredje ingeniør. Mangler der nogle faste rammer i aftalerne mellem arkitekt og ingeniør? Nej det tror jeg sådan set vi er godt i gang med at hjælpe hinanden med at lave, både med de her IKT-aftaler hvor vi gør dem mere detaljeret eksempelvis med CAD-manual 2008 hvor vi yderligere vedhæfter en BIM-manual hvor der står hvad man skal gøre i Revit og hvad man ikke skal gøre. Men det bliver også mange tusinde sider. Hvorfor ikke bare arbejde sammen med den samme ingeniør, så kan man bare lægge den samme IKT-aftale på bordet og siger at vi gør ligesom vi gjorde sidst. I byggebranchen skifter man partner som man skifter undertøj, tænk hvis man kunne arbejde sammen med de samme ingeniører de næste mange projekter. Hvis man de næste 5 år skulle arbejde sammen med den samme ingeniør, så ville man få et rigtigt godt samarbejde. Det er fint med IKT-aftaler, men vi skifter lige meget partner, så det er faktisk som at starte fra nul igen. Jeg hylder den frie konkurrence, men når du spørger om hvad der kan forbedres, så er det altid de samme værktøjer, men med nye mennesker. Men det kræver at hver gang du sætter dig med nye mennesker, at du skaber en ny aftale.

53 Interview med Simon Andreas Arnbjerg Schmidt.Hammer.Lassen Architects Anvender i IKT-ydelsesspecifikation som aftale grundlag mellem arkitekter og ingeniører? Ja det gør vi, IKT-specifikationen bliver lavet sammen med bygherren, og der definerer vi overfor bygherren hvad man afleverer. Og ud fra det ligger der jo også hvad ingeniøren og arkitekten skal afleverer. Og det er stadig en gråzone, for hvem afleverer hvad, der er altid noget hvor man siger at det her er ingeniør fagligt, det skal I afleverer. Vores erfaringer er at man skal være meget mere specifik omkring hvem der afleverer og hvad man afleverer. Kan i bruge IKT og CAD-manual 2008 til det? Vi har lavet et nyt dokument til at håndterer det, fordi det bliver ikke specifikt nok. Det hedder Level Of Development (LOD) det vi bruger. Hvor man ligesom siger at, på det her tidspunkt skal modellen være så veludviklet og de her ting skal afleveres på det her informationsniveau. Vi vil også bruge det til at håndterer økonomi, fordi hvis vi skal håndterer noget ingeniørfagligt, så skal vi også honoreres for det fordi vi har noget ansvar for det. Så i vedlægger et ekstra dokument med dette? Ja, og det gør vi for at gøre det mere specifikt og for at kunne styrer det. Vi har nogle erfaringer hvor man kommer i en gråzone, f.eks. hvis ingeniøren ikke syntes at de skal modellere det, så hvis vi ikke har noget dokumentation for at de skulle have modelleret det. Og det er tit ved sammenfald der opstår de problemer, f.eks. ved sokler hvor der er betongulve som er mere ingeniørfagligt end arkitektfagligt, hvordan håndterer man sådan nogle ting? Det er ligesom de gråzoner man skal have styr på. Det kan være et Excel ark hvor der står at til den her fase har man modelleret lofter, og hvem der har modelleret det. Det kan være i en konkurrence hvor vi har modelleret alle ingeniørens vægge og så skal de overtage det, men hvornår skal de overtage det? Det er ligesom det dokument der skal styrer det. Det er lige så meget for os selv og lige så meget for dem, for at kunne styrer processen bedre. Hvordan afgrænser i jeres og ingeniørens fagområder når, i projekterer i Revit? Til at starte med er det nok lettere at vi bare har det hele i vores model indtil designet er på plads. Så for de modellen så fjerner vi vores søjler hvorefter de kan tegne deres egne søjler ind. Og i den forbindelse er der også alle mulige forhold som kalkulation og sammenbygning som de skal forholde sig til som vi ikke forholder os til. Og det kan så godt være at der kommer en lille korrektion i forhold til det. Rent praktisk laver de en model, de laver faktisk en model for hver deres fag. F.eks. en for alt det bærende, men man kan også vælge at sige at arkitekten beholder alle de bærende vægge, hvor man så kan holde det op mod hinanden. Det man kan blive i tvivl om er hvem der ejer den væg, hvis vi nu har lavet en beton væg som vi mener ingeniøren skal lave og de så ikke laver den væg, så er det bare svært at finde ud af. Derfor fjerner vi det fra vores modeller så snart ingeniøren kommer med ind over.

54 Det handler igen om noget økonomi, ingeniøren kan godt sige at det er lettere at vi sætter væggen, så skal de nok overtage den senere, hvor de så kopiere geometrien ind i deres model. Men det er meget vigtigt de overtager væggen, fordi når væggen er i deres model er det deres ansvar. Og det er lige netop der, der opstår mange gråzoner, og det er sådan noget det skal klarlægges i IKT-ydelsesspecifikationen. På hvilke områder mener du, man kan forbedrer samarbejdet mellem arkitekter og ingeniører? Det er at få synliggjort den her LOD metode, simpelthen at få afklaret de ting fordi der skal opstilles en fælles målsætning af hvordan man aflevere et BIM projekt. Det kan jo godt at vi gerne vil levere et projekt med et rigtigt godt informationsniveau fordi vi bruger det, men ingeniøren ikke har ressourcer eller ikke har lyst, så bliver det et problem i sidste ende fordi man har lovet bygherre noget andet. Det mener jeg er noget man skal få koordineret fra start af. Så det handler meget og målsætningen? Ja det gør det, men også hvordan kan man håndtere den målsætning. Jeg vil mene at, ved at bruge metoden med LOD vil kunne gøre meget. Man kan godt sige at vi vil levere til informationsniveau 4, men hvad er informationsniveau 4? LOD går mere ind og siger at lofterne er så detaljeret på det niveau osv. Interview med Michael Porskær Rådgivende ingeniørfirma Søren Jensen Anvender i IKT-ydelsesspecifikation og kan denne bruges som aftalegrundlag mellem arkitekter og ingeniører? Ja, vi får som oftest en ydelsesspecifikation af bygherren, det skal lige siges, at vi laver rigtig meget offentligt byggeri. Og dvs. at der altid er, de her digitale bygherre krav gældende. Og det fleste af vores kunder ligger også en ydelsesspecifikation med så der hvad vi skal levere. Så er der så den Revit tekniske del af det, det ligger jo nede i de tekniske specifikationer, og dem udarbejder vi sammen med arkitekten. Og det fungerer okay syntes jeg. Hvordan håndterer i fagmodellerne når de skal samles til en fællesmodel? Det er faktisk der vi tit oplever problemer, fordi der er som regel ikke nogle der tager ansvar for at få samlet modellerne til en fællesmodel. Vores egen produktion fungerer på den måde at vi modtager en model fra arkitekten som vi så ligger ned på vores server og så kan vi ligge den ind i vores modeller. Hvordan afgrænser i jeres og arkitektens fagområder når, i projekterer i Revit? Jamen det plejer at foregå på den måde, og det har vi også tumlet meget med, skal arkitekten lave eller skal vi lave det? Efterhånden er det blevet sådan, at vi har alt det der er

55 bærende, og det har vi egentlig rimeligt tidligt. Så snart vi er med, så laver vi en konstruktionsmodel hvor alle de bærende elementer fremgår. Og dvs. at arkitekten skal have nogle tegninger der ser fornuftige ud, så er de også nødt til at have vores model med som underlag. Den eneste model der kan gå uden modeller, er sådan set konstruktionsmodellen. Fordi en installationsmodel med f.eks. ventilation eller el skal også bruge en arkitektmodel, og højst sandsynligt også en konstruktionsmodel for at give mening. Det plejer at være den måde det er aftalt på, at vi har alt det der vedrører det bærende system. Det ligger også lidt i hvordan man udbyder det, rent entreprisemæssigt. Så alt det konstruktionsingeniøren har ansvaret for, det bliver på normal vis udbudt til en entreprenør, f.eks. en råhus entreprenør, og alt det som arkitekten har ansvar for, er som regel en tømrer og måske en facadeentreprenør. Så det ligger egentlig meget i de der entrepriser, og det gir egentlig meget go mening at dele det på den her måde. Det hænger også sammen med at vi er nødt til at have modeller adskilt så det der ligger i vores model er reelt det jeg har ansvaret for. Oplever i at, i skal tidligere på banen med løsninger når i projektere 3D til sammenligning med når i projektere i 2D? Det er altid godt at komme tidligt på banen med løsninger, man for hurtigere en hovedgeometri i et hus, den tager ikke lang tid at lave, når det udelukkende er konstruktion vi snakker om. Det laver vi ret tidligt, nogle gange allerede i konkurrencefasen. Netop fordi det ikke er særlig tidskrævende, det der er tidskrævende er detaljeringen. F.eks. hvor mødes en søjle med et dæk? Så ja vi er tidligere på banen end før. På hvilke områder mener du, man kan forbedrer samarbejdet mellem arkitekter og ingeniører? Jeg tror at man aftalemæssigt skulle gøre noget mere ud af hvem der laver kollisionskontroller. Også opfølgning på projekteringsmøder f.eks. en gang om ugen eller hver anden uge. Det der tit er med kollisionskontroller er, at det tit er en ekstra ydelse som man påtager sig. Hvis vi påtager os koordineringsansvaret så føler vores projektledelse at de påtager sig en ekstra ydelse. Hvis vi arbejder sammen med en arkitekt, så har de som regel projekteringsledelsen, dvs. at de også har det overordnede koordineringsansvar. De har selvfølgelig ikke ansvaret for at vores installationer er koordineret, men de har ansvar for at det er koordineret mellem arkitekter og ingeniører.

56 7.3 Pentagon Fundamentet: Den udfyldte pentagon BIM bygningsmodel, samarbejde mellem arkitekt og ingeniør på det digitale byggeri. 1. Problemformulering og uddybning af overskriften. Hvorfor er det vigtigt at arkitekter og ingeniører samarbejder i projekteringsfasen af en bygningsmodel? I denne rapport vil jeg undersøge hvilke komplikationer der er mellem arkitekter og ingeniører i udarbejdelsen af en bygningsmodel 2. Faglige formål. Mit formål er at bliver klogere på emnet 3. Hvad søger du svar på, og hvor vil du finde svarene? Hvornår opstår der komplikationer mellem arkitekter og ingeniører i bygningsmodellen? Hvilke værktøjer, er tilgængelige for samarbejde mellem arkitekter og ingeniører, i projekteringsfasen når projektet udarbejdes i 3D? Hvordan afgrænser arkitekter og ingeniører deres fagområder når der udarbejdes en bygningsmodel? Hvordan kvalitetssikrer aktørerne på tværs af fagområderne projektet i en bygningsmodel? Lave interviews af konstruktører og ingeniører som har lavet eller laver projekter hvor de samarbejder med modparten. Søge artikler på nettet, hvor 3D projektering har været anvendt og hvor der har været et samarbejde på tværs af fagområderne. Arkitema Vestas, Københavns universitet. SHL Campus Skejby VIA. Søren Jensen Skejby sygehus (ingeniør) PIHL Skejby sygehus (ingeniør)

57 4. Hvad vil du gøre for at få besvaret dine spørgsmål, og hvordan vil du analysere dine svar? Jeg vil tage ud på tegnestuer og interviewe personer, der har prøvet at projekterer i 3D, hvor der har været samarbejde på tværs af fagområder. Undersøge om der er tilgængeligt materiale på internettet eller biblioteket Jeg vil sammenligne mit data fra bøger, med den viden jeg får fra mine interviews ude på tegnestuerne. Jeg vil finde ud af om der er en enstydig måde at køre samarbejdet på? 5. Fremgangsmåden. Indhente viden fra bøger og artikler på internettet. Formulerer spørgsmål til interviews. Ved et interview, for jeg forhåbentligt et mere uddybende svar. Og kan bedre få en fornemmelse for hvordan de oplever samarbejdet Tage kontakt til virksomheder angående aftaler om interviews. Lave interviews med min. 6 aktører (3 arkitekt virksomheder og 3 ingeniør virksomheder) som alle har prøvet at 3D projekterer hvor de har skulle samarbejde på tværs af fagområderne. Sammenligning af data. Skrive rapport.