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