nrb-metoder

# Granskning av 3D-CAD-modeller med BCF ## BIM Collaboration Format (BCF) BIM Collaboration Format (BCF) är ett öppet dataformat (bcfXML) som stödjer arbetsflöden för objektorienterad kommunikation, det vill säga BCF möjliggör ärendehantering kopplat till objektmodeller i IFC-formatet. Mer specifikt överför BCF-formatet XML-formaterad data i form av information om ett ärende som refererar till en koordinatsatt kameraposition och vinkel samt en referens till en skärmbild i PNG-format. Formatet kan både hanteras filbaserat eller via web service. Praktiskt innebär detta att ett ärende kan skapas av en aktör i modellmiljö och skickas över till en annan aktör som via ärendet kan navigera i en modellmiljö till den position där ärendet skapades, samt i bifogad skärmbild ta del av markeringar som med beskrivande grafik kompletterar texten i ärendet. Mottagaren kan i sin tur kommentera ärendet och skicka tillbaka till leverantören eller till en tredje part. Detta förfarande pågår till dess att ärendet är löst. Kommunikationen av ärenden kan både ske i eller utanför modellmiljö. Information om ärenden delas upp i attribut och metadata där vissa är obligatoriska och andra är valbara. Tabell 7 och Tabell 8 nedan redovisar en delmängd av dessa attribut och metadata. BCF-formatet innehåller mycket mer teknisk information än vad som redovisas nedan men den här studien fokuserar på de processrelaterade attributen. Tabell: Attribut som definierar ett ärende inom BCF.

Attribut	Beskrivning
TopicType	Ärendetyp enligt gällande värdelista.
TopicStatus	Ärendestatus enligt gällande värdelista.

* Obligatoriskt attribut enligt standarden. Tabell: Metadata kopplade till ett ärende inom BCF.

Metadata	Beskrivning
ReferenceLink	Referens till information som kan länkas till ärendet.
Title*	Rubrik.
Priority	Prioritet enligt gällande värdelista.
Index	Löpnummer för att sortera ärenden.
Labels	Etiketter för att gruppera ärenden enligt gällande värdelista.
CreationDate*	Datum när ärendet skapades.
CreationAuthor*	Identifikation på den användare som skapat ärendet.
ModifiedDate	Datum för när ärendet senast ändrades. (Existerar enbart om ärendet ändrats efter det har skapats.)
ModifiedAuthor	Identifikation på den användare som senast ändrat ärendet. (Existerar enbart om ärendet ändrats efter det har skapats.)
DueDate	Förfallodatum när ärendet måste vara löst.
AssignedTo	Identifikation på den användare som tilldelats ärendet enligt gällande värdelista.
Description	Beskrivning av ärendets innehåll.
Stage	Skede som ärendet tillhör enligt gällande värdelista.

* Obligatoriskt attribut enligt standarden. Förutom de attribut och metadata som nämnts ovan möjliggör BCF-formatet kommunikation kring ärenden via kommentarer. En kommentar är ett eget objekt, med egna metadata, kopplat till ett specifikt ärende. Gällande metadata redovisas i tabell 9 nedan. Tabell: Metadata kopplade till en kommentar inom BCF.

Metadata	Beskrivning
Date*	Datum när kommentaren skapades.
Author*	Identifikation på den användare som skapat kommentaren.
Comment*	Kommentar.
Viewpoint	Referens till tillhörande vypunkts GUID.
ModifiedDate	Datum för när kommentaren senast ändrades.
ModifiedAuthor	Identifikation på den användare som senast ändrat kommentaren.

* Obligatoriskt attribut enligt standarden. ## Ärendehantering och dess livscykelsteg Ärendehanteringen vid tillämpning av objektmodeller skiljer sig en del jämfört med ärendehantering vid tillämpning av ritningar. Följande begrepp, i form av attribut, som tillämpas inom BEAst granskningsstandard är inte nödvändiga för granskning av objektmodeller: * Sidetikett – Det finns inget behov av ritningsnummer vid objektorienterad granskning. * Sidindex – Sidnummer hanteras inte vid objektorienterad granskning. * Bockmarkering – Programspecifikt attribut för Bluebeam. Vid objektorienterad granskning tillkommer ett behov av ytterligare begrepp vilka presenteras i tabeller nedan. Tabell: Behov av begrepp för objektorienterad ärendehantering.

Begrepp	Beskrivning
Rubrik	Kort rubricering av ärendet.
Beskrivning	Utförlig beskrivning av ärendet.
Ärendestatus	Aktuell status för ärendet enligt värdelista
Skapad	Tidpunkt när ärendet skapades.
Granskare	Identifikation på den person som skapat ärendet.
Tilldelad	Identifikation på ansvarig som ärendet är tilldelat till.
Ansvarig Part	Beteckning på den disciplin som tilldelats ett ärende.
Förfallodatum	Tidpunkt när ärendet ska vara löst.

Tabell: Behov av begrepp för kommentarer relaterade till ärenden.

Begrepp	Beskrivning
Kommentar	Ärendets beskrivande kommentar.
Datum	Tidpunkt när kommentaren skapades.
Författare	Identifikation på den användare som skapat kommentaren.

Värdelistan för Status enligt BEAst granskningsprocess som beskrivits ovan kan även tillämpas för objektorienterad ärendehantering. Förklaringstexten har anpassats till vald processdefinition i kapitel 0\. Anpassningarna redovisas i kolumn Notering. Tabell: Värdelista för Ärendestatus.

Ärendestatus	Förklaring	Notering
Ny kommentar	Ny kommentar har skapats av granskningsdeltagare.	Granskningsdeltagare istället för granskare.
Avvisad	Avvisad av ansvarig projektör, ska ej åtgärdas.	Projektör istället för projekteringsledare.
Ska åtgärdas	Ska åtgärdas av ansvarig projektör.	Projektör istället för konsult.
Har åtgärdats	Har åtgärdats av ansvarig projektör.	Projektör istället för konsult.
Ny granskning	Krav på ny granskningsgenomgång.
Godkänd	Godkänd av ansvarig granskningsledare	Granskningsledare istället för projekteringsledare.

Figur 2 nedan beskriver ovan ärendestatus som livscykelsteg med en inbördes relation till varandra. Ett nytt ärende har alltid status ”Ny kommentar” för att sedan antingen bli direkt ”Avvisad”, och därmed stängd, eller bedömd som ”Ska Åtgärdas”. Ansvarig projektör kan begära en ”Ny Granskning”, och därmed stänga ärendet, eller åtgärda ärendet och ange status ”Har Åtgärdats”. Ärendet stängs när ansvarig granskningsledare bedömt det som ”Godkänd”.  (Figur: Processkarta över ärendestatus som livscykelsteg med inbördes relation till varandra) ## Handlingstyper och dess livscykelsteg Begrepp för handlingstyper och dess livscykelsteg överensstämmer med den kommande standarden ftSS 32209 som beskrivits ovan där handlingstyperna även appliceras på objektmodeller, exempelvis en objektmodell med handlingstypen Systemhandling. Figur 3 nedan beskriver tillämpade granskningssteg som livscykelsteg med en inbördes relation till varandra. I beskrivningen nedan benämns granskningssteg som status.  (Figur: Processkarta över tillämpade granskningssteg som livscykelsteg med en inbördes relation till varandra) En objektmodell har alltid status ”Preliminär” före leverans och status ”För Granskning” efter leverans. Om modellen efter granskningsperioden inte kommenterats via något ärende uppnår den direkt status ”För Godkännande”. Finns det däremot en eller flera tilldelade ärenden får den status ”Granskad med kommentarer” och dessa ärendens individuella status bestämmer hela modellens status enligt följande: * Om en eller flera ärenden har status ”Ny Kommentar” förblir statusen för granskad modell ”Granskad med kommentarer”. * Om alla ärenden antingen har status ”Avvisad” eller ”Har Åtgärdats” övergår modellens status till ”För Godkännande”. * Om en eller flera ärenden har status ”Ny Granskning” övergår modellens status till ”Ej godkänd”. När en modell uppnått status ”För Godkännande” avslutar granskningsledaren processen genom att godkänna modellen i sin helhet och övergår därmed till status ”Godkänd”. För att förtydliga att handlingstyp och granskningssteg inte får förväxlas exemplifieras hur handlingstyp och granskningssteg skall utläsas nedan: * Preliminär Systemhandling (Ej Preliminärhandling), * Systemhandling För Granskning (Ej Granskningshandling), * Systemhandling Granskad med kommentarer, * Ej Godkänd Systemhandling, * Systemhandling För Godkännande, och * Godkänd Systemhandling. ## Process Processen redovisas i tre simbanor där respektive simbana representerar följande roller: * Granskningsledare, * Granskningsdeltagare, och * Projektör. Aktiviteterna i processen är uppdelade i tre kulörer och representerar följande faser: * Grön – Initieringsfas * Blå – Granskningsperiod * Röd – Godkännandefas Nedan följer en beskrivning av respektive aktivitet i processen ovan. **1\. Initiera granskning** – Granskningsledaren planerar och bjuder in granskningsdeltagare till ett startmöte. **2\. Leverera objektmodeller** – Projektörer levererar modeller till anvisad plats. Dessa går då från granskningsstatus ”Preliminär” till ”För Granskning”. **3\. Genomför startmöte** – Granskningsledarean leder startmötet med följande agenda: 1. 1. Deltagarlista 2. Genomgång av BIM Alliance Granskningsprocess 3. Granskningstidplan 4. Granskningsmatris – redovisar granskningsansvar per deltagare 5. Metodbeskrivning för aktuellt systemstöd 6. Granskningspresentation – respektive disciplin presenterar sin ingående modellInför mötet har BIM-samordnaren förberett en sammansatt modell i aktuellt systemstöd, förberett ärenden enligt standarden, och bjudit in granskningsdeltagarna. Alla ingående modeller har granskningsstatusen ”R- För Granskning”. **4\. Genomför granskning** – Under granskningsperioden utför respektive granskningsdeltagare sin del av granskningen genom att skapa granskningsärenden enligt gällande metodbeskrivning. Följande information är obligatorisk för alla ärenden: 1. 1. Ärendestatus – Tilldelas alltid statusen ”Ny Kommentar”. 2. Rubrik – Kortfattad beskrivning av ärendet. 3. Beskrivning – Utökad beskrivning av ärendet. 4. Granskare – Beteckning för ansvarig part följt av för- och efternamn på den granskare som skapat ärendet. 5. Tilldelad – Beteckning för ansvarig part följt av för- och efternamn på den person som representerar aktuell projekterande disciplin. 6. Skapad – Datum och ev. tidpunkt när ärendet skapades. 7. Förfallodatum – Datum enl. gällande tidplan när ärendet senast skall vara åtgärdat. 8. Skärmklikpp – Bifogad bild från modellen som visualiserar den del som ärendet avser. Skärmklippet kan ofta kompletteras med anteckningar av skärmtext, pilar, moln, m.m. 9. Vypunkt – Bifogad kordinatreferens till den del av modellen som ärendet avser. Eftersom alla granskningsdeltagare kan se alla ärenden minimeras risken för att flera granskningskommentarer skapas angående samma ärende. **5\. Hantera granskningsärenden** – Inför granskningsmötet går varje projekterande disciplin igenom sina tilldelade ärenden, avgör om ärendet skall åtgärdas eller avvisas genom att ändra ärendets status, samt kommenterar hur ärendet skall hanteras. Efter utfört arbete skall samtliga ärenden ha status ”Avvisad” eller ”Ska Åtgärdas” **6\. Genomför granskningsmöte** – Granskningsledaren leder ett granskningsmöte med syfte att besluta åtgärd för respektive ärende. Eventuell avvikelse från av projekterande disciplin förslagen åtgärd dokumenteras i respektive ärende både genom ny kommentar och uppdaterad status. Efter utfört arbete skall samtliga ärenden ha status ”Avvisad” eller ”Ska Åtgärdas”. **7\. Genomför åtgärder** – Respektive disciplin åtgärdar ärenden med ärendestatus ”Ska Åtgärdas” och levererar därefter en ny modell med status ”G- För godkännande”. Projekterad åtgärds tillhörande ärende skall uppdateras med status ”Har Åtgärdats”. De åtgärder som är av sådan art att de kräver ytterligare granskning skall inte ingå i den levererade modellen utan skall hanteras i separat granskningsprocess. I sådant fall skall tillhörande ärende uppdateras med status ”Ny Granskning”. **8\. Sammanställ granskningsprotokoll** – Granskningsledaren sammanställer ett gemensamt granskningsprotokoll i aktuellt systemstöd. **9\. Genomför stickprov** – Granskningsledaren utför stickprov och för att säkerställa att beslutade åtgärder dokumenterad i ärendet är inarbetade i modellerna med status ”G- För Godkännande”. Godkänner granskningen och ändrar status på modellen till ”A1- Godkänd”.