SIMBA 1.2.1.: Tolkning av SBM 1.2.1
Følgende tolkningspunkter - tolket ut fra sin sammenheng og intensjon - er lagt til grunn i det digitale kravsettet for SIMBA 1.2.1 (og på samme måte i SIMBA 1.3). Den angitte tolkningen gjelder hvis man ikke i et konkret byggeprosjekt beslutter å tolke det annerledes og har nedfelt prosjektets tolkning.
(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 generelt 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.
*
I beskrivelsen av alle krav i kravadatabasen (BIMQ) 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.
*
Eventuelle feil som oppdages eller spørsmål om tolkninger kan meldes tilbake til oss på Kommentarskjemaet.