Innehåller Gästrike vattens metodbeskrivningar.
# 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”.
