infopack logo

tillampningsanvisningar-bim

1.0.0-rc.2

Underlag till de fyra delprojekten i Tillämpningsanvisningar BIM

Referensbeteckning med coclass - beskriver hur man jobbar med referensbeteckningar med CoClass

Jämför fil Öppna i webbläsare Ladda ner Se meta fil
# Referensbeteckningar med CoClass Följande metodikDetta dokument beskriver referensbeteckningar med CoClass, som används för att entydigt identifiera objekt i byggnader och anläggningar under hela deras livscykel. Metoden är alltså användbar både under projekt och tillgångsförvaltning. I grunden är det en svensk tillämpning av den internationella standardserien IEC/ISO 81346. Referensbeteckningar används främst för byggdelar, men kan också användas för utrymmen och för byggnadsverk. För en byggnad kan till exempel identifikation av en undercentral vara aktuell, en reglerventil i ett tappvattensystem som är lokaliserat i detta utrymme, dörren som leder in till utrymmet, och utrymmet som sådant. Referensbeteckningar är framför allt till för att kunna hanteras digitalt, men kan även läsas av människor. En invändning som ibland förs fram är att referensbeteckningar och dess strängar är oläsbara för människor. Det stämmer till viss del; bBeroende på tillämpningen kan strängarna av bokstäver och siffror bli långa och svåra att tolka för den som inte är van. Strängarna kan dock enkelt göras maskinavläsbara, till exempel i form av en QR-kod som skannas med telefonen. För att främja underlätta läsbarheten kan delar av en komplett referensbeteckning uteslutas i ett specifikt sammanhang, till exempel på en märkbricka som sätts på eller vid ett objekt. När en användare exempelvis står i en undercentral i en byggnad behöver inte all information om byggnaden följa med; det räcker med våning och rum för att visa var objekt är lokaliserade. ## Principer för referensbeteckning Referensbeteckningar består av en kombination av koder från en eller flera tabeller för att visa en eller flera aspekter av ett objekt. En aspekt är ett specificerat sätt att betrakta ett objekt på. CoClass använder fyra aspekter med tillhörande prefix för att beskriva förekomster av ett objekt (placering och lokalisering räknas som ett): **= Funktion**, som beskriver vad objektet har för roll i ett system. **–  Produkt**, som beskriver hur objektet rent konstruktivt sitter i förhållande till andra objekt i systemet. **++ Lokalisering** som anger var i objektet finns, till exempel i ett visst rum, och **+ Placering** som visar hur det är monterat, till exempel på ett annat objekt, eller i ett visst fack i ett rack. **% Typ**, som mer eller mindre i detalj visar objektets tekniska lösning. Varje aspekt beskrivs med hjälp av en strukturerad kod, baserad på klasser i CoClass tabeller. För en detaljerad redovisning hänvisas till [CoClass – Informationshantering för byggd miljö](https://byggtjanst.se/bokhandel/lagar--regler/coclass---informationshantering-for-byggd-miljo) (Eckerberg 2019) och SS-EN 81346-1:2010. Det är står användare fritt att definiera välja antal nivåer i den struktur som ska beskriva byggnadsverket. Ett funktionellt system kan innehålla ett eller flera konstruktiva system, som kan innehållaer komponenter, som i sin tur kan innehålla komponenter. Beroende på behov bör nedbrytningen stanna på den nivå som är relevant för syftet. Om till exempel ett luftbehandlingsaggregat är föremål för underhåll, kan referensbeteckningen stanna på nivån konstruktivt system. Aggregatets alla komponenter i form av fläktar, filter och annat behöver knappast beskrivas. Referensbeteckningar som visar flera aspekter kan skrivas på en eller flera rader. Om man skriver på en rad bör aspekterna avskiljas med snedstreck (/) för att öka läsbarheten. En grundläggande regel är att åtminstone en av aspekterna ska entydigt identifiera objektet. För att identifiera förekomster av objekt används ett löpnummer, med det antal positioner som krävs för att kunna numrera alla relevanta objekt. Två siffror räcker oftast. Om flera aspekter används är ordningen de skrivs i utan betydelse, men att inleda med den aspekt som identifierar objektet är oftast lämpligt. ## Funktionsaspekten (=) Funktionsaspekten beskriver vad ett objekt är avsett att göra eller vad det i verkligheten gör. Strukturen byggs uppifrån och neråt genom att dela upp en huvudfunktion i delfunktioner, som i sin tur delas upp så långt som krävs. Funktionsaspekten är användbar framför allt i tidiga skeden i projekt när krav på utrymmen och byggdelar ska struktureras. Funktionsaspekten är dock användbar också i övriga skeden av livscykeln. Vid drift och underhåll kan exempelvis ett fel på en funktion lokaliseras i ett system. Funktionsaspekten kan användas på olika typer av dokumentation, men används främst i scheman, diagram och rumsfunktionsbeskrivningar. ## Produktaspekten (-) Produktaspekten visar med vilka medel objektet gör vad det är avsett att göra. Den visar alltså hur ett system är konstruerat, eller sammansatt. I många fall blir produkt- och funktionsaspekt identiska, men inte alltid: ett fysiskt objekt kan ha flera funktioner, och en funktion kan bestå av flera fysiska objekt. Produktstrukturen byggs nerifrån och uppåt genom att utgå från komponenter och kartlägga dem i ett större system. Produktaspekten är särskild användbar vid produktion och underhåll. Den används typiskt för bland annat underhållsinstruktioner. ## Lokaliserings- och placeringsaspekten (++ / +) Lokaliseringsaspekten anger avsedd eller verklig lokalisering av ett objekt, exempelvis i ett visst rum i en viss t byggnad. Med placeringsaspekten avses hur något sitter relativt ett annat objekt: på vägg, i ett visst fack eller liknande. ## Typaspekten (%) En typ kan sägas vara en sub-klass, där objekten har ytterligare någon eller några egenskaper gemensamt. Det kan handla om mer detaljerad funktion, en viss teknisk lösning, eller ett visst material. Typaspekten visar vilken sådan typ ett objekt tillhör. I CoClass finns många fastställda typer av funktionella och konstruktiva system, komponenter, byggnadsverk och utrymmen. Det står användare fritt att definiera egna typer, men dessa ska dokumenteras och koder som finns i CoClass bör undvikas. Så långt som möjligt används typnummer 90–99 för egna typer. ## Exempel på tillämpning av CoClass för referensbeteckningar ![Lilla Tensta](../media/lilla-tensta.png) *Bild 1: Visualisering av objekt i förskolan Lilla Tensta.* Bilden ovan visar SISAB:s förskola Lilla Tensta i form av några 3D-CAD-modeller. 3D-CAD-modellerna består av många objekt som beskriver dess delar. Med hjälp av underlag från Lilla Tensta visas ett antal typiska utrymmen, system och komponenter, och tillämpning av CoClass för referensbeteckningar. Exemplen är förenklade och skalbarheten samt generaliteten kan diskuteras, men de visar på ett antal principer för hur CoClass kan användas för referensbeteckningar. (Här saknas en figurbild från originalsidan på Nationella Riktlinjer!) Figur Bild – Relationsmodeller från Lilla Tensta, SISAB. Bilden visar e ett apparatrum (gul), dörr (rödtt) och en vätskeventil (blå)\_ ## Lokaliseringsaspekt (++) Det rekommenderas att lokaliseringsaspekten beskrivs med 1–3 nivåer. Fler nivåer får förekomma. Exempel: |++BFA190.AHA01.DAD139
%BFA109|Skola nr 19 > Förskolebyggnad nr 1 > Apparatrum nr 139
Typ: Förskola| | :- | :- | De tre nivåerna är här byggnadsverkskomplex > byggnadsverk > utrymme. Förskola är typ 10 av klass BFA Skola, enligt typ fastställd i CoClass. För klasserna AHA och DAD används inte typer. Alternativt kan lokaliseringen beskrivas enligt följande förslagmed hjälp av egna förkortningar eller akronymer, men då används inte CoClass-koder inte som del av själva beteckningen. Det ger en kortare beteckningssträng, men gör det svårare för någon icke-insatt att förstå vad som menas. med till exempel LT, och gör detDet blir också svårt omöjligt att jämföra olika byggnadsverk eller byggnadsverkskomplex med varandra i en kommun eller mellan kommuner. Exempel: |++LT.1.139|Lilla Tensta > Byggnad nr 1 > Rum nr 139| | :- | :- | ## Funktionsaspekt (=) och typaspekt (%) Några exempel: |=F02.JB01.WPA09
%F21.JB10.WPA91|Vatten- och vätskesystem nr 2 > Vattendistributionssystem > Rör nr 9
Typ: Tappkallvattensystem > Vattenledningssystem > Rör typ 91 (egen typ)| | :- | :- | |=F02.KF01.GP?01
%F10.GP?03|Vatten- och vätskesystem nr 2 > Pumpsystem nr 1 > Vätskeflödesgenererande objekt (pump) nr 1
Typ: Råvattensystem > Pump typ 3| |=B01.RD01.QQC03
%B20.RD32.QQC92|Väggsystem nr 1 > Skydds-, tillträdes- och avstängningsanordningar nr 1 > Dörr nr 03
Typ: Innerväggssystem > Tillträdesanordningar till utrymme > Dörr typ 92 (egen typ)| Kod med en bokstav betecknar ett funktionellt system, två bokstäver betecknar konstruktivt system och tre tecken betecknar en komponent. I det andra exemplet används nummertecken (?) som utfyllnad, eftersom koden på trebokstavsnivån visar en teknisk lösning på en pump. Typer 90–91 är reserverade för egna typer, övriga är föreslagna i CoClass och har namn som skiljer sig från klassen. Som exempel har klass **F Vatten- och vätskesystem** typen **F21 Tappkallvattensystem**. ## Produktaspekt (-–) Produktaspekten, det vill säga hur något är uppbyggt, visar vanligen de tre nivåerna funktionellt system, konstruktivt system och komponent. Vid behov kan man också beteckna komponenter som är en del av en annan komponenter så långt som behövs. Exempel: |-F02.KF01.GP?01.MAA01|Vatten- och vätskesystem nr 2 > Pumpsystem nr 1 > Vätskeflödesgenererande objekt (pump) nr 1 > Elmotor nr 1| | :- | :- | |-B01.RD01.QQ03.SGD01|Väggsystem nr 1 > Skydds-, tillträdes- och avstängningsanordningar nr 1 > Dörr nr 3 > Trycke nr 1| Det första exemplet på produktaspekt är samma pump som det andra exemplet i funktionsaspekt. Det andra exemplet i produktaspekt är samma dörr som i det tredje exemplet i funktionsaspekt. Båda visas här utan angivande av typ. ## Rekommendation I båda dessa exempel är alltsåmånga fall blir funktionsaspekten och produktaspekten identiska ner till tredje nivån, och skulle vara det ner även till den tredjeen viss nivå. Eftersom byggdelar definieras utifrån funktion kan det då vara svårt att se varför båda aspekterna behövs. Svaret blir att det vanligen räcker med den ena. För komplexa installationer – speciellt inom fastighetsautomation – kan dock byggdelar som exempelvis styrenheter ha flera funktioner som behöver beskrivas. Rekommendationen är att för varje system använda antingen produktaspekten eller funktionsaspekten för att skapa den formella identifierande beteckningen för ett objektkationen som visar systemets beståndsdelar. Vid behov kompletterar man med den andra aspekten. Till detta kommer sedan vid behov typaspekten och lokaliseringsaspekten.