Kravene
SIMBA 2.1.1Generelle krav
SIMBA 2.1.1 ("minimumskravsettet") har ikke ikke en egen spesifikasjon for generelle (ikke-maskinvalidérbare) krav, men de generelle kravene i SIMBA 2.1 gjelder så langt det er relevant.
Innhold
Introduksjon
Generelle krav er krav som er overordnede for modelleveranser og ikke kan valideres maskinelt.
Kravene er identifisert med et referansenummer (Ref#) med prefikset "G" og et løpenummer.
Generelle krav kan enten lastes ned i PDF- eller Excel-format eller leses på siden under.
G1. Objektmodell
Alle avtale fag skal levere en objektbasert modell (også omtalt som «modell» eller «BIM-modell») bestående av objekter med egenskaper og relasjoner.
- Alle avtale fag skal koordinere og levere objektbasert modell på gjeldende IFC-format og native-format basert på god modelleringspraksis iht. NS 8360-serien, EBA sin MMI-veileder og NS-EN ISO 19650 del 1 og 2.
- Dette omfatter bla. praksis innen terminologi, prosjektnullpunkt, rotasjon, georeferering, identifikasjon (navngivning og nummerering), tverrfaglig merkesystem, relasjoner, prosesstatuskode (MMI), avtale og oppfølging av krav i prosjekt etc.
Veiledning
Modell skal bestå av objekter med egenskaper og relasjoner. Ved koordinering og leveranse skal det leveres på avtalt IFC-format.
Ved avsluttet forprosjekt og overlevering ferdig bygget skal det i tillegg leveres native-format. Native-format er det formatet til programvaren som modellen er modellert i.
Programvare skal være hensiktsmessig for effektivt å skissere og prosjektere. Dette omfatter etablering, vedlikehold og endring av informasjon samt samhandling med prosjektets andre aktører både på åpent format (IFC) og native-format.
G2. Originalformat
Modell skal leveres på native-format etter avsluttet forprosjekt og ferdig bygget prosjekt.
- Når modellen skal leveres på native-format skal leveransen omfatte alle objekter som er utviklet og benyttet i prosjektet.
- Objekter skal, med mindre annet er avtalt, ha full parametri for evt. videre bearbeiding.
- Proprietærformatet skal inneholde alle relevante «views», eksempelvis; plan, snitt, fasade og detaljer som har vært grunnlag for overleverte tegninger i prosjektleveransen. Andre Views som er benyttet som arbeidsunderlag, skisser etc. skal «ryddes» ut av modellen før overlevering.
- CAD-systemets objektbibliotek skal inneholde alle benyttede objekter i prosjektet. Andre objekter som ikke er benyttet i prosjekteringen skal «ryddes» ut av modellen før overlevering.
- Der de prosjekterende har utarbeidet prosjektspesifikt oppsett for berikelse av informasjon ved hjelp at script, skal oppsettet følge med proprietærformatet, og ved senere anledning kunne benyttes med full funksjonalitet.
- Alle lenker til eksterne referanser og avhengigheter av plug-ins skal være fjernet og modellen skal kunne åpnes og redigeres, eksporteres og fungere uten disse.
- Originalformatet skal muliggjøre framtidige IFC-eksporter til nyere IFC-versjoner og kunne være utgangspunkt for senere bruk av modellene.
G3. Georeferering, Lokale koordinater og globale koordinater
Det enkelte prosjekt kan avtale fravik fra krav til felles nullpunkt, hvis det leveres modeller i "globale koordinater".
- Bruk av globale koordinater krever at kompetanse, programvareverktøy, eventuelle konverteringer og transformasjoner samt definerte rutiner støtter globale koordinater. Dette skal være kommunisert, forstått, akseptert av alle involverte parter.
Veiledning
Modeller som leveres med globale koordinater vil kunne benyttes effektivt sammen med andre modeller innen GIS (f.eks. terreng, infrastruktur, fjellkoter osv.) som opererer direkte i "globale koordinater". Det vil redusere risiko for feil i modell eller prosjekteringsgrunnlag fra GIS som stammer fra manglende kunnskap og rutiner for georeferering, konvertering eller transformasjon.
G4. Nullpunktsobjekt
Det skal brukes «kjeglebiter" for å angi fagenes prosjektnullpunkt.
- Kjeglen skal "peke" opp (positiv y-akse).
- Selve origopunktet skal være z=0 i kjeglespissen.
- Entitet for objekttype: IfcBuildingElementProxy med IfcBuildingElementProxyTypeENum=USERDEFINED og IfcBuildingElementProxy.ObjectType=PROJECTORIGIN.
- Bruk standard forkortelser for fag for navngivning av kjelgebitene, f.eks. IfcBuildingElementProxy.Name=RIE for elektro.
G5. Tegning fra modell
Det skal være samsvar mellom informasjon i modell og på tegning. Modell skal være grunnlag for tegning.
Veiledning
Informasjon på tegning skal i størst mulig grad hentes fra modell.
Nærmere anvisninger om tegningsutforming finnes i veiledningen PA 0603 2-D DAK-tegninger.
Informasjon som er mer detaljert enn det som normalt modelleres og som bare finnes på tegning kan f.eks. være bygningsdetaljer, innfestingsrekkefølge etc.
G6. Tverrfaglig kontroll av modeller
Ledende leverandør har i alle prosjekter ansvar for at det gjennomføres tverrfaglig koordinering mellom alle prosjekterende og modellerende disipliner.
- Ledende leverandør har i alle prosjekter ansvar for at det gjennomføres tverrfaglig koordinering mellom alle prosjekterende og modellerende disipliner.
- Modeller som skal kontrolleres tverrfaglig omfatter både leverandører innen avtalen og leverandører innen andre avtaler i prosjektet. Dette inkluderer geometrisk kollisjonskontroll mellom objekter i modeller. Det skal gjennomføres maskinelt og manuell tverrfaglig kontroll av modeller.
- Ledende leverandør skal sammenstille modell for alle fag minimum hver 14. dag og tilgjengeliggjøre denne for Statsbygg. Omfang og prosedyre for dette skal avtales i prosjektet.
- Krav til tverrfaglig koordinering omfatter alle prosjekterende parter herunder prosjekterende underleverandører f.eks. prefab betong, prefab stål, prefab baderom, tekniske installasjoner, klimavegg etc.
- For alle modeller der det stilles maskinvaliderbare krav fra Statsbygg skal IFC-leveransen, før avtalte milepæler, valideres maskinelt av leverandør mot krav gitt på maskinlesbart format og avvik rettes.
- Ved hver avsluttet prosjektfase skal TE/PG levere kontrollrapport sammen med modeller for å vise at modeller er levert iht. krav.
Veiledning
Statsbygg forutsetter at de prosjekterende selv gjennomfører maskinell validering av sine modeller før leveranse til Statsbygg, for å kunne rette avvik i størst mulig grad.
G7. Modellfilnavn
Modellfilnavn skal følge Statsbyggs navngivningssystem:
ENr_BNr_PNr_Hf_Uf_LøpeN
- Det skal ikke inkluderes fritekst for eiendom/bygning på slutten av modellnavnet.
- Modeller av eksisterende bygg som ikke har et prosjektnummer kan få unntak av krav og utfylles med "0" (null).
Veiledning
ENr = Statsbyggs eiendomsnummer (obligatorisk). BNr = Statsbyggs bygningsnummer (obligatorisk). PNr = Byggherrens prosjektnummer eller annen prosjektreferanse-ID som oppgitt (obligatorisk). Hf = Fag-ID. Bruk norske fag-forkortelser (frivillig). Uf = Underfag (frivillig). LøpeNr = 1, 2, 3, … hvis flere filer inngår i underdelingen (frivillig). ext = Extension, dvs. filendelse, f.eks. .ifc for en IFC-fil, .rvt for en Revit-fil osv. (obligatorisk).
Eksemplet ovenfor er fra Østfold ungdoms- og familiesenter": 13879_112324_1192591_ARK_0_0.ifc Statsbygg-eiendomsnummer "13879". Statsbygg-byggnummer "112324". Statsbyggs prosjektnummer "1192501" Hovedfag "ARK" Modell er ikke underdelt i underfag eller løpenummer. Filformatet er IFC
Statsbygg bruker 7-sifret prosjektnummer (f.eks. "1146601"). Eldre prosjekter kan bruke 5-sifret prosjektnummer.
G8. Måleenheter
Hvis annet ikke er avtalt i oppdraget skal det benyttes SI-enheter både under oppdragsutførelse og ved leveranser til Statsbygg. Spesifikke måleenheter skal avtales for uttak av mengder i BaseQuantites.
Veiledning
Normalt vil man operere med millimeter (mm) for lengde kvadratmeter (m2) for arealer, og kubikkmeter (m3) for volumer. For avledede enheter, f.eks. volum pr tidsenhet bør det gjøres felles avtaler ved oppstart av oppdraget, men uansett skal enhetene framgå i selve modellene.
G9. Mengder
Alle relevante objektklasser skal eksporteres til IFC med «Base Quantities» (mengder som lenger, bredder, høyder, arealer, volumer mv.).
Veiledning
Hva som inngår i "base quantities" vil variere mellom objekt klassene.
På et sirkulært objekt vil f.eks. diameter kunne være en av mengdeparameterne, noe det ikke er for et rektangulært objekt.
Der mengder ikke finnes i "Qto_" skal mengder som finnes i "Pset-" benyttes. D
et er noen forskjeller i hvordan IFC2x3 og IFC4 angir mengdeegenskapene.
G10. Lagdeling
Om ikke annet er avtalt skal objekter tildeles DAK-lag iht. NS 8351 Byggetegniger - Datamaskinassistert konstruksjon - Lagdeling.
Lag skal være inkludert i IFC-eksporten.
G11. Forenklet geometrisk objekt
Hvis dimensjoner på et objekt ikke er kjent i gjeldende prosjektfase og kan variere skal det vises med et forenklet geometrisk objekt som viser største antatte dimensjon.
Veiledning
Forenklet geometri kan variere fra en enkel boks (bounding box) til tilnærmet kjent ytre geometri, avhengig av tilgjengelig informasjon om det fysiske objektet, og variasjonen i fysiske dimensjoner mellom ulike kjente handelsvarer.
G12. Forenklede modeller
Der fagmodeller er spesielt enfaglig detaljerte, utover det som er nødvendig for tverrfaglig prosjektering og dette tynger ned ytelse på sammenstilte modeller kan byggherre kreve leveranse av forenklet modell som brukes til sammenstillingsformål.
- Dette er del av tilbudt leveranse uansett om det er avtalt eksplisitt.
- Forenklede modeller for spesielle analyseformål f.eks. energiberegning skal avtales ved avtaleinngåelse eller er å oppfatte som tillegg.
Veiledning
Eksempler på modeller som skal leveres i håndterbar detaljeringsgrad kan være svært detaljerte modeller fra underleverandører for prefabrikkerte baderom eller klimavegger.
G13. Produktgeneriske og produktspesifikke objekter
Før anskaffelse (kontrahering av entreprenør og underleverandør) skal objekter ikke modelleres produktspesifikt.
- Modeller som brukes som underlag for anskaffelse av entreprenør og underleverandør skal være produktgeneriske.
- Det kan gjøres unntak fra dette kravet hvis det foreligger hjemmel for dette, og det er hensiktsmessig for prosjektet.
Veiledning
Hvis det brukes produktspesifikke objekter i modell skal produktnavn/-type angis i IFC-modellens tag-attributt, f.eks. IfcDuctSegmentType.Tag.
Objekttypenavn (IfcRoot.Name) skal fortsatt være produktgenerisk.
Noen programvarer bruker Tag-attributtet som standard-attributt for andre formål, så bruk av Tag-attributtet skal testes og kvalitetssikres i prosjektet.
Det skal ikke spesifisere konkrete produkter direkte eller indirekte i modell. Indirekte ved at angi egenskaper unike for ett spesifikt produkt.
G14. Leveranse av som-bygget modell
Det skal i alle prosjekter leveres modell som-bygget.
- Modellen skal være korrigert for alle faktiske endringer etter ferdig godkjent detaljprosjekt og fram til ferdigstillelse av bygget.
- Hvis modellen inneholder kjente avvik som er uttrykkelig akseptert av byggherren som en del av overtakelsen, skal disse være konkret listet sammen med modellen eller ved definerte og avtalte egenskaper i modellen på en måte som gjør at forvalter senere enkelt kan identifisere og modellere om avvikene.
- Prosess for registrering og modellering av avvik skal etableres i prosjektet.
- Ansvar for registrering og modellering av avvik skal avtales i prosjektet.
G15. Inntaks-/ uttakspunkt for infrastruktur
Bygningens inntaks-, eller uttakspunkter for relevant offentlig teknisk infrastruktur skal være modellert med relevante objektklasser.
- Objektene skal, om mulig, klassifiseres med PredefinedType. Hvis dette er mulig ved å beskrivende parametere, kan identifiseres som inntaks- eller uttakspunkter.
Veiledning
Eksempler på parametere som angir dette: Inntakskabler - IcfCableFittingTypeEnum=Entry Utløpsrør til avløp - IcfPipeFittingTypeEnum=Exit
G16. Revisjonshåndtering av modeller
Med mindre annet avtales skal ledende leverandør etablere løsning for utveksling og tydelig å kommunisere for alle relevante parter i prosjektet, gjeldende versjon av modeller samt revisjonsnummer og, hvis relevant, hva revisjon gjelder.
Veiledning
Modellrevisjon skal kommuniseres som metadata på modellfil og ikke inkluderes i modellnavn.
Hva revisjonen gjelder kommuniseres som beskrivelse på metadata eller i felles tilgjengelig liste med revisjonsnummer som referanse.
G17. GUID
Global Unique ID angitt på objektforekomster og systemer fra modellapplikasjonen skal ikke endres med mindre objektet erstattes med en annen type.
Veiledning
Entreprenør bruker GUID til å identifisere objekter i deres kalkylesystem.
Hvis GUID endres vil objektet oppfattes som et nytt objekt som ikke er tildelt prislinje.
For at samhandling mellom prosjekterende og utførende skal være effektiv med modell skal bare objekter som erstattes med ny type ha endret GUID.
G18. Bygningskropper
Det skal, i alle modeller, opprettes minst ett bygningsobjekt, IfcBuilding.
- Ved bruk av flere enn ett bygningsobjekt skal eventuell oppdeling og navngivning redegjøres for.
- Bruk av IfcBuilding-objekt, skal avklares med Statsbygg før modelleringen påbegynnes.
Veiledning
Generelle retningslinjer for opprettelse av et bygningsobjekt: Separat bygg/bygningskropp: Egen IfcBuilding
Tilbygg som bygges rett over, under eller ved siden av (grenser inntil) eksisterende bygning: Samme IfcBuilding som eksisterende bygning
Tilbygg som bygges nær eksisterende bygning, men med en egen, tydelig adskilt bygningskropp: Egen IfcBuilding
Mellombygg/forbindelser mellom adskilte bygningskropper: Egen IfcBuilding
G19. (Gjelder arkitektur) Gruppering av rom i soner
Der det er relevant for å modellere gruppering av romobjekter (IfcSpace) for et angitt formål skal IfcZone anvendes som soneobjekt.
Veiledning
IfcZone kan f.eks. benyttes for å gruppere rom etter deres funkjsoner eller tilhørighet til avdelinger.
Et IfcZone-objekt kan også ha andre IfcZone-objekter i sin gruppering. IfcZone har ikke egen geometri.
G20. (Gjelder arkitektur) Soneobjekter
Der det er relevant å modellere en romlig struktur for et angitt formål, uavhengig av romobjekter eller fysiske bygningsdeler/komponenter, skal IfcSpatialZone benyttes.
- Det skal samtidig angis hvilken PredefinedType av (SpatialZoneTypeEnum) som gjelder. USERDEFINED skal benyttes som egendefinert type der IFCs predefinerte typer ikke passer.
- Når USERDEFINED benyttes, skal navn på den egendefinerte typen samtidig angis på attributtet ObjectType på det relevante forekomstobjektet.
- Statsbygg kan ha krav til hvilke egendefinerte typenavn som skal benyttes.
Veiledning
Predefinerte typer kan være bl.a. OCCUPANCY for å angi en utleiesone, FIRESAFETY for å angi en brannsone.
En mulig brukerdefinert sone (USEREDEFINED) kan være f.eks. IfcZone.ObjectType=INFECTIONCONTROL eller CULTURALHERITAGE.
Ettersom det ikke er et krav å bruke soneobjekter er bruk av predefined type ikke kravstilt i kravdatabasen.
G21. (Gjelder arkitektur) Romarealer
Alle funksjonelle arealer skal modelleres med 3-dimensjonelle romobjekter med objektklassen IfcSpace.
- Rommets areal angir nettoareal (NTA).
- Rom kan være helt, delvis eller ikke avgrenset av omkringliggende bygningsdeler (vegger, dører, vinduer etc.).
- Romarealer kan både representere innendørs og utendørs funksjoner.
Veiledning
Eksempler på ikke-fysiske romarealer: En arbeidsplassfunksjon i et åpent landskap, et minikjøkken i en korridor.
Eksempler på utendørs funksjoner: En biloppstillingsplass, et sykkelstativområde, et lekeplassområde, et inngangsområde.
G22. (Gjelder arkitektur) Romfunksjonsnummer
Alle objekter som representerer romarealer skal ha et romfunksjonsnummer (RFNR) som samsvarer med byggherres romfunksjonsprogram.
- RFNR skal være unike i det aktuelle prosjektet.
- Rom som oppstår i prosjekteringen skal opprettes med nytt RFNR av den prosjekterende, og kommuniseres til byggherren, som tar stilling til om det skal aksepteres eller ikke og inngå i modell videre.
Veiledning
Eksempel: 10 like kontorer har 10 unike RFNR.
G23. (Gjelder arkitektur) Bruttoarealobjekt
Det skal for hver etasje (IfcBuildingStorey) opprettes et bruttoarealobjekt med objektklassen IfcSpace.
- Arealer skal beregnes i henhold til NS3940.
- Bruttoarealobjektet angis ved å navngi LongName attributten (SpatialFunctionCode) med "BTA", eventuelt etterfulgt av et mellomrom og en ytterligere spesifikasjon, f.eks. "BTA etasje 3".
Veiledning
Bruttoarealobjektet kan alternativt angis ved at predefinert type av romobjektet angis som "GFA" (Gross floor area), (IfcSpaceTypeEnum:GFA). Bruk av denne alternative metoden skal bare benyttes dersom det ikke er mulig å benytte kravstilt metode og skal aksepteres av Statsbygg.
BTA inkluderer alt nettoareal og konstruksjonsareal (også klimaskallet).
Arealobjekter kan leveres i egen modell for å unngå at romobjekt for BTA overlapper med andre romobjekter.
G24. (Gjelder arkitektur) Bruksarealobjekt
Det skal for hver etasje (IfcBuildingStorey) opprettes et bruksarealobjekt med objektklassen IfcSpace.
- Arealer skal beregnes i henhold til NS3940.
- Bruksarealobjektet angis ved å navngi LongName attributten (SpatialFunctionCode) med "BRA", eventuelt etterfulgt av et mellomrom og en ytterligere spesifikasjon, f.eks. "BRA etasje 3"
Veiledning
Bruksarealobjektet kan alternativt angis ved at predefinert type av romobjektet angis som "USERDEFINED", (IfcSpaceTypeEnum:USERDEFINED) og at navnet på den brukerdefinerte typenangis med attributten IfcSpace.ObjectType:UA (Usable Area). Bruk av denne alternative metoden skal bare benyttes dersom det ikke er mulig å benytte kravstilt metode og skal aksepteres av Statsbygg.
BRA inkluderer alt nettoareal og konstrusjonsareal for innervegger. Arealobjekter kan leveres i egen modell for å unngå at romobjekt for BRA overlapper med andre romobjekter.
G25. (Gjelder arkitektur) Høydeavgrensning av romarealer
Hvis annet ikke avtales i prosjektet, skal romarealer modelleres med IfcSpace fra overkant av bærende dekke opp til underkant dekke.
G26. (Gjelder arkitektur) Horisontal oppdeling av romarealer
Hvis annet ikke er avtalt skal rom som strekker seg over flere etasjer ha et eget romobjekt for hver etasje.
27. (Gjelder arkitektur) Himling
Ved modellering av nedsenkede himlinger skal enten kledning (IfcCovering:CEILING) eller dekke (IfcSlab, PredefinedType=CEILING) benyttes som objektklasse.
- Det stilles de samme informasjonskrav uansett om det brukes IfcSlab og IfcCovering.
Veiledning
IfcCovering benyttes også for å modellere andre former for overflater (gulvbelegg, veggkledning isolasjon, membraner mv.).
28. (Gjelder arkitektur) Curtainwall
Hvis en curtainwall (IfcCurtainwall) modelleres som en vegg (IfcWall), typisk i tidlig fase, gjelder kravene for vegg for curtainwall-objektene.
Veiledning
Dette gjelder at man i skissefase gjerne bruker veggobjekt for å beskrive en curtainwall. Dette gjøres fordi geometrien endres mye i tidligfase og det tar for lang tid å endre alle detaljer i en curtainwall.
29. (Gjelder bygningsmessige fag) Dekker
For følgende dekkeobjekter, eksportert som IfcSlab, skal angitte Predefined Type benyttes: Gulv på grunn = BASESLAB - Dekker mellom etasjer = FLOOR - Topp- eller takdekke = ROOF
G30. (Gjelder bygningsmessige fag) Yttervegger
Høyde på yttervegg (IfcWall eller IfcCurtainWall) skal være i samsvar med planlagt etasjehøyde, og være modellert fra overkant av bærende dekke i etasje n til underkant av bærende dekke i etasje n+1.
G31. (Gjelder VA) Kulvert for vann og avløp
RIVA skal modellere utendørs traseer i grunnen (kulverter).
Disse skal modelleres som rom (IfcSpace.InteriorOrExteriorSpace:External).
G32. (Gjelder tekniske fag) Tekniske systemer og undersystemer
Med mindre annet er avtalt, skal tekniske objekter grupperes i systemer eller undersystemer med bruk av IfcSystem eller annen relevant underkategori av IfcSystem.
- Undersystemer skal ha relasjon til hovedsystem gjennom IfcSystem.
Veiledning
Eksempel: En typisk inndeling av et system er et ventilasjonssystem som er delt i undersystemer for inntak, tilluft, omluft, fraluft, og avkast. Disse skal kunne gjenfinnes i BIM-modell som undersystemer.
Generelle krav
| Generelt krav | Beskrivelse |
|---|---|
| G1. Objektmodell | Alle avtale fag skal levere en objektbasert modell (også omtalt som «modell» eller «BIM-modell») bestående av objekter med egenskaper og relasjoner. |