SIMBA -
SIMBA -
STATSBYGGS BIM-KRAV 1.3
Generelle krav og veiledning
Dato: 2020-01-02
Statsbygg - Postboks 232 Sentrum, 0103 Oslo, Norge xxx.xxxxxxxxx.xx/xxx - xxx@xxxxxxxxx.xx
Innhold
1 Innledning 3
1.1 Bakgrunn og Formål 3
1.2 Oppbygning av SIMBA 1.3 3
2 (a) SIMBA1.3-a, Maskinvalidérbare krav 4
2.1 Om kravdatabasen 4
2.2 Anvendelse av valideringsløsningen 5
2.3 Fortolkning av krav fra SBM 1.2.1 5
3 (b1) Generelle krav i SIMBA 1.3 (SIMBA1.3-b) 7
4 (c1) Veiledning til krav i SIMBA 1.3 7
4.1 B-1 Tverrfaglig merkesystem (TFM) 7
4.2 B-2 Prosesstatuskode 10
4.3 B-3 Global Trade Item Number (GTIN) 15
4.4 B-6 Som-bygget 16
1 Innledning
SIMBA - Statsbyggs BIM-krav 1.3 inkluderer Statsbyggs BIM-manual 1.2.1, samt introduserer nye krav som gitt under kapittel 3 i dette dokumentet.
1.1 Bakgrunn og Formål
I SIMBA 1.3 er det laget en metodikk for å stille krav til BIM-leveranser til Statsbygg ved bruk av kravsett i en database. Disse kravene formuleres på et åpent maskinlesbart format kalt mvdXML. Kravsettene er laget for å maskinelt validere BIM-leveranser på formatet IFC.
I tillegg til validering av nye krav er det for SIMBA 1.3 utviklet mvdXML-kravsett for validering av forrige gjeldende BIM-manual 1.2.1 (SBM1.2.1) basert på en fortolkning av tekstdokumentet SBM1.2.1.
Formålet med SIMBA 1.3 er en formalisering av den maskinelle fortolkningen av SBM1.2.1 i tillegg til å stille nye krav til BIM-leveranser. Dette skal effektivisere oppfølgingen både for byggherre og de prosjekterende, samt gjøre det lettere å sjekke om modellene er i.h.t. kravene i kontrakten.
1.2 Oppbygning av SIMBA 1.3
SIMBA 1.3 er bygget opp av tre hoveddeler:
(a) Maskinvaliderbare krav i SIMBA 1.3 (SIMBA1.3-a) - Kravdatabasen
(b) Ikke-maskinvaliderbare krav
(b1) Generelle krav i SIMBA 1.3 (SIMBA1.3-b) - Kapittel 3 i dette dokumentet
(b2) Krav i SBM1.2.1. - PDF-dokument fra 2013
(c) Veiledning til krav og bruk av SIMBA
(c1) Veiledning i SIMBA 1.3 - Kapittel 4 i dette dokumentet
(c2) Veiledning i SBM1.2.1 - PDF-dokument fra 2013
Fordi flere av krav i del (a) er en fortolkning av SBM1.2.1. medfører det at den siste versjonen av SBM1.2.1, datert 17. desember 2013, med fortolkning som finnes i avsnitt 2.3 i dette dokumentet, er gjeldende.
Figur 1: Bestanddeler i SIMBA 1.3 - Statsbyggs BIM-krav
Kravene som stilles i del (a) SIMBA1.3-a og (b1) SIMBA1.3-b er SKAL-krav og skal i alle prosjekter følges om ikke annet er avtalt. Kravene er strukturert etter fag og fase. Mer informasjon om prosjektenes faseinndeling i Statsbygg finnes her: xxxxx://xxxxxxxxx.xxxxxxxxxxxx.xx/xxxxxxxxxxxxxx/
Ved motstrid gjelder delene i følgende rekkefølge (a) SIMBA1.3-a, (b1) SIMBA1.3-b og (b2) SBM1.2.1.
2 (a) SIMBA1.3-a, Maskinvalidérbare krav
2.1 Om kravdatabasen
Del (a) maskinvaliderbare krav i SIMBA1.3-a er en kravdatabase for objektklasser og parametere som er maskinelt validerbare. Denne kravdatabasen er strukturert etter gjeldende IFC 2x3 skjema.
Databasen er tilgjengelig på internett via xxxxx://xxxxxxxxx.xxx-x.xxx. Det må gis brukertilgang.
Databasen spesifiserer per fagfelt hvilke krav som er gjeldende for hver enkelt fase i prosjektet, med et visuelt brukergrensesnitt. Kravsettet kan lastes ned på den åpne standarden mvdXML eller som menneskelesbar .pdf eller.odt.
Databasen inneholder standard kravsett som stilles til prosjekter generelt. Disse kravene er basert på en tolkning av SBM1.2.1 i tillegg til et sett med supplerende krav beskrevet i dette dokumentet. Det kan
i det enkelte prosjekt, når dette er avtalt, avledes spesifikke kravsett som er gjeldende i det aktuelle prosjektet. Når annet ikke er avtalt er det standardkravene som gjelder. Disse kan i tillegg til i databasen finnes på: xxxxx://xxxxx.xxxxxx.xxx/xxxx/xxxxx-xxx-xxxx, under siden SIMBA 1.3.
2.2 Anvendelse av valideringsløsningen
Valideringen av BIM-leveranser foregår ved at kravsettet fra databasen maskinelt sammenlignes med leveransen og avvik fra kravsettet rapporteres, som vist i figuren under. I denne prosessen utrykkes kravsett i SIMBA 1.3 på det åpne formatet mvdXML, som brukes til å validere leveranser på formatet IFC. Løsningen legger opp til at avvik mellom leveranse og krav rapporteres på det åpne formatet BIM Collaboration Format (BCF).
Figur 2: Arbeidsflyt for validering
Ved BIM-leveranser på avtalte milepæler skal maskinell validering i henhold til prosjektets mvdXML- kravsett for gjeldende fase være gjennomført og godkjent. Eventuelle avvik fra SIMBA 1.3 skal være avtalt med byggherre før leveranse. For å unngå oppsamling av avvik mot slutten av leveranser, anbefales det at det fortløpende benyttes validering underveis i prosjektet.
Det vil i alle prosjekter tilgjengeliggjøres maskinlesbare kravsett på mvdXML-format.
Oppskrift på praktisk bruk av databaseløsningen og validering finnes på nettsiden: xxxxx://xxxxx.xxxxxx.xxx/xxxx/xxxxx-xxx-xxxx
2.3 Fortolkning av krav fra SBM 1.2.1
De maskinvalidérbare kravsettene i SIMBA1.3-a er delvis basert både på krav fra SBM1.2.1 og nye krav beskrevet i avsnitt 3 i dette dokumentet. I beskrivelsen av alle krav er det lagt inn ett eller flere
«Ref.#» (f.eks. «Ref.#14»). Dette refererer til punkt(er) i tabellene i SBM1.2.1 som er benyttet som primærkilde(r) for tolkningen. Følgende fortolkning ligger til grunn for kravene i SIMBA1.3-a som stammer fra SBM 1.2.1:
(a) Der spesifikke krav for en objekttype ikke er angitt men det følger eksplisitt eller implisitt av overordnende/generelle forutsetninger, er det medtatt spesifikke krav for objekttypen
(b) BØR-krav er generelt ikke medtatt i det som valideres.
(c) Det er ansett som et krav i SBM1.2.1 at «Base Quantities» (mengder som lenger, bredder, høyder, arealer, volumer mv.) skal medtas for alle relevante objekttyper, men det valideres ikke på dette.
(d) Krav til u-verdi («Thermal transmittance») på objekttyper som inngår i klimaskallet (dekker, vegger, vinduer, dører, tak, søyler, bjelker, curtain walls) er ikke eksplisitt satt i SBM1.2.1 men anses ut fra angitte anvendelser av modellen som et krav, og er medtatt i valideringen.
(e) Krav til rekkverk og håndløpere (IfcRailing) er medtatt i valideringen selv om det bare implisitt er kravstilt i SBM1.2.1.
(f) Ved modellering av himlinger er det tatt høyde for at både IfcCovering og IfcSlab (PredefinedType=CEILING) i praksis benyttes som objekttype. IfcCovering benyttes også for å modellere andre former for overfater (gulvbelegg, veggfliser, kanalisolasjon, membraner mv.). Det er i valideringen lagt inn de samme kravene til IfcSlab og IfcCovering.
(g) Åpninger (utsparinger mv.) forutsettes opprettet automatisk som IfcOpening av CAD-systemet når f.eks. et dørobjekt (IrcDoor) eller vindusobjekt (IfcWindow) etableres i en modellert vegg (IfcWall). Det valideres ikke på dette. Hvis man imidlertid oppretter IfcOpening (eventuelt som IfcBuildingElementProxy) som innmelding av behov for en utsparing, må denne navngis som det («ønsket utsparing», «void» el.l.). Det valideres ikke på IfcOpening.
(h) For objektegenskap Description er kravet tolket slik at det skal legges material- og typedefinisjon (beskrivelse) i feltet.
(i) For elementer som kan modelleres både som IfcWall og IfcCurtainWall er det tolket dit hen at de samme kravene som angitt på IfcWall også gjelder for IfcCurtainWall.
(j) I kravsettet for RIV står det at utendørs traseer (kulverter) i grunnen skal være modellert med IfcSpace, ved å angi IfcSpace.InteriorOrExteriorSpace=External. Imidlertid er normal praksis at alle romobjekter modelleres av ARK, så dette sjekkes ikke som krav for RIV.
(k) I kravsettet for RIV står det at hvis det for visse komponenter er nødvendig å spesifisere og definere produktspesifikke løsninger i komponentens "Name"-felt, skal komponentens produktspesifikke art angis i "Tag"-attributten, f.eks. IfcDuctSegmentType.Tag=ProductSpecific. Da Tag-feltet benyttes på ulike måter i programvare og noe av det kan være hardkodet, må man vurdere prosjektvis om man ønsker å validere dette. Det er IKKE medtatt som krav i mvdXML-template for RIV her, men det er enkelt å sette det på som krav i et prosjektspesifikt kravsett hvis man ønsker det.
(l) Det er angitt under «Generelle krav til modellstruktur» i SBM1.2.1 at tekniske komponenter skal være modellert på detaljert generisk (ikke-produktspesifikt) nivå, egnet for konkurranseformål. Dette må bety at komponentene skal ha relevante faglige egenskaper som leder fram til utsendelse for prising ved detaljprosjekt. Siden det ikke er angitt nærmere hvilke egenskaper dette er pr objekttype, må det tolkes konkret. I IFC vil det normalt bety å benytte egenskaper under egenskapssettene PSet_XXXCommon (der XXX er den aktuelle objekttypen), eventuelt supplerende PSet_XXXnnn som relevante for den aktuelle objekttypen i noen tilfeller. Det er pr nå ikke satt inn konkrete krav i RIV/RIE-kravsettene for slike PSets, men dette kan gjøres i et prosjektspesifikt kravsett hvis man ønsker det. Etter pilotering kan tolkningen konkretiseres ut fra praktisk erfaring med de egenskapene som benyttes.
3 (b1) Generelle krav i SIMBA 1.3 (SIMBA1.3-b)
Som tillegg til krav fra SBM1.2.1 stilles det ytterligere krav i SIMBA 1.3 som vist under. En del av disse kravene finnes også som maskinelt validérbare krav i (a) SIMBA1.3-a. Alle krav i Tabell 1 er SKAL-krav og skal følges i alle prosjekter om ikke annet er avtalt.
Tabell 1: Krav til BIM i SIMBA 1.3
Ref.# | Tema | Krav |
B-1 | Tverrfaglig merkesystem | Alle entiteter i BIM skal merkes med tverrfaglig merkesystem. Informasjonen legges iht. SIMBA1.3-a i IFC-egenskapssettet NOSSB_Reference. |
B-2 | Prosesstatuskoding | Alle entiteter skal merkes med prosesstatuskoding iht. avtalt standard og SIMBA1.3-a på egenskapssettet NOSSB_process. |
B-3 | GTIN | Det skal i det enkelte prosjekt bestemmes omfang av bruk av GTIN som en del av produktdokumentasjon i BIM. |
B-4 | Maskinell validering | For alle modeller der det stilles maskinvaliderbare, krav skal IFC- leveransen, før avtalte milepæler, valideres maskinelt mot krav gitt på mvdXML-format og avvik rettes. |
B-5 | Modelleveranse til arkiv | Ved avslutning av hver fase skal alle BIM-leveranser leveres iht. gjeldende prosedyre for arkivering av BIM i Statsbygg. |
B-6 | Leveranse av modell som-bygget | 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. |
4 (c1) Veiledning til krav i SIMBA 1.3
4.1 B-1 Tverrfaglig merkesystem (TFM)
4.1.1 Bruk av TFM i BIM
TFM-koden er opprinnelig utviklet av Statsbygg bla. for å beskrive tekniske systemer og administrere kobling mellom fysiske produkter i bygget med dokumentasjon.
Berikelse av BIM-systemer og –objekter med TFM gjør det bl.a. mulig å se systemtilhørighet i BIM’en og bruke BIM’en til å gjenfinne dokumentasjon.
Det er per i dag flere systemer/krav for TFM-merking, avhengig av hvilken driftsorganisasjon som skal overta modellen. I Statsbyggs prosjekter gjelder «PA 0802 TVERRFAGLIG MERKESYSTEM (TFM)», versjon fra 2017. Det forventes at Statsbygg vil endre dette kravet i løpet av 2020 til Standard Norge siste TFM standard (NS-TFM) som forventes å komme i offisiell versjon medio 2020.
NS-TFM er mer entydig på metode og mer presis på angivelse av typer: Den er også tilpasset bruk i BIM og kravstillingsverktøy (som f.eks. dRofus og BIMeye). Alle prosjekter som skal implementere TFM bør bruke NS-TFM.
Hvis offisiell versjon av NS-TFM ikke er tilgjengelig, kan høringsversjonen brukes. Denne kan fås ved henvendelse til BIM-gruppen, XXX@xxxxxxxxx.xx eller Standard Norge, xxxxx://xxx.xxxxxxxx.xx/xxxxxxxxxx-xx-xxxxxx/.
Når NS-TFM er fastsatt og adoptert av Statsbygg som gjeldende krav vil PA 0802 ikke lengere være gjeldende.
TFM-egenskaper som beskrevet i avsnitt 4.1.3 er i henhold til høringsversjonen av NS-TFM og skal benyttes om annet ikke er avtalt.
4.1.2 TFM-egenskapssett
Navn på egenskapssett: NOSSB_Reference
NO = Norge, SSB = Statsbygg + Sykehusbygg – Iht. regler for egendefinerte egenskaper i NS 8360, punkt 5.3
Alle egenskaper for TFM skal legges under dette egenskapssettnavn.
4.1.3 TFM-egenskaper
Det er tre nivå for innlegging av TFM-kode på BIM.
På nivå 0 angis hele TFM-strengen i en egenskap.
o Alle fortegn utfylles som del av koden.
På nivå 1 angis hvert «tema» i TFM-strengen (lokasjon, system, komponentforekomst, komponenttype) i fire separate egenskaper.
o Identifikator foran hvert «tema» utfylles ikke som del av koden men tildeles maskinelt.
o Identifikatorer mellom ledd innen temaet utfylles som del av koden.
På nivå 2 angis hvert ledd innenfor hvert «tema» i TFM-strengen, alle i separate egenskaper.
o Alle identifikatorer som skiller leddene utfylles ikke som del av koden men tildeles maskinelt.
Nivå 0
Nivå 0 er kravet som gjelder i prosjekt i Statsbygg, ut fra de behovene som pr. nå er angitt fra Statsbygg-systemene «PIMS 365» og «MainManager» («SESAM»).
Selv om det er nivå 0 som er krav til leveranse, kan det være enklere å utvikle og vedlikehold kodene som separate datafelter enten på nivå 1 eller nivå 2. Fordelene ved å kode på nivå 2 er at det kan være enklere å:
Utvikle koden løpende etter hvert som prosjektet modnes
Administrere løpenumre
Trekke ut de ledd som relevante for f.eks. fysisk merking
Legges leddene inn som separate datafelter, settes disse sammen til en kodestreng ved leveranse.
Det vurderes i det enkelte prosjektet om det skal kodes på nivå 0, 1 eller 2. Vurderingen kan gjøres fagvis.
Følgende egenskaper skal brukes for å angi TFM-koder på henholdsvis nivå 0, 1 og 2.
Tabell 2: TFM, Nivå 0 | ||
Nivå 0 | ||
Beskrivelse | Egenskap | |
Samlet kode | RefString | |
Eksempel på kode på nivå 0: | ||
++B106=360.014:04-SQZ0023%SQZ.008:03
Nivå 1
På nivå 1 angis de fire ledd av TFM-koden; Lokasjon, system, komponentforekomst og komponenttype som datafelter samlet for hvert ledd.
Tabell 3: TFM, Nivå 1 | ||
Nivå 1 | ||
Beskrivelse | Egenskap | |
Lokasjon - tomt og bygg | RefLocSys | |
Samlet systemkode | RefSys | |
Samlet komponentkode | RefCompType | |
Eksempel på kode på nivå 1: | ||
++ | B106 | = | 360.014:04 | - | SQZ0023 | %SQZ.008:03 |
Nivå 1 illustrert med hva man beskriver i BIMen.
Tomt og bygg System Komponentforekomst
SQZ0023
-
Komponenttype
B106
++
360.014:04
=
SQZ.008:03
%
Nivå 2
På nivå 2 angis alle ledd i TFM-koden som separate datafelter. Merk at lokasjonskoden er lik mellom nivå 1 og nivå 2 da denne bare består av en kode som velges av oppdragseier.
Tabell 4: TFM, Nivå 2
Nivå 2
Beskrivelse Egenskap
Lokasjon - tomt og bygg RefLocSys
Systemkode RefSysClass
Systemtypekode RefSysNo
Undersystemkode RefSysSubNo
Komponentkode RefCompClass
Komponenttypekode RefCompClassNo1
Underkomponenttypekode RefCompClassNo2
Komponentforekomstkode RefCompNo
Eksempel på kode på nivå 2:
++ | B106 | = | 360 | . | 014 | : | 04 | - | SQZ | 0023 | % | SQZ | . | 008 | : | 03 |
Tilleggskoder
Det stilles ikke generelt krav til bruk av tilleggskoder. Bruk av disse avtales i prosjekt etter behov.
Tilleggskoder til TFM er ikke en del av den tradisjonelle, hierarkiske strengen, men kan gi verdi for å angi informasjon viktig i drift og vedlikehold. F.eks.
Tabell 5: TFM, tilleggskoder
Tilleggskoder
Beskrivelse Egenskap
Bygningsdelskode på komponentforekomst NS 3451 Bygningsdelstabell RefClassNS3451 Sekundært teknisk system RefSysSec
Sekundært Funksjonelt system RefSysFunc
Systemkomponentkode RefSysComp
Komponentsforekomstens romnummer (lokasjon) RefLocRoom
Romnummer som komponentforekomsten betjener RefLocRoomServe
Database type synkoniseringsnummer RefDbCompSync
Database forekomst synkoniseringsnummer RefDbOccSync
4.2 B-2 Prosesstatuskode
Det er ikke mulig å se på et BIM-objekt hvor modent det er i beslutnings- og kvalitetssikringsprosessene ut ifra geometrien alene. Et BIM-objekt hentes ofte fra et objektbibliotek i modelleringsprogramvare og endrer sjeldent detaljeringsnivå i løpet av prosjektfasene. BIM-objektet kan endre dimensjon, lokasjon, type, material, egenskaper etc. men detaljeringsnivået kan være likt fra oppstart.
I en tid hvor bruken av BIM blir mer integrert med prosjektets prosesser og gjerne brukes mer i både byggefase og FDVU-fase er det viktig å kommunisere entydig hvor modent objektet er og hva det
dermed kan brukes til. Kan det brukes som grunnlag for kalkyle, som grunnlag for innkjøp av produkter? Kan det bygges som det er modellert eller er det en orienterende skisse?
Figur 3: Eksempel på et BIM-objekt som endrer status i modningsprosessen uten at detaljeringsnivået endres
For å kommunisere objektets modning entydig angis dets status som en egen egenskap. Denne legges på objektet. Det finnes ulike systemer for prosesstatuskoding. BuildingSMART Norge har utviklet en variant og flere konsulentfirmaer i BAE-næringen har egne systemer. Det system som er mest brukt blant utførende er Modell Modenhetsindeks, MMI. Entreprenørforeningen Bygg og Anlegg (EBA) utga i oktober 2018 første versjon av MMI-veileder i samarbeid med Rådgivende Ingeniørers Forening (RIF) og Arkitektbedriftene.
4.2.1 Modellmodningsprosess
Noen viktige prosesser i løpet av prosjekteringsfasen er modellkoordinering og modellkontroll. Beskrivelse av disse er tatt med i denne veiledningen for å forklare et av flere formål med prosesstatuskoding og hvordan dette henger sammen med modningen av prosjektet.
Modellkoordinering
Modellkoordinering er en iterativ prosess hvor konseptforslag modelleres og utprøves i forhold til andre fags modeller og i forhold til prosjektparametere som for eksempel økonomi, energi etc.
Modeller sammenstilles med avtalt frekvens hvor de koordineres og analyseres. Resultatet av koordinering og analyser tas med i neste iterasjon. I løpet av modellkoordineringen vil objekter trolig ikke endre status da de er under arbeid.
Figur 4: Eksempel på løpende modellkoordinering mellom fagene i prosjekteringsfasen
Modellkontroll
Før milepælsleveranse skal det sikres at leveransene er i henhold til gjeldende krav og at det ikke er flere avvik. Prosessen endres fra koordinering til kontroll hvor fagmodeller skal være ferdig modellert på det gjeldende nivået. Kontrollen dokumenteres for endringskontroll. Objekter gis modenhetsstatus gjennom kontrollprosessen. Etter gjennomført kontroll kan modellen godkjennes som underlag for neste milepæl, for eksempel bygging.
Figur 5: Eksempel på modellkontroll, i henhold til kontrollplan og dokumentert i sjekklister. Objekter statussettes pr. kontrollområde (avtalt utsnitt av modell, for eksempel etasje, avdeling, system etc.) for å kommunisere modenhetsnivå.
4.2.2 Prosesstatuskoding i BIM
Statsbygg og Sykehusbygg har utarbeidet felles navn på egenskapssett og egenskap for å formidle prosesstatus i IFC-modell. Egenskapssettet heter NOSSB_Process (iht. regler for etablering av egendefinerte egenskaper i NS 8360:2015 BIM-objekter, punkt. 5.3).
Alle prosesstatuskoder som omhandler modellmodenhet legges på egenskapene DesignedStatus, ConstructedStatus og OperationalStatus.
Grunnen til at det er angitt flere parametere for prosesstatuskoder er at dette åpner for muligheten til å kommunisere objektets modenheten på flere områder uavhengig av hverandre. Et eksempel er at et produkt er kontrahert før det er endelig plassert. Detaljene til selve objektet er da fastsatt, selv om plassering ikke er fastsatt og objektet ikke ennå er tverrfaglig koordinert.
Det er viktig at bruken av statuskoder avklares entydig i prosjektet.
4.2.3 MMI
Det anbefales å bruke EBAs MMI-koder med mindre prosjektets behov taler for en annen kode.
Et forslag til oppdeling og detaljering av EBAs MMI veileder, for bruk i prosjekt finnes under. Det er ikke nødvendig å benytte alle koder hvis det ikke gir verdi i prosjektet. Det er også mulig å legge til nye koder mellom de foreslåtte etter behov.
Tabell 6: Eksempel på MMI-koder og deres betydning.
Prosesstatuskode Definisjon
MMI100 Skisse - Objekt er lagt inn i modell, men er ikke prosjektert eller koordinert.
MMI200 Konsept – Objekt er prosjektert på konseptuelt nivå.
MMI300 Klar for tverrfaglig kontroll – Geometri.
MMI320 Geometri låst.
MMI340 Klar for tverrfaglig kontroll – Geometri og informasjon.
MMI350 Utført tverrfaglig kontroll - Geometri og informasjon
MMI390 Klar for kontroll produksjonsunderlag.
MMI399 Ferdig prosjektert
MMI400 Produksjonsunderlag – Objektet er godkjent som underlag for anbud. MMI410 Produksjonsunderlag – Objektet er godkjent som underlag for kontrahering. MMI430 Produksjonsunderlag - Objektet er kontrahert.
MMI450 Produksjonsunderlag - Objektet er godkjent som underlag for produksjon/bygging.
MMI500 Som-bygget – Objektet er lik det byggede objekt med alle krav til merking og kobling til dokumentasjon som gjelder i prosjektet.
MMI550 Godkjent for drift.
Tiltenkt bruk av MMI-koder og parametere i egenskapssettet NOSSB_Process er beskrevet i tabellen under. Normalt vil det være de prosjekterende som har ansvar for å vedlikeholde MMI-koder som ligger på DesignedStatus, mens ansvaret for MMI-koder på ConstructedStatus ligger hos utførende.
Tabell 7: Bruk av MMI-koder i NOSSB egenskapssettet
Parameter Beskrivelse
NOSSB_DesignedStatus Kommuniserer objektets modenhet i beslutnings- og
kvalitetskontrollsprosessen i prosjekteringsfasen. Koder fra MMI000 til og med MMI399 benyttes.
NOSSB_ConstructedStatus Kommuniserer objektets modenhet i beslutnings- og
kvalitetskontrollsprosessen i byggefasen. Koder fra MMI400 til og med MMI499 benyttes.
NOSSB_OperationalStatus Kommuniserer objektets modenhet i beslutnings- og
kvalitetskontrollsprosessen i driftsfasen. Koder fra MMI500 og høyere benyttes.
4.2.4 Prosesstatuskode og Level Of Geometry (LOG)
Prosesstatuskode og Level of Geometry (LOG) er ikke det samme.
Objektgeometrien (LOG) er tilsvarende som informasjonskrav i SIMBA1.3-a, kravstilt etter prosjektfase.
Prosesstatuskoden MMI beskriver status på modenhet av objektene i forhold til gjeldende krav til informasjon, LOG og prosess.
Tabellen under beskriver sammenheng mellom modellens modenhet på gitt tema, hvordan dette kravstilles og på hvilken form modenheten uttrykkes:
Tabell 8: Sammenheng mellom modellmodenhet, krav og metode for beskrivelse.
Tema | Krav | Metode for beskrivelse av modenhet |
Geometrisk modenhet | LOG | MMI |
Informasjonsmodenhet | Alle andre krav enn LOG | MMI |
Prosess | Prosjektvise beskrivelser | MMI/annen statuskoding |
4.2.5 Objektgeometri, LOG
SIMBA skiller mellom krav til geometri og informasjon. I SIMBAs database, BIMQ kalles geometrikrav for Level of Geometry, forkortet LoG. Det er etablert fem nivåer på geometrikrav i modell. Disse spenner fra oppstart modellering til ferdig bygget prosjekt. Krav til geometri knyttes til leveranser i milepæler, blant annet ved avslutning av prosjektfase. Følgende overordnede nivåer gjelder med mindre annet er avtalt.
Tabell 9: Geometrinivåer
LoG nivå | Beskrivelse |
LoG Level 1 | Objektet kan brukes til, men er ikke begrenset til, bla. visualisering og vurdering av konsept. Objektet representerer enten en konseptuell geometri eller et volum. Objektgeometrien er skissert uansett hvor detaljert objektet er. Objektets lokasjon og orientering er konseptuell. |
LoG Level 2 | Objektet kan brukes til, men er ikke begrenset til, bla. visualisering og vurdering av det tverrfaglige designkonsept. Objektet representerer generiske typer. Objektgeometri, -lokasjon og -orientering er tilnærmet. |
LoG Level 3 | Objektet kan brukes til, men er ikke begrenset til, bla. kostnadskalkyle og modellkoordinering. Objektgeometri, -lokasjon og -orientering er eksakt når modellen er tverrfaglig koordinert. |
LoG Level 4 | Objektet kan brukes til, men er ikke begrenset til, bla. innkjøp, planlegging og produksjon. Alle detaljer som er nødvendige for produksjon og montering er representert i geometrien. Objekter med tekniske tilkobling eller bærende oppheng skal vise dette presist i geometrien. Objektgeometri, -lokasjon og -orientering er eksakt. |
LoG Level 5 | Objektet kan brukes i, men er ikke begrenset til, bla. FDVU-prosessene. Objektgeometri, -lokasjon og -orientering er eksakte ift. det fysiske byggverk. |
Krav til geometri er beskrevet i databasen BIMQ som LoG. Kravet omfattes ikke av den automatiske valideringen, men kan eksporteres til en lesbar rapport for prosjektdeltakerne. Prosjektet skal etablere metode for å sikre at deres modeller tilsvarer krevd nivå på geometri.
4.3 B-3 Global Trade Item Number (GTIN)
Global Trade Item Number (GTIN) er en åpen identifikasjonskode fra organisasjonen GS1 som brukes til å gi produkter, forpakninger og tjenester ett unikt nummer. Dette gjør at to artikler ikke kan forveksles, som igjen gjør det enklere å bestille, selge og håndtere produkter i verdikjeden. GTIN er i denne sammenhengen en unik identifikasjon av den handelsvaren som tilsvarer en objekttype i en modell. Det er også mulig å identifisere forekomster av handelsvaren med GTIN - såkalt SGTIN (serialized GTIN). For nærmere informasjon om GTIN se xxx.xx0.xx.
De kjøpte handelsvarene skal primært dokumenteres ved sin GTIN som unik vare-ID, enten direkte som en egenskap ved de BIM-objektene som tilsvarer handelsvaren, eller ved at unike TFM-strenger
benyttes for å gjøre éntydige oppslag mot dokumentasjon som omfatter handelsvarens GTIN. Som sekundær-ID kan varedatabase-ID benyttes (for eksempel NOBB/EFO/NRF-nummer). Som tertiær-ID kan produsentens eget varenummer benyttes. For “one-of-a-kind"-produkter som ikke er katalogført direkte, kan alternative ID-er fra GS1 benyttes, som SGTIN avledet fra et hoved-GTIN el.l., eller GIAI.
4.4 B-6 Som-bygget
Det stilles i SIMBA1.3-b krav til leveranse av modellen som-bygget i alle Statsbyggs prosjekter. I prinsippet skal en «som-bygget»-leveranse som et minimum inneholde:
Xxxxxxxxx modell for alle faktiske endringer etter ferdig godkjent detaljprosjekt og fram til som- bygget. Gjelder endring av løsninger, typer, plassering utover akseptable toleranser.
Objekter beriket med egenskaper spesifikke for som-bygget leveransen i henhold til kravdatabasen. Dette omfatter blant annet kvalitetssikrede, unike TFM-strenger, oppdaterte prosesstatuskoder (MMI) som gjenspeiler som-bygget-situasjon og produkttypekoder (GTIN) i modellen dersom prosjektet har besluttet at dette skal foreligge.
Figuren under viser flyten for BIM fra som-prosjektert til som-bygget. Utførende, prosjekterende og oppdragsgiver danner en felles arbeidsgruppe (avviksstyre), med ansvar for å registrere avvik og avtale aksjoner. Avviksstyret blir enig om tillatte avvik, metode for avvikskontroll og frekvens for avviksbehandling. Bygget kontrolleres løpende, som del av kvalitetssikring for utførende, for samsvar med modell. Avvik rapporteres med gitte intervall til avviksstyret. Avviksstyret blir enig om hvordan ikke tillatte avvik skal håndteres, og melder dette til enten prosjekterende eller utførende. Når alle avvik er behandlet og det bare er tillatte avvik igjen er modellen oppdatert som-bygget.
Figur 6: Arbeidsflyt for BIM fra som-prosjektert til som-bygget
STATSBYGG
ADRESSE Postboks 000 Xxxxxxx, 0000 Xxxx
BESØKSADRESSE Biskop Xxxxxxxx' xxxx 0 (Byporten) 0155 Oslo
TLF. 00 00 00 00
NETT xxxxxxxxx.xx
E-POST xxxxxxxxxx@xxxxxxxxx.xx