BIM manual til ER-skjema for ebyggesak

Transkript

1 2016 BIM manual til ER-skjema for ebyggesak BIM-manual som beskriver kravene til validering av IFC filer for kommunal saksbehandling Simon Werner Stig Røstadli Kjetil Egeli NTNU Gjøvik

2 Dette er en prosjekt spesifikk BIM- manual og er tilpasset kravene i dette prosjektet. Innhold Grunnleggende BIM-krav... 3 BIM-leveranser hovedmål... 3 BIM Generelle krav... 3 Generelle krav til modellstruktur... 5 Modellkrav

3 Grunnleggende BIM-krav BIM-leveranser hovedmål Ref.# Tema Type Krav og beskrivelse 1. Åpen BIM - leveranse En digital 3D BygningsInformasjonsModell (heretter kalt "BIM") som er utarbeidet ved hjelp av objektbasert modelleringsverktøy (ved bruk av objekter med egenskaper og relasjoner) og bruker åpne BIM-standarder/formater, er en hoved leveranse. Dette innebærer at modellmakerne må bruke et egnet objektbasert BIM/DAK-program som effektivt støtter de spesifiserte åpne standardene, slik de er definert i denne spesifikasjonen. 2. BIM-formål De grunnleggende BIM-kravene skal oppfylles uansett BIMformål. BIM-en skal modelleres for det eller de spesifikke BIM - formålene som er spesifisert i prosjektet uttrykkelig eller underforstått. Hvis et av BIM-kravene av en eller annen grunn ikke kan oppfylles av modellmakeren eller BIM/DAK-programmene som brukes av modellmakeren, skal kommunen varsles, og modellmakeren skal foreslå en midlertidig løsning for leveranse av BIM-informasjonen. BIM Generelle krav Ref.# Tema Type Krav og beskrivelse 3. Åpent digitalt lagringsformat for BIM som skal overleveres til kommunen BIM/DAK-programmet må effektivt støtte import og eksport i det åpne BIM-formatet Industry Foundation Classes (IFC). Kjernemodellen i IFC er en ISO-spesifikasjon ISO/PAS BIM - modellen skal overleveres kommunen i IFC 2x3- format eller nyere. 4. IFC-versjon som skal brukes Med mindre annet er fastsatt, skal det åpne BIM-formatet IFC versjon 4 fortrinnsvis benyttes, men Kommunen kan velge å akseptere IFC-versjon 2x3, forutsatt at alle relevante objekter blir inkludert. 3

4 5. Navnekonvensjoner for BIMfiler Med mindre annet er fastsatt i forskrift eller veileder, skal BIM-filnavn samsvare med navngivningssystemet som oppsatt i ER-skjema: n = 1, 2, 3, hvis flere filer inngår i underdelingen. Hvis det bare leveres én fil, kan nummeret settes til "1", eller fortrinnsvis utelates. t = Enhver valgfri tekststreng avtalt i prosjektet som ytterligere beskriver filinnholdet med et subsett av ASCIItegnsettet bestående av bokstavene a z, A Z, tallene 0 9, og underscore-tegnet (_). De nordiske bokstavene "æäøöå/æäøöå" og andre spesialtegn bør ikke brukes for å unngå unødvendige tegnsettproblemer under filutveksling. De nordiske øö/øö oe/oe, å/å aa/aa 6. Måleenheter Relevante måleenheter må defineres på IfcProject-nivå i modellen (attributt UnitsInContext). Det skal brukes metriske SI-enheter, med mindre annet er fastsatt. "Imperial-enheter" (tommer, fot, kvadratfot osv.) brukes vanligvis ikke. 7. Målenheter BØR Lengder bør angis i millimeter eller meter, arealer i m2 og volum i m3. 8. Definisjon og georeferering av prosjektets nullpunkt ("prosjektnull") Prosjektnullet /stedet skal georefereres i samsvar med buildingsmart-dokumentutkastet Exchange Requirement (ER) for Georeferencing and Creation of Site Local Geometric Representation (filnavn _ER_GeoRef.xls), med mindre annet er avtalt med kommunen. 9. ER-skjema Skal ER-dokumentet kan fås ved tilgang til buildingsmart ebyggesak_ pdf. Dette ER- utkastet kan inneholde endrede krav i sin endelige versjon. I så fall er det den endelige versjonen som skal brukes, med mindre annet er avtalt med kommunen. 4

5 Generelle krav til modellstruktur Ref. # Tema Type Krav og beskrivelse 1. Relasjoner Modellen skal ha riktig relasjonsstruktur. Alle objekter, både abstrakte (som IfcProject) og fysiske (som IfcWall), skal ha definerte relasjoner (IfcRelContainedInSpatialStructure ) til strukturen de befinner seg i. F.eks: Et vindu skal ha relasjon til veggen det er plassert i (gjennom et åpningsobjekt i veggen), veggen og vinduet i veggen skal ha relasjon til samme etasje etc 2. Bruk av riktige objekter Alle bygningsdeler skal modelleres med korrekt entitet ihht IFC-skjemaet. Som et minstekrav skal entiteter listet i IFC Coordination View 2.0 ( være støttet, for relevante objekttyper i den enkelte applikasjon. Som anbefalt krav til entiteter bør man benytte IFC4 Bruk av «proxy-objekter» (IfcBuildingElementProxy) skal holdes på et minimum. Hvis de benyttes, skal de enkelt kunne identifiseres ut fra navngivningen (IfcBuildingElementProxy.Name) 3. Prosjekt Ett og kun ett prosjektobjekt (IfcProject) skal finnes per prosjekt. Prosjektnavnet (IfcProject.Name) skal inneholde tiltakets prosjektnavn eller annen prosjektreferanse-id. Det benyttes navn på bygg som f. eks enebolig - nytt bygg, tilbygg til enebolig, ny fritidsbolig etc. 4. Tomt, eiendom Med mindre annet er fastsatt i ER-skjema eller avtalt med kommunen, skal eiendommen inneholde fastsatt / foreslått / prosjektert geometri for hele eiendommen. I slike tilfeller skal det benyttes eiendommens knr, gnr, bnr, fnr eller snr Et komplett matrikkelnummer består av følgende komponenter: knr kommunenummer gnr gårdsnummer bnr bruksnummer fnr festenummer snr seksjonsnummer De tre første numrene (knr, gnr og bnr) er obligatoriske deler av matrikkelnummeret. Formatet skal alltid følge dette oppsettet: - knr har alltid fire 5

6 sifre med eventuelle ledende nuller - gnr, bnr, fnr og snr må ikke ha ledende nuller - alle felt må være inkludert - felt som ikke er i aktiv bruk, skal defineres med en null (0) - feltene knr, snr, bnr og fnr er adskilt med hvitt mellomrom - det må ikke brukes andre tegn enn mellomrom og tall Eksempler: (fnr er ikke brukt) (snr er ikke brukt) (verken fnr eller snr er brukt) 5. Bygninger Ett eller flere bygningsobjekter (IfcBuilding) skal finnes per eiendom, og skal gjenspeile antall fysiske bygg / bygningskropper som skal reises på eiendommen. Her benyttes matrikkelnavn Ved tvil om hvordan byggverk skal deles inn i IfcBuildingobjekter, bør dette avklares med kommunen før søknaden innsendes F. eks tilhørende frittstående garasje kan integreres i en og samme modell i nyetableringer. Bygnings-ID-en skal inneholde den offisielle ID-en / bygningsnummeret som er tildelt av relevant myndighetsorgan. Bygningsnummeret skal angis i samsvar med følgende navngivningssystem: knr gbnr Formatet skal alltid følge dette oppsettet: - knr har alltid fire sifre med eventuelle ledende nuller - gbnr må ikke ha ledende nuller - begge felt må være inkludert - feltene knr og gbnr er adskilt med hvitt mellomrom - det må ikke brukes andre tegn enn mellomrom og tall 6. Etasjer Ett eller flere etasjeobjekter (IfcBuildingStorey) skal finnes per bygning, og skal gjenspeile antall hovedplan som inngår i bygningen, inklusive mezzaniner og lignende konstruksjoner som kun dekker deler av en full etasje. FREMTIDIG Etasjenavnene (IfcBuidlingStorey.Name) skal bestå av et heltall, og man begynner med "0" ved nederste hovedplan og øker med én for hvert hovedplan dvs. at etasjenumre ikke må være negative selv for etasjer under bakkenivå. Inngangsplanet skal angis ved å tildele et egenskapssett Pset_BuildingStoreyCommon.EntranceLevel til etasjeobjektet, og sette dette til TRUE for hovedinngangsplanet. Hvis flere innganger i forskjellige hovedplan har status som "hoved", må likevel én og kun én inngang velges som inngangsplan. Dette nevner blant annet Norkart som en viktig faktor, dette er mangelfullt i dagens modeller og tilgjengelig i 6

7 7. Romarealer generelt FKBdata, men det vil være en vesentlig faktor for å kunne bedømme en helhet i byggesaksbehandlingen Romarealer skal modelleres med 3-dimensjonelle romobjekter (IfcSpace). Romarealer skal finnes for alle arealer som representerer en definert funksjon, uansett om romarealet er avgrenset av fysiske vegger / dekker eller er arbeidsplasser i åpne kontorlandskap. Med mindre annet er spesifisert, skal romarealer modelleres når de oppfyller betingelsene for "måleverdighet" i samsvar med måleregler i NS 3940 Arealog volumberegning av bygninger. 8. Bebygd areal Det skal være definert en BYA for hvert bygg og konstruksjon iht måleregler 9. Romarealer bruttoarealobjekt For hver etasje må informasjon om det totale bruttoarealet (BTA) være inkludert i et "BTA-objekt" (IfcSpace). BTA er det arealet i hver etasje som inkluderer utsiden av alle omsluttende bygningsdeler (vegger osv.). Den nøyaktige definisjonen finnes i NS Det eneste formålet med dette "BTA"-objektet er å angi det totale etasjearealet, inklusive vegger. "BTA-objektet" vil naturlig overlappe ("kollidere") med andre romarealer i etasjen. 10. Bruksareal Det skal defineres BRA for hver etasje, fløy, boenhet etc 11. Gesims- og mønehøyde 12. Fysiske bygningselementer BØR Gesimshøyden og mønehøyden regnet fra gjennomsnittlig planert terreng bør angis i BIM-en hvis BIM / DAKprogrammet tillater det, eller i en egen rapport (PDF, regneark osv.). Dette kan gjøres i alle programmer ved at man setter en «etasje» i snittet med en gjennomsnittlig modellert høyde på det bearbeidede terrenget. Dersom kotehøyder blir benyttet i tillegg vil dette forhindre eventuelle misforståelser om byggehøyder. For krav som stilles til fysiske bygningselementer, se kravpunktene i ER-skjemaet. 13. Soner Soner (IfcZone) betraktes som grupperinger av romarealer (IfcSpace) eller andre soner. Et romareal kan inngå i flere ulike soner samtidig. Soner skal brukes til å angi gruppering av romarealer for ulike definerte formål (brannsoner, sikkerhetssoner, funksjonssoner, adkomstsoner, varmesoner, lyssoner, akustikksoner osv.) Studentgruppas Revit-versjon lager kun soner for HVAC, mens det blir laget generelle grupper for areal, gruppene kan omgrupperes til å bli en IfcZone ved hjelp av programmer som f.eks SimpleBIM 7

8 14. Geometri Geometri skal være nøyaktig når det gjelder form, størrelse (lengde, bredde, høyde, areal og volum), plassering og retning. 14. Navngivning av objekter generelt Navngivning (.Name) skal ligge på typeobjekt, og kan ligge på objekt. Navngivning (.Name) av typeobjekter skal bruke de relevante bygningsdelsnumrene i NS 3451 Bygningsdelstabellen eller NS 8360 BIM-objekter - Navngivning, typekoding og egenskaper for BIM-objekter og objektbiblioteker for byggverk på 3-siffer nivå, med mindre annet er fastsatt eller på annet vis avtalt med kommunen. Dette forenkler identifikasjon av bygningsdeler. Noen bygningsdelsnumre er listet i fagavsnittene i dette dokumentet. Eksempel: Bygningsdelsnummer 234 i NS 3451:2009 er "utvendige dører og vinduer" 15 Eierhistorikk BØR Det er ønskelig at modellen inneholder informasjon om hvilken applikasjon og hvilken organisasjon modellen ble laget av, og hvilket tidspunkt modellfilen ble opprettet og sist endret. Denne informasjon skal ligge under IfcPropertysinglevalue, og håndteres ved Client Name, Author, Organization og CreationDate. 8

9 Modellkrav Fase/Beskrivelse Komponent Krav og beskrivelse Krav Generelt Alle Navngivning (.Name) skal ligge på typeobjekt, og kan Skal ligge på objekt. Rammesøknad, etttrinns søknad og igangsettingstillatelse PROSJEKT Komponent Navngivning skal henvise til bygningsdelstabellen NS 3451 på tre siffernivå Bruk av Proxy elementer skal holdes på et minimum. Ved bruka av Proxy elementer skal de kunne identifiseres ut ifra navngivningen. (IfcBuildingElementProxy.Name) Prosjekt IfcProject Info Ett og kun ett IfcProject skal finnes per søknad, jf. ER-skjemaet. Prosjektnavnet er planlagt bruk / formål + tiltakets art pbl IfcProject.Name= <pnavn> Eksempel: Enebolig - nytt bygg, tilbygg til enebolig, fritidsbolig etc Tomt IfcSite Eiendomsnavnet IfcSite.Name, den offisielle ID-en i matrikkelen - matrikkelnummer og / eller evt matrikkelnavn knr kommunenummer gnr gårdsnummer bnr bruksnummer fnr festenummer snr seksjonsnr IfcSite.Name = <knr><gnr><bnr> Eksempel: Bygning IfcBuilding Bygningsnavn.Name, her angis bygningstypekode forklaringstekst som f. eks enebolig Funksjon.Occupant, her angis bygningstypekode nummer, f. eks 111 9

10 Etasje IfcBuildingStorey Etasjeangivelse.Name iht prosjektkrav som u.etg, 1.etg, 2.etg, 3.etg etc Etasjehøyde.Elevation 0, 1, 2, 3 etc Areal IfcSpace Bruttoareal (BTA) Bebygd areal (BYA) Bruksareal (BRA) Bruttoareal hele bygget, areal rom og konstruksjoner. BTA for hver enhet, f. eks et kontor på 10m2.Name angis som romnavn, f. eks kjøkken.number - romnummer.area her angis arealet av rommet BYA for hver bygg på eiendommen.name, "BYA" + Eksisterende, Ny.Number nummer.area - areal Bruksareal hele bygget.name - "BRA" + 1etasje, fløy, boenhet.number - nummer.area areal Sone IfcZone Qto_SpaceBaseQuantities.GrossFloorArea gjelder hele bruttoarealet for en sone, f. eks 10 stk kontorer á 10m2=100m2. Gruppere de rommene som hører til samme funksjon (kontor, korridor, fellesareal etc).zonename navn på sonen / avdelingen Forfatter / opphavsrett Ifcpropertysinglevalue Tiltakshaver, byggherre, eier.author Arkitekt, tegner, personlig navn som er knyttet til opphavsrett.organization Prosjekterende firma.creationdate Dato for IFC-eksport Ifcpropertysinglevalue.ClientName navn på tiltakshaver TOMT Tomt IfcSite.Longitude Geolokasjon, lengdegrad 10

11 Tomt Prosjekt.Latitude Geolokasjon, breddegrad.refelevation Tomtehøyde datum.projected Area Tomtens areal IfcProject.RepresentationContexts.IfcGeometricRepresentati oncontext.truenorth Definerer ekte nord, orientering himmelretning av bygget Prosjekt.IfcCoordinateReferenceSystem.Description Definerer geodetisk datum, som f. eks EUREF89, sone 32 eller NTM.IfcCoordinateReferenceSystem.Name - Definerer geodetisk datum, som f. eks EUREF89, sone 32 eller NTM.IfcProjectedCRS.MapProjection.IfcProjectedCRS.MapZone BØR.IfcProjectedCRS.MapUnit Klassifikasjon IfcClassification.IfcClassificationReference.Identification Her angis IFC versjon klassifikasjonskoden som f. eks. 2x3, 4 etc.ifcclassificationreference.name Type standard og tekst som forklarer kodens betydning som f. eks «IFC standard».ifcclassificationreference.referencedsource Kilden og identifikasjon av klassifikasjonssystemet som f. eks NS 3451, NS 8360 etc.ifcclassificationreference.description Forklaring til kildens tittel som «BIM-objekter - Navngivning, typekoding og egenskaper for BIM-objekter og objektbiblioteker for byggverk» og «Bygningsdelstabellen» OBJEKTTYPER 212 : Byggegrop, avrettet underlag for gulv på grunn IfcSlab.IfcSlabTypeEnum:PAD Tas med for å få en link / høydereferanse på bygget til terrenghøyde / kotehøyde.name Navn på objekttypen som f. eks «byggegrop», «avrettet underlag for gulv på grunn».refelevation Kotehøyden på det avrettede 11

12 222 : Søyle, generisk 23x : Yttervegg, fasade generelt, generisk (231, 232, 233, ) 234 : Dør utvendig, alle type dører, (garasje) porter og innganger 234 : Vindu, overlys, alle typer vindu, utvendig 237: Solavskjerming 24x : Innervegg, alle typer innervegger, generisk (241, 242, 243) underlaget, topp singel IfcColumn.IfcColumnTypeEnum:COLUMN.Name Den tas med og navngis hvis bygningen har HVIS en søyle tilsluttet seg. Det vil likevel vær tilfeller der bygningen ikke har søyler, og av den grunn skal søyle(ne) illustreres og ikke valideres IfcWall Alle ytterveggene og alle ytre fasader og kledning som definerer klimaskallet, må modelleres inn. I tillegg settes balkonger og verandaer som IfcWall..Name objekttypenavn som f. eks «yttervegg».pset_wallcommon.isexternal: TRUE Utvendige objekter må defineres som «TRUE» ved IsExternal.Pset_WallCommon.Load bearing Her angis om BØR veggen er bærende eller ikke. Dette er valgfritt å oppgi siden det ikke skal valideres IfcDoor.Name objekttypenavn som «dør». Denne koden inneholder alle typer dører, garasjeporter, porter og innganger.pset_doorcommon.isexternal:true - Utvendige objekter må defineres som «TRUE» ved IsExternal Dørbeslag og omramming skal modelleres inn dersom bestemmelser i byggeområdet krever det. Modelleres da som proxy-elementer Omramming og sprosser skal integreses i dørobjektet, men i enkelte tilfeller vil dette kreve at man tilpasser biblioteket for dører IfcWindow.Name alle typer utvendige vinduer, overlys, takvindu etc.pset_windowcommon.isexternal:true - Utvendige objekter må defineres som «TRUE» ved IsExternal Vindusbeslag og omramming skal modelleres inn dersom bestemmelser i byggeområdet krever det. Modelleres da som proxy-elementer Omramming og sprosser skal integreses i vindusobjektet, men i enkelte tilfeller vil dette kreve at man tilpasser biblioteket for vinduer. IfcPlate.Name objekttypenavn, alle bygningsdeler som har funksjon som solavskjerming, både på tak, vegg og elementer som er montert på vinduer IfcWall.Name objekttypenavn, gjelder alle typer innvendige vegger.pset_wallcommon.isexternal: FALSE Må ha egenskapen «false» for å kunne tolkes som en innervegg - HVIS KRAV FRA KOMMUNE N HVIS 12

13 .Pset_WallCommon.Load bearing Er valgfritt om veggen er bærende eller ikke siden det ikke skal valideres og ikke skal behandles iht TEK BØR 244 : Dør, innvendig 244 : Vinduer, innvendig 251 : Frittbærende dekker, generisk 252 : Gulv på grunn 255 : Gulvoverflate, angir de enkelte romareal 26X : Tak, alle typer tak, kvist, arker, gesimser, generisk (261, 262, 263, 264 og 265) 271 : Murte piper og ildsteder og monteringsferdi ge ildsteder (271, 272) 277: Skilt og tavler 281 : Trapp, innvendig 282 : Trapp, utvendig IfcDoor.Name Alle typer innvendige dører mellom rom.pset_doorcommon.isexternal:false - Må ha egenskapen «false» for å kunne tolkes som en innerdør IfcWindow.Name Alle typer innvendige vinduer.pset_windowcommon.isexternal:false - Må ha egenskapen «false» for å kunne tolkes som et innvendig objekt IfcSlab.Name objekttypenavn, gjelder både etasjeskille og dekke definert ved bruk av takstoler (undergurt) IfcSlab.IfcSlabTypeEnum:BASESLAB.Name Navn på objekttypen IfcSpace.IfcSpaceTypeEnum:SPACE.Name Navn på objekttypen som er med på å avgrense de enkelte rommene.qto_spacebasequantities.netfloorarea Arealet til de enkelte rommene (BRA) IfcRoof.Name objekttypenavn, her angis alle objekter som er med på å definere et tak, kvist, arker etc.pset_roofcommon.isexternal:true - Utvendige objekter må defineres som «TRUE» ved IsExternal FOR BYGG MED FLERE BO- ENHETER HVIS IfcChimney.Name objekttypenavn, tas med hvis bygningen HVIS har en pipe, ildsted eller monteringsferdig ildsted IfcPlate.Name objektttypenavn, tas med hvis det skal HVIS monteres et skilt eller tavle på eiendommen IfcStair.Name objekttypenavn, tas med hvis bygningen har innvendig (e) trapp(er).pset_staircommon.isexternal:false - Må ha egenskapen «false» for å kunne tolkes som et innvendig objekt HVIS IfcStair.Name - objekttypenavn HVIS.Pset_StairCommon.IsExternal:TRUE - Utvendige objekter må defineres som «TRUE» ved IsExternal 13

14 283 : Rampe IfcRamp.Name objekttypenavn, tas med bygningen har en rampe.pset_rampcommon.loadbearing:true - Utvendige objekter må defineres som «TRUE» ved IsExternal HVIS 285 : Øvrige dekker som balkong, amfi, tribune, repos 286: Baldakiner og skjermtak 287 : Rekkverk, alle typer rekkverk balkong og trapper, generisk 761 : Atkomstvei, sykkel og gangveg, parkeringsareal, lekeplasser, balløkker etc (761, 762) 311 : Bunnledninger for sanitærinstallasj oner, vann, avløp, overvann, fjernvarme etc 431 : System for elkraftinntak, målerskap på yttervegg IfcSlab.fcSlabTypeEnum:FLOOR.Name Alle typer dekker, balkonger, amfi, tribune HVIS og repoer Øvrige dekker IfcSlab.fcSlabTypeEnum:ROOF.Name - objekttypenavn HVIS IfcRailing.IfcRailingTypeEnum:BALUSTRAD.Name - objekttypenavn HVIS IfcSpace.IfcSpaceTypeEnum:PARKING.Name - objekttypenavn.qto_spacebasequantities.netfloorarea Utvendige arealer som skal medregnes i BYA IfcRoot.description (IfcPipeFittingTypeEnum=Entry).Name - objekttypenavn IfcPipeFittingTypeEnum=Entry.Name objekttypenavn Eiendommens eller bygningens antatte inntakspunkter for relevant offentlig teknisk infrastruktur skal være modellert med relevante objektentitetstyper når det er relevant (f.eks. IfcPipeFittingTypeEnum=Entry) BØR BØR 14