tillampningsanvisningar-bim

# Introduktion Syftet med leveranspaket 1 för AG3 -- IFC-gruppen, är att förklara grundläggande begrepp och standarder som används vid utbyte av information där IFC är det centrala överföringsformatet. # Om IFC-standarden **IFC** (*Industry Foundation Classes*) är en öppen och neutral standard för informationsmodellering inom bygg- och anläggningsindustrin. Den är utvecklad av intresseorganisationen buildingSMART, och antagen som internationell standard i form av ISO 16739-1:2018. IFC används som en gemensam informationsmodell för att representera olika aspekter av ett byggprojekt. Modellen definierar strukturen och semantiken för data som kan vara relevanta för byggobjekt, såsom geometrier, egenskaper, relationer och hierarkier. Alla dessa definieras som entiteter -- ungefär "företeelser" -- oavsett om de har en fysisk representation eller inte. IFC kan implementeras i olika filformat för att underlätta informationsutbyte mellan olika programvaror och system. Det vanligaste filformatet som används för att lagra och överföra IFC-data är filformatet som har filändelsen \"ifc\". Detta är en textfil som följer en specifik syntax och struktur enligt IFC-standardens specifikationer. IFC är alltså både en standard för informationsmodellering och ett filformat. Informationsmodellen definierar strukturen för data, medan filformatet (IFC-filen) används för att lagra och överföra data som följer den definierade informationsmodellen. Genom att använda IFC kan olika programvaror och system kommunicera och dela projektrelaterad information på ett strukturerat sätt. Informationen kan omfatta geometri, egenskaper, relationer och andra relevanta data om byggobjekt såsom väggar, golv, tak, dörrar, fönster, vägar, broar, installationer, material och komponenter. IFC-filen fungerar som en container för att lagra denna information, och den kan sedan användas av olika programvaror för att visualisera, analysera, simulera och hantera byggprojekt. Genom att använda IFC-standardens gemensamma informationsmodell kan olika aktörer inom bygg- och anläggningsbranschen effektivt samarbeta och dela data oavsett vilken programvara eller system de använder. Det hjälper till att förbättra kommunikationen, minska dubbelarbete och öka precisionen i informationsutbytet mellan olika faser av ett projekt, från design och konstruktion till drift och underhåll. ## Struktur Strukturen för att beskriva entiteter enligt IFC ser ut så här:  Bild : Grundläggande struktur för IFC-objekt. Alla entiteter som placeras inom denna struktur ärver sin överordnade entitets attribut. Alla entiteter som definieras under *IfcRoot* tilldelas det obligatoriska attributet *GlobalId* (i form av en globalt unik identitet, GUID) samt följande valfria attribut: - OwnerHistory: ägare och dess historik - Name: entitetens namn - Description: entitetens beskrivning. Följande typer av entiteter placeras under *IfcObjectDefinition*: - fysiskt påtagliga objekt, exempelvis väggar, balkar och rör - fysiskt existerande objekt, exempelvis utrymmen - konceptuella objekt, exempelvis stomlinjer och gränser - processer, exempelvis arbetsuppgifter - kontroller, exempelvis kostnadsuppföljning - resurser, exempelvis personal, material, och utrustning - aktörer, exempelvis personer och företag. Entiteter under *IfcRelationship* definierar olika relationstyper mellan entiteter och egenskaper. Entiteter under *IfcPropertyDefinition* definierar hur egenskaper läses, ändras, och tilldelas till entiteter inom *IfcObjectDefinition*. ## Attribut och egenskaper Entiteter kan beskrivas ytterligare med hjälp av egenskaper (*IfcProperty*). Dessa egenskaper redovisas i **egenskapsuppsättningar** (*IfcPropertySet*) och **mängduppsättningar** (*IfcQuantitySet*). Attribut ligger alltid direkt på respektive entitet, medan egenskaper alltid ligger i en egenskaps- eller mängduppsättning. Figuren nedan visar ett exempel på hur attribut (numrerade från 1 till 8) ärvs i IFC-strukturen samt hur egenskaper är samlade i egenskaps- (orange) och mängduppsättningar (grön) för en balk (*IfcBeam*).  Bild : Exempel på attribut, egenskaper, samt egenskaps- och mängduppsättningar. Attributen kan både vara tvingande och valbara. Av de nio attribut i exemplet ovan är det enbart *GlobalID* som är tvingande. Mappningen av information från originalprogramvaran till dessa attribut styrs av programvaruleverantörens exportfunktion, men kan i vissa fall ändras av användaren. Det kan vara svårt att veta hur denna mappning är definierad, vilket gör det svårt att kravställa information på dessa attribut. Egenskaper ingår alltid i en eller flera egenskaps- eller mängduppsättningar, och en egenskaps- eller mängduppsättning kan i sin tur beskriva en eller flera IFC-entiteter. Relationen mellan dessa styrs via *IfcPropertyDefinition* som nämnts ovan. För balken i exemplet ovan finns en koppling till 25 egenskapsuppsättningar och två mängduppsättningar, se nedan.  Bild : Egenskaps- och mängduppsättningar som är kopplade till entitetet IfcBeam. Mappningen av information från originalprogramvaran till dessa egenskaps- och mängduppsättningar styrs av programvaruleverantörens exportfunktion, men kan i vissa fall ändras av användaren. Det kan vara svårt att veta hur denna mappning är definierad vilket gör det svårt att kravställa information på egenskaperna i dessa egenskaps- och mängduppsättningar. För varje egenskaps- och mängduppsättning finns en beskrivning av ingående egenskaper, se exempel för *Pset_BeamCommon* i figuren nedan. Exemplet visar enbart tre av de nio ingående egenskaperna.  Bild : Exempel på egenskaper i egenskapsgruppen Pset_BeamCommon. Varje egenskaps beskrivs med en benämning (*Name*), egenskapstyp (*Property Type*), datatyp (*Data Type*), och en beskrivning (*Description*). Det går även att skapa användardefinierade egenskaps- och mängduppsättningar som inte ingår i IFC-standarden, exempelvis med egenskaper enligt CoClass (www.coclass.bytttjanst.se) eller BIP (www.bipkoder.se), eller med företags- eller projektspecifika egenskaper. I dessa fall ska benämningarna av egenskaps- och mängduppsättningen inte föregås av prefixet *Pset* eller *Qto*. Däremot är det möjligt att skapa egenskaps- och mängduppsättningar med dessa prefix om benämning och ingående egenskaper följer IFC-standarden. Detta kan vara aktuellt för att kringgå programvaruleverantörernas fördefinierade mappning av originalprogramvarans information mot IFC-standardens egenskaper. *Vid utbyte av information via IFC är det viktigt att säkerställa att den kravställda informationen kan levereras från de tilltänkta programvarorna eller att använda programvaror som kan leverera information enligt planerad kravställning.* ## Versioner Den första versionen av IFC (IFC1.0) publicerades officiellt i januari 1997. Den användes enbart som en prototyp fram till att IFC1.5.1 publicerades i september 1998 och implementerades kommersiellt. Denna version omfattar i huvudsak enbart byggdelar inom arkitektur. Fram till 2023 har sedan följande huvudsakliga uppdateringar publicerats. **IFC2.0** från oktober 1999 innehåller stöd för bland annat entiteter för installation, kostnadskalkylering, och produktionsplanering. **IFC2x** kom i oktober 2000, och var den första versionen med en bredare implementation, och den första versionen med ett certifieringsprogram. Den fick senare tillägg i form av **IFC2x ADD1**. **IFC2x2** från maj 2003 innehåller ännu bättre stöd för entiteter för installation, byggkonstruktion och fastighetsförvaltning. Versionen innehåller även stöd för tvådimensionellt innehåll som linjer, text, och symboler, samt stöd för kulör, mönster och ytskikt. Även den fick senare tillägg i form av **IFC2x2 ADD1**. **IFC2x3**, publicerad i december 2005, innehåller till stor del enbart kvalitetsförbättringar från tidigare version. Detta är den version som fram till 2023 har implementerats i flest programvaror. Den lämnades in till ISO för godkännande som en så kallad PAS (*Publicly Availible Specification*), publicerad i form av ISO/PAS 16739:2005. Den korrigerades sedan i juli 2007 i form av **IFC2x3 TC1**. ***IFC2x3 TC1** är den ena av nuvarande två gällande versioner.* **IFC4** från februari 2013 var den första versionen av IFC som godkändes som en fullvärdig ISO-standard (ISO 16739:2013). Denna version har bland annat utvecklats med: - stöd för 4D, 5D, tillverkare och produktbibliotek - BIM till GIS-kompabilitet - länkning till bSDD (*buildingSMART data dictionary*) - visst stöd för infrastruktur och andra delar av den byggda miljön - flerspråkig översättning av schemat. Den här versionen fick två tillägg i form av **IFC4 ADD1** och **IFC4 ADD2**, samt en korrigering i form av **IFC4 ADD2 TC1**. Denna innehåller en del tekniska förbättringar och förbättrad dokumentation gentemot sina föregångare. ***IFC4 ADD2 TC1** är den andra av nuvarande två gällande versioner.* Två mellanversioner i form av IFC4.1 och IFC 4.2 har dragit tillbaka. Under 2023 pågår en publicering av **IFC4.3 ADD2**. Den har också skickats in till ISO för godkännande. Denna version har utvecklats mycket inom infrastruktur, och har bland annat stöd för: - entiteter för spår, vägar, tunnlar, hamnar, vattenvägar och broar - beskrivning av långsträckta byggobjekt - sektioner - spatial nedbrytning i form av anläggningar (*IfcFacility*) och anläggningsdelar (*IfcFacilityPart*). Denna version är alltså av stor betydelse för storskalig implementering av IFC inom infrastrukturområdet. För en officiell översikt över IFC-versioner, se [buildingSMART IFC Specification Database](https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/). För release notes, se [buildingSMART IFC Releases Notes](https://technical.buildingsmart.org/standards/ifc/ifc-schema-specifications/ifc-release-notes/). *Beställaren av en informationsleverans via IFC måste ange vilken version som ska användas.* ## MVD (Model View Definition) En **MVD** specificerar kraven för att använda IFC i en viss kontext eller för ett specifikt ändamål. MVD:er anger vilka entiteter, egenskaper och relationer som är relevanta för en viss tillämpning, till exempel för att skapa ritningar, utföra energiberäkningar, eller för att hantera underhållsinformation. En MVD beskriver alltså enbart en del av innehållet i en specifik version av IFC, se figuren nedan.  Bild : Schematisk bild över skillnaden mellan IFC (vänster) och MVD (höger). \[Källa: Mark Baldwin, The BIM Manager, 2019\] MVD:er nyttjas främst av programvaruleverantörer för att beskriva hur deras programvaror tar emot och skickar information via IFC, det vill säga vilka delar av IFC-standarden som nyttjas. För att minimera antalet MVD:er, och därmed underlätta kommunikation mellan olika programvaror, har buildingSMART godkänt ett antal MVD:er som officiella buildingSMART-standarder. De två mest använda är *Coordination View* för IFC2x3 TC1 och *Reference View* för IFC4 ADD2 TC1. Ett exempel på en specifik MVD är *IFC4Precast*, som används för att skicka geometrisk information från CAD-programvaror till MES-system för maskintillverkning av prefabricerade betongkomponenter. För en översikt över MVD:er och dess status, se [buildingSMART MVD Database](https://technical.buildingsmart.org/standards/ifc/mvd/mvd-database/). *Beställaren av en informationsleverans via IFC måste alltid ange både gällande IFC-version och tillhörande MVD.* ## Implementering och certifiering av programvaror Programvaruleverantörer har möjlighet att certifiera sina programvaror enligt buildingSMARTs certifieringsprogram och därmed säkerställa kvaliteten på den information som utbyts via IFC. Programvaror certifieras för en viss version av IFC och tillhörande MVD. År 2023 är det möjligt att certifiera följande versioner av IFC och MVD: - **CV2.0** (*IFC2x3 Coordination View V2.0*) - **RV1.2** (*IFC4 Reference View*) Certifieringsprocessen tar ofta lång tid och programvaruleverantörer implementerar därför ofta sina funktioner innan de blivit godkända och certifierade. För att se aktuell implementation av IFC och MVD i programvaror, se [buildingSMART Software Implementations](https://technical.buildingsmart.org/resources/software-implementations/). *Vid planering av informationsutbyte via IFC är det viktigt att känna till vilka programvaror som har implementerat vilka versioner av IFC och MVD samt om de är certifierade eller ej. Vid krav på certifierade programvaror minskar möjligheten till val av programvara avsevärt.* ## Överföringsformat Informationsleveranser via IFC kan levereras med olika format. De vanligaste är än så länge filformatet **ifc** eller **ifcxml**, men det förkommer även att leveranser görs i exempelvis **json**. Syftet kan vara att filen behöver kunna läsas av olika typer av programvaror. CAD-program, som är grafikbaserat, använder oftast ifc medan webb-applikationer, som många gånger är textbaserade, kanske använder json. En relativt ny möjlighet är att använda **ifcowl**, som är det språk som används för att publicera länkade data med så kallad semantisk webbteknik. För en översikt över möjliga format, se [buildingSMART IFC Formats](https://technical.buildingsmart.org/standards/ifc/ifc-formats/). *Beställaren av en informationsleverans via IFC måste alltid ange vilket överföringsformat som ska användas.* # MVD (Model View Definition) En MVD definierar en delmängd av IFC-data som är relevant för ett visst arbetsflöde inom bygg- och fastighetsförvaltningsindustrin. Varje arbetsflöde identifierar datautbyteskrav för programvaror.  *Figur 1: Schematisk bild över skillnaden mellan IFC (vänster) och MVD (höger).*\ *\[Källa: Mark Baldwin, The BIM Manager, 2019\]* MVD är viktigt för byggbranschen eftersom det möjliggör interoperabilitet mellan olika programvaror och domäner. IFC är ett brett format där man tex kan lagra information om en vägg på olika sätt. Olika arbetsflöden och informationsutbyten kräver sina data. För att stödja vissa arbetsflöden behöver man komma överens om vad som skall med och hur det skall kodas. Detta gör man med en MVD. Det finns en rad bestämnda MVD:er som stödjer vissa informationsutbyten. I programvaror som stödjer informationsutbyten med flera olika parter har ofta flera valbara MVD:er. En viss mvd är grundinställning i en viss programvara. Det finns också program där val av MVD inte görs då endast ett informationsutbyte är underförstått. Det är också mot dessa specifika MVD:er som programföretag certifieras för IFC, dvs en programvara blir certifierad för en viss MVD och IFC version. Det finns tre (bas) MVD:er som är nivåerna för implementering av IFC: - Coordination view (IFC 2x3) & Reference View (IFC 4.\*) - Alignment based Reference View (IFC 4.3) - Design transfer View (IFC 2x3, IFC 4.\*) Utbyteskrav kan definieras ovanpå (bas) MVD. Det finns många olika sätt att definiera datorläsbara utbyteskrav. BuildingSMART IDS-standarden fungerar hand i hand med IFC för att kunna definiera datorläsbara utbyteskrav per användningsfall. En MVD är en specifikation för en delmängd av det övergripande IFC-schemat, som används för ett specifikt datautbyte. Enklast är att den använder samma formulär och format som IFC-källschemat för att beskriva data. Men den kan också innehålla ytterligare specifika datakrav, till exempel anpassade egenskaper (egna property sets) eller specifika värden för vissa datafält. # IDS (*Information Delivery Specification*) ## Vad är IDS? IDS är en datafil som används för att kravställa och kontrollera IFC-filer innan och efter de levereras. En IDS är direkt kopplad till IFC genom att använda IFC-schemats klasser för att kravställa vad en viss IFC-fil ska innehålla. \[Placeholder IDS i för hållande till EIR i 19650\] Tekniskt sett är IDS en strukturerad textfil i form av ett xml-protokoll. Formatet är läsbart både för människa och maskin. I en applikation kan den läsas som ett vanligt textdokument, medan en dator ser filen som ett facit som antingen godkänner eller underkänner en levererad IFC. ## Vad används IDS till? IDS använder IFC-schemat för att precisera hur en objektorienterad modell ska vara strukturerad när den levereras som en IFC-fil. Den styr vilka klasser av objekt som ska ingå, vilka egenskaper som ska användas för att beskriva dem, och hur det ska finnas värden för dessa egenskaper vid det aktuella leveranstillfället. ## Hur används IDS? - En IDS innehåller en syntes av kravställning, leveranstillfälle och IFC-schema. Det finns flertalet applikationer på marknaden som klarar att skapa och redigera IDS-filer. Specifikationen består av tre delar:Beskrivning (*Description*). Här formuleras krav i klartext, till exempel "Bärande väggar ska vara brandklassade". - Tillämpning (*Applicability*), som anger vilka objekt som kravet gäller, baserat på typ eller någon annan egenskap, till exempel klassifikation. - Krav (*Requirements*), som visar vilka specifika krav som ska var uppfyllda, till exempel på vilken nivå av detaljering som modellen ska vara. *Applicability* och *Requirements* kan brytas ner och specificeras genom sex aspekter: - Entitet (*Entity*), alltså vilka objekt som ska ingå. - Attribut (*Attribute*), som handlar om de grundläggande beskrivningarna av objektet. - Klassifikation (*Classification*), som visar objektet klass utöver den som finns i IFC. - Egenskap (*Property*), som i detalj beskriver objektet. Här kan man till exempel ange att enbart bärande väggar ska ingå. - Material (*Material*), alltså vad objekten är gjorda av. - Del av (*Part of* ), som visar om IFC-filen ingår i en samling av leveranser. För varje aspekt anges om den är obligatorisk (*Required*), valfri (*Optional*) eller förbjuden (*Prohibited*), dvs hur den ska hanteras för en specifik leverans. När en IFC-fil levereras kan man låta IDS-applikationen kontrollera att den följer IDS:en. # IDS, IFC och MVD: hur förhåller de sig till varandra? ## Information ska kunna delas och förstås av alla parter För att få en så bra och riktig leverans som möjligt som kan hanteras av alla berörda parter, behövs en tydlig kravställning, en bra anpassning i använda programvaror och filformat som kan läsas av alla. I dag finns förutsättningarna för detta genom att använda öppna, neutrala BIM-standarder. ## Användning av öppna, neutrala standarder Den information som ska levereras vid ett visst tillfälle kravställs i en IDS. Vid export till IFC från ett CAD-program görs urvalet av informationen med hjälp av en MVD och mottagande parter erhåller strukturerad användbar information i IFC för definierat syfte. Visst låter det bra, men vad står de olika förkortningarna för och hur förhåller de sig till varandra? **IFC** (*Industry Foundation Classes*) är en öppen och neutral standard för informationsmodellering. Det är en begreppsmodell och ett digitalt filformat för strukturerad beskrivning av CAD-modeller. Formatet är neutralt, icke-proprietärt och används därför vid export från olika CAD-program. Vid export skapas en IFC-fil som innehåller objektinformation lagrad enligt IFC-schemat. En IFC-fil är alltså en digital modell av en byggnad eller anläggning där informationen är strukturerad enligt vissa regler. Syftet med IFC-filen är att tillgängliggöra informationen i modellen för alla intressenter, inte bara de som använder sig av en viss programvara. IFC-filen kan öppnas i program som kan läsa IFC-formatet, eller importeras till andra program. Detta är en förutsättning för utbyte av modellinformation. **MVD** (*Model View Definition*) är ett utsnitt eller en delmängd av IFC-schemat. En MVD innehåller en beskrivning av den geometri och objektdata som definierats för ett specifikt ändamål. Vid export till IFC används alltid en MVD som är fördefinierad i programvaran. Det kan finnas flera MVD:er som kan väljas av användaren. Vissa programvaror har dock endast en MVD, och då framgår det inte alltid för användaren att en MVD väljs vid exporten. Ett exempel på MVD är CV 2.0 (*Coordination View 2.0*), som ofta används vid samordning av 3D-modeller. Denna är fastställd av buildingSMART, medan andra MVD:er kan vara projektspecifika (mer om det nedan). **IDS** (*Information Delivery Specification*) kan beskrivas som utbyteskrav. Den definierar vilken alfanumerisk information som ska finnas i IFC-modellen vid en specifik leverans. Uppbyggnaden av IDS följer en bestämd struktur som är tolkningsbar för både människor och datorer, och därmed hanterbar digitalt.  Figur 1: Schematiskt bild på hur en delmängd av IFC-schemat definieras med hjälp av en MVD. ## Vem skapar vad? IFC-filer skapas av projektörer eller andra parter, vid leverans av information genom en exportfunktion i programvaran som används. En arkitekt-fil och en VVS-fil innehåller olika typer av information, men informationen är i båda fallen strukturerad enligt IFC-schemat. MVD:er definieras oftast av buildingSMART, men själva MVD:n implementeras av programvarutillverkare och finns med i deras programvara. MVD:er kan även definieras av branschstyrande organisationer för ett specifikt syfte. IDS:er skapas av kravställare och delges den som ska leverera information. I IDS:en framgår vilka egenskaper som ska finnas på olika objekt vid leverans. IDS nyttjas av både den som ska leverera och den som ska granska informationsleveransen.  *Figur 7: Sammanfattning av informationsleveranser baserade på buildingSMART-standarder* ## Sammanfattning - Den information som ska levereras vid ett visst tillfälle finns kravställd i en IDS. - Vid export till IFC från ett CAD-program används IDS för urvalet av information. - MVD definierar vad som kommer med vid exporten. # BCF ## Vad är BCF? BCF är ett neutralt och öppet filformat (bcfxml) som gör det möjligt att kommunicera objekt- och modellbaserade ärenden mellan olika program och aktörer. ## Vad används BCF till? BCF används vid till exempel samordning och ärendehantering där informationen visas i modellfiler. Formatet gör det möjligt att visuellt visa både vad ärendet gäller och var i modellen det är. ## Var finns funktioner för BCF? BCF används genom programvaror som har implementerat formatet. Certifierade programvaror förtecknas på [denna buildingSMART-sida](https://technical.buildingsmart.org/resources/software-implementations/?filter_5%5B%5D=bcfXML%202.2&filter_1=&gv_search=&mode=any). Överst på sidan finns möjlighet att filtrera informationen i listan. En programvara som har BCF-loggan är certifierad för formatet.  Läs mer om BCF formatet: - i [Standardkartan](https://www.bimalliance.se//for-dig-inom-bygg-och-forvaltning/standarder-for-digital-informationshantering/bcf-bim-collaboration-format/) på BIM Alliance - på [Nationella Riktlinjer](https://www.nationella-riktlinjer.se/innehall/metoder/granskning-av-3d-cad-modeller-med-bcf/) - hos [buildingSMART](https://technical.buildingsmart.org/standards/bcf/). # buildingSMART International (*bSI*) ## Vad är buildingSMART? buildingSMART International är en neutral, internationell organisation med syfte att initiera, skapa och anta öppna digitala standarder och neutrala format för BIM-processer. Mest känt är överföringsformatet IFC. I arbetet ingår delar så som grundläggande funktioner, begrepp och metoder som alla har till syfte att kunna användas inom projektering, byggande och förvaltning av byggd miljö. Organisationen tar även fram och visar på goda exempel från verkligheten, lyfter upp aktuella frågeställningar och organiserar informationstillfällen för medlemmarna. ## Vilka standarder har buildingSMART tagit fram? buildingSMART har för närvarande tagit fram följande öppna BIM-standarder: - **IFC** (*Industry Foundation Classes*), som är en begreppsmodell och ett digitalt filformat\ för strukturerad beskrivning av CAD-modeller. - **MVD** (*Model View Definition*), som är ett utsnitt eller en delmängd av IFC-schemat för ett\ specifikt syfte. - **IDS** (*Information Delivery Specification*), som är en strukturerad textfil som beskriver\ vad en specifik IFC-fil ska innehålla. - **BCF** (*BIM Collaboration Format*), som är ett filformat (bcfxml) för att kommunicera\ objekt- och modellbaserade ärenden mellan olika program och aktörer. - **bsDD** (*buildingSMART Data Dictionary*), som är ett online-bibliotek för klasser,\ egenskaper, relationer och enheter. ## Hur sker utvecklingen av IFC-formatet? Utvecklingen sker i arbetsgrupper med aktiva medlemmar från hela världen. Samverkansträffar inom organisationen och de årliga fysiska träffarna (*BIM Summits*) bidrar till att sprida information och få in synpunkter på pågående arbeten. bSI främjar internationell konsensus bland intressenter om specifika standarder för att påskynda implementering och användning. ## Vad innebär certifiering av programvaror? Vid publicering av en ny version eller delversion av IFC kan programvaruleverantörer ansöka hos buildingSMART om att bli certifierade för den versionen. Godkända programleverantörer förtecknas i [Software Implementations](https://technical.buildingsmart.org/resources/software-implementations), där det framgår för vilka versioner programvaran är certifierad. Här framgår även certifiering för BCF och bsDD. ## Vilka är medlemmarna i buildingSMART? buildingSMART baserar hela sin verksamhet på engagemang från branschen. Medlemmarna deltar genom olika typer av engagemang i form av arbetsgrupper och samarbeten, eller som ekonomiskt stöttande parter. Engagemanget kan vara i olika former: som [medlemmar](https://www.buildingsmart.org/community/members/), [chapters](https://www.buildingsmart.org/community/chapters/), [partners](https://www.buildingsmart.org/community/partners/) och [sponsorer](https://www.buildingsmart.org/community/sponsors/). **Medlemmar** Medlemskapet är öppet för företag, statliga organ och institutioner från hela världen. Som medlem stöttar man buildingSMART ekonomiskt på olika sätt, och kan delta i olika typer av samarbeten och utvecklingsprojekt. **Chapters** Ett *chapter* är en lokal gruppering av ett eller flera länder, som delar samma vision och mål som buildingSMART och verkar för detta inom sitt geografiska område. Den svenska gruppen utgörs av buildingSMART Sweden, och har formerats inom BIM Alliance där det har sin bas. **Partners** Partners är andra organisationer som också arbetar för ett standardiserade arbetssätt och neutrala format, till exempel CEN, ISO och GS1. **Sponsorer** Sponsorer är medlemsföretag som går in stöttar olika delar inom buildingSMART ekonomiskt eller genom obetalt arbete. Här finns många olika typer av företag, till exempel programvaruleverantörer, beställarorganisationer och konsulter.