Behandling: ÅPEN. F:\IFC\10 Fra Prosjekteringsgruppen (PG) i Bodø\HITOS_IFC_Forprosjekt-RAPPORT_norsk_v11.doc. Forfatter(e):

Transkript

1 RAPPORT Rapportdato: Behandling: Gradering: Language ÅPEN UGRADERT Arkivreferanse(r): F:\IFC\10 Fra Prosjekteringsgruppen (PG) i Bodø\HITOS_IFC_Forprosjekt-RAPPORT_norsk_v11.doc Prosjektreferanse(r): FoU: Objektbasert prosjektering Administrativt ansvarlig: FoU-direktør Anne-Grethe Woie, UP Dokumenttittel: Prosjektleder (tittel, navn, enhet) Senioringeniør Diderik Haug, UP Forfatter(e): Ernst Eberg, Norconsult AS (PGL) Turi Heieraas, Arkitektstudio AS (ARK) Jan Olsen, Norconsult AS (RIB) Svein-Helge Eidissen, SWECO Grøner AS (RIV) Sigmund Eriksen, Norconsult AS (RIE) Kai Haakon Kristensen, Skanska AS (ENT) Øivind Christoffersen, Statsbygg (Sb/DIR) Mai Anh Thi Lê, Statsbygg (Sb/ED) Frode Mohus, Statsbygg (Sb/FE) Erfaring med utvikling og bruk av en digital bygningsinformasjonsmodell (BIM) iht IFC-standarden ved byggeprosjekt Høgskolen i Tromsø (HITOS) etter avsluttet forprosjektfase Illustrasjonsbilde(r): Nøkkelord: forskning og utvikling informasjon modellering BIM IFC Bestilling: Sammendrag: Rapporten beskriver de konkrete erfaringer som prosjekteringsgruppen (PG) har hatt ved gjennomført forprosjektfase ved HITOS-prosjektet, med utarbeidelse av en bygningsinformasjonsmodell (BIM) basert på IFC-standarden, for Statsbygg som byggherre. PGs opplevelse av situasjonen er søkt gjengitt mest mulig direkte fra de involverte aktørene. Statsbygg har omgruppert noe av stoffet, tillagt enkelte forklaringer og utdypende tekster, og endret noe tekst. Statsbygg står således ansvarlig for denne rapporten slik den foreligger nå. Statsbyggs Administrerende Direktør Øivind Christoffersen har skrevet Forord til rapporten. Rapporten finnes både i norsk og engelsk versjon. Keywords research and development information modelling BIM IFC Statsbygg Postboks 8106 dep, 0032 Oslo Telefon: Fax: E-post: postmottak@statsbygg.no - Web: Dokumentinformasjon: Antall sider: 53 Antall ord: Antall tegn: Klassifikasjon(er): DDC: 62 UDC: 62 LC: TA

2 Statsbygg Side 2 av

3 FORORD Statsbygg er per i dag Norges største byggherre. Stortinget har gitt Statsbygg en oppgave i å bidra til effektivisering i bygg-, anlegg- og eiendomsnæringen (BAE-næringen) og i å initiere og delta i FoUprosjekter som fører til forenkling av prosesser og mer effektiv bruk av IKT i BAE-næringen. Med bakgrunn i dette har Statsbygg tatt mål av seg til spille en aktiv rolle i utviklingen av næringen og vi har tatt mål av oss til å bli ledende på IKT i BAE-næringen. BAE-næringen i dag kjennetegnes ved at informasjon utveksles ved alle-til-alle -kommunikasjon av den enkelte aktørs informasjons biter - tekstlig informasjon ved rapporter / notater eller tegninger typisk i form av DWG-filer. Dette skjer ofte per e-post eller ved bruk av webhoteller med filarkiver. Videre kjennestegnes situasjonen ved at mye av informasjonen registreres flere ganger enkelte rapporter angir sju ganger fram til overtagelse av bygget dessuten vedlikeholdes informasjonen også etter overtagelse av bygget i flere ulike applikasjoner. Den ønskede situasjonen både mht kvalitet og effektivitet vil derimot være en situasjon der alle aktørene i BAE-prosessene deler kvalitetssikret informasjon i en felles, intelligent datamodell, og at informasjonen legges inn kun én gang. Det er med dette bakteppet at Statsbygg som stor statlig byggherre og eiendomsforvalter i Norge de siste 2-3 årene har involvert i det internasjonale arbeidet som etter hvert er søkt samlet under paraplyen buildingsmart, gjennom organisasjonen IAI International Alliance for Interoperability. Statsbygg har som en av sine målsettinger å være en av bransjens mest profesjonelle oppdragsgivere og en ledende premissleverandør i utviklingen av, og bruk av digitale bygningsinformasjonsmodeller (BIM), basert på åpne standarder. Målet med denne satsingen er å øke verdiskapning i hele verdikjeden knyttet til lokalisering, planlegging, bygging, forvaltning, drift og vedlikehold av bygg. Statsbygg skal bidra til en bedre, og mer effektiv samhandling og informasjonsutveksling, mellom partene i byggeprosessen, gjennom forenkling og forbedring av prosesser. Mer effektiv bruk av IKT er sentralt, og må skje ved nytenkning, økt kompetanse, bruk og gjenbruk av data i sanntid og over tid. Statsbygg skal derfor initiere og delta i FoU-prosjekter for at det gradvis skal innføres og benyttes digitale bygningsmodeller gjennom hele byggets levetid. Dette skal dels foregå ved å bruke egne byggeprosjekter som pilotprosjekter, og dels gjennom en aktiv og bred deltagelse i utviklingen og bruk av standarder, som IFC, på nasjonalt og internasjonalt nivå. På denne bakgrunn er byggeprosjektet med samlokalisering av Avdeling for ingeniør- og økonomifag med Avdeling for lærerutdanning ved Høgskolen i Tromsø (HITOS) valgt ut som et pilotprosjekt for uttesting av BIM med IFC-standarden. Prosjektet er på ca 5000 m2, hovedsakelig nybygg / tilbygg til eksisterende ca m2 bygningsmasse på stedet. Programfasen (kravspesifikasjonsfasen) ble gjennomført fram til tidlig høst 2005, med bruk av en IFCkompatibel romfunksjonsdatabase. Skisseprosjekt (tidligfase prosjektering) ble levert i februar 2006 med en integrert IFC-modell for fagene Arkitekt, VVS, og Elektro, mens byggmodellen ( structural ) ble holdt separat i denne fasen av praktiske hensyn mht valg av IKT-verktøy. Forprosjekt ble levert i juni 2006, med en integrert IFC-modell for alle fag. Modellens innhold gjenspeiler i hovedsak et ambisjonsnivå mht detaljering som samsvarer med Statsbyggs normale forprosjekter. Denne rapporten gjengir status etter avlevert FoU-forprosjekt. Byggeprosjektet avventer nå myndighetenes videre bevilgninger. FoU-prosjektet vil videreføres i 2007 ved ytterligere uttesting av viktige forhold ved bruk av BIM, men prosjekteringen vil i prinsippet ikke bli ført videre i detaljering før byggestartbevilgning foreligger. Et avgrenset testområde av bygningen vil likevel kunne bli detaljert med formål å teste spesifikke forhold i FoU-prosjektet. Statsbygg Side 3 av

4 Effektmål Initiere og delta i forsknings- og utviklingsprosjekter (FoU) innen digitale bygningsinformasjonsmodeller (BIM) basert på åpne, IFC-relaterte standarder, og ved dette bidra til at det gradvis innføres og benyttes BIM gjennom hele byggets levetid. Benytte egne byggeprosjekter som pilotprosjekter for å teste ut i praksis bruk av IFC-basert BIM. Gjennomgå relevante juridiske problemstillinger knyttet til bruk av IFC-basert BIM for derigjennom å bidra til at det settes fokus på et eventuelt. behov for tilpasninger av eksisterende juridisk rammeverk Bedre datakvaliteten (pålitelighet, konsistens, gyldighet mv) i bygningsinformasjon. Øke verdien i bygningsinformasjon ved at det semantiske innholdet knyttet til bygningsobjektene (dvs betydningen av benyttede ord for objekter, deres egenskaper og relasjoner) gjøres presist og entydig ( intelligent ) ihht. omforente standarder som IFD. Minimalisere antallet manuelle inntastinger av bygningsinformasjon, og antallet manuelle konverteringer mellom ulike formater, måleenheter mv. Bidra til kostnadsreduksjoner, basert på den økte kunnskap/verdi som ligger i forbedret bygningsinformasjon. Bidra til å forbedre mulighetene for temarelaterte analyser (for eksempel innen LCC, energi, miljø, brann, lyd, universell utforming, levetider mv) basert på den økte kunnskap/verdi som ligger i bygningsinformasjonen. Oslo 26. oktober 2006 Øivind Christoffersen Administrerende direktør Statsbygg Side 4 av

5 FORKORTELSESLISTE Begreper ARK BARBi BIM buildingsmart Detaljprosjekt ENT Forprosjekt FoU GPP GUID IAI IDM IFC IfcSpace IFD Library IFD ISO ISO/PAS ISO/PAS Lexicon merge NS 3420 NS 3451 PG PGL Pset_ RIB RIE RIV Skisseprosjekt Arkitekt i en prosjekteringsgruppe Norsk bygg og anlegg referansebilbiotek etter IFD-standarden, Bygningsinformasjonsmodell(ering), branding av IAIs aktiviteter for å bygge smart, I norsk sammenheng normalt den tredje og siste prosjekteringsfasen. Refererer gjerne til fasen Coordinated Design i referanseprosessbeskrivelsen GPP Entreprenør i et byggeprosjekt I norsk sammenheng normalt den andre prosjekteringsfasen. Refererer gjerne til fasen Full Conceptional Design i referanseprosessbeskrivelsen GPP Forskning og Utvikling, tilsvarende engelsk R&D (research & development) Generic Process Protocol, Global Unique Identifier, et helt éntydig, unikt, autogenerert fødselsnummer som lages for hvert objekt i en IFC-modell, og som aldri skal endres eller gjenbrukes International Alliance for Interoperability, Information Delivery Manual, Industry Foundation Classes, Definisjon fra IFC-standarden som definerer et område, f.eks et rom, en romgruppe, et avgrenset areal osv, Sammenslått IFD-basert referansebibliotek mellom BARBi og Lexicon International Framework for Dictionaries, International Organization for Standardization, IFD - Building construction -- Organization of information about construction works -- Part 3: Framework for object-oriented information exchange, IFC - ISO/PAS 16739:2005 Industry Foundation Classes, Release 2x, Platform Specification (IFC2x Platform), &scopelist=PROGRAMME Nederlandsk Bygg og anlegg referansebilbiotek etter IFD-standarden, [eng.] slå sammen, forene, fusjonere; benyttes i BIM-sammenheng om en funksjon som muliggjør å generere én felles modell for alle fag, basert på kontrollert og kvalitetssikret sammensmelting av de ulike del-fagmodellene Norsk Standard NS 3420 Beskrivelsestekster for bygg, anlegg og installasjoner, Norsk Standard NS 3451 Bygningsdelstabell, Prosjekteringsgruppen (består normalt av ARK, RIB, RIV, RIE og eventuelle andre rådgiverdisipliner (geoteknikk, akustikk osv) Prosjekteringsgruppens leder Property Set, veldefinert mekanisme i IFC-modellen som gjør at man kan utvide egenskapsdefinisjoner ved objektene Bygningsteknisk ingeniør i en prosjekteringsgruppe Elektroteknisk ingeniør i en prosjekteringsgruppe VVS-teknisk ingeniør i en prosjekteringsgruppe I norsk sammenheng normalt den første prosjekteringsfasen, også dels kalt tidligfase. Refererer gjerne til fasen Outline Conceptional Design i referanseprosessbeskrivelsen GPP Statsbygg Side 5 av

6 STEP ISO Standard for the Exchange of Product model data, SubSpace Benyttet om oppdeling av et IfcSpace i mindre områder, typisk kan et rom (en IfcSpace med to ulike takhøyder til underkant dekke og to ulike nedhengte himlingshøyder i rommet danne fire ulike områder (SubSpace). Dette kan være ønskelig f.eks for å kjøre energisimuleringer U-verdi Termisk konduktivitet, angir materialets/elementets evne til å lede varme, YT Ytelsesbeskrivelse; Statsbyggs betegnelse på en kravspesifikasjon for de ytelser de ulike aktørene i PG (ARK, RIB, RIV, RIE osv) skal levere i ulike faser (skisseprosjekt, forprosjekt, detaljprosjekt, bygging osv) av et byggeprosjekt; se også begrepet IDM, som kan oppfattes som YT-er for en BIM-basert arbeidsprosess ARK Arkitekt i en prosjekteringsgruppe BARBi Norsk bygg og anlegg referansebilbiotek etter IFD-standarden, BIM Bygningsinformasjonsmodell(ering), buildingsmart branding av IAIs aktiviteter for å bygge smart, Detaljprosjekt I norsk sammenheng normalt den tredje og siste prosjekteringsfasen. Refererer gjerne til fasen Coordinated Design i referanseprosessbeskrivelsen GPP ENT Entreprenør i et byggeprosjekt Forprosjekt I norsk sammenheng normalt den andre prosjekteringsfasen. Refererer gjerne til fasen Full Conceptional Design i referanseprosessbeskrivelsen GPP FoU Forskning og Utvikling, tilsvarende engelsk R&D (research & development) GPP Generic Process Protocol, IAI International Alliance for Interoperability, IDM Information Delivery Manual, IFC Industry Foundation Classes, IfcSpace Definisjon fra IFC-standarden som definerer et område, f.eks et rom, en romgruppe, et avgrenset areal osv, IFD Library Sammenslått IFD-basert referansebibliotek mellom BARBi og Lexicon IFD International Framework for Dictionaries, ISO International Organization for Standardization, ISO/PAS ISO/PAS 16739:2005 Industry Foundation Classes, Release 2x, Platform Specification (IFC2x Platform), &scopelist=PROGRAMME Lexicon Nederlandsk Bygg og anlegg referansebilbiotek etter IFD-standarden, merge [eng.] slå sammen, forene, fusjonere; benyttes i BIM-sammenheng om en funksjon som muliggjør å generere én felles modell for alle fag, basert på kontrollert og kvalitetssikret sammensmelting av de ulike del-fagmodellene PG Prosjekteringsgruppen (består normalt av ARK, RIB, RIV, RIE og eventuelle andre rådgiverdisipliner (geoteknikk, akustikk osv) PGL Prosjekteringsgruppens leder Pset_ Property Set, veldefinert mekanisme i IFC-modellen som gjør at man kan utvide egenskapsdefinisjoner ved objektene RIB Bygningsteknisk ingeniør i en prosjekteringsgruppe RIE Elektroteknisk ingeniør i en prosjekteringsgruppe RIV VVS-teknisk ingeniør i en prosjekteringsgruppe Skisseprosjekt I norsk sammenheng normalt den første prosjekteringsfasen, også dels kalt tidligfase. Refererer gjerne til fasen Outline Conceptional Design i referanseprosessbeskrivelsen GPP STEP ISO Standard for the Exchange of Product model data, SubSpace Benyttet om oppdeling av et IfcSpace i mindre områder, typisk kan et rom (en IfcSpace med to ulike takhøyder til underkant dekke og to ulike nedhengte Statsbygg Side 6 av

7 U-verdi YT himlingshøyder i rommet danne fire ulike områder (SubSpace). Dette kan være ønskelig f.eks for å kjøre energisimuleringer Termisk konduktivitet, angir materialets/elementets evne til å lede varme, Ytelsesbeskrivelse; Statsbyggs betegnelse på en kravspesifikasjon for de ytelser de ulike aktørene i PG (ARK, RIB, RIV, RIE osv) skal levere i ulike faser (skisseprosjekt, forprosjekt, detaljprosjekt, bygging osv) av et byggeprosjekt; se også begrepet IDM, som kan oppfattes som YT-er for en BIM-basert arbeidsprosess Programvare ADT Archicad Calcus DDS drofus EPM Gemini Inopso Navisworks Octaga Revit Riuska SMC Tekla ADT Archicad DDS drofus EPM Gemini Inopso Octaga Revit Riuska SMC Tekla Autodesk Architectural Desktop, Graphisoft Archicad, Norconsult Informasjonssystemer (NOIS) G-PROG Calcus, Data Design System, Nosyko drofus, EPM Technology EDMServer, Powel Gemini Terreng, Inopso IFC utility plugin for ADT, Navisworks Jetstream, Octaga Modeller for IFC, Autodesk Revit, Granlund Riuska energisimuleringsprogram, Solibri Model Checker, Tekla Structures, Autodesk Architectural Desktop, Graphisoft Archicad, Data Design System, Nosyko drofus, EPM Technology EDMServer, Powel Gemini Terreng, Inopso IFC utility plugin for ADT, Octaga Modeller for IFC, Autodesk Revit, Granlund Riuska, Solibri Model Checker, Tekla Structures, Statsbygg Side 7 av

8 GENERELT Prosjektorganisasjon BYGGHERRE STATSBYGG Postboks 8106 DEP 0032 OSLO Telefon: Telefax: E-post: Web: Prosjektleder: Fagkoordinator Tele/aut. Overingeniør FoU Diderik Haug Frode Mohus Ole-Kristian Kvarsvik BRUKER: Høgskolen i Tromsø (HITOS) 9293 TROMSØ Telefon: Telefax: Web: Høgskoledirektør: Plan- og driftsleder/ Brukerkoordinator: IT-/Biblioteksdir.: Britt Elin Steinveg Tor-Arne Tiber-Olsen Kai Mathisen Engasjerte rådgivere PROSJEKTERINGSGRUPPELEDELSE (PGL) Norconsult AS Alsgården, Notveien 17, 8013 Bodø Telefon: Telefaks: Saksbehandler: Ernst Eberg E-post: eme@norconsult.no ARKITEKT (ARK) Arkitektstudio as Postboks 234, 8001 BODØ Telefon: Telefaks: Saksbehandler Ole Martin Hartløfsen E-post: ole-m@arkitektstudio.no Turi Heieraas turi@arkitektstudio.no RÅDGIVENDE INGENIØR I BYGGETEKNIKK (RIB) Norconsult AS Alsgården, Notveien 17, 8013 Bodø Telefon: Telefaks: Saksbehandler: Jan Olsen E-post: jko@norconsult.no Statsbygg Side 8 av

9 RÅDGIVENDE INGENIØR I VVS-TEKNIKK (RIV) Sweco Grøner AS Jernbaneveien 85, 8006 Bodø Telefon: Telefaks: Saksbehandler: Svein Helge Eidissen E-post: svein.helge.eidissen@sweco.no RÅDGIVENDE ING.ENIØR I ELEKTROTEKNIKK (RIE) Norconsult seksjon Elektroteknikk (tidligere Ingeniørtjeneste AS) Storgt BODØ Telefon: Telefax: Saksbehandler: Sigmund Eriksen E-post: ser@norconsult.no Entreprenør (ent) Skanska Norge AS Postboks BODØ Telefon: Saksbehandler: Kai Haakon Kristensen E-post: kai.haakon.kristensen@skanska.no Statsbygg Side 9 av

10 INNHOLDSFORTEGNELSE FORORD... 3 EFFEKTMÅL... 4 FORKORTELSESLISTE... 5 BEGREPER... 5 PROGRAMVARE... 7 GENERELT... 8 PROSJEKTORGANISASJON... 8 ENGASJERTE RÅDGIVERE... 8 ENTREPRENØR (ENT)... 9 INNHOLDSFORTEGNELSE OPPSUMMERING ARKITEKTFAG (ARK) BYGNINGSTEKNIKK (RIB) VVS-TEKNIKK (VVS) ELEKTROTEKNIKK (RIE) SKANSKA NORGE AS (ENT) INNLEDNING MODELLERING ARKITEKT (ARK) MÅLSETTINGER I FORPROSJEKTET Evalueringer MODELL Evaluering OBJEKTEGENSKAPER Evaluering APPLIKASJONER I FORPROSJEKTET MODELLSERVER OG EVALUERING MODELLERING BYGGETEKNIKK (RIB) MÅLSETTINGER I FORPROSJEKTET MODELL AV BYGNING OG TERRENG Evaluering av modelleringsnøyaktighet. Detaljnivå OBJEKTEGENSKAPER APPLIKASJONER I FORPROSJEKTET MODELLSERVER Evaluering MODELLERING VVS-TEKNIKK (RIV) MÅLSETTINGER I FORPROSJEKTET MODELL MODELLERING OG PROSJEKTERING I DDS BEREGNING I RIUSKA OBJEKTEGENSKAPER APPLIKASJONER I FORPROSJEKTET SAMT EVALUERINGER VED BRUK MODELLSERVER Evaluering MODELLERING ELEKTRO-TEKNIKK (RIE) MÅLSETTINGER I FORPROSJEKTET Statsbygg Side 10 av

11 5.2 MODELL VEIEN VIDERE OBJEKTSEGENSKAPER APPLIKASJONER I FORPROSJEKTET MODELLSERVER ENTREPRENØRENS ROLLE (SKANSKA) MÅL OG HENSIKT - DELTAKELSE I IFC-FORPROSJEKT AMBISJONER PROSESSEN Anbudskonkurranse Entrepriseform Kalkulasjon/Kostnadsoverslag EVALUERING AV REKALKULASJON VHA IFC OG G-PROG CALCUS Programvaren Import av IFC-filer Elementnavn/bibliotek IFC-viewer Resultat FORBEDRINGSOMRÅDE FOR CALCUS IFC Generelt AMBISJONENE FOR ENTREPRENØRENS ROLLE I DETALJPROSJEKTET Generelt E-handel Fremdriftsplanlegging Terrengmodell Calcus Bidrag inn i modellen KONKLUSJON Statsbygg Side 11 av

12 Merknad fra Statsbygg: Det vesentligste av innholdet i de etterfølgende kapitler gir uttrykk for oppfatninger og opplevelser gjengitt direkte fra prosjekteringsgruppen dog med enkelte omformuleringer/ redigeringer og omgruppering fra Statsbyggs side. Det vil kunne være nyanser i oppfatninger av enkelte punkter mellom ulike aktører og sett fra ulikt ståsted, men vi har valgt å gjengi mest mulig direkte de opplevelser som er rapportert, ganske enkelt fordi vi tror praktisk erfaring i reelle situasjoner i prosjektene er den mest fruktbare måten å diskutere seg fram til framtidige løsninger og måter å bruke BIM på. Eventuelle rene faktafeil og misforståelser av betydning som måtte oppdages bes meldt til Statsbygg, for senere oppretting av rapporten. Teksten er skrevet sommer/tidlig høst 2006, i etterkant av levert forprosjekt. OPPSUMMERING Arkitektfag (ARK) Arbeidet med å endre den hovedsakelig geometribaserte IFC-modellen fra skisseprosjektet til en modell med flere nyttige IFC-egenskaper har i tillegg til ytterligere modellering, tilføring av egenskaper også bestått av avklaringer av hvilke egenskaper som hører hjemme hvor i IFC-atributter og property sets (Pset_). Hvordan ulik informasjon skal benevnes har også vært gjenstand for diskusjon. IFC-egenskaper er blitt tilført objekter og testet ut ved IFC-eksport og import i de andre fags applikasjoner. Erfaringene har variert fra stor frustrasjon til desto større glede når alt fungerer som det skal og resultatene blir som forventet. Forprosjektarbeidet har skapt ytterligere forståelse for hva IFC og BIM innebærer. Prosjekteringsgruppa har jobbet tettere sammen internt og eksternt sammen med Statsbygg og programleverandører. Det å kunne sjekke egen modell i SMC har gitt en del nyttige erfaringer om modelleringstekniske temaer, og vært flott kvalitetssikring av eget arbeid. Vi er så vidt kommet i gang med kollisjonssjekker fagene imellom og har allerede sett hva SMC er i stand til å avdekke. Videre i FoU-prosjektet blir det nødvendig å bruke tid til sjekk av alle fagene i SMC. Tettere samarbeid med entreprenøren for å få sjekket modellen mot deres arbeidsverktøy / applikasjoner er også nødvendig. Arbeidet så langt har også avdekket behovet for et felles nasjonalt elektronisk produktbibliotek og klare retningslinjer for utfylling av IFC-egenskaper. Det er flere som jobber med dette i dag, så det burde samarbeides med disse også. Bygningsteknikk (RIB) Av utfordringer videre i FoU-prosjektet nevnes følgende: Modelleringsnøyaktighet og krav til nøyaktighet i 2D-tegninger må avklares, Bruk av detaljhenvisninger i modellen må diskuteres nærmere (hvor langt det skal modelleres før man henviser ut til statiske detaljbeskrivelser, for eksempel i PDF-format) Grensegangen mellom arkitektverktøy (som ADT) og konstruksjonsprogrammer (beregnet for structural -formål) Armering: Beslutning om det skal modelleres i 3D eller ikke (i så fall: Valg av programvare) Terrengmodell: videre samarbeid med Powel eller samarbeid med Skanska Statsbygg Side 12 av

13 Utvide samarbeidet med for eksempel EDR (som leverandør av Tekla Structures i Norge). Statsbygg foreslås av RIB å spille en aktiv rolle Leverandørprosjektering: Innlegging av informasjon i modell fra Skanska mv må avklares Etablere av IDM-er for alle fag Modellserver må stabiliseres Feil ved delvis import og eksport (under oppretting) må sjekkes VVS-teknikk (VVS) Prosjektering med 3D-modellering med objektinformasjon kommer til å være fremtiden, her er det mange muligheter for kunne forbedre byggeprosessen for alle involverte parter. Muligheten for visualisering tidlig i prosessen for brukere. Utveksling og beregninger/prosjektering mellom forskjellige fag gjør at det er mulig å unngå feil og kan på et tidligere tidspunkt ta riktige beslutninger, noe som gjør at entreprenørene får et komplett grunnlag å treffe sine beslutninger på - for slik å kunne koordinere bedre, og unngå feil. IFC-prosjektering innebærer at man må legge mer informasjon inn i tegningene (modellen), og tidligere enn i normal (tradisjonell) prosjektering. Dette medfører at tidsforbruket vil øke, men når man tenker på hvor liten del av totalen prosjekteringskostnadene utgjør, vil en økning her være minimal i forhold til en besparelse i byggefasen. Da vi i dag står i startfasen for IFC-prosjektering, står prosjekteringsgruppen overfor en del utfordringer som må løses. Her vil videre utvikling av IDM-er og avklaringer i forhold til hvilken informasjon som hvert enkelt objekt skal inneholde bli viktig. Målsettingene for VVS i modellen er ikke helt oppnådd, men vi vil sette fokus framover på å jobbe ut en bedre modell, kunne komplettere modellen med mer energidata, og kanskje kunne kjøre vindsimulering på modellen (bl.a. for å avdekke om det ved framherskende vindforhold kan oppstå større snøansamlinger foran planlagte innganger). Elektroteknikk (RIE) Når denne delrapporten skrives (tidlig høst 2006) har elektro nok dessverre ikke klart å komme riktig så langt modelleringsmessig som var det ønskede ambisjonsnivå, men vi fortsetter å modellere flere anlegg i 3.etg framover, og berike modellen med mer informasjon. Det har gått med mye tid til å gi tilbakemelding til DDS om ting som ikke fungerer helt som forventet i programmet. Det vil fortsatt være viktig med hurtig tilbakemelding fra DDS, slik at det ikke blir stopp pga at applikasjonen ikke er i stand til å utføre de ønskede operasjoner. Vi har også hatt store utfordringer med å få importert nye modellgrunnlag fra ARK, men dialogen har vært god, så dette ser ut til å være overkommelig i løpet av relativ kort tid. Utfordringene fremover blir å få modellen til å bli bedre gjennom samarbeid med DDS for å få applikasjonen til å fungere godt, samt å bruke modell-sjekkere og modellserver for å gjøre byggbarheten av modellen bedre. Det har vært en sann fornøyelse og se at vi faktisk har fått til å samle alle fag i én felles modell og gjort sjekker av denne. Vi ser frem til å ta videre tak i utfordringene og jobbe med problemene, slik at vi etter hvert får en bedre og bedre modell. Skanska Norge AS (ENT) Entreprenørens deltakelse i tidligfase av prosjektering er etter Skanskas mening en betydelig nøkkel for å oppnå suksess for alle parter i byggeprosjekter. Ved innføring av BIM - og her IFC - inn i prosjektet, gir dette mulighet for mer effektive byggeprosesser, enklere beslutningsprosesser samt en mer forutsigbar hverdag i bransjen. Dette vil føre til lavere kostnader samt reduksjon av feil i prosesser og i bygg. Statsbygg Side 13 av

14 1 INNLEDNING Statsbygg har valgt byggeprosjektet Høgskolen i Tromsø - Samlokalisering av avdeling for lærerfag (AFL) og avdeling for ingeniør- og økonomifag (AFL) som pilotprosjekt for sin FoU - aktivitet knyttet til digital bygningsmodellering ved bruk av IFC. Hensikten med forskningsprosjektet er å teste mulighetene til forbedring og effektivisering av byggeprosesser. Rapporten beskriver gjennomføringen av forprosjektfasen ved bruk av IFC - dels med beskrivelser av prosessen samt oppnådde resultater mhp. modellering inkl etablering av objektegenskaper. Hensikten med denne statusrapporten er å: Overføre praktiske erfaringer i forbindelse med arbeid med IFC-verktøy Dokumentere effekter Avdekke avvik i forhold til målsettinger Leveransen i IFC Forprosjekt består av: Digital bygningsmodell i IFC format ( merget alle fag). IFC Forprosjektrapport Prosjekteringsgruppen (PG) for Høgskolen i Tromsø (HITOS) har gjennomført modelleringen av den aktuelle bygningsmassen ved bruk av sine respektive modelleringsverktøy, og det er etablert en merget digital bygningsmodell i IFC-format på modell-server. Skanska Norge AS har som entreprenør bidratt gjennom forprosjektfasen med vurderingen av løsninger og byggbarhet samt at det er gjennomført kostnadsanalyser basert på den digitale bygningsmodellen i IFC format. Prosjekteringsgruppen har valgt å systematisere rapporten fagvis der det fokuseres på: Modell og detaljnivå Objektegenskaper Applikasjoner Modellserver/merging Det vises for øvrig til egen forprosjektrapport levert i byggeprosjektet: Høgskolen i Tromsø. Forprosjekt Ikke vedlagt her. Statsbygg Side 14 av

15 2 MODELLERING ARKITEKT (ARK) 2.1 Målsettinger i forprosjektet Modellen skal ved forprosjekt være brakt til et nivå hvor alle hovedgrep er på plass. Yttervegger skal inneholde dører og vindu vist i rett størrelse og form. Disse elementene skal også være påført eventuelle brann- og lydklasser samt vise slagretning. Ytterveggenes materialoppbygging/hovedmateriale skal også være på plass. Modellen skal inkludere øvrige utvendige elementer som påvirker uttrykket (fasadeuttrykket). Innvendige vegger med dører og vinduer skal være på plass slik at alle rom har fått sin form og plassering i bygget. Innvendige dører og vinduer skal også være påført brann- og lydklasse samt slagretning Innvendig hovedmaterialbruk skal være med Hovedgrep for brann og lyd skal kunne leses av vegger, dører og vindu. Fargebruk/overflatekvaliteter skal kun medtas dersom det foreligger spesielle krav som medfører større kostnadskonsekvenser. Modellen skal gi tilstrekkelig grunnlag for de øvrige fag iht avtalt ambisjonsnivå. Tekniske rom, hovedsjakter og El-skap skal være plassert. Modellens objekter skal typebetegnes slik at mengdeuttak er mulig. Alle rom skal ha sin IfcSpace ihht romprogram. Dette gjelder også arealer som ikke er programmert slik som tekniske rom, kommunikasjonsarealer og toalett/garderober. Sub-spaces skal defineres dersom det er behov for detaljert energisimulering eller andre tekniske beregninger. Modellen skal følge gjeldende IDM-er i den grad disse er ferdigstilt. Modellen skal sjekkes i Solibri Model Checker (SMC) Evalueringer Ytelsesbeskrivelsen for arkitektfaget er uproblematisk å utføre i IFC-standarden. Unntaket er kanskje kravet til tegning av detaljer i målestokk M 1:5, 1:20. Takplaner er forløpig ikke mulig å modellere i ArchiCAD. Sammenhengen mellom bygg og tekniske anlegg vil enkelt kunne illustreres i en IFC-modell. I dagens YT er det ikke stilt krav om himlingsplaner. Da de tekniske fag er forutsatt å vise sine hovedføringer, er det kanskje nødvendig at arkitekten viser himlingene i sin modell; og som et minimum vise i hvilke høyder himlingene ligger i. Når det gjelder arealoppstillingene kreves det arealtabell som viser netto programareal, netto skisseprosjektareal og netto forprosjektareal. I drofus er det ikke egen kolonne for skisseprosjektet. Det er ukjent om en slik kolonne kan innarbeides eller om andre programleverandører har slike muligheter. 2.2 Modell Arkitektens forprosjektmodell for Høgskolen i Tromsø viser alle hovedgrep på de to bygg som utgjør nybygget. I tillegg er alle nye vegger, dører og vinduer samt gjenmuringer i eksisterende bygg medtatt. Alle vegger er detaljert med materialoppbygging, brann og lydklasse. U-verdi er ikke påført ytterveggskonstruksjoner siden RIV ikke kan utnytte denne informasjonen i dette prosjektet (Riuska har i øyeblikket ikke importmulighet for dette). Modellen inneholder bæresystemer som søyler, dekker og betongvegger. Objekter som trapper av betong, toalett og servanter som tilhører henholdsvis RIB og RIV er også medtatt i vår modell. Dører og vinduer er på plass både hva dimensjon, form og plassering angår. Brannklasser og lydklasser er også påført. Hovedmaterialer er definert og modellens fargesetting indikerer ønsket uttrykk. Alle rom har fått sin IfcSpace hvor også himlingshøyde er definert. Statsbygg Side 15 av

16 Romnummer er identisk med programmert romnummer. Rom/Spaces kan senere påføres et romnummer til bruk i byggeprosessen og eventuelt et som bruker benytter til fysisk merking av rom. Subspaces er ikke definer i modellen ennå. RIV har ikke kunnet nyttegjøre seg en slik informasjon ennå og det er noe uklart hvordan disse skal utformes, navngis osv. Det er lagt inn himlinger i alle rom ved hjelp av dekke-verktøyet (slab-tool i Archicad). Tekniske rom, sjakter og Elektriske fordelingsskap er plassert i samråd med de respektive fag. Modellen i DDS IFC Viewer Modellen i Solibri Model Checker Figur 1 Visualisering av modellen i to verktøy Detaljeringsgraden varierer noe. Alle vegger er i ArchiCAD detaljert med alle sjikt. Dette vises også i modellens ifc-data men kan være vanskelig å se i en viewer. Se eksempler. Utsnitt av plan i DDS IFC Viewer Figur 2 Detaljeringsvisning i to ulike verktøy Utsnitt av plan fra ArchiCAD Dører og vinduer har høy detaljeringsgrad. Overganger dekke/vegg - vegg/tak er ikke detaljert slik de blir utført da dette vil kreve for mye modellering. Dekkerforkanter er heller ikke modellert som egen veggtype ytterveggen går opp til overkant dekke i etasjen over. Yttertakenes falloppbygging og tekking er ikke medtatt i modellen da programmet (Archicad) ikke har noe godt verktøy for dette. Vi vil teste ut ulike måter å løse dette på. Statsbygg Side 16 av

17 Innvendig utsnitt i Solibri Model Checker Figur 3 Utsnitt vist i SMC Innvendig utsnitt i Solibri Model Checker Evaluering Archicad har vært et godt verktøy å jobbe med, men har også skapt til dels store problemer, som for eksempel da all IFC-informasjon forsvant fra modellen. Problemet ble løst ved hjelp av Graphisoft, men årsaken er ikke funnet. At programmet mangler merge-funksjonen skaper problemer både når nye rom skal importeres fra drofus og når de øvrige fags modeller skal importeres. Det savnes en søk-/ erstatt-funksjon basert på IFC-egenskaper. I siste del av forprosjektet har det vært knyttet direkte kontakt mellom oss som bruker og Graphisoft som programleverandør. Siden vi har jobbet med 3d-modellering i mange år er måten å jobbe på i et Ifc-basert prosjekt på mange måter likt et tradisjonelt prosjekt. Forskjellen ligger i nøyaktigheten i 3D-modelleringen og behovet for å modellere mer enn man gjør tradisjonelt. Å legge IFC-informasjon på alle deler av modellen er en helt ny del av prosjekteringen. Dette har tatt lang tid i FOU-prosjektet siden retningslinjene ikke var klare. Det blir mye fokus på modelleringsdelen av prosjekteringen og de datatekniske sidene ved IFC. Det er behov for klare definisjoner på hvilken informasjon som hører hjemme hvor. 2.3 Objektegenskaper Arkitektens modelleringsverktøy ArchiCAD har mulighet til å knytte mye IFC-egenskaper til sine objekter. Alle objekter har standard attributter som Ifc GUID (globalt identifikasjonsnummer), IfcName, Object type, Description og Tag. Alle objekter har også et property_set_common hvor blant annet brann- og lydklasse spesifiseres. I tillegg har dør, vindu og space (zone) verktøyene flere property_sets. Det er mange property_set som ikke er utfylt til forprosjektet, men som vil bli testet ut mot de øvrige fagene samt entreprenør i neste fase. De objektegenskaper som er på plass i modellen er GUID, IfcName, Description, Object type, Brannog lydklasse (Fire rating, acoustic rating) samt referanse der dette forefinnes. Se eksemplet som viser en innvendig vegg: GlobalId Name Description ObjectType Navn 3aNTigAIH2qBdn33QvxNjQ AV02T Stålbindingsverk Innervegg Verdi Figur 4 IfcWallStandardCase Statsbygg Side 17 av

18 Navn Verdi Beskrivelse LAYERNAME A24_Innervegger. INFO AV02T. REFMATNAME HVITT. SIDEMATNAME HVITT. OPPMATNAME HVITT. WALL CONTPEN Pen241. WALL CONTLTYPE WALL CONTPEN3D Hel linje. Pen241. WALL FILLPEN Pen241. WALL FILLBGPEN Pen91. WALL USECOMPPENS WALL USECOMPBGPEN Figur 5 Graphisoft AC90 WALL : Graphisoft AC90 Navn Verdi Beskrivelse Reference Rockwool 8.17 Reference ID for this specified type in this project (e.g. type 'A-1') AcousticRating 47dB Acoustic rating for this object. It is giving according to the national building code. It indicates the sound transmission resistance of this object by an index ration (instead of providing full sound absorbtion values). FireRating A60 Fire rating given according to the national fire safety classification. er yttervegg usann Indication whether the element is designed for use in the exterior (TRUE) or not (FALSE). If (TRUE) it is an external element and faces the outside of the building. Figur 6 Pset_WallCommon Gips Navn Verdi Beskrivelse volume m³ QTO_CLASSIFICATION Gips Navn Verdi Beskrivelse volume m³ QTO_CLASSIFICATION Stålbindv. Navn Verdi Beskrivelse volume m³ QTO_CLASSIFICATION Gips Statsbygg Side 18 av

19 Navn Verdi Beskrivelse volume m³ QTO_CLASSIFICATION Figur 7 Materialoppbygging av vegg IfcElementQuantity Navn Verdi Beskrivelse volume m³ QTO_CLASSIFICATION horizontal area m² QTO_CLASSIFICATION left face area m² QTO_CLASSIFICATION right face area m² QTO_CLASSIFICATION PSet_Draughting Navn Verdi Beskrivelse Layername A24_Innervegger. Red 0. Green 0. Blue 0. IfcMaterialLayerSet : 'AV02T' Materialnavn Materiallag tykkelse Er ventilert Gips 13 mm. Gips 13 mm. Stålbindv. 100 mm. Gips 13 mm. Owner Info Navn ApplicationFullName ArchiCAD 9.0 ApplicationDeveloper Graphisoft User_FamilyName Turi User_Organization OrganizationName CreationDate Fri Jun 30 05:10: Verdi Figur 8 Andre egenskaper angitt for en vegg Evaluering ArchiCAD har mange standardobjekter i sine biblioteker. Det er også enkelt å bygge favoritter (prosjektbiblioteker) som for eksempel en veggtype med IFC-egenskapene forhåndsutfylt. Programmet svikter imidlertid når man senere benytter disse IFC-egenskapene følger ikke med. Flere av programmets objekter trenger flere innstillingsmuligheter både når det gjelder utseende og materialegenskaper. Som et eksempel kan nevnes glassfelt (curtain wall) som ofte har tette materialer i feltene som går forbi dekkeforkant mens de andre feltene har glass. Det lar seg ikke gjøre å definere dette i dag. Det er gitt tilbakemelding til programleverandøren Graphisoft på mangler og ønsker. Statsbyggs tverrfaglige merkesystem TFM er ønsket benyttet i prosjektet. For vårt fag er det ønskelig at lokaliseringskoden blir plassert på IfcSite. Vi er usikre på hvordan systemskoden skal benyttes på de ulike komponentene i vår modell. Vi tror løsningen kan bli at de bygningsmessige objektene i modellen kun er merket med produktkoden. Forprosjektmodellen er kodet med TFM-systemets Statsbygg Side 19 av

20 produktkode på alle innvendige- og utvendige vegger samt dører og vinduer i 3.etg. Det er ingen automatisk generering av TFM-koder i programmet slik at de må legges inn manuelt. 2.4 Applikasjoner i forprosjektet Modellen er modellert i ArchiCAD. drofus (program for rom- og utstyrsprogrammering) er benyttet både for å kreere dummy-spaces for alle programmerte rom, og for å sjekke prosjekterte arealer. DDS IfcViewer har vært benyttet for å se på modellen både i plan (2D) og 3D samt kontrollere IFCegenskaper. EPM modellserver med Octaga Modeller integrert har også vært benyttet. Modellsjekkerprogrammet Solibri Model Checker (SMC) har vært brukt, i hovedsak til kontroll av egen modell, men også noe kontroll av alle fag. Figur 9 Kollisjon mellom to vegger avdekket ved modellsjekk i SMC Terrengmodelleringsverktøy har vært savnet i forprosjektfasen. Det hadde også vært ønskelig med applikasjoner for uttak av mengde/beskrivelse og kostnadsberegning. 2.5 Modellserver og evaluering Vi har eksportert og importert egen modell til vårt område på modellserveren med blandede resultater. Enkelte ganger fungerer den enkle drag and drop -funksjonen mens det andre ganger har vært så å si umulig å importere/eksportere filer. De fleste av problemene vi har hatt underveis er nå løst, og da er denne funksjonen ikke noe problem. Modeller tilhørende andre fag er også eksportert fra modellserveren med samme erfaring som med egen modell. Det har vist seg at det å merge (sette sammen) alle fags modeller i modellserveren ikke har vært så enkelt som vi trodde. Noe skyldes nok at IDM-ene ikke er ferdige og implementert i modellserveren. Modellserverleverandøren EPM har lyktes i å merge alle fags modeller og en opplæring ble gitt prosjekteringsgruppa på et arbeidsmøte. Modellserveren har vært for ustabil. Det er ikke helt enkelt å finne ut av modellenes størrelse og alle nødvendige data som dato for import til modellserveren. Brukergrensesnittet kan her forbedres. Det forekommer mange feilmeldinger fra modellserveren som er vanskelige å forstå. Mange av dem skal man heller ikke bry seg om ifølge leverandøren. Det må her sies at produktet har vært i en utviklingsfase i samme periode. Statsbygg Side 20 av

21 Feilmeldingene sammen med ustabiliteten som serveren har hatt har skapt mye forvirring. Det hadde vært ønskelig at modellserveren bare ga feilmeldinger som man faktisk skal forholde seg til. Vi savner enkel funksjonalitet som det å kunne se at programmet jobber når man importerer/eksporterer en fil. Statsbygg Side 21 av

22 3 MODELLERING BYGGETEKNIKK (RIB) 3.1 Målsettinger i forprosjektet Målsettingen i IFC-forprosjektet er kort gjengitt nedenfor: Gjennomføre en import av ARK-modellen som grunnlag Alle normale bærende elementer skal være modellert geometrisk RIB-objektene skal tilføres normale Structural -egenskaper Uttesting med Tekla Structures for å forsøke å tilføre en 3D armering Forsøke å løse problemene knytte til dobbelt eierskap til objekter (f.eks dekker, bjelker, søyler) der både ARK og RIB gjennom prosessene eier objektet for å tilføre det egenskaper Samarbeide med Powel Gemini for å få en terrengmodell i IFC-format For RIB har i målsettingen i forprosjektet i tillegg vært å skrive ut konstruksjonstegninger fra egen modell, med tekst og målsetting i tråd med Statsbyggs ytelsesbeskrivelser. 3.2 Modell av bygning og terreng Modellen er generert i Architectural Desktop 2005 (ADT) Produktversjon N Programmet benyttes til modellering av bygningskonstruksjoner ADT bygger på AutoCad-plattformen, og kan betraktes som en videreutvikling av det kjente AutoCad. Verktøyet ble innført som ett av Norconsults bygg- modelleringsverktøy i januar ADT er, som det ligger i navnet, i utgangspunktet utviklet for arkitekter, basert på objektbasert 3D modellering av bygningskonstruksjoner. Programmet kan i et begrenset omfang modellere terreng og terrengendringer. Programmet har stor utbredelse, med totalt ca lisenser i Norge og ca i verden. Programmet er fleksibelt med hensyn til brukertilpasninger og har en rekke brukere utenfor arkitektmiljøet. Nedenfor vises isometrisk, forminsket plott av RIB-modellen, plottet fra ADT. Modellen er generert ut fra importerte IFC-filer fra arkitekt, og rene DWG-filer. Figur 10 Isometrisk plott av RIB-modellen Modellen inkluderer alle konstruksjonselementer som søyler, dragere, dekker og fundamenter. Alle elementer har fått tilført egenskaper så langt IFC-standard 2x2 final dekker konstruksjonselementer. I tillegg er objektene tilført materialegenskaper for stål og betong. Belastningen på dekkene er påført som egenskaper på dekkene. Statsbygg Side 22 av

23 Merk at Addendum 1 til IFC 2x2 ikke er dekket av ADTs IFC-pluginmodul (Inopso). Konstruksjonsopplysninger som treghetsmomenter, slankhet på søyler, konstruksjonsforbindelser mellom elementene etc, er ikke tilført modellen. Siden ADT ikke er et konstruksjonsverktøy, ville dette være en nokså tidkrevende og unødvendig prosess. Konstruksjonsprogrammer (applikasjoner) som laster ned IFC-modellen vil imidlertid i kunne tilføre disse egenskapene i forbindelse med kalkulasjonen. Nedenfor er samme modell presentert etter eksport til server, gjennom Octaga Modeller viewer. Figur 11 Modell etter eksport til server, gjennom Octaga Modeller viewer Grafisk sett overføres modellen godt. Property ene en likeledes overført. Ved tilbakeimport til egen modell ser all grafisk informasjon ut til å ha endret seg. Objektinformasjonen er intakt. Enkelte objekter forsvinner i løpet av eksporten til IFC. Vi tror at dette er et ADT-/Inopso-problem. Dette er objekter som er sammensatt av flere objekter i ADT. Som eksempel nevnes en stål gitterdrager som skal stive av glasspartiet i front. Den er modellert i ADT ved hjelp av forskjellige stålprofiler og deretter definert som et objekt. Ved eksport overføres bare deler av gitterdrageren. Problemet har vært forsøkt løst i IFC-modulen til ADT ved å definere hele objektet som object. Da får en eksportert hele drageren, men den er da delvis speilvendt. Norconsult har ikke et modelleringsverktøy for terreng som kan kommunisere gjennom et nøytralt industriformat med andre programmer. Powel Gemini har verktøy for dette. Norconsult har utvekslet noen filer med firmaet med tanke på en terrengmodell av utgravingen. Statsbygg Side 23 av

24 Figur 12 Plott av graveplan utarbeidet i Powel Gemini Evaluering av modelleringsnøyaktighet. Detaljnivå Modelleringsnøyaktighet Å ivareta alle detaljer i en bygningskonstruksjon direkte i 3D-modellen anses som svært tidkrevende med ADT som verktøy. Det er ikke utviklet biblioteker som kan modellere typiske detaljer som f.eks. søylefot, bjelke-/søyleforbindelser etc. Inn i byggefasen ser vi at det må utarbeides detaljskisser (2D) som supplement til 2D-planer og 3D-modell. I forprosjektet har det ikke vært lagt vekt på detaljeringsnøyaktighet i modellen. For eksempel er det ikke modellert konsoller på søylene. For samspillet mellom fagene er det viktig at de korrekte detaljene modelleres. Søylekonsoller er en slik sak. Objektinformasjonen vil til enhver tid kunne styres i ADT. Modelleringsnøyaktighet i de forskjellige fasene av byggeprosjektet 3D-modellering tillater høy grad av innhold knyttet til property ene i en tidlig fase av prosjekteringen. Det kan gi et informasjonsinnhold som ikke er relevant for de forskjellige fasene i et byggeprosjekt (skiseprosjekt, forprosjekt etc.) Dette kan styres av en IDM som er faseorientert. Så vidt vi vet skal arbeidet med en IDM for structural -området være avsluttet i løpet av høsten Nøyaktighetsgraden som kreves for utprising vil også være en styrende faktor for modelleringsnøyaktigheten. Høgskolen i Tromsø er organisert som et totalprosjekt og priset ut med basis i beskrivelse av elementer som stort sett er sammenfallende med objektene i IFC. IFC-modellen skal slik den nå foreligger i prinsippet kunne brukes for utprising på objektnivå. Dersom en i fremtiden skal innhente pris med tanke på fastpriskontrakt med spesifikasjoner basert på NS 3420 slik en kjenner i dag, vil dette kreve en langt større modellnøyaktighet. I en NS3420- spesifikasjon er absolutt alle deler av en konstruksjon spesifisert som f.eks: Bolter, muttere, skiver og underlagsplater Alle hull for innfesting av prefab-søyler med tilhørende limtyper. Innstøpte stålplater i betong. Dimensjon, festeklør, materialkvalitet etc Statsbygg Side 24 av

25 Fjellbolter. Hulldiameter, borelengder, stålkvaliteter, limtype etc. Dersom dette spesifikasjonsnivået skal oppnås kreves det en svært høy detaljeringsgrad. Slik vi kjenner selve IFC-standarden i dag, vil det heller ikke være mulig. Detaljrikdommen kan også styres i ADT ved at det etableres et objektbibliotek med svært enkle objekter som ikke er relatert til f eks materialer. I Norconsult er det ikke etablert slike objekter. 3D-modellen setter tidlig krav til nøyaktige høydeangivelser og tidlig fastsetting av byggets høyder. En høy grad av nøyaktighet er påkrevd for å unngå store omarbeidinger av modellen. Det virker foreløpig som det er mer arbeidskrevende å modellere i 3D enn i 2D. Det er imidlertid mulighet for at IFC kan åpne for store tidsbesparelser i kombinasjon med applikasjoner. 3D-modellen gir en utmerket oversikt innenfor egen modell og avslører raskt avvik rent visuelt. ADT kan til en viss grad lage en 3D-modell av terrenget, slik at en relativt nøyaktig fastlegging av betongvolumer for fundamenter kan gjøres når fundamenteringsnivået endrer seg fra sted til sted. (f.eks. fjelloverflate). Denne terrengmodulen har vi valgt å ikke benytte, da vi mener at en tilstrekkelig nøyaktighet oppnås ved å basere modellen på antatte dybder basert på fjellkontrollboringer. Muligheten til å blande (merge) modellene øker nytteverdien ytterligere, kfr nedenfor. Det er som nevnt svært tidkrevende å modellere alle detaljer i hele modellen med full 3D-nøyaktighet. Ved generering av 2D-tegninger mister en derav noe av nøyaktigheten i tegningene, som f.eks synlige/usynlige linjer. ADT krever en nokså omfattende tilrettelegging før en kan høste ut komplette snitt og planer som kan sendes ut til byggeplass. ADTs IFC modul (Inopso) har hatt en del mangler som har ledet til en rekke nye utgaver av programmet. Gjennom forprosjektfasen har det kommet ut sju nye revisjoner av programmodulen. Flere av revisjonene har kommet som en følge av dette prosjektet. En gjenganger har vært endringer av Globale identifikatorer (GUID) ved eksport (etter import.) Dette ser ut til å være løst. Vi har også opplevd ustabilitet i programmet (ADT/Inopso) ved delvis eksport av objekter., dvs hvor en bare eksporterer et utvalg av bygningselementene. Pr i dag har vi en forespørsel inne som kan innebære en ny revisjon av programmet. Etter vårt skjønn har vi fått god support fra programutvikler. Pr i dag er vi usikker på om entreprenøren kan hente ut mengder for prissetting ut av ADTs IFCmodell. 3.3 Objektegenskaper ADT kan i utgangspunktet programmeres til å ha enhver tenkelig opplysning knyttet til objektene. Konstruksjonsegenskaper ( Structural properties ) IFC-standarden i versjon 2x2 setter grenser for hva som kan overføres innenfor standarden. Innenfor konstruksjonsteknisk prosjektering er standarden i denne versjonen mangelfull. Etterfølgende versjoner (2x3, 2x3g) skal ha forbedrede egenskaper på dette området, uten at dette er testet. Norconsult har generert objektegenskaper som til en viss grad er konstruktive - som f.eks. materialkvalitet og belastninger på dekker. Tverrsnittskonstanter er ikke lagt inn. De fleste konstruksjonsobjekters tverrsnittsegenskaper finnes i tabellarisk form. Konstruksjonsprogrammer har disse egenskapene innebygget. Dersom tverrsnittstypen gjenkjennes, beregnes alle tverrsnittets egenskaper av applikasjonen selv. Vi ser det derfor ikke som nødvendig å overføre slike egenskaper. Ved eksport til IFC-blir alle objektegenskapene overført og er lesbar ved f.eks Octagas viewer. Siden opplysningene ligger i IFC-modellen, har vi valgt å definere noen property_sets (Pset_) som Statsbygg Side 25 av

26 definerer materialkvaliteten på betong og stål. Videre er det definert sett som definerer belastningen på dekkefeltene. Property ene er utviklet direkte i ADT, uten PSet-generator som er mottatt. Definerte og benyttede Propertysets fremgår nedenfor. Figur 13 Definerte og benyttede PropertySets Der er imidlertid usikkert om dataene kan leses/tolkes av andre programmer pr idag. Det er gjort noen tester mot Archicadd; dit overføres egenskapene. En enkel modell er oversendt EDR (norsk Tekladistributør) for å se på hvilke egenskaper en der klarer å lese ut av modellen. Tekla Structures importerer ikke selve modellen. IFC-modellen ligger som en referanse som må modelleres på nytt i Tekla. Tekla Structures er under endring på dette punktet. Det er overført en svært enkel modell til EDR. Nedenfor vises modellen slik den er importert til Tekla. Form og dimensjoner er korrekt overført. Statsbygg Side 26 av

27 Figur 14 Importert modell til Tekla Structures Norconsult har utviklet et sett av objekter som dekker de fleste forekommende tilfeller av bjelkeformer og søyleformer, med tilhørende objektegenskaper. Vi er pr i dag usikre på om alle mulighetene innenfor IFC-standarden er utnyttet fullt ut. Forespørsel er sendt til Autodesk/Inopso, da det er usikkerhet rundt nøyaktig hvilken utgave av IFC-standarden programmet støtter. Det vil i det videre arbeidet bearbeides en del av PropertySet ene med utgangspunkt i nyere utgaver av IFC-standarden. Modellen skal berikes i byggefasen av for eksempel leverandør av betongelementer. De egenskapene som tillegges en del av elementene av oss må således først og fremst være grunnleggende bæretekniske krav - som f.eks belastninger og sikkerhetsprinsipper etc. Siden ADT ikke er et fullverdig konstruksjonsverktøy (for Structural -området), vil det ikke være mulig å definere på en effektiv måte relasjonene mellom objektene, som for eksempel den statiske virkemåten i knutepunktet mellom en bjelke og en søyle. Det vil være mulig å definere et PropertySet som kan angi dette, men det er tvilsomt om noen konstruksjonsprogrammer vil kunne benytte denne informasjonen. Prosessen er også tungvint i ADT. Tverrfaglig merkesystem (TFM) ADT kan programmeres til også omfatte å merking av objekter iht Statsbyggs Tverrfaglig merkesystem (TFM). Siden TFM ikke følger bygningsdeltabellen (NS3451), må det utføres en manuell prosess knyttet til en av IFC-Property ene. I ADT ville det være mulig til en viss grad å automatisere prosessen, da laginndelingen følger bygningsdelstabellen. Vi vil legge merking på noen av objektene i modellen. Armering Armering kan ikke legges inn i på en effektiv måte av ADT. Til det vil det være nødvendig med en egen applikasjon. TEKLA Structures har moduler som genererer 3D-armering - manuelt eller direkte etter beregninger. Denne modulen er ikke IFC-kompatibel ved import. Modellen må modelleres på nytt i Tekla før armering tillegges. Det vil antagelig også være behov for endringer når entreprenøren skal Statsbygg Side 27 av

28 hente ut mengder og spesifikasjoner ut av modellen. 2D-objekter Aksenett og annen 2D informasjon må kunne eksporteres til IFC-modellen for en mer utstrakt bruk av modellen mellom prosjekterende. Slik det nå fungerer, utveksles aksenettet pr DWG-filer i prosjekteringsgruppen. Entreprenøren vil også ha stort behov for et aksenett. Delt eierskap på objekter RIB deler eierskap med alle aktørene i prosjekteringsfasen modellen på følgende objekter: Project Site Building Storey Det har vært en programfeil i ADTs IFC-modul som har medført at ADT ikke har sendt tilbake de samme GUID-ene på Project-Site-Building-Storey -nivåene. I praksis betyr dette at ADT har laget et nytt IFC-prosjekt. Det har vært tidkrevende å finne ut av dette, og rette feilen. Import og eksport av disse objektene går nå feilfritt uten at GUID-ene endres, dvs slik det skal være. I ADT må konstruksjonene, som modelleres etasjevis, knyttes til de importerte objektene nevnt over. RIB deler i tillegg eierskap med ARK på samtlige bærende objekter: Dekker Tak Bærende vegger, indre og ytre Gulv på grunn av betong Bjelker Søyler RIB har ansvaret for bæreevnen og står som eier og fagansvarlig for denne delen av objektenes egenskaper. Dette innebærer forhold som fysiske dimensjoner, materialkvaliteter, bæreevne og brannresistans. ARK sørger for overflatebehandlingen, eventuell utlekting og kledning av objektene, og er medbestemmende vedrørende fysiske dimensjoner, plassering, og i materialvalget. ARK/RIB ønsker at et delt eierskap skal fungere slik: ARK har full råderett over alle bærende objekter i en tidligfase som kan strekke seg f.eks til og med skisseprosjekt. RIB importerer på et stadium objektene og foretar de nødvendige suppleringer og erstatninger med egne objekter. Fra dette stadiet er disse elementene RIBs ansvar og har enestående revisjonsrett på objektene. ARK kan bare importere objektene for å se på om de tilfredsstiller ARKs krav til f.eks fysiske størrelser og plassering. Flyten kan skisseres slik: ARK alle rettigheter Eksport RIB overtar Eksport ARK har kun importrett Tidlig fase Senere fase Sorteringen med hensyn til eiendomsretten må skje i modellserveren og baseres på for eksempel en logisk property i IFC-standarden som går på loadbearing (=true/false). Den 3. juli 2006 ble det gjennomført en merging ved at RIBs bærekonstruksjon ble lastet inn i ARKmodellen. ARK-modellen var eksportert uten bærekonstruksjonene. Denne mergingen ser ut til å ha fungert - men er ikke utfyllende kontrollert. Statsbygg Side 28 av

29 3.4 Applikasjoner i forprosjektet I løpet av forprosjektet er det i hovedsak to applikasjoner som har vært benyttet: Octaga viewer Applikasjonen er en ren viewer som kan lese IFC-filer. Programmet er enkelt i bruk og synes å virke stabilt også på store filer. Det har ikke lykkes oss å merge modeller i programmet. Vi benytter programmet til gjennomsyn av modellene før vi laster dem over i modellserveren. Octaga- vieweren gir av og til resultater som ikke vises tilsvarende i DDS-vieweren som ble benyttet i skisseprosjektet. Solibri Model Checker (SMC) Programmet ble tatt i bruk i juni 2006, med kurs avholdt i uke 25. Programmet kan benyttes som viewer og for kontroll av modellene mot hverandre. Programmet ser ut til å være et svært effektivt verktøy for å avsløre kollisjoner i egen modell og mellom fagene. Den ser dermed ut til å effektivt løse geometridelen av vårt arbeid - mot arkitekt og de andre fagene, og representerer helt klart et fremskritt i forhold til tradisjonell prosjektering. Vi ser et betydelig potensiale i å redusere risikoen for uoverensstemmelser mellom de enkelte fag på det geometriske planet. Verktøy for mengdeuttrekk/prising Verktøy for dette er slik vi oppfatter nyutviklet og er under utprøving. Prosjekteringsgruppen bør ha kunnskap om programmets funksjonalitet. Verktøy for terrengmodellering RIB har ikke terrengverktøy som i dag er kompatibelt med IFC (inklusive IFG)-standarden. I det følgende må det tas en beslutning om hvordan dette skal løses. Programleverandøren Powel Gemini har ikke kompetanse innenfor faget terrengbehandling. Skanska har kompetanse på området. Da Skanska er totalentreprenør vil det kunne være enklere å definere ansvarsforholdet der. Vi vet pr i dag ikke hvilken programvare de benytter. 3.5 Modellserver Det har vært gjennomført to kurs i bruk av modellserver. Kursene har dessverre rent praktisk vært preget av dårlige forbindelseslinjer til server. Programvaren er under utvikling og under forbedring Evaluering Det har samtidig vært noen problemer med ulike globale identifikatorer (GUID-er) på samme objekter som har gjort det vanskelig å merge modellene. EPM har utført en del manuelt arbeid i modellene på serveren. Serveren har vært benyttet til import og eksport av filer. Dette fungerer brukbart. Vi har opplevd at serveren av og til ikke besvarer anrop. Stabiliteten må bedres dersom modellserveren skal stå sentralt i byggesaken. Det er ikke etablert sikre/effektive forretningsrutiner for endringer og innlegging/uttak av deler av modellen. Inntil en relevant IDM er etablert, vil effektiv bruk av serveren være vanskelig. Import av andre fags modeller Det er gjennomført en rekke importer av ARK-modellen. Nedenfor vises et forminsket plott av modellen etter mottak. Objektegenskapene overføres. Statsbygg Side 29 av

30 Figur 15 Forminsket plott av modellen etter mottak fra ARK Modellen overføres til etasjevise filer som samles i en samlet DWG gjennom ADT`s eksterne referanse - mulighet. RIB bruker filene etasjevis. Det er mulig å kun endre/tilføre egenskapene på de mottatte elementene - men fordi RIB ikke mottar alle objektene, har konsulentene stort sett modellert alt direkte fra egen applikasjon. Den importerte modellen blir da bare benyttet som bakgrunn. Vi er da også sikret en god grafisk gjengivelse av objektene med tanke på tegninger til en fremtidig byggeplass. RIV og RIEs modeller er importert og satt inn i egen modell. Grafikken er ikke tilfredsstillende, så vi ser pr i dag det ikke som spesielt nyttig - spesielt når modellene kan kontrolleres bedre mot hverandre i SMC enn en visuell kontroll i ADT. Statsbygg Side 30 av

31 4 MODELLERING VVS-TEKNIKK (RIV) 4.1 Målsettinger i forprosjektet Ved hjelp av aktuell programvare som er tilgjengelig (DDS VVSPartner) kunne vi oppfylle de krav som legges til grunn i ytelsesbeskrivelsen til Statsbygg og prosjektets byggeprogram (kravspesifikasjon). Dette gjøres ved hjelp av IFC-modellering og beregning for å berike modellen, samt klarlegge systemløsninger med de hovedprinsipper som er lagt til grunn i godkjent skisseprosjekt. RIV har detaljert modellert 3.etg helt ut. Dette området oppfyller da det som i Statsbyggs YT angis som krav til å vise typiske typerom. Vi har modellert alle føringsveier og VVS-objekter (kanaler, ventiler, *.FlowSegment ) basert på grunnlagsmodell fra ARK, herunder bekreftet tilstrekkelige arealer for tekniske rom/skap/tavler og andre VVS-tekniske installasjoner (IFC-objekter). Det er fortatt IFC-leveranser mht luftmengdeberegninger, kjøle- varmebehov, energibehov, eller energi-/effektbudsjett. Programmet Riuska er kjørt for energisimulering, og resultater tilført IFCmodellen. 4.2 Modell Det blir brukt Data Design System (heretter kalt DDS) som modelleringsverktøy og beregningsverktøy for VVS faget. For energi- og temperaturberegninger/simuleringer er Riuska blitt brukt. Modellen fremstår i dag som et utvidet forprosjekt i forhold til Statsbyggs ytelsesbeskrivelse, der 3.etg er modellert og prosjektert helt ut på detaljnivå (som typerom ). Figur 16 VVS-modellen vist i IfcViewer fra DDS Statsbygg Side 31 av

32 4.3 Modellering og prosjektering i DDS Romdata som er hentet fra ARK-modell Data som blir lagt i IfcSpace (rommet) etter at vi har gjort vår modellering og beregning VVSinstallasjoner med objektinformasjon ARK-modell Figur 17 Elementer i RIV-modell DDS fungerer godt som modellerings- og beregningsverktøy, vi ser her utsnitt av 3.etg., der vi har hentet inn arkitektfilen og brukt denne som underlag for våre arbeider. Vi har fått med oss rommene (IfcSpace) fra arkitekt, noe som medfører at data som vi legger inn i våre tegninger vil bli lagt rett i forhold til rom og videre beregninger. Statsbygg Side 32 av

33 Teknisk informasjon som er lagt inn i DDS, blir overført videre inn i IFCfilen. Figur 18 IFC-informasjon i VVS-modellen Figur 19 Visualisering av føringsveier i SMC - 3 etg - alle tekniske fag Statsbygg Side 33 av

34 SMC fungerer utmerket som kollisjonskontroll. Kollisjon mellom Elektro og VVS som ble fanget opp etter kontroll Kollisjon mellom rør og ventilasjon Figur 20 Kollisjonskontroll Figur 21 Kollisjonskontroll Statsbygg Side 34 av

35 4.4 Beregning i Riuska Figur 22 Bruk av Riuska energisimuleringsprogram Programmet Granlund Riuska er brukt for å kjøre energisimuleringer og for å kunne gjøre årskostnadsberegninger. Det ble her hentet inn arkitektmodellen, noe som gjør at vi får inn geometrien for bygget, og hvilke elementer bygget er bygd opp av. Vi kan da legge til egenskaper til vegger og tak, samt at det gir mulighet til å legge inn internbelastninger (fra personer, belysning, utstyr mv) i hvert enkelt rom. Dette muliggjorde at vi kan på en enkel måte kunne simulere hele bygget med korrekte soldata, værdata og internlaster, og fikk beregnet hvert enkelt rom korrekt. Det hadde vært ønskelig å kunne hente U-verdier fra selve arkitektmodellen, og samtidig kunne hente internbelastning fra annnen programvare, dette er verdier som legges inn/kan legges inn i modellene til andre fag, og som ville være av stor nytteverdi å kunne hente inn for VVS. Rommene er bygd opp av forskjellige elementer Figur 23 Riuska Statsbygg Side 35 av

36 Figur 25 Riuska-resultater 4.5 Objektegenskaper Vi kan i dag legge data inn i modellen egenskaper som definert på objektene av ulik type programvare. Det er imidlertid ingen mulighet til å påvirke enkeltvis hvilke IFC-egenskaper man eksporterer til en IFC-fil. Det ville være ønskelig med flere muligheter til å velge hvilke egenskaper som skulle følge med ved eksport av data, og mulighet for å kunne legge til ytterligere data som man ønsker å ha med ved eksport. Det varierer fra objekt til objekt hvilke egenskaper som er definert. Objektegenskapene vises forskjellig alt etter hvilke applikasjon som brukes - om dette har med de enkelte viewerne å gjøre eller om informasjonen legges feil inn har vi ikke klart å konkludere éntydig med. Når det gjelder Statsbyggs tverrfaglig merkesystem (TFM) skal vi kunne bruke dette systemet i forhold til å merke objekter i VVS-faget, da DDS har gjort om systemet sitt slik at dette er mulig. 4.6 Applikasjoner i forprosjektet samt evalueringer ved bruk DDS VVSPartner Fungerer bra i forhold til å kunne modellere VVS-anlegg Har egne funksjoner for beregning av trykkfall og varmebehov Det vil være ønskelig å utvikle 2D grafikken DDS IFCViewer Fungerer bra mot VVS-modelenl, er lett å bruke og har de funksjoner man ønsker. Har et klart forbedringspotensiale mot visning av andre fag i forhold til fargesetting Octaga Modeller Fungerer bra sammen med modellserver, bra fargesetting og visualisering Statsbygg Side 36 av

37 Solibri Model Checker 4.0 Programvaren fungerer veldig bra som kollisjonssjekker, og har mange finesser i forhold til å generere rapporter. Farger og visualisering fungerer bra men er noe vanskelig i forhold til manøvrering. Granlund Riuska Bra programvare i forhold til energiberegninger, får ut nøyaktige beregninger og kan enkelt kjøre hele bygningsmassen eller enkeltrom med forskjellige beregninger. Det hadde vært ønskelig med mulighet for å kunne hente inn verdier utover geometri, som u-verdier, ventilasjonssystemer, luftmengder og internlaster 4.7 Modellserver Funksjonene med eksport og innport til modellserver fungerer, men er noe vanskelig. Modellserveren har mange funksjoner men er vanskelig å bruke, her bør det gjøres noe med brukervennligheten. Sammenslåing av modeller fungerer delvis i dag, men da vi jobber med store og tunge filer vil ting virke tregt Evaluering Bruk av modellserver vil være en nødvendighet i et slikt prosjekt, derfor er det viktig at modellserveren fungerer og er enkel å bruke. Her vil det være et stort forbedringspotensiale og ønske om at en modellserver kan ha andre funksjoner, herunder også integrasjon med et prosjekthotel / webhotel, for lagring av prosjektreferater og lignende. Statsbygg Side 37 av

38 5 MODELLERING ELEKTRO-TEKNIKK (RIE) 5.1 Målsettinger i forprosjektet RIE modellerer detaljert helt ut EN etasje et sted i modellen som avtales mellom ARK, RIV og RIE. Dette området viser da typerom osv iht forprosjekt-yt Modellere alle føringsveier og elektro-objekter (kanaler, fordelinger, lysarmaturer, stikk, punkter, ) basert på grunnlagsmodell fra ARK, herunder bekrefte tilstrekkelige arealer for tekniske rom/skap/tavler og andre elektro-ekniske installasjoner (IFC-objekter) I samarbeid med ARK vurdere konsekvenser ved bygningsutforming, herunder vindusareal, antallog plassering av fordelinger IFC-leveranser ved at det legges inn en del default-egenskaper på objektene, evt helt konkrete egenskaper med reelle objekter fra objektbibliotek hvis merarbeidet er lite. Riuska skal kjøres for energisimulering evt i samarbeid med RIV (dimensjonering elvarme), og resultater tilføres modellen. Teste sammenhenger med delvis tilsvarende funksjonalitet i DDS Teknisk Partner. Modellen skal følge relevante IDM-er ( Electrical etc) i den grad de er ferdigstilt, og sjekkes mot implementerte IDM-er på modellserver 5.2 Modell Figur 26 RIE-modell forprosjekt Statsbygg Side 38 av

39 Figur 27 Detalj av kabelstiger Figur 28 Detalj av stikk i kanal Statsbygg Side 39 av

40 Som det fremkommer av utsnitt av modellen, er detaljnivået på 3D-presentasjon svært høyt. Med denne typen modellering er man egentlig på detaljprosjektnivå i det øyeblikket modelleringen starter. DDS har videreutviklet modelleringsverktøyet etter hvert som vi har gitt tilbakemelding på feil og mangler, og vi bruker nå versjon 6.35 Prerel build 31/ Det kommer også en ny versjon 6.40 i løpet av høsten 2006, og det må vurderes om denne skal tas i bruk i prosjektet. Vi har siden skisseprosjektet hatt store problemer med å få importert ny ARK-modell. Ved import har det kommet feilmelding om GUID-er som allerede eksisterer og PC-en har låst seg mange ganger uansett hva vi har prøvd. Problemene er sendt videre både til DDS og ARK, som har jobbet med å løse dette. 2. juli 006 lykkes vi for første gang å ta inn ny ARK-modell siden skisseprosjekt. Feilmeldingene er der fortsatt, men nytt grunnlag er kommet inn. Etasjene havnet feil, antagelig fordi de er endret fra ARK i forhold til skisseprosjekt, men vi har løst dette i DDS. Det oppsto problemer med dører som ble for store og dører som er feil plassert. Problemet er sendt videre. 5.3 Veien videre Objektbibliotek har pr i dag ikke alle de nødvendige objektene IIFC-egenskapene til de enkelte objektene må struktureres og bli riktig Merkesystem/Tverrfaglig merkesystem må på plass i modellen Funksjonalitet med hensyn til plassering og rotering av 3D- og 2D-objekter må bedres slik at modellene/tegningene for begge disse blir bra (samtidig). Det støttes ikke lange filbaner (path) og det er problemer med norske tegn (æ,ø og å) Ved import av ny modell fra ARK fungerer ikke sletting av den gamle romdatabasen, noe som igjen gir låsing. For å få importen til å fungere, må eksisterende romdatabase slettes manuelt. Plassering av filer for import/eksport kan påvirke sluttresultatet. Det må bli mulig å ta inn bare én ny etasje, ikke bare en komplett modell med alle etasjer ARK-grunnlag mangler fremdeles nødvendig 2D-informasjon som skravur, slik at man visuelt kan lese ut hvilken veggtype det er. Det går an å dobbeltklikke på veggen inne i DDS og få denne informasjonen frem som skrift, så informasjonen ligger der. I forbindelse med utsendelse av ordinært forprosjekt ble DWG-tegninger fra ARK lagt inn som grunnlag fordi IFC modellen inneholdt for lite informasjon. Import av rutenett/akser fra ARK via IFC i DDS Teknisk Partner er ennå ikke implementert På tross av konkrete problemer så går ting fremover, og 3D presentasjonen ser svært bra ut. 5.4 Objektsegenskaper Modellering i DDS er basert på at man henter ferdig definerte objekter i et objektbibliotek. Det er imidlertid ingen mulighet for å påvirke eller lese IFC-egenskapene før man har eksportert en IFC-fil. Vi har i skisseprosjektet etterspurt denne muligheten, samt en brukermanual for IFC-delen. Vi har foreløpig ikke mottatt noe på dette, men går ut fra at dette er noe det jobbes med. Det varierer fra objekt til objekt hvilke egenskaper som er definert. Objektegenskapene vises forskjellig alt etter hvilket applikasjon som brukes, samt at visning av geografisk plassering i bygget i navigasjonstre varierer, men i 3D-visningen vises de enkelte objektene geografisk riktig. Statsbygg Side 40 av

41 Figur 29 Eksempel - Kabelstige i DDS Viewer 6.40 ( ny viewer-versjon) Figur 30 Eksempel - Samme kabelstige vist i Octaga-viewer Statsbygg Side 41 av

42 Figur 31 Eksempel - Samme kabelstige vist i Solibri Model Checker (SMC) Figur 32 Eksempel Relasjoner vist i SMC Figur 33 Navigasjonstre i DDS Viewer - Alle objektene havner under rett etasje Statsbygg Side 42 av

43 Figur 34 Navigasjonstre i SMC - Objekter uten geografisk tilknytning Tverrfaglig merkesystem (TFM) er påført alle fordelinger, men det er kun i hovedfordeling at disse vises i IFC-egenskapene. Figur 35 Hovedfordeling +G=432.K1 Figur 36 Underfordeling +G=433.K1 Statsbygg Side 43 av

44 5.5 Applikasjoner i forprosjektet DDS Teknisk Partner 6.35 Prerel build 31/ Se kommentarer ovenfor. DDS IFC Viewer for IFC version 6.40 PreRel build 1/ Dette er en ny versjon av programmet. Tidligere versjoner har vært svært ustabile. Vi har fått prøvd denne noen få dager og merker at den er blitt betydelig forbedret, virker nå stabil og sorterer objektene korrekt på etasjenivå. Navigeringen er blitt enklere samt at det er lagt til en mulighet for å endre PropertySets, noe som ennå er uprøvd. Vi savner Name (romnummer) på IfcSpace-er i navigasjonstreet, som er det mest naturlige å navigere etter. Kun Longname vises. Vi har bruk for begge deler for å få en enkel navigering. Vi har prøvd denne bare på RIE-modellen. Programmet laster modellen raskt inn og er enkel i bruk. Octaga Modeller 2.1.0m10r Dette programmet har den store fordelen at det kan brukes inne i modellserveren, slik at am får 3Dvisning av objektet på server. Det er forholdsvis enkelt brukergrensesnitt, men vi savner funksjonaliteten at du kan klikke på objektene i 3D-visning for å få frem objektegenskaper. Det kan godt hende at dette finnes, men RIE har ikke funnet dette ennå. Vi bruker relativt lang tid på å starte programmet når man henter inn nye modeller. Brukergrensesnittet et greit med litt opplæring. Vi får frem enkelte feilmeldinger som foreløpig ikke er forståelige, for eksempel følgende: Figur 37 Uavklarte feilmeldinger Statsbygg Side 44 av

45 Solibri Model Checker 4.0, Build number _0 (SMC) Dette er et svært funksjonelt program, som dog krever litt opplæring for å kunne utnytte potensialet. For å kjøre programmet rasjonelt stilles det krav til en relativt oppdatert PC, bl.a. minimum 1 Gbyte RAM. Det er enkelt å hente inn modeller fra alle fag, og lage en felles modell som grunnlag for diverse modellsjekker ved Rules Sets. Programmet er intuitivt og fremfor alt: Det fungerer. Vi fikk problemer med 3D -isningen, men det skyldtes at driveren til skjermkortet i PC-en ikke var oppdatert. Solibri virker generelt å være et opplagt førstevalg i en prosjekteringsprosess. Flere av våre objekter havnet som tidligere nevnt utenfor rett etasje rett under bygningen; vi er litt usikker hva dette skyldes, men det ser ut som at etasjeinformasjonen mangler på disse objektene. 5.6 Modellserver Stabiliteten til modellserveren er blitt betydelig bedre når det gjelder eksport og import av egne og andres modeller. Dette går stort sett greit nå. Vi har ennå ikke fått prøvd å merge elektromodelenl med andres modeller. Dette er noe som må taes tak i i løpet av høsten Vi har så vidt prøvd å kjøre sjekk på elektromodellen etter relevant IDM ( Electrical ) og fikk feilmelding på at spenningssystem ikke var valgt for fordelinger. Vi har tatt dette opp med DDS, og fått tilbakemelding på at dette er noe det jobbes med. Det er nødvendig med mer opplæring i bruk av modellserver, samt bruke tid til å sjekke inn/ut modeller og merge disse. Statsbygg Side 45 av

46 6 ENTREPRENØRENS ROLLE (Skanska) 6.1 Mål og hensikt - Deltakelse i IFC-forprosjekt Ambisjoner Entreprenørens rolle i forprosjektet var i startfasen av svært generell karakter. Byggherrens og rådgivernes forventninger var å bidra med vår kompetanse vedrørende priser og byggemetodikk som beriker prosjektet. Det var forventet at entreprenøren skulle benytte programmene drofus og Calcus til kalkulasjon av prosjektet. En tidlig forventning var å bidra til å finne hvilken standard som skulle legges til grunn for beskrivelsestekster. Det ble vurdert om en skulle søke en NS3420-basert eller en NS3451-basert modell. Entreprenørens bidrag ble i denne fasen begrenset til rekalkulasjon av prosjektet i Calcus ved bruk av rådgivernes (ARK, RIB, RIV, RIE) IFC-modell. Entreprenøren skulle også benytte drofus som informasjonsdatabase. Modellserver skulle også benyttes. 6.2 Prosessen Anbudskonkurranse Byggherrens ønske om å knytte til en entreprenør som behersker IFC-prosjektering, måtte håndteres slik at offentlige anbudsregler iht EØS-regelverket ikke ble brutt. Det totale prosjektet ved HITOS er vurdert og behandlet som et FoU-prosjekt. Det ble utarbeidet en anbudskonkurranse for entreprenør (ENT) der to hovedelementer skulle besvares. Første del var et grovt beskrevet anbud over et testbygg. Her ville man finne anbydernes prisnivå. Andre del av konkurransen var å dokumentere entreprenørens kompetanse, både med hensyn til den interne prosjektorganisasjonens kompetanse og entreprenørens øvrige referanser fra BIM/IFC-relaterte prosjekter i Norge og utenlands Entrepriseform Entrepriseform for dette prosjekt er noe spesiell, pga behovet for FoU knyttet til uttesting i et konkret byggeprosjekt. I utgangspunktet skal vi ende opp med en kontrakt basert på totalentreprise. Siden utvikling av byggeprosjektet og FoU-prosjektet foregår samtidig, er det valgt å gjennomføre prosjektet etter åpen bok - prinsipp, med visse uthoppsklausuler. I FoU-delen av prosjektet vil denne form for samarbeid fremme konstruktivt samarbeid mellom byggherre, rådgiver og entreprenør Kalkulasjon/Kostnadsoverslag Kalkulasjon av selve prosjektet ble avtalt utført etter Skanskas interne metodikk ( PAN-standard ). Kalkulasjonsmaterialet som ble lagt til grunn var rådgivernes tegninger og ytelsesbeskrivelser. I tillegg ble drofus benyttet for å kalkulere de tekniske ytelser. Kalkulasjonen er utarbeidet på 3-sifret nivå iht NS3451. Kostnadsoverslag som ble overlevert til påske 2006 lå primessig høyere nn budsjettet utarbeidet av rådgivergruppen i skisseprosjektet. For å ha en smidig fremdrift med hensyn til denne problemstillingen, ble kalkulasjonene i sin helhet fremlagt for byggherre og rådgivere. Deretter ble kalkulasjon gjennomgått i detalj med rådgiverne for å sikre at det ikke forelå misforståelser eller avvik mellom det prosjekterte og det kalkulerte materiale. For å tilfredsstille byggherrens budsjett ble det utviklet en kuttliste som inneholder mulige besparelser som likevel gir et fullgodt prosjekt. I Detaljfasen av prosjektet er det naturlig å rekalkulere prosjektet etter at de nødvendige grep er foretatt. 6.3 Evaluering av rekalkulasjon vha IFC og G-PROG Calcus Programvaren Programvaren G-PROG Calcus fra NOIS er et godt og oversiktlig verktøy for kalkulasjon av prosjekter etter Bygningsdelstabellen (NS3451). Bildet under viser hovedbildet av programmet hvor elementer i Statsbygg Side 46 av

47 kapittel 2 (dvs bygningsmessige elementer) er tatt frem. IFC-importen automatiserer inndelingen av etasjer fordelt på delprosjekt, dvs at all informasjon og objekter blir fordelt i ett delprosjekt for hver etasje. Fordelingen av elementer på kontoplan foregår relativt smertefritt. Calcus beregner mengder selv ut fra modellen. Nøyaktigheten av dette skal etter sigende være meget god. Ved fornuftige elementnavn, og gjerne NS3420-informasjon, er det lett å bygge opp kalkulasjonen ved å hente ut ferdig prisede elementer og prislinjer fra prisbiblioteket som ligger i programvaren. Biblioteket er laget av NOIS, og inneholder et sett av forhåndsdefinerte elementer, med tilhørende erfaringspriser. Det er uproblematisk å bygge opp egne bibliotek med egne priser. Bruk av Calcus krever lite resurser for opplæring av programvaren. Selvfølgelig må brukeren kunne kalkulere (!). Figur 38 Calcus - hovedbilde Import av IFC-filer Modellserver Bruk av modellserver medførte en del uforutsette problemer. Pga Skanskas strenge politikk mht kontakt med Internet og andre servere, måtte all kontakt med modellserver kjøres gjennom intern viruskontroll. For at dette skulle virke, måtte informasjonen overføres via http-protokoll. Dette medfører en vesentlig tregere utveksling av data. [Gleden ved bruk av modellserver ble også noe redusert da undertegnedes PC ikke klarer å laste ned store filer. Angivelig har dette sammenheng med operativsystemet (XP Pro) og dennes plassering av temporærfiler.] Modellfilene måtte av denne grunn utveksles via minnepinner (flash memory stick) / CD. Statsbygg Side 47 av

48 Import til Calcus Import av IFC-filer inn i en enten tom kontoplan, eller en kontoplan som inneholder ferdigdefinerte elementer, går smertefritt. Calcus ber brukeren med en gang ta stilling til om IFC-filen skal lagres som delprosjekt, eller at alt samles inn i ett hovedprosjekt. En av de virkelig fine funksjoner i Calcus er at en allerede ved importstadiet kan legge inn prislinjer på elementene. Dette gjøres i en enkel dialogboks, se utsnitt under. Figur 39 Innlegging av prislinjer i Calcus Under den beskjedne forutsetting at det er samsvar mellom IFC-navnet på elementene og navnet/koden i prisbiblioteket, går denne prosessen raskt. Import av flere IFC-filer i samme kalkulasjon er fullt ut mulig. En utfordring som tilsynelatende ikke er behørig definert, er hvordan typisk informasjon som ligger i romskjema skal legges inn i modellen. Området Malerbehandling må muligens legges inn som egne objekter i form av sjikt eller egne IfcSpace i modellen. Tilsvarende gjelder for eventuell påstøp og belegg. Det er mulig å kalkulere malerbehandling i Calcus ved å definere at for eksempel alle innervegger skal ha malerbehandling i elementets prislinje, men da er det vanskelig å skille ut malerarbeidene separat. Eksport fra Calcus Calcus har i skrivende stund ikke muligheter for å eksportere IFC-informasjon. Dette er synd, og et klart forbedringsområde for NOIS. Mer om dette under. Calcus kan eksportere kalkulasjonen i NS3420-format. Dette er virkelig bra. Kalkulasjon på bygningselementnivå er betydelig raskere enn å jobbe med NS3420. Likevel er det i produksjon en stor fordel å nettopp ha NS3420, og gjerne fordelt på kapittelnivå. Funksjonaliteten som her er beskrevet, sparer entreprenøren/kalkulatøren for betydelig med arbeid. Calcus kan også eksportere til Excel. Calcus gir brukeren en rekke valgmuligheter for hva som skal eksporteres - hele kalkulasjonen, eller bare deler av den Elementnavn/bibliotek Statsbygg Side 48 av