IFC-prosjekt Nye Ahus

Transkript

1 IFC-prosjekt Nye Ahus Evalueringsrapport Versjon av 75

2 Denne rapport er et Nye Ahus-dokument med dokumentnummer: A-2220-Z-KR-0001 IFC-prosjektet Nye Ahus, Evalueringsrapport 2 av 75

3 Forord Arkitektfirmaet C.F. Møller valgte allerede i 2001 å gjennomføre prosjekteringen av Nye Ahus som en objektorientert prosjektering. Allerede da var det en underliggende forventning om å kunne benytte den informasjonen som ble lagt inn til noe mer enn å produsere tegninger. Etterhvert som programvaren utviklet seg og prosjektet nærmet seg detaljprosjekt og anbudsproduksjon ble dette mer aktuelt. Samtidig hadde utviklingsarbeidet med den internasjonale overføringsstandarden IFC kommet så langt at også brede norske miljøer hadde begynt å engasjere seg i dette gjennom Norsk IAI Forum. Det førte til at det i 2004 ble tatt et initiativ for å gjennomføre et prøveprosjekt for objektorientert prosjektering og utveksling av bygningsinformasjonsmodeller innenfor Nye Ahus prosjektet. Dette forslaget ble tatt i mot meget positivt både i Nye Ahus, i prosjektorganisasjonen, byggenæringen og IAI miljøet, både nasjonalt og internasjonalt. Dette førte til at det ble etablert tre delprosjekter som har vært direkte knyttet opp mot prosjektet med direkte og umiddelbar nytte for prosjektet som også har blitt direkte finansisert av prosjektet. I tillegg ble det etablert et fjerde delprosjekt, en bred utprøving av BIM og IFC i Frontbygningen, som har inkludert hele prosjektorganisasjonen for denne delen av prosjektet og som også ble åpnet opp for deltagelse fra byggebransjen for øvrig. Nye Ahus har støttet prosjektet både direkte og gjennom organisering av deltagelse fra entreprenørene på Frontbygningen. I tillegg har prosjektet blitt støttet av de deltagende bransjeorganisasjonene. Prosjektet har gjennom prosjekteringsorganisasjonen, entreprenørene, programvareleverandørene som har vært involvert og byggenæringens organisasjoner engasjert svært mange, og en bred interesse også fra bransjen for øvrig har ført til at prosjektet er blitt presentert bredt både nasjonalt og internasjonalt. I tillegg har prosjektet gjennomført jevnlige seminarer med bred oppslutning fra hele den store gruppen som etter hvert ble engasjert. Dette har ført til at prosjektet har bidratt kraftig til spredningen av kunnskap om denne arbeidsmåten. Det har også bidratt til utvikling av programvare og gitt erfaringer tilbake til de som arbeider med utvikling av IFC standarden. Slik sett har prosjektet blitt en viktig del av den verdensomfattende dugnaden som nå blir kalt BuildingSMART og som er i ferd med å sette en ny målestokk for hvordan byggebransjen skal arbiede og samarbeide framover. Oslo 14. desember 2007 Kjell Ivar Bakkmoen, Arkitektfirmaet C.F. Møller 3 av 75

4 Innholdsfortegnelse Forord... 3 Innholdsfortegnelse... 4 Innledning... 7 Generelt om oppbygging av IFC-BIM... 9 Begreper og forkortelser IFC-prosjektet ønsker å takke Delprosjekt 1 Sjekk av modellens konsistens og mengdeuttrekk Solibri Model Checker Delprosjekt Kobling mellom rom i tegning og rominformasjon i databaser (drofus) Delprosjekt Overføring av informasjon for arealforvaltning til FDVU systemer Delprosjekt Innledning Prosjektets organisasjon ARK Innledning Modellering og property sets Eksport og import Model server EPM Technology Kollisjonskontroll Visualisering Realistisk visualisering for prosjekterende arkitekt og brukere Grafisk oversikt over BIM med objektegenskaper i arbeide med BIM Kalkyle D NavisWorks Jetstream Timeliner e-handel Innkjøpsportal RIB Modellering av modellen i Microstation RIV VVS-teknikk/RIV generelt Objekter og property set (Pset) EDM modelserver fra EPM Technology RIV Modelleringsverktøy MagiCAD Solibri Model Checker v NavisWorks Jetstream med Clash Detective Viewere Energisimuleringsverktøy e-handel - Innkjøpsportal Beskrivelsesprogram G-Prog RIE Innledning Aktivitetsbeskrivelse RIE Delaktiviteter Programmer brukt i pilotprosjektet MagiCAD DDS ElektroPartner Febdok av 75

5 Eldata Utviklingsmøter Måloppnåelse og status Erfaringer Konklusjon av 75

6 6 av 75

7 Innledning Bakgrunn Arkitektfirmaet C.F. Møller valgte allerede i 2001 å gjennomføre prosjekteringen av Nye Ahus som en objektorientert prosjektering. Allerede da var det en underliggende tanke om å kunne benytte den informasjonen som ble lagt inn til noe mer enn å produsere tegninger. Etterhvert som programvaren utviklet seg og prosjektet nærmet seg detaljprosjekt og anbudsproduksjon ble dette mer aktuelt. Samtidig hadde utviklingsarbeidet med den internasjonale overføringsstandarden IFC kommet så langt at også brede norske miljøer hadde begynt å engasjere seg i dette. Det førte til at det i 2004 ble tatt et initiativ for å gjennomføre et prøveprosjekt for objektorientert prosjektering og utveksling av bygningsinformasjonsmodeller innenfor Nye Ahus prosjektet. En prosjektplan ble behandlet av Nye Ahus i mars og august Det ble også presentert for byggenæringens organisasjoner på entreprenørsiden i agust Alle parter sluttet seg til prosjektplanen. IFC-prosjektets mål Utprøve IFC som felles utvekslingsstandard for BIM Gevinstrealisering ved å redusere feil i prosjektert materiale før bygging Få praktisk erfaring med dataverktøy, som kan automatisere og effektivisere prosesser i prosjektering, dokumentasjon og bygging. Få erfaring med bruk av IFC-BIM på modelserver som felles dokumentasjonsplattform for prosjekterende, byggherre og entreprenør. Få hele verdikjeden representert: Program-modell-simulering-anskaffelse-byggesimulering/formidling-FDV Fire delprosjekter Prosjektet er nedbrutt i fire delprosjekter. Oppdelingen er en naturlig konsekvens av at delprosjektene med fordel kunne gjennomføres uavhengig av hverandre. Delprosjekt 1 Konsistenskontroll av bygningsinformasjonsmodellen ARK/Alle prosjekterende Delprosjekt 2 Kobling mellom rom, installasjoner og utstyr i rom- og utstyrsdatabase og BIM Delprosjekt 3 FDV-dokumentasjon fra BIM med interaktiv viewer Delprosjekt 4 Generell utprøving av IFC-BIM på modelserver som felles dokumentasjonsplattform for prosjekterende, byggherre og entreprenør. Teknologien var ikke moden for delprosjekt 4 før senere i forløpet og Nye Ahus-prosjektets organisasjon var ikke klar for delprosjekt 3 før ved oppstart av produksjon av FDV-dokumentasjon. Fremdrift Delprosjektene har vært gjennomført uavhengig av hverandre og i ulikt tempo. Delprosjekt 1 Fra primo 2004 til ultimo 2007 Delprosjekt 2 Fra primo 2004 til medio 2006 Delprosjekt 3 Fra ultimo 2007 til medio 2008 Delprosjekt 4 Fra primo 2006 til ultimo 2007 Organisering av det daglige arbeidet Prosjektet er matriseorganisert. Alle deltakene er i deres daglige arbeid tilknyttet linjen som i dette tilfellet er prosjektorganisasjonen Nye Ahus. Prosjektorganisasjonen IFC-prosjektet er derfor tverrfaglig og forankret i Nye Ahus-organisasjonen. Deltakerne i IFC-prosjektet kjenner til relevante problemstillinger innen prosjektering og bygging. Og de forholder seg måltettet og resultatorientert til prosjektet. Den klassiske utfordring med matriseorganisering har vi dog også merket i IFC-prosjektet. Når deltakerne har rikelig å gjøre med jobben deres i linjen kan det være vanskelig å finne tid til å delta i 7 av 75

8 prosjektarbeid. Prosjektet har været gjennomført med gode resultater og høy læringskurve pga. stort engasjement og utholdenhet. Finansiering Deler av prosjektet har vært en naturlig del av prosjekteringen, deler av prosjektet har blitt finainsert direkte av Nye Ahus. For delprosjekt 4 ble det etablert en særskilt finanisering gjennom tilskudd fra entreprenørene og de bransjeorganisasjonenen som ville følge med på prosjektet. Videre drift avslutning Det gjenstår noe arbeid på noen av aktivitetene for å ha oppfylt alle prosjektmål. Aktivitetene er følgende: Energiberegning med dataverktøyene IDA, Riuska og Ecotect e-handelsportal Logiq/EPM Visualisering med spillteknologi - Center of vizualization, Chalmers Hele delprosjekt 3 er fortsatt i oppstartfdv Plannja. Alle aktiviteter er beskrevet i rapporten. IFC-prosjektet er derfor ikke avsluttet for det finnes endelig avklaring på disse punktene. Prosjektet fortsetter ut i første kvartal Steen Sunesen og kjell Ivar Bakkmoen, Arkitektfirmaet C.F. Møller 8 av 75

9 Generelt om oppbygging av IFC-BIM En IFC-BIM bygges opp i en hierarkisk struktur i flere nivå. Dette er sentralt uansett hvilken programvare det modelleres i. I noen sammenhenger, for eksempel når det skal merges filer i modelserveren. Er det viktig at strukturen er lik i alle delmodeller. Noen applikasjoner kan også ha vanskelig ved å lese BIM innholdet, hvis strukturen ikke er iht. standard. Nivåene for hierarkiet er: Project - Prosjekt Site - Byggeplass Building - Bygning Storey - Etasje Selve modellens innhold legges vanlig på den enkelte storey. Project Site Building Storey Viste eksempel er fra modellserver klienten. De ulike nivåene har ulike symboler som indikerer fra hvilket nivå man betrakter modellen. 9 av 75

10 Begreper og forkortelser IFC filosofien benytter en rekke av begreper som kan være ekskluderende for de som ikke kjenner til de. Følgende oversikt beskriver kortfattet de mest brukte begrepene. IFC står for Industry Foundation Classes, en standard for overføring av informasjon i byggeprosessen mellom de forskjellige dataprogrammene, enten det er tegneprogram eller beregningsprogram. I motsetning til proprietære (leverandøreide) dataformater, f.eks. AutoDesks DWG, er IFC er en åpen, veldokumentert internasjonal standard som alle kan bruke. IFC definerer bygningselementer (IFCbeam, IFCweall) og plassering, retning og koblinger mellom ulike bygningselementer. Videre sørger IFC for at data eksporteres som bygnings - elementer / -objekter og ikke som linjer og lag. IFC 2x2 og IFC 2x3 - beskriver versjon av IFC standarden som benyttes. 2x3 er dagens versjon som ble implementert i programvarer i Størsteparten av testingen i dette prosjekt har været i IFC 2x2. IFC-Prosjektet skiftet til 2x3 i vårensommeren 2007 da ny programvare var tilgjengelig. IFD International Framwork for Dictionaries. IFD er en internasjonal, entydig kodingsstandard for bygningskomponenter. En koding av for eksempel en gipsplate vil være bli forstått av alle applikasjoner og på alle språk. IFD er IFCs komponent ordbok. BIM står for Building Information Model, en 3D-tegningsmodell (ikke bokstavelig tegning) på en felles server som også inneholder all tenkelig informasjon og koding for et byggeprosjekt: produktinformasjon, U-verdier, brannklassifikasjon, informasjon man i byggeprosessen kan benytte til beregninger, bestillinger, vedlikehold osv. IDM Information Delivery Manual. Overordnet kan IDM beskrives som en beskrivelse av hvilke krav som stilles til modellen for at den kan brukes i en gitt prosess. IDM er inndelt i tre nivåer: 1. Process Maps - Beskriver flyten av informasjon på tverrs av applikasjoner (evt. disipliner) for å beskrive en process. 2. Exchange Requirements Beskriver krav til informasjon og struktur som en modell skal ha for å kunne formidle informasjon fra en applikasjon til en annen i en gitt prosess. 3. Functional Parts Beskriver behandling av information innen en applikasjon i en gitt prosess. buildingsmart, et «varemerke» for prosessen rundt BIM, som tilhører IAI, International Alliance for Interoperability, organisasjonen som står bak IFCstandarden. Den norske grenen er pådriver internasjonalt innenfor bruk og spredning av IFC. buildingsmart = BIM + IFC Property set Et sett av egenskaper som knyttes til objekter. For en vegg kan det for eksempel være brannmotstann, akustiske egenskaper, bærende egenskaper, yttereller innervegg etc. IFCProperty set Et property set, som viser til IFC-klassifikasjonen og som vil bli forstått av alle IFC-kombatible applikasjoner. Hvis IFCProperty set for en vegg (IFCWall) er Is external = True skal alle IFC-applikasjoner forstå at dette er en yttervegg. GUID Global Unique ID. En unik identifikasjonskode som knyttes til hver enkelt objekt. uten denne koden kan man ikke holde styr på historikken i et prosjekt. Berike en modell Når det tales om å berike en modell betyr det at der endres eller tillegges verdi til (deler av) modellen. Dette kan gjøres i den opprindelig modellapplikasjon eller i en annen applikasjon. 10 av 75

11 Objekt Er en funksjonell eller geometrisk avgrensning av byggeriets bestanddeler. Objekter kan være sammensatte. For eksempel kan et objekt være en vegg eller et dekke. Komponent Et objekt kan bestå av flere komponenter. En komponent tilsvarer et produkt i virkeligheten. For eksempel kan en komponent være en gipsplate i en lett vegg eller en bjelke i et dekke. Modelserver En felles server hvor disiplinenes delmodeller lagres, berikes og merges. Merge Englesk for å sammenføye. Delmodellene fra ulike etasjer innenfor disiplinen eller delmodeller fra de ulike disiplinene kan sammenføyes i ulike programvare for å få en samlet modell som beskriver hele bygget eller de deler som er ønsket, på tverrs av etasjer og/eller disiplinene. Modelviewer En applikasjon som tillater brukeren å se modellen. Man kan vanligvis gå rundt i modellen og peke på objektene og få frem de sett av egenskaper som er knyttet til de. Graden at realisme i den grafisk fremstilling varierer. Render Betyr å generere en visualisering som forutsetter en digital fremkalling for å få til tilstrekkelig god kvalitet på overflater og lyssetning. Walk-thru Å gå gjennom BIM en med en viewer Viewer Et program som viser BIM en geometrisk. Evt. med mulighet for å vise objekt egenskaper. Real-time Viser i sammenheng med dette prosjekt at en simulering eller visualisering foregår i realistisk tempo. En real-time walk-thru simulerer en gårtur gjennom bygget. ARK Arkitekt RIB Rådgivende Ingeniør Bygg RIV Rådgivende Ingeniør VVS RIE - Rådgivende Ingeniør Elektro DDS - Data Design System FEL - Forskrift om elektriske lavspenningsanlegg DLE - Det lokale Eltilsyn NELFO - Foreningen for EL og IT bedriftene TELFO - Tekniske Entreprenørers Landsforening NEK Norsk Elektroteknisk Komite NS 3420 Norsk Standard, Beskrivelsestekster for bygg, anlegg og installasjoner NS Norsk Standard, Prosjektdokumenter for bygg og anlegg NS Norsk Standard, Bygningsdelstabell NS Norsk Standard, Bygningstypetabell NS Norsk Standard, Elektronisk overføring av prosjektdata 11 av 75

12 IFC-prosjektet ønsker å takke Dette IFC prosjektet hadde ikke vært mulig uten en del velvillighet fra programvareleverandører for utlån av lisenser. ARK ønsker å takke NavisWorks, Sheffield for evalueringsversjon av NavisWorks Jetstream med alle moduler og Heikki Kulusjärvi i Solibri som har lånt oss lisens av Solibri Model Checker. Vi ønsker å takke NOIS for IFC-modul til Calcus i testperioden. RIV ønsker å takke Jan Nøtland i SWECO MEC for evalueringsversjon av NavisWorks Jetstream med Clash Detection, Heikki Kulusjärvi i Solibri som har lånt oss lisens av Solibri Model Checker og Ola Ødegård i Octaga som har lånt oss lisens for Octaga Modeller. Videre ønsker RIV å takke Progman og Nestor for bra oppfølging og samarbeid i forbindelse med å utvikle MagiCAD videre. Endvidere takk til DDS v/ Bjørn Stangeland som har bidratt i prosjektet med support og programvare samt været aktiv. 12 av 75

13 Delprosjekt 1 Sjekk av modellens konsistens og mengdeuttrekk Solibri Model Checker For å spare inn den tiden som var gått med til omprosjektering og revidert forprosjekt i ble prosjekteringstiden for detaljprosjektet kortet ned. Dette aktualiserte ønsket om å kunne trekke mengder mest mulig direkte ut av modellen. Da arkitekten sommeren 2004 begynte å forberede anbudsbeskrivelse var det derfor behov for en kvalitetsikring av mengdene som ble trukket ut fra modellen. Arkitekten valgte å benytte Solibri Modell Checker til å kontrollere modellens konsistens og til å gjøre alternative uttrekk av mengder for å kunne sammenligne tallene fra to forskjellige kilder. For å gjøre dette ble modellen eksportert fra ADT til IFC format for å kunne importeres i Solibri. I Solibri ble konsistenskontrollen utført som kollisjonskontroll, dvs. se om vegger lå over hverande og ville gi dublering av mengder. Det ble videre gjort et uttrekk av mengdene fra Solibri for å ha uttrekk fra to kilder. Kontrollen ga som resultat at det var lite dublering og mengdene i utrekkene fra ADT og Solibri varierte med mindre enn 1 %. Denne forskjellen avdekket at utsparinger ble håndtert litt forskjellig, det samme gjaldt tilpasninger der vegger i noen tilfeller skifter høyde. Med utgangspunkt i denne kontrollen ble det konkludert med i hovedsak å benytte mengdene fra uttrekkene i anbudsbeskrivelsene. Dette ble videreført ved avregning av mengder da kontrakten for behandlingsbygningen skulle avsluttes. Pga. forseringen av anbudsutsendingen var ikke detaljprosjektet kommet så langt at det var detaljert hvilke veggtyper som skulle benyttes hvor. Dette var imidlertid oppdatert fortløpende i modellen for å produsere tegninger. Ved avregningen kunne man derfor gjøre et nytt uttrekk hvor det kom fram mengder for nye veggtyper der dette var endret. Til tross for store endringer viste det seg at totalmengdene stemte godt overens, og dette førte totalt sett til en vesentlig forenkling av mengdeavregningen. Kjell Ivar Bakkmoen, Arkitektfirmaet C.F. Møller 13 av 75

14 Delprosjekt 2 Kobling mellom rom i tegning og rominformasjon i databaser (drofus) Kobling mellom rom i tegning og rominformasjon i databaser (drofus) I den løpende prosjekteringen er det kontinuerlig behov for å kunne sammenholde informasjon i tegningene og drofus. Dette har f.eks. vært formulert som ønsker om å kunne peke på et rom i tegningen og så få opp samme rommet i drofus eller omvendt, når man sitter med rommet oppe i drofus, kunne be om å få opp en tegning som viser hvor rommet befinner seg. I tillegg er det behov for avvikskontroll, om tegningene og drofus er konsistent. Dette vil være svært tidsbesparende i forhold til de manuelle kontroller som ellers må utføres. Dette gjelder tilsvarende for inventar og utstyr og tekniske installasjoner. Organisering gjennomføring Utføres som et mer ordinært kundestyrt utviklingsprosjekt hvor dataleverandører for henholdsvis integrasjonsløsning (EPM) og drofus (Nosyko) utvikler sine løsninger i samsvar med Nye Ahus' spesifikasjoner. ARK deltar for å kvalitetsikre sin datamodell og eksportere denne til det standardiserte formatet. Nettverket rundt IAI Forum Norge deltar i den grad det er nødvendig og naturlig med kompetanse. Om drofus i Nye AHUS Fra 2003 har drofus blitt benyttet i Nye AHUS prosjektet som et sentralt informasjonssystem for byggeprosjektet. Bruken av systemet har siden implementeringen blitt utvidet til å dekke nye anvendelsesområder. I dag benyttes systemet til å ta vare på følgende informasjon om prosjektet: Funksjonelle og tekniske krav til alle rom og alt utstyr i det nye sykehuset. Koordinering av brukermedvirkning fra AHUS vedrørende krav rom og utstyr. Dokumentasjon av endringer og beslutninger i prosjektet. Registrering av valgte overflatebehandlinger i alle rom. Innsamling av FDVU dokumentasjon for alle tekniske systemer og komponenter for alle faggrener og disipliner. Planlegging av anskaffelse og mottak av brukerutstyr. Rapportering og oppfølging av mangler ved ferdigbefaring. I drofus har krav til rom og utstyr fra byggherre, brukere og rådgivere blitt registrert allerede fra 2000 (gjennom et annet system som ble avløst av drofus i 2003). Dette har dannet grunnlaget for arbeidet til arkitekter og rådgivere i prosjektet. Etter hvert som det velges løsninger og prosjektet endrer seg, oppdateres kravene i databasen slik at man til slutt sitter med en oppdatert liste med krav og løsninger, samt en historikk over endringene som har skjedd. Behov for kobling av database og tegning. I den løpende prosjekteringen var det et kontinuerlig behov for å kunne sammenholde informasjon mellom tegningene og drofus. Slike sammenligninger kan dreie seg om: Kontroll av at alle planlagte funksjonelle arealer er medtatt i tegningene og at alle arealer som skal utgå er fjernet. At alt utstyret som det er krav til er plasser i tegningene. Med over 5000 rom og utstyrsartikler er dette et svært tidkrevende arbeid hvis det skal gjøres manuelt. 14 av 75

15 Det var også et ønske om tettere integrering mellom plandata i databasen og tegning slik at man f.eks. i møte med brukere enkelt kan navigere seg mellom krav og foreslått løsning. Integrasjon mellom drofus, EPM modelserver og Octaga viewer. I løpet av våren 2004 laget EPM og Nosyko en integrasjonsløsning mellom drofus og EPM modelserver der bygningsinformasjonsmodellen er lagret. Løsning gjorde at du fra databasen direkte kan visualisere ønskede rom (Figur 1). Man kan også peke på rom og utstyr i 3D-vieweren og få ut rapport fra drofus med krav til henholdsvis rom og utstyr. Figur 1 Avvikskontroll For å gjøre avvikskontroll var det nødvendig å sikre at rom og utstyr i modellen til C.F.Møller ble gjort IFC kompatible og identifiserbare. Drofus og CAD modellen må benytte felles identifikator for rom og utstyr, samt at man må ha en felles forståelse av hvor dette skal plasseres i modellen. Dette er spørsmål som en fremtidig IDM1 for programmering vil definere. I dette prosjektet ble det løst ved at?? Siden drofus inneholder mye utstyr som ikke tegnes, var det også nødvendig å gå gjennom alle artikkeltyper for å merke de som skal i modellen og dermed være med i en avvikskontroll. Nosyko laget deretter både en eksport funksjon som kunne eksportere rom og utstyr til IFC for videre innlesning i modelserver, og en import funksjon direkte fra modelserver. Det ble til slutt laget avviksrapport i form av direkte visualisering i drofus for hvorvidt rom eksisterte i modellen eller ikke (Figur 2). 1 Information Delivery Manual. Nosyko AS leder et internasjonalt arbeid med en IDM for programmering der målet er å definere arbeidsprosessen og krav til datautveksling (Exchange Requirements) for IFC kompatibel programvare for byggprogrammering og annen programvare som ønsker å kommunisere med slik programvare. 15 av 75

16 Differanser mellom plan og prosjektering Viser om rommet er tegnet eller ikke Informasjon fra tegning Figur 2 På samme mate ble det laget avvikskontroll for utstyr og direkte visualisering av forskjell mellom plan og modell i drofus (Figur 3). Dette ble benyttet for å sikre at mengder som skulle anskaffes via drofus var riktige. Viser at det finnes tegningsinformasjon for denne artikkelen Viser at utstyret er tegnet/ikke tegnet Figur 3 Tilsvarende rapporteringfunksjoner for avvikkontroll ble også laget i EPM s modelserver. Brukererfaring C.F: Møllers objektmodell er preget av at den har vært gjennom mange oppdateringer av programvaren og at Autodesk ADT ikke har hatt gode funksjoner for globale oppdateringer av objektene. Det har ført til at rom- og utstyrsobjektene i den fasen hvor det hadde vært mest aktuelt å kjøre slike tester, ikke hadde den ønskede og nødvendige ryddigheten som muliggjorde automatiske tester. De automatiske avvikskontrollene ble derfor ikke tatt i bruk utover testnivået. Det ble vurdert slik at oppryddingen i objektene ville kreve mer arbeid enn det som sto igjen av manuelle tester. Det er imidlertid åpenbart at dette har et stort potensiale og i nye prosjekter hvor det kan legges til rette for dette fra starten og med nye versjoner av programvaren hvor det er enkelt å oppdatere objektene vil dette bli tatt i ordinær bruk. 16 av 75

17 Erfaringer I tillegg til å gjennomføre de konkrete målsetningene med prosjektet, sammenkobling mellom modell og drofus og avvikskontroll, ga prosjektet verdifull erfaring med bruk av IFC i en programmeringsfase. Prosjektet viste at i byggeprosjekter som Nye AHUS vil det være svært verdifullt å kunne benytte IFC for kommunikasjon mellom krav fra byggherre/bruker og prosjekteringen. En komplett BIM er langt mer enn kun det visuelle og dette stiller krav til hvordan informasjon struktureres og lagres i modellen. Man løser ikke dette ved å benytte IFC alene. Informasjonsmengden i slike store prosjekter gjør også at man ikke kan holde oversikt kun gjennom CAD/DAK programvare, men man er avhengig av en separat kravmodell for å koordinere brukermedvirkning og holder oversikt over beslutninger i prosjektet. IFC standarden er foreløpig ikke god nok til å fange denne type opplysninger. Verktøy som drofus er med på å gjøre dette og dermed sikre gode BIM er. Siden gjennomføringen at dette delprosjektet har IFC støtte blitt et kjernesatsningsområde for drofus og det har blitt jobbet mye med å gjøre avviksrapportering og visualisering ved hjelp av EDM modelserver og Octaga 3D-viewer enklere og bedre. Håkon Clausen, Nosyko og Kjell Ivar Bakkmoen, Arkitektfirmaet C.F. Møller 17 av 75

18 Delprosjekt 3 Overføring av informasjon for arealforvaltning til FDVU systemer Ved idriftsetting av sykehuset er det behov for å overføre informasjon til FDVU systemer fra prosjektmaterialet, både fra tegninger og databaser. En videreutvikling av kobling mellom rom i tegning og rominformasjon i databaser, ville være å overføre denne informasjonen direkte til et eller flere FDVU system på IFC format. Dette burde forenkle oppstarting av driftsorganisasjonen på det nye sykehuset. Dette prosjektet vil både evaluere det som finnes av slike løsninger internasjonalt og forsøke å få med norske programvareleverandører til å utvikle sine programmer til å importere data på IFC format. Datafangst Informasjonene til FDV-dokumentasjonen skal følge produktet på dets vei inn i bygget. Vi tenker det som en videreføring av e-handel. Se prosessskissen for e-handel under avsnittet for e- handel under kapitlet ARK. Informasjonsflyeten tenkes slik: BIM EDI - Generisk produkt EDI - Spesifikt produkt EDI - Spesifikt produkt inkl. FDV Berikelse av BIM Figur 3.1 Informasjonsflyt ved berikelse av BIM med produktspesifikk informasjon ifm. elektronisk innkjøp. EDI en er den elektroniske melding om en vareforespørsel/-bestilling. Når produktet er kjøpt berikes den generiske produktinformasjon med informasjon om det konkrete produkt. Denne informasjon omfatter FDV informasjon (eller link til FDV). Denne informasjon går via en ny EDI tilbake til handelsportalen som beriker BIM en. Nå har BIM en fått produktspesifikk informasjon om det innkjøpte produktet som omfatter FDV (eller link til FDV). Uansett hvis BIM en berikes med reell FDV eller link til FDV informasjonen tenker vi at selve FDV-dokumentasjonen vil følge produktet sammen med EDI en tilbake til handelsportalen. Det forretningsmessige potensiale er at FDV-dokumentasjonen genereres automatisk i løpet av byggetiden istedet for at det blir en egen ressurskrevende aktivitet etter bygging. Visualisering Visualisering av geometri og egenskaper for vedlikeholder og leverandører. Visualisering av geometri handler om å vise objektenes geografiske plassering i bygget. Visualisering av egenskaper handler om å få informasjoner fra FDV dokumentasjon frem om egenskaper som ikke fremgår av det virkelige objektet selv. Det forretningsmessige potensial er at informasjon blir mye enklere tilgjengelig for de som skal drifte. Det er stort potensial for reduksjon av feil antakelser og for å overføre prosjektert informasjon om bygget. Dermed krever systemet ikke ekspertkjenneskap til bygget. Drifting vil i høyere grad kunne out-sources, hvor det kan være hensiktsmessig. Steen Sunesen, Arkitektfirmaet C.F. Møller 18 av 75

19 Delprosjekt 4 Innledning Frontbygningen som testcase Frontbygningen er et av bygningsavsnittene på sykehuset Nye Ahus. Bygningens funksjon er resepsjon, stort auditorium og kantine med kjøkken. Frontbygningen er et lite bygg på ca m 2, men den har relativt komplisert geometri som ble vurdert som interessant for å teste modellering og programmer for beregning av for eksempel statikk, elektro, kalkyle, energiberegning. Det ble derfor besluttet å bruke frontbygningen som testcase i en mer omfattende utprøving. Formål Formået er å få erfaring med at arbeide med modell-server og IFC-kompatibel programvare. Prosjektets delaktiviteter er valgt for å simulere bruk av BIM i verdikjeden fra utvikling i designfasen over innkjøp og bygging til generering av FDV-dokumentasjon. Perspektivene ved at jobbe med sømløs dataflyt fra felles BIM er mange og interessante. Sentralt i IFC tankegangen er at en BIM utviklet av alle de prosjekterende disipliner skal sikre gjenbruk av informasjoner og minimere manglende og feil koordinering mellom disiplinene og aktørene. Dette IFC-prosjekt skal forsøke å ta i bruk eksisterende IFC-kombatibel programvare for å teste ut automatisering av ulike funksjoner i verdikjeden. Det er viktig at det tenkes riktig ift. IFC. Prosjektet tilstreber ikke funksjonalitet for enhver pris. Prosjektet skal tydeliggjøre utfordringer i sømløs dataflyt i verdikjeden. Derfor må prosjektspesifikke løsninger mest mulig unngås. Parallell prosess ift. byggeprosjektet I Nye Ahus benyttet Prosjekteringsgruppen Autocad eller dwg kompatibel programvare. Dermed er overføringsproblemene for den grafiske delen av tegningene i hovedsak unngått. Overføring av mer omfattende intelligens i tegningene knyttet til objekter, blir imidlertid vanskeliggjort av at de mer fagspesifikke applikasjonene og overbygningene til Autocad ikke kommuniserer like godt mellom hverandre. Derfor har IFC-prosjektet og prosjektorganisasjonen generelt søkt å dra nytte av IFC som felles overføringsstandard i det omfang hvor fagapplikasjonene har kunnet skrive til og lese fra standarden. Byggeprosjektet var kommet for langt til at det var hensiktsmessig å forutsette at IFC skulle være den eneste overføringsstandard. IFC var også for ny og ukjent ved IFC-prosjektets oppstart til at dette kunne være hensiktsmessig i et så stort prosjekt. Det er imidlertid enkelte områder hvor det har vært en åpenbar direkte nytteeffekt ved bruk av standarden. Deltakerne Fra IFC-prosjektets start ville man ha hele verdikjeden representert i utprøvingen. Arkitekt, konsulenter, byggherren og entreprenørene skal hver især bidra med kompetanse fra deres fagområde så utprøvingen fikk så faglig bredt perspektiv som mulig. I den reelle utprøving har det dog vært arkitekt og konsulenter som har vært pådrivere og utført det egentlige arbeidet. Byggherren og deler av entreprnør har deltatt som observatør. Flertallet av entreprenørene har ikke kunne prioritere dette arbeidet ift. byggeprosjektet. Det daglige modelleringsog utprøvingsarbeidet har derfor vært utført av en mindre gruppe, primært arkitekt og rådgivere samt de involverte programvare- og serviceleverandører. Den større gruppe har så vært informert om prosjektets utvikling i løpet av fire seminarer i prosjektets løpstid. Entreprenørenes manglende deltakels i den reelle utprøving har gjort at de delaktiviteter som omfatter anskaffelse og bygging har måttet legge forutsettninger til grunn som ikke nødvendigvis reflekterer virkeligheten. For eksempel benytter 4D byggesimulering fiktive planer for utbygging og den digitale representasjon av byggeprosessene er ikke verifisert med entreprenør. Av samme grunn har det ifm. 19 av 75

20 avprøvning av 4D- og kalkyle-verktøy vært fokusert på utvikling av metode og ikke nødvendigvis fullskalatest. Steen Sunesen, Arkitektfirmaet C.F. Møller Prosjektets organisasjon Byggherre Nye Ahus Arkitekt Arkitektfirmaet C.F. Møller - ARK Konsulenter Multiconsult - RIB Sweco Grøner - RIV Cowi/Hjellnes Cowi - RIE Entreprenører Heimdal Entreprenør Hovedentreprenør Oras Rør YIT Luft Siemens El og kabling Gunnar Karlsen Automatikk Telenor Business IKT Deltagere fra bransjen EBA NELFO Norges Forskningsråd Boligprodusentenes Forening NOBB Programvareleverandører Solibri Modellsjekk NavisWorks Modellsjekk NavisWorks Visualisering/ NavisWorks 4D byggesimulering DDS Modelviewer DDS Elektropartner Modellering elektro Calcus Kalkyle IDA Energiberegning FEM-Design Statikkberegning Nosyko drofus Rom- og utstyrsdatabase FebDok Elektro beregning ElData Elektro kalkyle/anskaffelse EPM Technology Modelserver Microstation Modellering RIB MagiCAD Modellering RIV MagiCAD Modellering RIE Autodesk ADT Modellering ARK Riuska Energiberegning Inopso IFC-import og eksport applikasjon til Autodesk ADT 20 av 75

21 ARK Innledning Arkitektens rolle i IFC-prosjektets utprøving Ift. utprøving i IFC-prosjektet ser vi bort fra, at det er ARK som har initiert og ledet IFC-prosjektet. I det følgende ser vi bare på vår rolle i prosjekterings- og oppfølgingssammenheng. ARK har tradisjonelt sett en koordinerende rolle, hvor vi skal sikre helheten og kvaliteten på det ferdige bygget. Denne rolle lever vi opp til ved hjelp av en rekke ulike prosesser. I IFC-prosjektets delprosjekt 4 har vi sett på noen av disse og hvordan implementering av IFC-BIM verktøy kan automatisere og effektivisere noen av disse. Prosessene som vi har fokusert på i IFC-prosjektet er: Modellering Koordinering av geometri med øvrige disipliner - Kollisjonskontroll Visualisering i prosess, for bruker og entreprenør 4D byggesimulering Kalkyle (og beskrivelse) Modellering og property sets Arkitekt har brukt Autodesk sin Architectural desktop (ADT) som modell konfigurator siden prosjekteringsoppstart. Det er skiftet versjon iht. programvarens utvikling. Oppgradering av versjon har medført meget ekstra arbeid i form av oppdatering og utskifting av objekter samt remodellering av hele delmodeller (delfiler). Derfor blir versjon oppdatering innen et prosjekt vurdert ift. forventet nytteverdi. Denne vurdering medførte et stopp for oppgradering ved ADT sin versjon 2006 som ble implementert i prosjektet i år Siden Autodesk Architectural 2008 ble tilgjengelig med IFC2x3 eksport/import har ARK brukt dette programmet parallelt med ADT Det arbeides derfor i byggeprosjektet fortsatt på ADT 2006 og i IFC-prosjektet i Architectural Wireframe av komplett ARK modell. 21 av 75

22 Modellering i ADT Modellene som beskriver den arkitektfaglige delen av byggeriet består av relativt få ulike hovedkomponenter. Vegger, søyler, dører, vinduer, curtain-walls og dekker. Perspektiv av ARKs modell plan 02 Det er flere ulike typer av hver av disse hovedkomponenter. Av praktiske årsaker ble alle etasjer delt på to filer: plan og konstruksjon. Plan inneholder romobjekter, innervegger og de objekter som sitter i veggene (dører, vinduer og utsparinger) samt utstyr. Konstruksjon inneholder yttervegger (klimaveggene) og bærende konstruksjoner. Grunnen til denne deling er logistiske ift. tilgjengelighet til filer. Kledninger på yttervegger og curtain-walls som strekker seg over flere etasje er samlet på en egen fil som omfatter alle etasjer. Perspektiv av ARKs modell kledningsfil over alle etasjer Det har i tillegg vært nødvendig å lage egne filer med dekker, tak, spesielle himlingskomponenter for å kunne få en full digital representasjon av bygget og samtidig kunne jobbe med tradisjonell tegningsgenerering fra modell. 22 av 75

23 Objekter i ADT Redigering av objektene er rimelig enkel å lage nye objekter forutsetter litt mer kunnskap for eksempel å modellere sin egne dørtyper med spesiell geometri krever litt trening og tid. Men brukertersklen er forholdsvis lav. Objektene fungerer parametrisk innen komponenten. Settes en dør i en vegg lages det automatisk en utsparing for døren. Reglen for denne utsparing skal man selv definere for å være sikker på at man får riktig toleranse i utsparing. Regneregler for dører avviker også fra land til land. Så standard oppsettet fra ADT kan ikke brukes ukritisk. Enkel parametri innenfor objekter. For eksempel setter dører seg i vegger og genererer egne utsparinger iht. definert regelsett. Arkitektmodellen består av rundt 500 bygningsobjekter. Det er en relativt liten modell. Men byggets komplekse geometri gjør at det er mange spesialtilpassede avslutninger og hjørner. En stor fordel ved bruk av objektmodellering er at ARK kan generere automatiske oppriss av rom til romskjema direkte fra modellen. Dette har spart tid og har været kvalitetsikrende. Endring av modellens objekter er som sagt relativ enkelt og vedlikehold av modellens vegger, dører og vinduer fungerer bra. Men endring av objekter som støter mot flere andre objekter kan være tidskrevende. Så generering av fasader og især hovedsnitt fra modellen har vært så tidskrevende at oppfølging av snitt har vært en flaskehals. 23 av 75

24 Propersty sets Alle komponenter har fått knyttet egenskaper til seg. ARK har uviklet egne IFC-property sets som sikrer at modellens egenskaper blir fullt tilgjengelig for andre IFC-applikasjoner. Egenskapene knyttes til objektene på style-nivå. Det vil si at egenskapene ikke knyttes til hver enkelt objekt med kan knyttes til og redigeres for alle objekter av samme type. Egenskaper kan også legges til og redigeres på objekt-nivå hvis det er enkelte objekter som avviker fra den generelle types. Objekt med property sets. Venstre: typebetegnelse, geometri og plassering. Høyre: IFC-propeties. Eksport og import IFC 2x2 ADT 2006 hadde ikke integrert en egen applikasjon til eksport og import av IFC-filer. Denne applikasjon ble innkjøpt fra en tysk leverandør Inopso. Ved eksport med bruk av Inopso skal modellen først initieres. Her får alle objekter en GUID (Global Unique ID). Deretter kan modellen eksporteres. IFC-modeller er relativt mye større (fil-størrelse) enn for eksempel dwg filer. Men de er også komprimerbare med for eksempel zip. Enkelte komponenter genererer større filer enn andre. I ADT er det dekker og MVB er som gjør filene store. Import av IFC-filer er en viktig del av prosjekteringsarbeidet. Man har bruk for å endre på filene sine og man må gjøre det samtidig som man ser dem i sammeheng med de andre disiplinenes filer. Import fungerer i prinsippet bra. Det er dog ikke modellene fra alle applikasjoner som blir like lesbare. Det har primært vært problemer med geometrien. IFC 2x2-filer fra de ulike applikasjonene fungerte ikke uproblematisk seg imellom. Våres største problem med eksport fra Imopso var at IFC-strukturen ikke var komplett. Eksportfunksjonen genererte ikke IFCStorey (etasje). Delmodellen beskriver dermed ikke sin etasje. IFC 2x3 Archtectural 2008 har sin egen integrerte IFC eksport/import funksjon. De fleste store programvare leverandører har fått sertifisert sine applikasjoner til IFC 2x3 i en prosess i våren Testingen som gikk forut for sertifiseringen bestod primært i å teste geometrien på modeller som ble utvekslet på tvers av alle applikasjoner. Dermed er eksport og import IFC 2x3 vesentlig forbedret ift. IFC 2x2. Archtectural 2008 sin måte å bygge et prosjekt opp på i Project Navigator minner om hierarkiet i IFCfilen. Det lages et prosjekt hvor de ulike delmodeller (filer) knyttes til ulike bygg (IFCBuilding) og høyder (IFCStorey). Denne struktur i Architectural gjør at IFC-filene blir riktig. 24 av 75

25 Import Import er en vesentlig del av å jobbe med IFC-filer. Med import vises det til at IFC-filer generert fra for eksempel et modelleringsprogram kan importeres til det gjeldende format i en applikasjon. Dette er viktig fordi det ikke utelukkende er ens egne IFC-data som man vil fortsette å modellere på. Det kan for eksempel være at man har fått beriket modellen sin fra en annen applikasjon og det er denne modell som det skal jobbes videre med i prosjektet. Geometri og properties bevares ved import av IFC 2x3 i Architectural 2008 Import fungerer bra for filer generert av ADT/Architectural og MagiCAD. Filer fra Mircrostation hadde feil på runde former i IFC 2x2. I IFC2x3 format var dette problem løst. Steen Sunesen, Arkitektfirmaet C.F. Møller 25 av 75

26 Model server EPM Technology Modelserver minner på overflaten om et prosjekt-web eller hotell. Forskjellen er at modell-serveren jobber med objekter og ikke filer. Model serveren kan merge delmodeller fra ulike delmodeller. Log-in Tilgangen til serveren er internettbasert og administreres via vanlig brukernavn/passord. Bruker ID brukes til å identifisere bruker og tildele avtalte rettigheter til modellene. Brukerflaten er en såkaldt serverklient, som gir oversikt over programmets funksjoner. Upload/download Upload av filer vil si at man legger sine modeller inn på serveren. Hver bruker/fag tildeles et repository (fag-/ansvarsområde) som er det område man uploader sine filer til. Arkitekt har for eksempel et repository som hedder ARK. Arkitekt har bare mulighet for å uploade sine modeller hertil. Ved upload skal man velge hvilken versjon av IFC som silen skal identifiseres som (schema). Denne funksjon kan være litt forvirrende fordi utviklingen går fort og det derfor ligger mange ulike forslag og bare en fungerer riktig. Dialogboks for å uploade delmodeller i serverklienten Ved upload er det vanlig med en del feilmeldinger, som ikke alltid betyr at noe er feil sett fra brukers synspunkt. Disse er et potensial til forbedring. Generelt er det ganske enkelt å bruke funksjonen, når man har blitt vant til den. Download er funksjonen hvor man kan laste ned modeller som filer fra serveren. Filene kan være delmodeller slik som de er lagt uploaded, de kan være beriket med for eksempel IFD koder og de kan være merget delmodeller som gir mer komplette modeller, for eksempel flere etasjer, flere fag etc. Filformatet kan være IFC eller IFC-XML. Download fungerer veldig brukervennlig og feilfritt og er en god måte å utveksle modeller på. 26 av 75

27 Sjekk ut/inn Utsjekking av en modell fungerer på noenlunde samme måten som download. Utsjekking gjør man når man skal redigere modellen som er uploaded. Det er derfor bare de som har skriverettigheter til delmodellen som kan sjekke en modell ut. Når en modell sjekkes ut låses den, så den ikke kan sjekkes ut av andre som også måtte ha rettighet til det. Når en modell er redigert og sjekkes inn igjen sjekker serveren hva som har skjedd. Alle endrede objekter markeres med ulike fargekoder som forteller om objektet er redigert, slettet eller nytt. Inn- og utsjekking skjer i både IFC og IFC-XML format. Objektene identifiseres utifra deres GUID. Serveren registrerer og dokumenterer også hvem som har sjekket ut/inn filer og dermed hvem som har gjort hvilke endringer på objektene. Denne logg-funksjon er et veldig bra verktøy til å automatisere dokumentasjonen av historikken. Ut- og innsjekking fungere bra. Merge Merging betyr at delmodeller sammenføyes. Det er i modelserveren at man setter etasjene sammen, og hvor de ulike disipliners delmodeller samles. Flere av de prosjekterendes programvarer kan selv merge filer. Men når byggherren, brukeren eller entreprenøren trenger en helhetlig modell er det via lesetilgang til serverens felles repository. Eksempel på ARK sine delmodeller som de er strukturert i serverklienten Merging skjer i et eget repository, som flere brukere eller bare en administrator kan ha tilgang til. Merging har krevd en del jobb for EPM technologies. IFC-filene som de ulike disipliner har uploaded har ikke umiddelbart kunne merges uten en del tilpasninger. Det vanligste problemet er feil håndtering av GUID i CAD applikasjonene ved at det genererers ny GUID på allerede eksisterende objekter ved eksport. Det er også ofte problemer med koordinatsystemer og skallering av modellene. Det kommer stadig forbedringer på dette fra applikasjonsleverandørene og i modellserven, men noe manuelt arbeid må fortsatt påregnes. 27 av 75

28 Sortering Serverklienten er et bra verktøy til å sorterer i objektene i modellene. For eksempel har vi i sammenheng med e-handel skulle downloade IFC-XML av en bestemt type vegg. Denne vegg har vi kunne sortere frem ut ifra typen. Eksempel på sortering av objekter i serverklienten Sorteringsfunksjonen fungerer bra, og er et viktig redskap når man skal downloade filer av utvalgte typer objekter. For eksempel lettvegger ifm. e-handel. IFD-koding I samarbeid med Standard Norge har EPM Technologies utviklet en link til Standard Norge sitt IFDbibliotekt. Dette gir mulighet for å berike objektene med IFD-koder i serverklienten. Ved avslutningen av IFC-prosjektet skulle man berike hver enkelt objekt hver for seg. Og det kan bare legges en IFDkode pr. objekt. Dette er ikke tilstrekkelig for objekter som består av flere komponenter eller har flere beskrivende egenskaper. EPM jobber på å utvide funksjonen. I IFC-prosjektet har vi bare avprøvd denne funksjon i samarbeid med EPM Technologies. Standard Norge gav ikke IFC-prosjektet egne tilgangslisenser for utprøving. 28 av 75

29 Octaga IFC-viewer Octaga og EPM Technologies har i samarbeid gjort det mulig å åpne Octaga sin viewer inne i serverklienten. Det gjør det mulig å få en enkel grafisk representasjon av den aktuelle modell og å få highlightet de objekter som man har valgt. Eksempel på visualisering av vegger og highlihgting av hva som er valg ut i serverklienten Steen Sunesen, Arkitektfirmaet C.F. Møller og Gudbrand Skarseth, EPM Technology 29 av 75

30 Kollisjonskontroll Kollisjonskontroll er norsk for clash detection. Dette verktøy er omfattende beskrevet av RIV i rapportens delprosjekt 1. ARK har også utprøvet kollisjonskontroll med Solibri Model Checker (SMC). Dels ifm. kollisjoner av bygningskomponenter. Og dels som kvalitetsikringsverktøy ifm. mengdeberegning til beskrivelse. Det er primært kollisjonskontrollen som vi har satset på i dette prosjekt og det har vist seg å være et meget effektivt og kvalitetskapende verktøy. En stor del av de kostnadsdrivende og forsinkende feil i bygging skyldes mangledne koordinering mellom disiplinenes modell (arbeidstegninger). SMC har vist seg å være et enkelt og effektivt verktøy til å redusere slike feil. SMC leser IFC-geometri og egenskaper veldig bra og programmet fungerer med meget få feil. De feil som vi har erfart er generelle krasj som er sjeldne og at vieweren ikke fungerer sammen men alle skjerm-drivere. Ingen av disse feil kan tilsies konkluderende å være feil i SMC. Vieweren i SMC gir med nåværende versjoner (4.1) en abstrakt men god representasjon av BIM en. SMC gir også mulighet for å teste bygget for fluktveier og universiell utforming. Disse har vi utprøvet på test-nivå. Byggets geomtri og beskjedne størrelse gjorde sistnevnte test lite effektive. 30 av 75

31 Visualisering Visualisering omfatter flere perspektiver. Generelt handler det om å få en grafisk representasjon av BIM en så man kan danne seg et sammenhengende bilde. Hovedsakelig kan visualisering inndeles i to ulike funksjoner. Realistisk representasjon og modell viewer. Realistisk visualisering for prosjekterende arkitekt og brukere Formålet er å lage en representasjon som viser hvordan det ferdig bygg vil ta seg ut. Representasjonen kan være fotorealistisk eller det kan være et visst nivå av abstraksjon. Det finnes etter hvert flere programmer som kan vise modellene med en god grafiks representasjon og hvor det er mulig å styre materialer og lyssetning. ADT 2006 programvaren kommer sammen med 3D studio VIZ og Architectural 2008 har integrert grafisk motor fra VIZ. Så begge versjoner gir mulighet for å lage grafiske visualiseringer direkte fra modell. Hvis man ønsker å visualisere felles BIM med bidrag fra andre disipliner kan disse importeres i IFC format. Muligheten for rendering er gode. Disse egner seg især når det skal lages illustrasjoner som skal selge eller markedsføre den arkitektonsike visjon. Arbeidet er tidskrevende og resultatet er stillbilder. Bildet av frontbygningen på forsiden av rapporten er generert slik og med etterbehandling i Photoshop. NavisWorks Jetstream Roamer I det daglige bruk er det ikke tid eller ressurser til å lage et så omfattende arbeide for å få til noen få bilder av bygget som beskrevet ovenfor. Vi har bruk for å kunne se og vise modellen slik som den er. Det skal ikke brueks tid på å vente på renderinger og visningen skal være animert live. Vi skal med andre ord ha mulighet for å gå rundt i bygget (walk-thru ) og se det nok så fotorealistisk representert. Prosjektet har ikke hatt som mål å skulle prøve ut alle programvarer på markedet. Så det er sikkert flere gode programmer som kunne nevnes her. Et opplagt valg for oss var å bruke samme program som vi har brukt til å jobbe med kollisjonskontroll og 4D-byggesimulasjon, NavisWorks Jetstream. Det geniale ved dette program er at det er en basisapplikasjon med overbyggingsmoduler. Basisapplikasjonen er Roameren som er en avansert viewer. Vieweren tillater walk-thru og har flere interessante funksjoner. Her nevnes noen favoritter. Man kan gå rundt i bygget med en 3. person foran seg. Personen gir god fornemmelse for skala. 3. personen gir mulighet for å teste om dører og korridorer har minimum bredde og høyde. Man kan kommentere objekter eller steder i bygget. Kommentarene vil synes uansett hvor du er i bygget. Det er et godt verktøy til å utveksle informasjon mellom prosjekterende (såfremt alle har lisens). Man kan lage dynamiske snitt i alle tre plan (plan og to vertikale), så man kan se modellen fra alle sider. Den grafiske representasjon av snittet er ikke helt tilfredsstillende. Solide komponenter ser for eksempel ikke solide ut når det snittes i de. Men funksjonen gir veldig god oversikt. NavisWorks Jetstream Presenter En av tilleggsmodulene er Presenter. Denne applikasjon gir mulighet for å legge til materialer og kontrollere lyssetning. Disse egenskaper bevares i noen grad ved en vanlig walk-thru. Det er også mulighet for å lage renederinger av bedre kvalitet. Disse genereres som enkelt bilder og gir ikke mulighet for walk-thru. Det kan også skapes animasjoner av walk-thru eller definerte kameraføringer som kan eksporteres til flere ulike formater og i ulike kvaliteter. Disse kan ses på vanlige medieavspillere som for eksempel Windows Media PLayer eller Quick Time. Disse gjør visualiseringer alment tilgjengelige. Men de er ikke interaktive. Programvaren er meget brukervennlig. Det forutsettes ikke spesiell innsikt i renderingsteknikker eller stor erfaring for å få til gode representasjoner. Justeringsmulighetene er likevel mange og begrenser ikke de som vil fordype seg i mer avansert bildebehandling. Eneste minus er programvarens pris. Programmet er ikke så dyrt for de som likevel skal ha modulene for 4D-byggesimulering eller kollisjonskontoll. Men for visualiseringdelen kan det bli mye å skulle ha lisenser for alle som skal kunne ha mulighet for walk-thrus. 31 av 75

32 Center of vizualization - Chalmers Prosjektet ble etter en presentasjon ved Chalmers tekniske høgskolas Center of Visualization i regi av Göteborg Business Region Göteborg AB bedt om å være del av et prøveprosjekt innenfor visualisering. Dette arbeidet er ikke kommet ordentlig i gang, men vil bestå i at modellen vil bli prøvet ut i egne visualiseringsverktøy soem er basert på spillteknologi. Grafisk oversikt over BIM med objektegenskaper i arbeide med BIM. DDS IFC Viewer DDS lagt en IFC-viewer tilgjengelig gratis på nettet. Brukerflaten krever til øvelse. Ikke fordi den er vanskelig å bruke, men fordi deres ikoner og måte å bevege seg rundt i modellen ikke minner så mye om andre tilsvarende viewere. IFC-vieweren til DDS er bare en liten del av virksomhetens utvalg av programvare. De er langt fremme ift. bruk av IFC. IFC-vieweren kan for eksempel kombineres med modul for å berike objekter med IFD-koder. Veldig kult. I dette prosjekt har vi ikke funnet anledning til å benytte flere av programvaren deres enn IFCvieweren og Elektropartner (se avsnittet RIV). Octaga Octaga sin viewer kan brukes som selvstendig IFC-viewer eller integrert med EPM Technology sin modelserver. I dette prosjektet er sistnevnte utprøvet. Viser til kapitlet Modell server EPM Technology. 32 av 75

33 Kalkyle IFC-prosjektet har utarbeidet en kalkyle for frontbygningen. Kalkyleverktøyet Calcus fra NOIS har et IFC-interface som tillater import av IFC-filer. Kalkylen er tenkt å skulle etableres tidlig i byggeprosjektet, så det kontinuerlig holdes kontroll med de samlet kostnader. IFC-prosjektets del 4 kom i gang mens byggeprosjektet var kontrahert og bygging var i gang. Derfor har et været fokusert på IFC funksjonalitet. IFC-modulet er en ekstra applikasjon, som ikke følger med standard programvaren. Import av IFC-BIM og visualisering Oppstart av prosjekt gjøres enklest ved å finne en mal som er mest mulig representativ for byggets type eller kostnadsnivå. Eksempel på hvordan veiviseren utfylles Malen fylles ut med grunnleggende data i en veiviser, om byggets størrelse og kostnadsdrivende fasiliteter. Når malen er utfylt slettes data for post 2.; dvs. alle data som er rene byggedata. Grunnen til dette er at disse data skal vi legge inn fra IFC-BIM en. Import av IFC-filen er uproblematisk og det finnes en viewer som gir god oversikt og byggets geometri. Eksempel på hvordan etasjene U1 og 01og02 er generert fra veiviseren mens delprosjektene 00, 01,02,U1 og U2 er generert fra BIM 33 av 75

34 Eksempel på model-viewer Vieweren brukes til å holde oversikt over hvilke objekter som elementlinjene i Calcus det vises til i modellen og hvilke objekter som er priset og hvilke som mangler prising. Vieweren er dog ikke interaktiv. Objektene i vieweren kan altså ikke velges ved å peke på dem. Valg av elementer for prising Calcus bruker begrepet element for det vi ellers i denne rapport kaller objekt. Et objekt som f.eks. en vegg kaldes mao. element. Et element kan bestå av en eller flere komponenter. Disse kalles prislinjer i Calcus. Eksempel på prosjektspesifikk elementregister 34 av 75

35 Prosjektspesifikke element- og prisregistre I IFC-prosjektet er det opprettet prosjektspesifikke element og prisregistre for frontbygningen. Grunnen til å lage egne prisregistre er at vi i NOIS sitt standard prisregister ikke kan finne representative priser på alle komponenter. Derfor lager vi våre egne ut i fra erfaring og forespørsel. Eksempel på prosjektspesifikk prisregister Grunnen til å lage egne elementregistre er dels, at det ikke er alle elementer i frontbygget som vi finner representert i standardregistret. Dels er det fordi vi ved å lage egne registre, hvor elementene heter det samme som objekttypene i modellen får automatisk priset objektene. Når et elementregister heter det samme som et objekt blir det automatisk identifisert og priset. Dermed spares en del manuell arbeid. Byggekostnad og prosjektkostnad Priser på byggekostnad fra BIM kombinert med erfaringtall fra andre prosjekter på øvrige poster for å få en samlet kostnad på prosjektet. 35 av 75

36 Steen Sunesen, Arkitektfirmaet C.F. Møller 36 av 75

37 4D NavisWorks Jetstream Timeliner Innledning 4D er et begrep som viser til objektmodellens tre dimensjoner + den fjerde tidsdimensjon. I BIM verdenen er det en måte å simulere en virtuell bygging av den digitale modellen. Dette gjøres i spesiell programvare som kan linke en tidsplan for byggingen med de respektive objekter i den relevante digitale modell. I utprøvingen av 4D visualisering i IFC-prosjektet har vi brukt NavisWorks Jetstream Timeliner. Timelineren er en del av Jetstream programpakken. Så for import og visualisering av IFC-filer vises til ovenstående kapitel Visualisering - NavisWorks Jetstream Roamer og Presenter. Vi har inndelt utprøvingen i tre nivåer. Alle nivåer forutsetter at det importeres/appendes/merges relevante BIM. I dette prosjekt bruker vi naturligvis IFC-format. 4D - Nivå 1 Den enkleste måten å simulere byggeprosessen på er å kople objektene i den importerte BIM med en tidsplan som lages i Timelinerens egen Task Manager (oppgave kontroll). Task Manageren er hvor arbeidsoppgavene vises med navn, tid planlagt, tid avvik, objekttype og hvilke objekter som er linket til de enkelte tasks. Eksempel på BIM i Timeliner Objekttype viser i dette tilfelle til om objektene er konstruksjons-, midertidige eller nedrivningsobjekter. Det har betydning for hvordan objketene skal vises. Denne informasjon skal legges til manuelt i Timelineren fordi det ikke er en IFC egenskap som objektene kan berikes med før import i Timeliner. 37 av 75

38 Valg av objekter for kopling kan gjøres ved visuelt å peke på de ønskede objekter eller å finne de frem etter kjente egenskaper, typer, etasje etc. Vi fant i dette prosjekt ut at det var hensiktsmessig å samle objekter som ble omfattet av de enkelte task i sett av valg (selection sets). Selections sets velges i NW Jetstream Når det er definert en task med et gitt tidsforløp kobles den enkelt til disse selection sets. Simuleringsverktøyet fungerer som en tegnefilm, hvor det ved prosjektets begynnelse ikke er noen konstruksjons- eller midlertidige objekter. Hvis det i et prosjekt finnes nedrivningsobjekter vil disse vises fra start. I dette prosjekt kunne det f.eks. være terrenget som ble endret i løpet av byggingen. I dette prosjekt er det dog ikke arbeidet med terrengmodell. Innstillingerne på simuleringsverktøyet er i den gitte programvare ganske omfattende. Det vesentligste er at man angir hvilket tidsforløp som skal visualiseres, hvor mange intervaller forløpet skal deles i og hvor lenge de skal vare, hvordan objekter vises (farge) før, under og etter aktiviteten pågår og om/hvordan modellen skal bevege seg mens simuleringen foregår. 4D - Nivå 2 Dette nivå bygger videre på nivå 1. Forskjellen er at tidsplanen ikke lages i Jetstream men at man importerer en tidsplan fra et planleggingsverktøy. I dette tilfellet bruker vi Microsoft Project. Tidsplan i MS Project 38 av 75

39 Tidsplanen fra MS Project importert og synkronisert med tasks (oppgaver) i NW Timeliner Programvaren tillater ulike metoder for hvordan vi lager automatisk kobling med lignende objekter og aktiviteter. I praksis er det ikke alle muligheter som er like gode. Det gis mulighet for å kople aktiviteter med enten objektenes lag, type eller selection sets. Alle automatiserte koplinger forutsetter at programvaren kan identifisere like navn på aktiviteten og de tidligere nevnte valgmuligheter for objektene. Kobling mot lag problematisk pga at vi bruker lag iht. NS. Og lag er mye mer generelle enn en seleksjon trenger. Typer Typer er generelle og er ikke stedsspesifikke i konstruksjonen. Selections set Virker som den riktige måten å jobbe på for oss. Tillater seleksjon på tverrs av lag og type samt full kontroll på hvilke objekter som velges. Dermed blir seleksjon full automatisert. Selection set er en manuell prosess. 39 av 75

40 4D - Nivå 3 Simulering av arbeidslogistikk. Kollisjonskontroll med ulike fags tilgang til arbeidsområder. Nivå 3 bruker samme metoder som nivå 1 og 2. Men adskiller seg ved å simulere arbeidsplassen som tegnes rundt byggeobjektene. Arbeidsplasser kan kollisjonskontrolleres mot hverandre og/eller mot bygningsobjekter. Øvelsen gikk ut på å prøve ut om verktøyet kunne avdekke clash i tidsplanleggingen i forhold til de ulike arbeidsprosessene på byggeplass. Vi benyttet Autocad til å lage volumelementer som gav en teoretisk illustrasjon på det arbeidsområdet som kreves for å utføre en arbeidsoperasjon i et bestemt rom, eller et forløp av flere rom. Filen ble kopiert i 4 eksemplarer og volumene i de forskjellige filene fikk ulik farge for kunne skille dem fra hverandre. Filene representerte arbeidsprosessene: Overflate gulv Himling Oppbygging av innervegger Overflate innervegger Bildene illustrerer volumet som opptas av de ulike fagene når de bygger/utfører en oppgave, for eksempel å legge gulv, å bygge innervegger etc. Filene ble trukket inn i Navis Works. For å differensiere utprøvingen delte vi områdearbeidsområdet inn i 3 soner. Ved hjelp av sellection sets dannet soner og arbeidsprosesser 12 kombinasjoner som det var mulig å jobbe videre med i forhold til timeliner. Vi bygget opp en fiktiv planlagt arbeidsforløp i timeliner. Her la vi inn tidsmessig overlapp for å fremprovosere clash mellom arbeidsprosessene. Forventer resultat er at testen skal gi 40 av 75

41 beskjed om clash i tidsrommet 26/11-30/11 for vegger i sone1, 6/12 07/12 for vegger i sone 3 og 10/12-14/12 for gulv/himling i sone 2. Timeliner ble linket opp mot Navis Works. Ved hjelp av sellection sets ble operasjonene i de forskjellige sonene satt opp mot hverandre. Resultatet er ustabilt. Det avdekkes 20 clash i sone 3 i tidsrommet Sonene 1 og 2 får ikke det forventede resultatet, ved at det ikke avdekkes clash i det hele tatt. Sone 3 består av 6 elementer. Rapporten ser ut til å rapportere den samme clash 2 ganger. Illustrasjonen av clash -et er i rapporten ikke presis da det er vanskelig å grafisk fremstille situasjonen. Det interessante i rapporten er datoen det oppstår en clash /tidsmessig konflikt og i hvilken sone det oppstår. Mulige faktorer som kan være årsak til upålitelighet: En feil eller manglende innstilling i Rules Testen er satt opp på en generell måte der hvert objekt ikke er spesifikt merket. Dette reduserer muligheten for å identifisere feilen. Utgangspunktet med opprinnelige like objekter er muligens ikke et gunstig utgangspunkt for testen.!" Vi laget til slutt et filmforløp ved hjelp av simulate. Filmforløpet ble satt opp på en slik måte at ved begynnelsen av arbeidsprosessen kom figuren til syne som et halvtransparent objekt. Ved slutten av prosessen forsvinner figuren. Her viser modellen seg som forventet i forhold til den oppsatte tidslinje. I det området av tidslinjen der det er en overlapp eller clash i arbeidsprosess vil figuren få en mørkere tone. Cathrine Barth og Steen Sunesen, Arkitektfirmaet C.F. Møller 41 av 75

42 e-handel Innkjøpsportal Elektronisk innkjøp av byggekomponenter er en velkjent og utprøvd teknologi. IFC-prosjektet ønsket å koble de eksisterende standarder for elektronisk datautveksling (EDI) med IFC-BIM. I et samarbeid mellom IFC-prosjektet, leverandør av elektronisk handelsportal, Logiq og BuildingSMART ble det definert et prosjekt som skulle utvikle programvare som tillater å hente inn informasjoner fra IFC-BIM og foreta innkjøp via dagens standard. Logiq sin prosessmodell for informasjonsflyt i e-handel Informasjonsflyten som vises i prosessmodellen er som følgende (tekst med rødt er funksjoner utviklet ifm. prosjektet: BIM en er generert fra de ulike disipliners delmodeller. De komponenter som skal innkjøpes sorteres ut i modellserveren. I denne modell benyttes IFC-XML format, eventuelt Step. Objektene er beriket med IFD-koder som beskriver de enkelte komponenter generiske egenskaper. XML-/Step-filen importeres inn i handelsportalen. Brukeren får der opp en oversikt over de varer fra portalens varekatalog som matcher de egenskapsinformasjoner som var med i den importerte filen. Brukeren velger deretter de ønskede varer og legger disse i handlekuven. Når varene er lagt i handlekurven og brukeren har bekreftet at dette stemmer, blir de ulike varer sendt som EDImeldinger (ordrer) til den enkelte leverandør. Portalen splitter opp de bestilte varer pr. leverandører og sender EDI-meldinger via meldingssentralen. til de leverandører som kan motta elektroniske ordrer. Meldingssentralen konverterer og formidler alle typer handelsdokumenter (Ordre, ordrebekreftelse, pakkseddel, faktura) og meldinger mellom e-handelsløsning og økonomisystem til de aktuelle parter. Det sendes en EDI-melding tilbake som bekrefter kjøpet med eventuelle endringer. Ved leveranse mottar bestiller en elektronisk faktura.. Den fysiske varen behandles deretter som ved analogt innkjøp. Leverandørens ERP-system sender en elektronisk melding tilbake til handelsportalens vareadministrasjon med produktspesifikk IFD 42 av 75

43 og NOBB informasjon og evt. FDV-, HMS- eller teknisk dokumentasjon, dersom dette ikke ligger i portalen allerede. Handelsportalen beriker BIM en med produktspesifikk IFD-/NOBB-koding og administrerer linken mellom objekt og FDV-, HMS- og teknisk dokumentasjon. Potensiale Det forretningsmessige potensialet er å automatisere prosessene dels med entreprenørens fortolkning av tilbudsgrunnlag/arbeidstegner fra rådgiverne for bestilling av varer og dels med innhenting og systematisering av FDV-, HMS- og teknisk dokumentasjon. Begge prosesser er tidkrevende og genererer feil og mangler som fordyrer og forsinker. Automatisering av varesøk på markedet skal gi bedre oversikt over tilgjengelige produkter og gi bestiller større mulighet til å oppnå best pris og leveringspresisjon ved å kunne innhente prisforespørsler fra flere leverandører. For leverandørene kan det øke konkurransesituasjonen, men også gi mulighet til å komme inn i prosjekter gjennom å delta som leverandør i Innkjøpsportalen, som da fungerer som en markedsplass for en community. Status og erfaring Som en del av samarbeidsavtalen utvikles det IDM er (Process Maps og Exchange Requirements) for e-handel. Disse IDM er er ikke ferdig i skrivende stund. Teknisk sett er den avtalte utvikling av portalens interface mot IFC ferdig. Da objektenes egenskaper gjenkjennes på deres IFD-koder, er disse koder sentrale for utprøvingen. Standard Norge, som utvikler IFD-koder, har dog fortsatt en del gjenstående arbeid for å få kodet alle identifiserte bygningskomponenter. Siden vi mangler flere vesentlige IFD-koder og også mangler tilgang til koding fra Standard Norge, har utprøvingen været gjort på BIM med objekter som er kodet med midlertidige prosjektspesifikke koder. Kodingen av objektene er gjort på samme måten som man ville kode med riktig IFD-koder. Dette betyr at innkjøpsportalen vil være operativ når de korrekte kodene foreligger. Eksport av IFC-XML fra modellserver og import av IFC-XML til handelsportal fungerer bra. Berikelse av BIM med produktspesifikk IFD-/NOBB-koder. Linke objekter til FDV-, HMS- og teknisk dokumentasjon. Inger Ramstad, Logiq og Steen Sunesen, Arkitektfirmaet C.F. Møller Mangler 43 av 75

44 RIB Modellering av modellen i Microstation Multiconsult har modellert frontbygget i Microstation versjon Triforma XM. Modellen er bygd opp av elementer, fundamenter og dekker er laget som dekkeelementer, banketter, grunnbjelker, vegger og bjelker som veggelementer. Basiselementene er modifisert med et klippeelement for å lage slisser og utsparinger. Stålprofiler er hentet fra en liste med allerede definerte profiler. Alle elementer er laget som det bygges, dvs at vegger og søyler avsluttes under dekker/bjelker. Eksport av 3D modell i Microstation til IFC modell Multiconsult har modellert frontbygget i Microstation versjon Eksporten av modellen ble gjort med IFC-eksport vertøyet i Microstation Arciteckture Våre erfaringer med dette viser følgende: Vegger og dekker som ikke er modifisert med klippeobjekt fungerer uten problemer, i en roundtrip. Søyler og bjelker blir eksportert som ren geometri (dvs de kan ikke endres etter import) Vegger og dekker som blir behandlet med klippeelementer eller kantavslutninger som er kompliserte vil ikke vises riktig i IFC-viewer og klarer ikke roundtripp. Egendefinerte bjelketverrsnitt vil ikke vises riktig i IFC-viewer og klarer ikke roundtripp. IFC modellen ble lagt inn på Jotne EPM sin IFC Modell Server Browser og hentet inn i DDS IFC viewer 6.34 med stort sett ønsket resultat, men med noen utfordringer både når det gjelder modellserver og viewere. Utfordringer knyttet opp til Modell Serveren / eksport fra Microstation Punktfundamenter/ og veggbanketter blir plassert som egne bygg. 44 av 75

45 Utfordringer knyttet til DDS viewer og eksport fra Microstation Krumme bjelker og dekker slik som i auditoriet eksporteres feil og vises ikke korrekt i viewerne. Slisser og sprang i veggtykkelser eksporteres ikke korrekt / vises ikke korrekt i viewerne. Eksporten av Microstation modellen til IFC formatet gir ulikt resultat avhengig av avhengig av hvilken versjon av IFC formatet modellen eksporteres til. 45 av 75

46 Import av IFC modell til Microstation ARK sin IFC modell ble hentet inn med IFC-import vertøyet i Microstation Arciteckture Vegger med rektangulære dør/vindushull, vegger og dekker som ikke er modifisert med klippeobjekt fungerer uten problemer. Søyler og bjelker blir ren geometri (dvs de kan ikke endres) Vegger og dekker som blir behandlet med klippeelementer eller kantavslutninger som er kompliserte blir ren geometri (dvs de kan ikke endres). Egendefinerte bjelketverrsnitt blir ren geometri (dvs de kan ikke endres). Import av IFC modell til Staad og FEM Design Den komplette IFC modellen ble forsøkt importert i FEM Design, 3D Structure versjon beta. IFC modellen hentes inn direkte i Open som vist under. 46 av 75

47 Importen av den komplette IFC modellen fungerte ikke, og en mulig årsak til dette kan være at IFC modellen ikke blir eksportert korrekt fra Microstation som beskrevet tidligere. For å se om det var mulig å få importert deler av IFC modellen ble de elementene som defineres som IFC-beams i modell serveren trukket ut som en egen modell og importert i 3D Structure. Dette resulterte i følgende modell: Her vises samtlige bjelker uavhengig av materiale. En nærmere undersøkelse av modellen viste følgende: 47 av 75

48 Tverrsnittet av stålbjelkene viser ikke eksakt korrekt tverrsnitt hverken når det gjelder standard profiler eller oppsveiste profiler. De oppsveiste profilene er her vist som stålplater og geometrien av standard stålprofiler er vist tilnærmet korrekt, men uten den eksakte geometrien (avrunding i hjørner etc.). Dette er også synlig i IFC vieweren slik at det er nærliggende å tro at dette har noe med eksporten fra Microstation å gjøre. Bjelkene er definert som betongmateriale og ikke som stål. Dette medfører at modellen i 3D Structure må bearbeides før de statiske beregningene og dimensjoneringen kan utføres. Hvert enkelt element må redigeres slik at det tilordnes korrekt materiale og tverrsnitt. På bakgrunn av at hele modellen ikke lot seg importere i 3D Structure ble modellen redusert til å omfatte bare utkraget tak over inngangsparti. Modellen for det utkragede taket ble påført egenlast og det ble hentet ut deformasjonsberegninger fra 3D Structure. Dette ser ut til å fungere greit. Problemene i forbindelse med importen av IFC modellen i 3D Structure kan ligge i at pr.idag så eksisterer det ikke IFDer som beskriver tverrsnitt og materiale fullt ut. Noe er utarbeidet innen trekonstruksjoner mens det ikke er utarbeidet innenfor stål og betong. Informasjon fra IFC modellen Dagens FEM Design gir ikke mulighet til å eksportere 3D Structure gir ingen mulighet for eksport av modellen til en IFC modell. Dette kunne vært nyttig både med hensyn på å eksportere verdier knyttet til utnyttelsesgrad og laster. Dersom 3D Structure kunne eksportere til IFC format kunne dette hentes opp igjen og oppdateres i Microstation direkte. Mari Anne Overå/Hans Auver Lahus/Arne Matthiasen, Multiconsult 48 av 75

49 RIV VVS-teknikk/RIV generelt Ett av målene med BIM og IFC prosjektet på frontbygget har vært å benytte de samme verktøyene som vi benytter i prosjekteringen av Nye Ahus. SWECO Grøners utgangspunkt for å utvikle sin BIM har vært veldig bra da man har benyttet 3D-modellering med MagiCAD i en god stund for prosjekteringen av hele prosjektet. Noen store skritt har det derfor ikke vært nødvendig å ta i forhold til modellering av VVS. Det er liten tvil om at 3D-modellering er fremtiden. Våre erfaringer med BIM-modellering på Nye Ahus er positive. 3D-modellering gir et godt visuellt bilde av anleggene, muligheter til å legge intelligens i tegningene, for bergeninger, for overføring til tilbud-/anbudsbeskrivelser. I tillegg er det også mer morsomt å modellere enn å tegne dumme 2D-streker. I hele dette prosjektet har vi hatt mulighet til å kontinuerlig å kontrollere kollisjoner mot elektro som også har benyttet MagiCad. I IFC prosjektet har vi i tillegg gjort kollisjonskontroll mot andre disiplinger via IFC-formatet med programmer som er både viewere og kollisjonssjekkere. Energiberegninger var et delprosjekt som som vi hadde store forhåpninger til, men som ga oss mange utfordringer. Det har vært varierende interreer potensiale i flere ser ut til at har vist seg stod vi en stund på stedet hvil, da programvaren ikke svarte til forventningene. I skrivende stund har vi fått en opptur etter å ha lett oss frem til alternative programmer. En stor fordel RIV har hatt med 3D-modellering er at vi kan kontrollere om det er kollisjoner mot andre fag. I tillegg ville det vært svært arbeidskrevende å sjekke kollisjoner mot våre egne installasjoner om det ikke hadde vært mulig å foreta kollisjonskontroller i modellen. Et sykehus som Nye Ahus er så komplekst med mange rør og ventilasjonskanaler som ikke skal kollidere med hverandre. Det høye prosjekteringstempoet med prosjektering og bygging samtidig, har gjort det ekstra viktig å unngå feil og levere de riktige løsningene første gang. Vi har også benyttet et 3D visualiseringsprogram fra Autodesk for å gi entreprenørene 3Dillustrasjoner i enkelte komplekse områder og har fått tilbakemeldinger på at dette har vært til hjelp i monteringen. BIM og IFC åpner for mange muligheter til å forbedre byggeprosessen for alle involverte parter. Fra de prosjekterendes ståsted kreves det et større stykke arbeid tidligere i prosjekteringsprosessen, da det skal legges mer informasjon i BIMen. Gevinsten er at denne informasjonen er mulig å benytte gjennom hele prosjektet og i flere programmer. Informasjon på objektene legges kun inn en gang og denne informasjonen eksporteres fra program til program ved hjelp av utvekslingsformatet IFC. IFC i Nye Ahus prosjektet ble startet på et stadium i prosjekteringen da objektene hadde blitt produktspesifikke, med andre ord ikke generiske objekter. Dette har medført at vi ikke kan høste erfaring fra hvordan overgangen mellom generiske objekter og produktspesifikke objekter fungerer. Den største utfordringen så langt i forhold til IFC er at standarden ikke er ferdig utviklet. Vi savner sårt et IFD-library slik at vi får kodet objektene våre. Det gjenstår dessverre en god del i forhold til VVS objekter. Det foreligger heller ikke IDM er som kan benyttes. Dette innebærer at vi dessverre ikke har oppnådd alle de mål som vi har satt oss da prosjektet ble startet. Objekter og property set (Pset) RIV har modellert alle føringsveier og VVS-objekter i dette prosjektet. Med VVS objekter menes kanaler, rør, ventiler, rister, spjeld etc. Alle objektene er modellert som produktspesifikke objekter. Det er ikke benyttet generiske objekter. Objektene er hentet fra leverandørenes eget objektbibliotek. 49 av 75

50 I dette prosjektet har man, som tidligere nevnt, kun hatt en BIM med produktspesifikke objekter. MagiCAD som er modelleringsverktøyet har et eget objektbibliotek med generiske objekter. Dette biblioteket er imidlertid ikke komplett. Det er mulig å lage egne generiske objekter i MagiCAD, men ansvaret for å ha et komplett generisk objektbibliotek bør ikke ligge hos den prosjekterende. Ideelt sett burde det kanskje vært opprettet et felles nasjonalt objektbibliotek der objektene blir beriket med IFD koder etter hvert som disse foreligger. Ansvaret for å drifte dette kunne kanskje ligge hos Sintef Byggforsk? Et annet alternativ, om enn noe dårligere, er at programvareleverandøren oppretter et komplett generisk bibliotek. Alle objekter har som standard et globalt identifikasjonsnummer, en såkalt Ifc GUID. Dette gjør det mulig å gjennkjenne et spesifikt objekt i modellen. Videre har objektene property sets, Pset, som inneholder informasjon om objektet (type, størrelse etc) og opplysninger man har beriket modellen med (f.eks luftmengde som modellen berikes etter at det er utført beregninger). Dette er definert i IFC, med det er nødvendig med et egendefinert pset i tillegg, bl.a. er det nasjonale forhold som NS koder som bør fremkomme på objektene. Vi har erfart underveis at Pset vises forskjellig i ulike programmer. Det hadde vært ønskelig at de ulike programvareleverandørene samarbeider om en felles standard for hvordan Pset skal vises. Det vil gjøre det enklere å mer oversiktlig. På neste side er det vist et eksempel på Pset for en KSO avtrekksventil i henholdsvis DDS IFC Viewer og Solibri Model Checker. Tilsvarende gjelder også for Octaga Modeller og NavisWorks Jetstream. #$# %&" '(")**+ 50 av 75

51 #,-!" '(")**+ EDM modelserver fra EPM Technology Modellserveren har vært benyttet til å laste opp vår egen modell (RIV) og laste ned andre fags modeller. Merging av filene i modellserveren har vært gjort av EPM. Det har vært behov for å gjøre en del tilpasninger av de enkelte fags modeller for å få til dette. Prosjektet har ikke hatt en felles prosjektstandard for definering av nullpunkter og måleenheter (milimeter brukt av alle fag, med unntak av RIB som har benyttet meter). Koordinater som ifcsite i forhold til referansepunkt, ifcbuilding i forhold til ifcsite osv var ikke definert (gjelder for alle fag). Dette ble korrigert manuelt i modellserveren. Opplasting av vår egen modell i modellserveren har stort sett fungert bra. Innimellom har vi opplevd en del uforståelige feilmeldinger, men EPM har vært raske med å gi tilbakemelding i forhold til dette og andre problemer vedrørende modellserveren. Nedlasting av andre fags modell fungerer bra. Når det gjelder brukergrensesnittet er det klart et forbedringspotensiale. Når man beveger seg mellom de ulike ifcsystem er det litt irriterende at man hele tiden må justere kolonnestørrelsen for å få med seg all teksten. Dette er meldt tilbake til EPM og de vil forbedre dette etter hvert. Underveis har det kommet flere revisjoner av modellserveren etter hvert som nye funksjoner er lagt til og forbedringer er utført for å få modellserveren mer stabil. 51 av 75

52 RIV Modelleringsverktøy MagiCAD SWECO Grøner bruker MagiCAD med AutoCAD 2005 plattform som modelleringsverktøy verktøy under arbeidet med å prosjektere Nye Ahus. Programmet er godt kjent av alle som prosjekterer og tegner i dette prosjektet. # - $. MagiCAD er ett program med stor presisjon og nøyaktighet. Det inneholder symbolbiblioteker for rør og ventilasjonsfaget hvor alle symboler er 3D objekter. Som tidligere nevnt var prosjektet i en fase hvor leverandørspesifikke objekter ble brukt. Disse objektene er hentet fra leverandørenes eget symbolbibliotek og har riktig geometri. Objektene er beriket med prosjektets egendefinerte systemnummer, luftmengder, NS koder osv etter som beregninger gjøres og ny informasjon blir tilgjengelig. Alle typer av rørsystemer og ventilasjon er tegnet i den samme modellen, og det er en modellfil for hver etasje. På neste side er det vist eksempel på Part Properties for en tilluftsventil. Part Properties inneholder mye av den samme informasjonen som et pset ved IFC eksport. Alle objektene har egne Part Properties (eller pset). Man kan også skrive inn egne opplysninger som man ønsker å ha med. Det kan være foreksempel NS-kode, løpenummer med mer. 52 av 75

53 #."/0/0 0 0/ 0 /0 - Versjon av MagiCAD som vi har benyttet i prosjektet har kun IFC 2x2 eksport. Vi hadde store problemer med å generere IFC-filer av de største modellfilene våre, antakelig pga noen begrensninger på filstørrelsen. Dette ble løst ved å dele IFC-eksporten i ventilasjon, sprinkler og rør. Den siste versjon av MagiCAD som kom i vår/sommer har imidlertid IFC 2x3 eksport. Vi testet ut IFC eksporten i denne versjonen også, og det gikk da smertefritt å generere store IFC filer uten å måtte dele modellen opp. IFC filene ble lastet opp på modellserveren. Det er dessverre kun mulig å eksportere til IFC-format i MagiCAD. Import av IFC-format er ikke mulig. Dette er noe programleverandøren jobber med å løse. Det finnes en egen eksport kommando for å eksportere ut IFC filer. Denne kommandoen er laget spesielt for Nye Ahus prosjektet og finnes nå på den nyeste revisjonen av MagiCAD. # /# Dette er bare et eksempel på dialogen som har vært mellom produsenten og leverandøren av MagiCAD. Progman i Finland, som utvikler programmet, og Nestor, som er forhandleren i Norge, har vi hatt et tett og konstruktivt samarbeid med. Begge firmaene har hjulpet oss med egne ønsker. Mange av våre ønsker og behov har blitt innlemmet i de nyeste versjonene av MagiCAD. Vi har i tillegg ofte fått betaversjoner for utprøving. Et ønske fra oss har vært å fått med IFC eksport av isolasjon (isolasjon er ikke IFC 2x3) slik at vi kan teste i Clash Detection programmene om alle kanaler og rør som går gjennnom brannvegger har brannisolasjon. Dette ønsket har vi nå fått oppfyllt i den siste betaversjonen av MagiCAD. Et eget felt for IFD-kode er i tillegg noe vi ønsker å få med i Part Properties, slik at dette blir en del av IFC eksporten. Vi har testet eksporten av IFD-kode med å legge inn en fiktiv kode, noe som fungerer bra. 53 av 75

54 Solibri Model Checker v 4.1 I pilotprosjektet har vi testet Solibri Modell Checker versjon 4.1 (en versjon 4.2 er kommet, men ikke testet). Dette programmet fungerer godt for å utføre kollisjonskontroller. Vi har testet ut både filformatet IFC 2x2 og 2x3, og begge formatene fungerer like bra. Solibri Model Checker er benyttet til å sjekke eventuelle kollisjoner vi har på våre VVS installasjoner mot fagene ARK, RIB og RIE, men også for å teste kollisjoner innen vårt eget fag og mellom de andre sitt fag. MagiCAD har som nevnt mulighet til å foreta kollisjonstester, og kollisjonstesting i Solibri vil være et suppliment til denne ikke en erstatning. Presentasjonsmessig vises kollisjoner mye bedre i Solibri. Vi ser en stor gevinst i å kunne utføre disse handlingene på en enklere måte enn tidligere, hvor man før brukte 2D tegninger og måtte ha kontroll på høyder/dimensjoner av utstyr og føringsveier. Modellen som er eksportert til IFC-format i MagiCAD hentes direkte inn i Solibri. Her kan man enkelt merge inn de andre fagene og foreta kollisjonskontroll. Solibri gjør mer enn kollisjonskontroller. Det er også forhåndsdefinerte Rule sets (regeloppsett). En regel kan f.eks være kontroll av størrelse på brannceller, kontroll av dører, vinduer i brannvegger etc. #12 # ")2% )-! Det er enkelt å bevege seg rundt i modellen. Man har muligheten til å rotere, fly, zoome, gå osv. Hvis man har merget flere fags IFC-filer, kan man skru av og på de fagene man ønsker å se/ikke se. Når man skal foreta en kollisjonstest må minst to av filene være aktive. Man må også velge riktig regel for det man ønsker å kontrollere. Tolleranser kan legges inn og flere regler kan kombineres. Kollisjoner eller varslingspunkter deles inn i tre kategorier avhengig av hvor alvorlige de er. Mindre alvorlige blir merket med gul trekant, litt mer alvorlig med oransje og de alvorligste med rød trekant. Kollisjonene vises med en tekst som forklarer hva som kolliderer og dette vises som en liste i ett trådsystem. Når vi markerer ett punkt i listen blir denne kollisjonen markert rød i modellen. Etter at kollisjonene er funnet kan man ta bilde av det aktuelle området, legge til en kommentar og lagre det hele som en rapport i pdf-format. Perfekt for å ha med seg i møter for problemløsing. 54 av 75

55 Fig H - Kollisjon mellom RIEs kabelstige RIVs lydfelle. Fig I Utdrag av kollisjonsrapport. Store bilder av det aktuell området med kommentarer til. Testingen av Solibri har vært lærerikt og gøy, spesielt fordi det fungerer så bra mot IFC-formatet. Kunnskap er oppnådd gjennom prøve og feile metoden. Vi har også brukt Solibri som en viewer. Under prosjektet med Solibri har vi også hatt seminarer med presentasjon av status for IFC prosjektet. Det har da blitt gitt hands-on demonstrasjoner av programmet. Det er ingen resultater av det vi har gjort i programmet som har beriket IFC-modellen. Det er kun vært enveis kommunikasjon med IFC BIM. Programmet er kun ett verktøy for å løse kollisjoner eller som viewer. Vi har ikke kunnet finne noen feil ved programmet. Vi har vært i kontakt med Solibri angående muligheten for ytterligere regler. Vi ønsker oss muligheten til blant annet å sjekke om kanaler og rør 55 av 75

56 har den nødvendige brannisolasjonen i forhold til brannvegger. Det er bare å komme med ønsker for dette og annet. NavisWorks Jetstream med Clash Detective Programmet har mange likhetstrekk med Solibri Model Checker. I tillegg til å kunne foreta kollisjonssjekker er programmet en flott viewer. Denne funksjonen og Timeliner blir omtalt andre steder i rapporten. Vi har testet bruken og mulighetene med NavisWorks Clash Detective med bruk av både IFC 2x2 og 2x3 filer. Kollisjonskontrollen er meget enkel i bruk og det har ikke vært noe behov for opplæring. Det er stor gevinst å kunne hente ut resultatene fra en kollisjonskontroll mot andre fagene på en enkel og rask måte. IFC filene er lette å behandle i NavisWorks ClashDetective, og det tar bare noen sekunder fra prosessen starter til testen er gjennomført. Som for Solibri har man utført kollisjonskontroller hovudsakelig mellom RIV og RIE, men også mot ARK. Resultatetene er sammenlignet med resultatet for tilsvarende kollisjonskontroll i Solibri. Resultatet er likt i begge programmer. Forskjellen på disse to programmene er ikke så store. Resultatet vises litt annerledes i de to programmene, men ellers merger man på nesten samme måte, man kan legge inn toleransemål og egendefinerte punkter. Fig J - RIV IFC-fil av plan 1.etg åpnet i NavisWorks. Man har flere grader av kollisjonskontroll. Vi har stort sett valgt Hard, da dette valget tar med seg alle typer kollisjoner. Resultatene presenteres litt annerledes i NavisWorks enn i Solibri. Vi får opp en liste med beskrivelse, hvilken koordinat kollisjonen er i, klokkeslett, dato, osv. Ved å velge de ulike clashene i listen får man bilde av konflikten (bilde av BIM hvor kollisjonen har annen farge enn resten) og man kan godkjenne kollisjoner (markeres grønne og vil ikke komme opp som kollisjoner senere). Utifra dette kan man generere en rapport. I rapporten kan man velge hva som skal tas med (gamle kollisjoner, godkjente, nye osv). Man kan velge hvilket view de ulike kollisjonene skal sees fra og filformat for rapporten (XML, HTML, TEXT og AS viewpoint). 56 av 75

57 Fig K Utdrag fra kollisjonsrapport i NavisWorks. Bildene i rapporten er små, men klikker man på dem blir de større. NavisWorks er et flott og nyttig verktøy, både til kollisjonskontroll og som viewer. Vi har ikke funnet feil ved programmet, det er enkelt i bruk og resultatene fra kollisjonstestene kommuniserer på en bra måte. Programmet kan kun hente informasjon fra BIM, men ikke berike IFC-modellen. Eneste vi kunne ønske oss på sikt er den samme muligheten man har ved bruk av Rule sets i Solibri: Kunne foreta andre tester av modellen slik som f.eks tilgjengelighet for rullestolbrukere, kontroll av rømningsveier etc. Joakim Engen, Sweco Grøner Viewere Vi har testet ut ulike viewere. Mange av de testede viewerne har andre funksjoner enn bare viewere. Dette er nevnt under, men beskrevet ytterligere i de enkelte kapitlene. Solibri Model Checker v 4.0 Merging av de enkelte fags modellfiler gjøres i programmet og filen får ny filendelse. Det er enkelt å navigere rundt i modellen og man har flere ulike valg i forhold til hvordan man vil bevege seg rundt (gå, fly, gravityfunksjon etc). Grafikken er veldig bra for alle fag. Man kan ved å klikke på objektene få oversikt over egenskaper (pset). Programmet har også andre funksjoner slik som Clash detection. Navisworks Jetstream Merging av modellfiler gjøres også her i programmet. Filen får også her ny filendelse. Som for Solibri er det enkelt å rotere og navigere rundt i modellen og grafikken er for alle fag veldig bra. Man kan ved å klikke på objektene få oversikt over egenskaper (pset). I Presenter delen av programmet kan man legge på ulike materialtyper, bakgrunnseffekter, og lyssette med skygger, slik at modellen blir mest mulig virkelighetstro. Programmet har en rekke andre funksjoner som enten er en del av programmet eller en tilleggsmodul. Dette er funksjoner som Presenter (visualisering), Timeliner (linking av modell mot fremdriftsplan) og Clash Detection (kollisjonstesting). Disse funksjonene blir omtalt andre steder. 57 av 75

58 Octaga Modeller 2.1.0m25r Merging av modellfiler gjøres i programmet. Filene får ingen ny endelse. Det tar relativt lang tid å åpne filer i programmet sammenliknet med de andre viewerne. Når det gjelder objektenes Pset får man her opp en liste og utifra det kan man zoome inn på enkelte objektene. Det er dessverre ikke mulig å klikke på et objekt i modellen å få opp dets tilhørende Pset. Grafikkmessig ser vieweren ut til å fungere bra for arkitektunderlaget. Når det gjelder IFC-eksport fra MagiCAD forsvinner mange kanal og rørdeler, slik at det er elementer som ikke er lett å skjønner hva er (se bilde på neste side). Ellers er det enkelt å rotere og navigere i modellen og man har også her mange muligheter for å ulike måter å navigere på. DDS IFC viewer 6.40 DDS sin IFC viewer fungerer bra. Grafikken kunne med fordel vært mer spennende med blant annet flere farger, men det veier opp for det faktum at vieweren er gratis. Filene får ingen ny endelse, men beholder sitt IFC-filformat. Programmet har i tillegg mulighet til å importere en fil direkte fra en modellserver. Man har de samme mulighetene for å navigere i modellen på en enkel måte som for de andre programmene. Programmet viser objektenes Pset på en veldig bra måte og man kan zoome rett inn på objektet. Man har i tillegg mulighet til å klikke på et objekt å få opp Pset for dette. Fig F Den samme modellen vist i ulike viewere 58 av 75

59 Energisimuleringsverktøy Vi har i prosjektet testet ut to ulike energisimuleringsverktøy. Bakgrunnen for at det ble testet ut to verktøy er at det førstnevnte ikke tilfredsstiller de kriterier vi forventet av et slikt program, samt at man ikke har fått den oppfølgingen fra leverandøren som vi hadde forventet. RIUSKA fra Granlund RIUSKA har dynamisk simulering av komfort og energibruk i bygninger. Programmet beregner innetemperatur, oppvarmingsbehov og kjøling av områder i bygninger. Det kan benyttes for å sammenligne og dimensjonere HVAC systemer, i tillegg til at man kan beregne energibruken i den totale bygningsmassen. Man kan legge inn internbelastninger fra personer, utstyr, belysning etc for hvert enkelt rom. I prosjektet har vi forsøkt hentet inn ARK BIMen som en IFC-fil. Kombinasjonen av IFC-fil fra ADT og Riuska viste seg å gi svært dårlige resultater, hvor begge verktøyene skapte problemer. Importen krever dessverre også manuell innlegging av all data, da det er geometrien og elementer som bygget er bygd opp av som følger med eksporten. Data som U-verdier må dessverre legges på BIMen på nytt, da dette ikke følger med fra IFC importen. RIUSKA støtter heller ikke curtain-walls (her glassfelt) noe som er et stort minus. Det ser også ut som at Riuska takler store modeller dårlig. Det hadde også vært ønskelig at man kunne hente internbelastninger fra annen programvare. Personbelastningen i et rom legges f.eks inn i drofus. Det har vært forsøkt via DDS, å få til en konstruktiv dialog med Granlund som leverer RIUSKA mtp forbedringer i forhold til IFC import. Det har dessverre vært liten respons på dette, så resultatet var at vi bestemte oss for å teste et annet program. Hensikten med dette prosjektet har vært at man skal kunne hente inn BIM som en IFC fil uten å måtte legge de samme dataene som BIMen allerede inneholder inn på nytt igjen. IDA Klima og Energi fra EQUA IDA Klima og Energi 3.0 har de samme energisimuleringsmulighetene som RIUSKA. Versjon 3.0 har dessverre ikke IFC 2x3 import, men betaversjon av dette er testet. Vi møtte noen av de samme problemene som ved Riuska, bl.a. manglet IFCStorey i ADT-eksport på det tidspunktet samarbeidet med Equa startet, så det var en modifisert modell som ble importert i IDA. Pr. i dag må også alle egenskapene som U-verdi og lignende legges inn ved at det forskjellige typene av konstruksjoner må mappes mot en database. EQUA arbeider imidlertid fortløpende med utviklingen av IDA og har vist stor interresse for å få alle tilgjengelige daqta i IFC-modellen med i en import. Vi har håp om at det skal foreligge en bedre import til IDA innom kort tid. Dialogen og samarbeidet med IDA har vært bra. e-handel - Innkjøpsportal Logiq Det er som tidligere nevnt utviklet en testportal for e-handel. Foreløpig er det ikke lagt inn så mange produkter, da IFD-kodingen av objekter ikke har kommet langt nok. Trelast er pr i dag ferdig, men når det gjelder IFD koder for VVS har vi kun fått testet eksport av to avtrekksventiler som har fått foreløpige IFD-koder. Portalen fra Logiq er enkel å bruke. Søking på varer og bestilling fungerer som en helt ordinær webløsning med internettbestilling. Forskjellen her er at BIMen er utgangspunktet og produkter bestilles etter IFD-koder. Samarbeid med Logiq har fungert bra, og teknisk sett er portalen ferdig. Dessverre har vi ennå ikke fått muligheten til å teste ut portalen fullt ut, da vi avventer at IFD kodingen skal komme videre. 59 av 75

60 Beskrivelsesprogram G-Prog SWECO Grøner benytter i dag G-PROG Beskrivelse for å lage anbudsbeskrivelser. BIMen kan hentes inn i G-PROG Beskrivelse via Calcus. Importen fra MagiCAD til Calcus går relativt bra, med unntak av noen tilpasninger må gjøres i. Feilen her ligger hos MagiCAD. Generering av Beskrivelser direkte fra BIM vil være veldig nyttig, da det er en omfattende og ofte kjedelig jobb å gjøre dette manuelt. Generering av Beskrivelse fra IFC-fil, innebærer at man kan bruke mesteparten av tiden på å kontrollere mengder. Siv Hilde Bjørkkjær/Joakim Engen/Geir Gullvik, Sweco Grøner 60 av 75

61 RIE Innledning RIE startet for fullt arbeidet med IFC pilotprosjektet på nyåret Vi definerte våre mål i aktivitetsbeskrivelsen. Denne har vært grunnlaget for vårt arbeid i forbindelse med pilotprosjektet. Vi vil nå beskrive hvordan vi har jobbet, hva vi har jobbet med, og hvor langt vi har kommet. Vi vil også gå inn på våre erfaringer knyttet opp mot IFC pilotprosjektet. Til slutt vil vi legge til at denne fellestverrfaglige rapporten inneholder kun hovedmomentene fra RIE sin fullstendige rapport om IFC pilotprosjektet. Vi vil også benytte anledningen til å takke alle som har bidratt i pilotprosjektet. En spesiell takk til følgende personer: Nestor v/ Trond Engebråten for god hjelp med MagiCAD. DDS v/trond Inge Rødland for god hjelp med ElektroPartner. TELFO v/ Agnar Holen for et hyggelig samarbeid gjennom pilotprosjektet. Aktivitetsbeskrivelse RIE Målene våre er definert i en aktivitetsbeskrivelse. Vi har kalt aktiviteten: datautveksling mellom ulike programmer ved hjelp av IFC-format. Det overordnet målet med denne aktiviteten er å effektivisere selve prosjekteringsprosessen i et prosjekt. Aktiviteten har vi igjen delt opp i mindre delaktiviteter. Slik som hverdagen er i dag bruker vi mange forskjellige dataverktøy der vi beregner ulike parametere i et prosjekt. Ofte er det de samme opplysningene man legger inn som grunnlag i programmene. Ved hjelp av IFC-formatet skal det bli mulig å hente ut ønskede opplysninger, som man kan bruke som grunnlag i videre beregninger, fra den digitale bygningsmodellen (BIM). Det er viktig at datautvekslingen er programuavhengig, noe man oppnår ved å benytte seg av IFC-formatet. Vi vil nå oppsummere delaktivitetene våre slik de ble satt opp våren 2007: Delaktiviteter Anskaffelse av programvare til bruk i pilotprosjektet Vi benytter oss av MagiCAD som det primære DAK verktøyet. Dette leveres av Nestor, og utvikles av Progman. ElektroPartner fra DDS benyttes i et spesifikt område (2.etg. kjøkken/servering). Eldata fra NELFO skal brukes som kalkyleprogram, mens Febdok, også fra NELFO, benyttes som beregningsverktøy. Utvikle MagiCAD med tanke på IFC-eksport Da vi begynte arbeidet med pilotprosjektet hadde MagiCAD en del mangler med tanke på eksport til IFC-format. Programleverandøren har bra fokus på dette, og jobber mye med denne delen. Det må gjøres en jobb med å utvikle programmet videre på dette området.. Slik som det er i MagiCAD i dag dimensjonerer man kabler og ledninger samtidig som man tegner. Man legger også inn belastning og velger vernstørrelse. I tillegg til kabellengde er dette opplysninger som kan benyttes (via IFC-formatet) i Febdok for videre beregninger. Det å få med disse parametrene i en IFC-eksport er en av utfordringene til MagiCAD. Datautveksling mellom MagiCAD (CAD), Febdok og Eldata Dette klassifiseres som hovedmålet i prosjektet (Figur 0.1). Ved hjelp av utviklingsmøter (se avsnitt om utviklingsmøter) mellom programvareleverandørene, bransjeorganisasjon, Siemens og RIE, er målet å få til datautveksling på IFC-format. Febdok brukes til kortslutnings- og spenningsfallsberegninger, dimensjonering og dokumentasjon av det elektriske anlegget. Mer informasjon om Febdok i kapittel av 75

62 Eldata er et kalkyleprogram som brukes til tilbudsberegning av Elektroinstallatører. Programmet kan også brukes til etterkalkyle av en jobb. Mer informasjon om Eldata i kapittel 0. Figur 0.1: Grafisk fremstilling av hovedmålet til RIE ElektroPartner, DDS Med det utgangspunktet at DDS har kommet lengre enn MagiCAD når det gjelder eksport til IFCformat, ønsker vi å prosjektere en del av frontbygget ved hjelp av DDS sin programvare. Ønsker også å se på koblingen mot G Prog og Eldata (muligens også Dialux, lysberegning). Oppbygning av BIM Underveis i prosjekteringen av frontbygget bygger vi opp og supplerer den digitale bygningsinformasjonsmodellen. Testing / simulering av den digitale bygningsinformasjonsmodellen Simulering ved hjelp av viewer fra Octaga og DDS. Programmer brukt i pilotprosjektet MagiCAD MagiCAD er et teknisk objektbasert DAK-verktøy på AutoCAD plattformen. Programvaren leveres av Nestor og utvikles av Progman i Finland. I pilotprosjektet har vi benyttet MagiCAD (2004.9) som vårt primære DAK verktøy. I MagiCAD er prosjekthåndtereren (Figur 0.2) svært viktig. I denne definerer man alle komponenter og utstyr vi ønsker å ha med i prosjektet. Prosjekthåndtereren blir ofte gradvis tilpasset etter hvert som prosjektet utvikler seg. Det som har vært litt spesielt i dette pilotprosjektet er informasjonsmengden vi har lagt inn i prosjekthåndtereren, og i komponentene. Siden vi har jobbet med sømløshet mellom ulike programvarer har vi brukt en del tid til å legge inn diverse informasjon i komponentene. Deler av denne informasjonen håpet vi å kunne utnytte i andre programvarer. 62 av 75

63 Figur 0.2:Prosjekthåndtereren MagiCAD og IFC MagiCAD har foreløpig kun eksport muligheter til IFC-formatet. Dette jobbes det med, og i neste versjon ( ) vil programmet også ha import muligheter. Denne versjonen kommer ut rundt årsskiftet til Eksportfunksjonen fungerer bra. Når man overfører filer til IFC-format følger egenskaper for utstyr med, og man kan se disse ved hjelp av et visningsprogram (viewer). 3D grafikken på objekter følger også med. Erfaringer med MagiCAD Som tidligere nevnt var MagiCAD det primære DAK verktøyet vi benyttet oss av i dette pilotprosjektet. Alt av arbeidstegninger (plan, snitt, skjema) ble produsert ved hjelp av MagiCAD. Vi hadde i mindre grad vært borti programmet tidligere, og ble kurset av Nestor for å komme skikkelig i gang. Siden vi daglig bruker AutoCAD, gav dette oss en fordel siden MagiCAD benytter seg av AutoCAD som plattform. Mange av kommandoene og grensesnittet var da kjent fra før. 3D prosjekteringen var enkel å ivareta, og de gode rapport-mulighetene var praktiske. Vi benyttes oss også av den muligheten til å få generert enlinjeskjema på grunnlag av det vi hadde tegnet. Et problem som ikke var løst i den versjonen av MagiCAD som vi brukte, var 3D visningen av komponenter som står over hverandre. For eksempel ved en dør der vi har bevegelsesdetektor og termostat (Figur 0.3). I 3D visning ble plasseringen av komponentene feil (Figur 0.4). Dette problemet blir løst i neste versjon av MagiCAD. Figur 0.4: 3D view fra siden Figur 0.3: Komponenter plassert over hverandre Måten MagiCAD fungerer på ved at alt av informasjon, objekter osv ligger i prosjekthåndtereren (mep filen), var en fordel for oss i dette prosjektet. Det var ikke alt av informasjon vi hadde da vi startet å prosjektere. Utover i prosjektet la vi inn informasjon på objektene etter hvert som vi fikk den. På denne måten ble modellen vår beriket hele tiden underveis i prosjektet. 63 av 75

64 Oppfølgingen fra Nestor har vært veldig bra. Vi har hele tiden hatt en dialog slik at eventuelle problemer har blitt løst raskt. Vi har også gitt tilbakemeldinger underveis hvis det er funksjoner, kommandoer som vi mener programmet burde hatt, eller som burde vært utbedret. DDS ElektroPartner DDS ElektroPartner er et tegne/dokumentasjons og prosjekteringsverktøy for elektrobransjen. Programmet utvikles og leveres av Data Design System (DDS). I pilotprosjektet har vi benyttes oss av DDS sin programvare fordi de har kommet langt med tanke på utveksling av data på IFC-format. Når man starter et nytt prosjekt i ElektroPartner begynner man med å definere hvilke (eller antall) plantegninger og skjemategninger, som skal være i prosjektet. I dette pilotprosjektet ser tegningslisten ut som Figur 0.5. Vi har opprettet en plantegning for 2. etasje, samt skjemategninger for de tre fordelingene som forsyner servering og kjøkkenområder. Figur 0.5: Tegningsliste for frontbygget Når man skal begynne å tegne starter man på vanlig måte med å referere inn et tegningsunderlag. Man kan for eksempel referere inn en dwg fil eller en IFC-fil. En bildefil kan også brukes som tegningsunderlag. Det beste er å referere inn en IFC-fil som tegningsunderlag. Ved å gjøre dette kan ElektroPartner utnytte den informasjonen som ligger i IFC-filen. På menyen som heter standard verktøy er det et valg som heter sentral og kurser. Det er her man går inn for å opprette de fordelingene man skal ha i prosjektet. Man legger også inn alle kursene som skal høre til de respektive fordelinger. Som tidligere nevnt er det de tre fordelingene som dekker servering og kjøkkenområdet, som vi skal definere. 64 av 75

65 Figur 0.6: Kursliste normalkraft fordelingen Figur 0.6 viser normalkraft fordelingen. Når man legger inn en kurs kan man blant annet definere type kurs (lys, stikk og lignende), antall faser, type vern, kabeltype og kabeltversnitt. I ElektroPartner kan man også forta en grov eller en førstegangsberegning av hovedvernet. Hovedvernet beregnes ut fra den nominelle verdien på vernene i fordelingen. I de kablene man tegner fullt ut får man også beregnet spenningsfallet. Disse funksjonene er praktiske hjelpemidler. I ElektroPartner kan man på grunnlag av det man tegner få generert ulike typer skjemaer. I dette prosjektet har vi valgt å lage kursfortegnelser og enlinjeskjemaer. ElektroPartner og IFC DDS har kommet langt når det gjelder utveksling på IFC-format. Elektropartner kan både eksportere og importere IFC filer. Ved å bruke et arkitektunderlag på IFC-format som tegningsunderlag, kan man hente inn informasjon som: veggtyper (sjikt), U verdier, 3D geometri og vinduer med propertieset. Ved hjelp av IFC-formatet kan informasjon fra ElektroPartner for eksempel overføres til beregningsprogram og kalkulasjonsprogram. Erfaringer med ElektroPartner For brukere som er vant til å jobbe på AutoCAD plattform vil det alltid være en prosess å bytte verktøy. Dette gjelder selvfølgelig uansett hvilke programvarer man bytter til. Derfor fokuserer vi ikke på dette her. 65 av 75

66 For å komme i gang med programvaren var vi på et 2 dagers kurs hos DDS. Vi valgte kursing kontra det å prøve å sette seg inn i programmet på egen hånd. Dette var riktig måte å starte på. Vi fikk en grundig gjennomgang av bruk og muligheter med programvaren. Vi trøblet litt i starten pga at vi begynte å jobbe med en ikke utgitt versjon av ElektroPartner. Denne var ikke ferdig testet og kvalitetssikret ennå. Når dette ble løst gikk alt mye bedre. Brukergrensesnittet til programmet er greit å komme i gang med. Det å tegne standard installasjoner som lys, stikkontakter, brytere osv er svært enkelt. 3D prosjektering blir også enkelt ivaretatt når man tegner. Grafikken er svært bra og modellen er enkel å manøvrere i. Vår erfaring er at programmet fungerer dårligere når anleggene blir litt mer avansert. Tenker da hovedsaklig på ulike type bygningsautomatiserte anlegg, sentral driftskontroll (SD). Stikkord her er Lon, dali, kjøling og vannbåret varme. Tilpassninger, for eksempel av symboler følte vi var lettere å få til med AutoCAD. Når vi prøvde å importere en arkitekt modell på IFC-format fikk vi problemer. Vi fikk ikke frem modellen slik den skulle være, og etasjeinndelingen ble feil. Frontbygget ble delt inn 8 etasjer. Dette skyldes ADT programvaren, ikke ElektroPartner. Dette problemet kan løses ved å importere etasje for etasje, i stedet for hele modellen samtidig. Oppfølgingen fra DDS har vært veldig bra. Problemene vi hadde i starten med bug i programmet ble raskt ordnet opp i. Underveis i prosjektet har de vært svært behjelpelige ved henvendelser fra oss. Vi vil også takke for lisens vi fikk av dem. Febdok Febdok er et dataprogram for dimensjonering og dokumentasjon av elektriske installasjoner i henhold til Forskrift om elektriske lavspenningsanlegg (FEL) og normen (NEK400). Programmet dimensjonerer ledninger, skinner og vern, kontrollerer vernets bryteevne, utkoblingstid og selektivitet. Programmet gir nødvendig dokumentasjon til eltilsyn, kunde og installatør. Melding om installasjonsarbeid kan sendes elektronisk til DLE/netteier. Leverandør av programmet er NELFO. Kort innføring i programmet I Febdok starter man med å definere det elektriske anlegget man skal beregne. Blant annet definerer man startpunktet for beregningen (trafo eller fordeling), type fordelingssystem, spenningsnivå, frekvens, og spenningsfall. Man må også legge inn data for første fordeling, samt data på foranliggende nett. Dette må man gjøre for at Febdok skal ha et utgangspunkt å beregne ifra. Data på foranliggende nett får man fra netteieren i området. Det siste man må gjøre før man kan begynne å bygge opp selve anlegget, er å akseptere data (Figur 0.7). Figur 0.7: Akseptere data 66 av 75

67 Avhengig om man skal beregne fra trafo eller en fordeling, starter man med å bygge opp det elektriske anlegget. Man definerer da hovedfordelinger, stigerkabler, underfordelinger og kurskabler. Dette fremstilles som et stigeledningsskjema (Figur 0.8). Figur 0.8: Stigeledningsskjema i Febdok Når man har bygget opp det elektrisk anlegget slik man ønsker det, samt beregnet anlegget etter gjeldende forskrifter og normer, kan man velge hva slags dokumentasjon man ønsker. Eksempler på dokumentasjon er: Stigeledningsskjema, enlinjeskjema, selektivitetsanalyse og verninnstillinger. I febdok er det enkelt å ordne fasefølgen slik at belastningen blir fordelt ut på alle faser. Programmet inneholder også en stor verndatabase. Dette gjør at data på de fleste verntyper og fabrikanter, er lett tilgjengelige. Man kan da foreta selektivitetsanalyser mellom ulike vern i anlegget. 67 av 75

68 Febdok og IFC Febdok har i skrivende stund (november 2007) ikke eksport/import muligheter til IFC-format. Denne muligheten får man i neste utgave av Febdok som blir lansert under Eliaden 2008 (mai). Man får da muligheten til å hente inn en IFC-fil fra et tegneprogram, og utnytte det som er lagt inn av relevant informasjon der. Etter at anlegget er beregnet og dokumentert kan man eksportere informasjonen ut på IFC-format igjen fra Febdok (se kapittel om aktivitetsbeskrivelsen). Erfaringer med Febdok Vi har fått lisens på programmet av NELFO, slik at vi har blitt kjent med hvordan programmet fungerer. Siden Febdok med eksport/import muligheter til IFC-format ikke er ute enda, har vi ikke fått testet dette. Takk til NELFO for lisens. Eldata Innledning ELdata er Nelfo bedrifters dataprogram for anbudsregning. Programmet er basert på Norsk Standard for prosjektbeskrivelser(ns 3420, 3450, 3451, 3457, 3459). Grunnlaget for beregningene er vareregister, rabattavtaler, akkordtariff og pakkeregister. ELdata beregner selvkost for materiell, arbeid, timeforbruk, anbudssum, dekningsbidrag og bruttofortjeneste. Programmet gir en meget god dokumentasjon. ELdata kommuniserer direkte mot MS Project, DDS TekniskPartner, Visma SalesOffice, Focus Anbud, G-PROG Beskrivelse og FEBDOK. Leverandør av programmet er NELFO. ELdata kan skrive ut en rekke rapporter: Tilbudssammendrag Postsammendrag Enhetspriser Detaljert tilbud Beskrivelse Akkord pr. aktivitet Netto + timer pr. post Arbeids- og materiellkalkulasjon Kort innføring i programmet Figur 0.9 viser en beskrivelse for et elektrisk anlegg lest inn i Eldata. Beskrivelsen består av poster med spesifikasjon av leveranse. Bruker oppfyller spesifikasjonen ved å legge inn kostnader/ytelser og kalkulere enhetspriser. Etter kalkulasjon av tilbudet kan bruker velge presentasjon av resultatet blant mange forskjellige rapporter. 68 av 75

69 Figur 0.9: Beskrivelse lest inn i programmet 69 av 75

70 I Figur 0.10 er det valgt en rapport som viser beskrivelse med enhetspriser per post. Figur 0.10: Beskrivelse med enhetspriser per post Rapport kan skrives ut på skriver eller som PDF-fil, og sendes til kunde. Tilbudet kan også leveres elektronisk som NS utgave Pristilbud. Når tilbyder får jobben kan data fra tilbudet trekkes ut og overføres til eksterne systemer som MS Project for prosjektstyring, og administrative systemer som Visma, Agresso, Axapta med flere for budsjettering, bestilling og annet. Produktinformasjon: Eldata i pilotprosjektet Tanken bak aktiviteten var å starte en prosess som gjør det mulig å overføre verdier rett fra DAKverktøyet, og inn i ELdata. Dette er verdier som, føringsveier, kabler og stikk osv. Dette vil på sikt forenkle kalkyle- og tilbudsprosessen betydelig. Den prosjekterende vil konstruere/tegne et elektrisk anlegg i et bygg. Deretter overføres informasjonen til ELdata, som igjen kan beregne timer og materiell på dette. I dette prosjektet er det valgt ut noen spesifikke oppgaver som skulle løses. Det er nå mulig å overføre data fra MagiCAD til ELdata via IFC. Vi kan overføre objektsinformasjon kodet etter NS 3451 (bygningsdeler), NS 3420 (spesifiserende tekster) og ELdata.Koder. ELdata vil ved import fra IFC bygge opp en kalkulasjonsstruktur og omsette ELdata.Kode- referanser til Eldata-pakker med 70 av 75

71 kostnader/ytelser. Bruker kalkulerer prosjektet og kan deretter presentere resultatet fra tilgjengelige rapporter. Løsningen er ikke optimal, og kan forbedres. Vi har fått en god start og ser frem til å jobbe videre med IFC. Siemens Utviklingsmøter For å nå målene vi har definert i aktivitetsbeskrivelsen gikk vi sammen med TELFO, og inviterte aktuelle representanter fra programvareleverandører, utviklere og entreprenører, til felles utviklingsmøter (workshops). Representanter fra følgende bedrifter har deltatt i utviklingsmøtene: TELFO, Erik Selvik Elektro, AEC3, Nestor, Progman, Data Design System, Siemens, Gunnar Karlsen AS, Hjellnes Consult, SINTEF byggforsk og COWI AS. Det ble avtalt at vi skulle arrangere 4-5 utviklingsmøter i perioden fra mai 2007 til 1. desember TELFO og RIE byttet på å arrangere disse utviklingsmøtene. Første utviklingsmøte ble arrangert 2. mai. Arbeidet gikk ut på å kartlegge hva som skal utveksles av data/informasjon mellom de ulike programvarene (se avsnitt om aktivitetsbeskrivelsen). Dette betydde i praksis at vi skulle utvikle IDMer. Ansvarlig for at jobben med utvikling av IDMer gikk riktig for seg, var Jeffrey Wix fra ACE3. Agendaen i utviklingsmøtene ble stort sett delt i to. I den ene delen jobbet vi med Eldata og MagiCAD, mens vi i den andre delen jobbet med Febdok og MagiCAD. Vi prøvde oss også med parallelle seanser, men fant ut at dette ikke var den mest effektive måten å jobbe på. Til å begynne med kom vi best i gang med Eldata - MagiCAD koblingen. Men det viste seg etter hvert at denne koblingen ikke var så enkel som det virket i starten. Etter mye jobbing ble det besluttet å ta en midlertidig snarvei. For å komme i mål til pilotprosjektets avlutnings dato (14. desember), ble det opprettet et midlertidig propertieset: Pset_ElectricalCostData. Propertieset et inneholder NS3451, NS3420 og ElData kode (Figur 0.11). Som nevnt over er dette propertieset et kun midlertidig. Arbeidet med IDMen og Eldata koblingen vil fortsette på nyåret. Når ny versjon av Eldata blir lansert på Eliaden 2008 (mai) er dette propertieset et borte. CAD (MagiCAD og ElektroPartner) Febdok koblingen utgjorde hovedtyngden i utviklingsmøtene. Dette arbeidet har vært omfattende, da mange begreper, elektriske spesifikasjoner og lignende måtte på plass. En stor del av diskusjonene gikk også ut på hva man skulle gjøre i de ulike programmene. Det ble blant annet diskutert i hvilket program man skulle bygge opp det elektriske anlegget (typisk illustrert med et stigeledningsskjema). Løsningen ble at man selv kan velge hvor man ønsker å starte, med Febdok eller med et CAD verktøy. I motsetning til koblingen mellom MagiCAD og Eldata, inneholder koblingen mellom CAD og Febdok ingen program/nasjonalt spesifikt propertieset. Utvekslingen her er på IFC-format og med IFC-propertieset. 71 av 75

72 Figur 0.11:Stikkontakt med NS 3451, NS 3420 og Eldata kode Måloppnåelse og status Som nevnt i kapitlet om utviklingsmøtene vil arbeidet med IDMer og sømløsheten mellom programvarene forsett på nyåret. Det endelig målet med disse aktivitetene er fullstendig sømløshet mellom de utvalgte programvaretypene på IFC-format, uten program/nasjonal - spesifikke properties sett. Når det gjelder måloppnåelse i forhold til aktivitetsbeskrivelsen, er de fleste mål/del - aktiviteter er nådd. Hvis vi går igjennom de ulike delaktivitetene slik som de er satt opp i kapittel 0, kan vi se hva som er gjort: Anskaffelse av programvare: Vi har hatt tilgang til alle de nevnte programvarene. I tillegg har vi også brukt vieweren fra Octaga og DDS. Utvikle MagiCAD med tanke på IFC-eksport : Siden vi begynte å bruke MagiCAD (våren 2007) har utviklingen av IFC-delen i programmet vært svært bra. I starten var det kun mulighet til å eksportere til IFC-format, og dette var også med begrensede egenskaper på komponentene. Som tidligere nevnt i rapporten kommer ny utgave av MagiCAD ( ) ut rundt årsskiftet. Denne versjonen vil blant annet inneholde IFC eksport/import muligheter, samt koblingen mot Febdok og Eldata. Datautveksling mellom MagiCAD (CAD), Febdok og Eldata: Dette har vært vårt hovedmål. Som beskrevet i kapitlet om utviklingsmøtene er utvekslingen mellom CAD og Febdok på IFC-format, i orden. Utvekslingen mellom MagiCAD og Eldata er langt på vei i orden. Litt arbeid i forbindelse med propertieset gjenstår. ElektroPartner: Vi har prosjektert 2. etasje kjøkken- og serveringsdelen med programvaren. Plantegning og skjemategninger har blitt laget. Når det gjelder testing opp mot arkitekt IFC-modellen gikk ikke dette så bra. Dette skyldes tidligere omtalt problem (avsnitt om ElektroPartner) i forbindelse 72 av 75

73 med ADT. Etter import av ARK modellen inn i ElektroPartner ble modellen delt i feil etasjer. Koblingen mot G-PROG Beskrivelse har vi ikke fått sett på. Dette skyldes tidsressurser, samt prioritering. Vi vet likevel at denne koblingen fungerer bra. Oppbygging av BIM: I fase med den ordinære fremdriften på byggeprosjektet, koordinert mot tegningproduksjon, har vi bygget opp/beriket den digitale bygningsmodellen (BIM). Vi har fortløpende lastet inn IFC-filer på modell serveren. De siste filene er på IFC 2x3 format. Testing/simulering av BIM: RIE sine IFC-filer er lagt ut på modell-serveren, og blitt flettet ( merget ) sammen med ARK, RIV og RIB modellen. Denne jobben har Jotne EPM Technology hjulpet oss med. Av viewere har vi brukt Octaga og DDS IFC-viewer. Figur 0.12: Kjøkkenet i 2 etasje. Utsnitt fra IFC-modellen (viewer Octaga) 73 av 75

74 Erfaringer Da vi for fullt startet arbeidet med pilotprosjektet på nyåret 2007, fant vi raskt ut at IFC og selve IFCformatet ikke var utviklet godt nok. Selv om IFC har vært et begrep i flere år, har det ikke vært veldig utbredt annet enn i kretser for spesielt interesserte. Dette har nok satt sitt preg på utviklingen. Det som ofte gikk igjen av spørsmål og kommentarer fra folk utenfra, handlet om misforståelser med tanke på hvor langt IFC var kommet. Mange trodde at det var bare å skaffe seg de riktige IFCkompatible programvarene, og så var de i gang. Problemet er at man på markedet mangler programmer som behersket IFC fullt ut (foreløpig). Med dette utgangspunktet gikk flere av våre delaktiviteter ut på å jobbe sammen med blant annet programvareleverandører, for å videreutvikle programmene. Vi trodde nok før vi startet at vi skulle jobbe med litt andre aktiviteter enn hva det endte opp med. En annen ting som bør utbedres er selve prosessen med å flette, merge, ulike modeller. Dette må bli enklere. Det blir tungvindt at man er avhengig av hjelp fra andre for å få utført en merge. I Nye Ahus sitt tilfelle var det Jotne EPM Technology som hjalp oss med dette. Det må lages et enklere grensesnitt på modell-serveren som gjør det mulig for oss (eller andre aktører) å merge selv. Ser vi tilbake på arbeidet sitter vi igjen med mange gode erfaringer. Alle vi har vært i kontakt med i forbindelse med pilotprosjektet, hatt en positiv innstilling. Programvareleverandører og andre involverte bedrifter har jobbet svært bra, og vært veldig interessert i å utvikle programmene sine videre med hensyn til IFC-formatet. Uten velvilje fra bransjen kommer man ikke videre. Et slikt pilotprosjekt som frontbygget på Nye Ahus er med på drive IFC arbeidet veldig bra fremover. Man er avhengig av slike prosjekter for å ta nye steg videre. Det blir spennende å se utviklingen videre. Både nasjonalt og internasjonalt. Dagfinn Tanggaard, COWI AS 74 av 75

75 Konklusjon Prosjektets deltakere er ikke i tvil om at BIM er fremtiden. Og IFC er tross sine mangler det eneste format på markedet, som det er så stor tilsluttning til og som for det meste viser god funksjonalitet og potensiale. IFC-prosjektet har været en interessant og lærerik prosess for alle deltakerne. I det følgende vil vi forsøke å gi noen av våres overordnet erfaringer videre. IFC er ikke bare IFC. Det viser seg at det er forskjell på hvor godt ulike typer applikasjoner fungerer sammen. Dvs. at IFC-filer som innholder samme typer informasjon, men som er generert fra ulike modell-applikasjoner vil fungerer ulikt på mottaker-applikasjoner. Vær derfor sikker på at alle applikasjoner snakker sammen innen de velges. IFC-BIM er ikke en pakkeløsning. Det er en filosofi som bygger på et sett av internasjonale og nasjonale standarder IFC/IFD/IDM. Og det brukes mange ulike dataverktøy til å automatisere og effektivisere prosesser. Noen verktøy fungerer bedre ift. IFC enn andre. Vær selektiv når det velges hvilke prosesser som skal avprøves. Velg programvare som virker. Et program kan være veldig bra til noen prosesser uten at dets IFC-interface fungerer noe bra. IFC er et utvekslingsformat. Hvis det ikke er noen til å ta imot formatet (rådgivere, arkitekter, entreprenører etc.) er det ingen vits i å bruke det. Det skal med andre ord avtales med flere aktører å bruke formatet, og hvilke prosesser som skal gjennomføres. Hvor det finnes IDM er som beskriver prosesser, så integrer disse i DAK-manual og/eller kontrakt. Samarbeidet med IFC-format er ikke bedre enn modellene. Vær grundig med modelleringen og bruk riktig struktur. Kollisjonskontroll med Solibri Model Checker eller NavisWorks Jetstream Clash-Detective er opplagte verktøy å begynne med. De fungere stort sett uten problemer. De er brukervennlige, og potensialet for gevinstrealisering er stort uten stor innsats. Utstyrs- og romdatabasen fra Nosyko er brukervennlig og dokumenterer informasjon og beslutninger på en oversiktlig måte. Programvaren gir mulighet for mange gode funksjoner, for eksempel automatisk generering av rombehandlingsskjema. Så programvaren er i seg selv verdifull. Det å linke utstyrs- og romdatabase gir i tillegg en verdifull, digital, kvalitetsikrende sjekk av om modellen er konsistent med de beslutninger som er tatt i prosjekteringstiden. Tidligfase kalkyle er et viktig styringsverktøy og muligheten for å få kontroll på objekter og mengder med import av IFC-BIM har et stort potensial. Funksjonaliteten er bra og brukervennligheten er god. Kalkyle med IFC-BIM kan gjøres av ARK (og RIB) uavhengig av andre fag. Sømløshet handler om effektivitet i datautveksling. De prosjekterende i et byggeprosjekt er sjelden eksperter på ulike programvarer og IFC. De skal ofte komme i mål innen for en stram tidslinje og med begrenset ressurser. Det er en god idé å organisere seg slik, at tekniske spørsmål og utfordringer ivaretas av fagfolk. Dette kan evt. være gjennom avtale med programvareleverandørene. Og i den sammeheng er det grensesnittet mellom programmene som det skal fokuseres mest på. Steen Sunesen, Arkitektfirmaet C.F. Møller 75 av 75