Disclaimer: Det skal understreges at disse dokumenterede overvejelser på nuværende tidspunkt ikke er fyldestgørende, og i virkeligheden repræsenterer et ganske specifikt udtag eller udpluk fra en langt større tankeramme og helhed. Nedenstående, udvalgte info og grafik er altså et forsøg på at illustrere nogle af de overordnede, principielle overvejelser bag arbejdet, mere end at fungere som udtømmende oplistning af alle aspekterne. 

Derfor; dette er en igangværende proces.



Mit arbejde og den opsamlende publikation kredser om et designsystem der søger at forene Revit-indsatsen omkring et fælles, ensrettet, visuelt og systematisk sprog, med fokus på udvikling af Revit Families (digitale bygge-objekter) på tværs af en organisation eller en tegnestue. Systemet kan, integreret på den rigtige måde, måske være med til at reducere den tidsmæssige investering, optimere workflowet og ensrette det endelige resultat, samtidig med at løfte objekterne (og herigennem projekterne) et skridt fremad.

En fremtidssikring af indsatsen.

Projektet vil altså, jf. ovenstående, omhandle mange af de dagligdagsprocesser der arbejdes med i projekter af forskellige størrelse og art, gennem alle projekteringsfaserne og nok delvist influeret af alle involverede personer på en arbejdsplads. For at imødekomme mine egne, opsatte krav om at dokumentationen skal kunne fungere som et slags referenceramme / opslagsværk, har jeg forsøgt at inddele de forskellige overvejelser i kapitler og grupperinger, der gerne skulle kunne noget hver især, og samtidig, så vidt muligt, fungerer i en nogenlunde etableret rækkefølge eller proces, og selvfølgelig som en større helhed. 

I kombination med det digitale bibliotek af opbyggede, typiske objekter / Families, baseret på nærværende retningslinjer, bør der være tilstrækkeligt grundlag for et videre forløb eller indsats, udført ved en organisation eller tegnestue.

Introduktion

Kernen i BIM (Building Information Modelling) er denne “intelligente” dataopsamling og arkivering der, udover information omkring geometri og placering, også indeholder alle relevante data tilknyttet bygningen (Project) og samtlige af dens komponenter eller bygningsdele (Families), hvilket kan reducere misforståelser, fremskynde designprocessen og bygge farbare broer mellem hold, der samarbejder for frembringelsen af hurtige, velovervejede og resultatorienterede løsninger. Publikationen er altså afstedkommet ud fra en betragtning om gerne at ville videreformidle og skabe en platform for det videre arbejde med disse førnævnte Families, gennem forklarende tekster og illustrationer,  søgt udformet som et letfordøjeligt, grafisk opslags- eller referencehæfte, og affødt af mange timers arbejde med emnet.

Og for, på sigt, at få skabt rammerne for et større arkiv indeholdende klargjorte, fleksible hyldevarer med standardiseret indholdsopbygning, navngivningsprincipper og bagvedliggende metode, der sikrer en langt højere brugervenlighed, et større fælles grundlag for opsamling af data og større transparens.

Denne dokumentation er altså gradvist afstedkommet gennem mange overvejelser gjort af undertegnede gennem de sidste par år, og i udgangspunktet med den hensigt at fungere som noter til mig selv, samlet ét sted. Dog er det relativt hurtigt blevet tydeligt, at det samlede arbejde, måske også kan bruges i en videreformidling til andre relevante fagpersoner der, lige som jeg selv, har haft et behov for en større transparens, og forhåbentlig herigennem, en mere systematisk tilgang til emnet.



Grundpremissen for alt dette er, at strømline produktionen af Revit Families / BIM-content for på denne måde at opnå en betragtelig tidsbesparelse og højne kvalitetsniveauet. Ofte, når vi, som arkitekter eller bygningskonstruktører, går ind på produkt-specifikke hjemmesider og downloader Revit content direkte fra deres online kartoteker, finder vi over-modellerede, over-komplicerede, data-tunge Families med importeret 2D CAD-data, manglende, essentiel information, ukorrekt, tilknyttet klassificering og uendelige rækker af “warnings” der popper op, blot vi ændrer lidt i nogle af de alt for mange og usammenhængende parametre. Alt sammen medvirkende til en ophobning af ubrugbare elementer, eksponentielt og unødigt skred i data-størrelser, og herigennem drastisk nedsat brugsværdi samt massiv tidsforøgelse tilknyttet for den enkelte projekterende og de enkelte projekter.

De i denne publikation nedfældede tanker søger altså at opridse en arbejdsmodel for at kunne imødekomme førnævnte problemstillinger, og har derved til hensigt at samle store dele af (primært) arkitekt-fagets nødvendige projektdokumentation, illustreret gennem geometriske repræsentationer af fremtidige projekter og bygningsdele, deres tilknyttede information og den endelige sammensætning af alle disse.
    
Et højere niveau af præcision og konsistens i det videre arbejde samt minimering af gentagelsestunge processer bør også kunne forstås, opnås og integreres med denne metode som udgangspunkt. Kampen ligger altså fremadrettet i, at kunne samle objekterne og deres tilblivningsprocesser under en række strammere - og måske nok i større omfang - centralt administreret retningslinjer og systematiker, der vil kunne sikre en mere gennemgribende konsistens i projekterne. Resultatet vil derfor, forhåbentlig, vise sig ved et højere og mere uddybende kvalitetsniveau hvor disse bygningsdele implementeres, set gennem ikke bare optimeringen af workflows men også gennem en mere konsekvent tilgang til de nødvendige, tilknyttede arbejdsgange og data-inputs samt -outputs.

Mit arbejde har altså, kort fortalt, ført mig gennem mange aspekter og afkroge af denne nok “niche”-viden, men med en potentielt bred konsekvens-radius, og herved har jeg søgt muligheden for at kunne bidrage til arkitektfaget på tværs af processer, projektfaser og indhold.

Processer 1

I dette kapitel vil jeg forsøge at redegøre for de overordnede tanker der ligger bag processerne og de strategiske overvejelser der nødvendigvis må være trædestenene for tilblivelsen af de enkelte Revit Families. Grundet den stigende kompleksitet og forøgede kravstillelse til ikke blot den mængde information der skal og bør afdækkes via den enkelte rådgiver, skal vi altså kunne påtage os at mestre, administrere og udnytte disse nye datadrevne metoder. Af samme grund sættes der også nye forventninger til det enkelte objekts kunnen, i form af, bl.a. fleksibilitet, tilpasnings- og indpasnings-evner, grafiske indstillinger og måske især tilknyttet, struktureret data på forskellige niveauer og på forskellige tidspunkter i projekteringsfaserne.



Der er derfor al mulig grund til at systematisere tilblivningsprocessen omkring dette.

Således, og for at kunne videregive informationer på et velfunderet og systematiseret plan, og for netop at kunne sætte andre ind i de bagvedliggende processer, er tanken altså at ensrette så mange af processerne som muligt. Derfor er mange af disse øvelser og overvejelser specifikt målrettet mod et decideret genbrug af objekterne i projekter af varieret størrelse og målsætning, og med et tungt vægtet tidsaspekt for øje, for således ikke at skulle bruge for meget energi og sparsomme ressourcer på tekniske, bagvedliggende og måske mindre givende dele, ift. projektet.

Dermed forsøges det at understrege vigtigheden af dette overlagte og relativt stramme system.



Processerne 2

Her fokuserer vi på de mere tekniske, kvalitative og bagvedliggende processer der nødvendigvis på et tidspunkt må ligge til grund for tilblivelsen af Revit Families. Grundet en stigende kompleksitet og stadigt øget kravstillelse til ikke bare hastigheden hvorpå vi arbejder, men også det enkelte objekts informationsniveau, dokumentation af valg, processer og beslutninger, fleksibilitet og tilpasningsmuligheder,  er der ingen grund til ikke at forsøge og trække på computerens bedste egenskaber - at udføre kalkuler og processer, defineret af slutbrugeren.



Dynamo er en udvidelse af Revit-projekteringsmiljøet. Programfladen giver adgang til en lang række mere skræddersyet funktionaliteter, gennem et såkaldt VPL (Visual Programming Language), som det standardiserede interface fra Revit ikke udbyder, hvilket kort fortalt vil sige at man kan sammensætte eller opbygge sine egne, specifikke værktøjer, der så kan udføre opgaver, baseret på den projekterendes specifikke ønsker og behov. Både i forbindelse med den enkelte projekt- og Family-fil, men også på tværs af mange filer, og herved opstår en unik mulighed for en ophøjet, systematisk udvikling og vedligeholdelse af et bibliotek indeholdende aktuelle Families, uden integrering af manuelle, slidsomme og som oftest, fejlbårne, processer.

Desuden opstår muligheden for opkobling af data taget fra andre steder eller andre kilder, geometriske manipulations- og formgivningsøvelser, defineret ud fra præcise inputs og systematiker, og standardiserede, automatiserede processer, der, jf. ovenstående, kan korrigere for fejl og mangler, nedsætte størrelser på filerne, ensrette og justere i indtastet data.



Med denne “åbning” ind under motorhjelmen af Revit, følger altså en lang række fordele - men også ulemper. Hurtigt kan små automatiseringsopgaver opsluge mange timers indsats, og det bør derfor altid opvejes, i de enkelte, specifikke situationer, om der overhovedet er behov for denne definition af de mere bagvedliggende processer. Der findes hele communities der arbejder på udviklingen af værktøjer, med overordnede såvel som ganske specifikke målsætninger for øje. Værktøjer der kan sikre konsistens ikke bare på projektnievau, men også på tegnestueskala, altså på tværs af flere projekter.



Tænkte eksempler på brugen af Dynamo-definitioner, kan være, bl.a. --

Parametre (input) -

• at tilføje alle de standardiserede parametre, der fra tegnestuens og de forskellige klassificeringers side bør angives som tilknyttet metadata på de enkelte objekter, baseret på netop objektets type eller kategorisering (manuelt valgt fra liste eller automatiseret læsning af Revits egen kategorisering, i.e.; Walls, Windows, Doors, Furniture, osv.),
• at fjerne uønskede / uanvendelige parametre og generel fjernelse af irrelevant information,
  
• at tjekke for uønsket geometriske forekomster og lineworks, vurderet på et konsekvent og, fra tegnestuens side, etableret grundlag, og på denne baggrund enten slette eller beholde disse,

• at omnavngive allerede etablerede, tilknyttede parametre, til en fra tegnestuens side, standardiseret navngivningsmetode,
• at i videst muligt omfang, udfylde data i de tilknyttede felter baseret på definerede kategoriseringssystematiker (så som eksempelvis en Family kategoriseret som Windows, der giver nogle relativt specifikke data-behov, eller en Family kategoriseret som Doors, der ligeledes giver nogle relativt specifikke data-behov),
• at opkoble førnævnte automatiseringsprocesser ifm. kategoriseringssystematikkerne på klassificeringssystemer, så som eksempelvis IFC-klassifikationer (Industry Foundation Class), BIM7AA-klassifikationer og / eller CSS-klassifikationer,
  
• at tjekke op på allerede udfyldt data i de forskellige Type- eller Instance-parametre, og om navngivningskonventionerne overholdes, og om disse er korrekt / tilstrækkeligt udfyldt,
• at opnå en mere stringent og højere konsekvens ved automatiseringen.

Parametre (output) -

• at udtrække data (evt. via Bumblebee-package til Dynamo), herunder med henblik på videre bearbejdning i andre, tredjeparts-applikationer (så som Microsoft Excel-kalkuler, Microsoft PowerBI, diverse visualiseringsplatforme (både data-visualisering og geometrisk visualisering), andre data-behandlingsprogrammer og ikke mindst priskalkule-applikationer),
• at etablere en generel og relativt ensrettet / systematisk proces, der måske groft kan skitseres som følger; a) udvalg af relevant data, b) rensning af udvalgte data, c) normalisering af udvalgte data, d) data-minering i udvalgte data og e) fortolkning gennem eventuel visualisering,
• at eksportere disse data (der kan være alt fra kvantitativ information, til tegningslister, objektlister, fejl-logs, generel dokumentation ift. ansvarsområder og historik, til arealopgørelser, brugsmønstre og data i relation til bæredygtighedsprincipper),

Geometri (input) -

• at tilknytte eller indskrive objekter eller geometriske forekomster i et objekt til underklassificering og eller omplacering til anden kategori,
• at løbende tjekke op på dobbelt-forekomster af objekter og eller udføre kollisionskontrol,
• at tjekker om navngivningsprincipperne tilknyttet de enkelte Families er overholdt, og hvis ikke, opdaterer disse, jf. tegnestuens / projektets tilknyttede standarder,
• at gennemgå standardiseret visning af tredimensionel geometri versus to-dimensionel linework, i henholdsvis plan, snit, opstalt, isometri og perspektiv, jf. tegnestuespecifikke retningslinjer for etablering af Families, generelt,

Geometri (output) - 

• at eksportere geometri med henblik på visualisering eller efterfølgende analyse, kalkule eller andet gennem andre, tredjeparts-applikationer (herunder statiske og økonomiske beregninger), på en standardiseret og automatiseret baggrund,

• at eksportere “projekt-status” til statiske formater (som PDF, eller andet låst format),

Materialer (input) -

• at navngive materialer i overensstemmelser med førnævnte klassificeringssystemer, og tilknytte meta-data baseret på databaser,
• at gennemgå alle tilknyttede data og properties ift. enkelte forekomster af materialer, jf. tegnestuespecifikke retningslinjer, med henblik på navngivninsstandarder og standardiserede metoder til udfyldning af disse data-felter, 

Materialer (output) - 

• at koble eksporteringsprocesserne, i sammenhæng med førnævnte videre bearbejdning i tredjeparts-applikationer (herunder statiske og økonomiske beregninger), op på hurtigere og mere præcist definerede  videre forløb, hvor videretagelse af bl.a. mængder og materialespecifikationer, gøres mere automatiseret,
• at automatisere mængdeopgørelser, mere præcis navngivning, sortering og kategorisering af disse, herunder klassificeringer og identifikation tilknyttet de enkelte materialegrupperinger,

Vedligehold (input) -

• at minimerer størrelsen på den enkelte Family-forekomst, ved generel gennemgang af de enkelte forekomster, med primært henblik på eliminering af overflødig geometri, linework og eller tilknyttet, irrelevant information, også her (måske / måske ikke) tænkt ift. etableret, aktuelle LOD-niveau,

Vedligehold (output) - 

• at opnå en “renere” eksportering af hhv. geometri og tilknyttet data, herigennem mindre eksportstørrelser, grundet fjernelse af bl.a. unødig geometriske forekomster, linework, tilknyttet data og materialer.

Eksemplificeringer, objekttyper

Følgende er et forsøg på at konkretisere udvalgte eksempler på diverse Family-typer, i form af visuelle afbildninger med tilknyttede ikke-udtømmelige properties-oplistninger. 

Med dette formål for øje, har jeg derfor valgt følgende Revit system- og Revit loadable-Families;