Automatisk check af BIM-modeller ift produktdata

Objekter identificeres her med ID’er på formen :XX. Kolon er en forkortelse for et præfiks i form af en URL-adresse. Da linked data og RDF forudsætter brug af web-adresser til at navngive ting, bliver det egentlige ID en sammenføjning af præfiks og ID. Hvis præfikset : defineres som https://niras.dk/projects/1234/ bliver det egentlige ID altså https://niras.dk/projects/1234/XX. Hvis NIRAS internt bruger en URL-struktur, der altid inkluderer projektnummeret (her 1234), så bliver ethvert ID globalt unikt, så længe det blot er unikt i projektet. 

I RDF klassificeres objekter med den særlige rdf:type-relation. Et objekt kan tilhøre flere klasser, så en bil kan eksempelvis både være et ’Køretøj’, et ’Transportmiddel’ og en ’Potensforlænger’ (bemærk at klasser angives med stort begyndelsesbogstav).

Klasserne defineres i såkaldte ontologier beskrevet i web-ontologisproget OWL.I test-modellen er der klassificeret med the Building Topology Ontology (BOT), IFC2x3 og en række klasser som er oprettet specifikt til projektet. På sigt kan disse trækkes ud og publiceres i en ontologi for et særligt fag som eksempelvis brand. Da terminologien opstår, efterhånden som den bliver nødvendig, kan vi følge en bottom-up approach i standardiseringen, understøttet af linked data.

De enkelte RDF-filers indhold er beskrevet mere dybdegående i denne video, som er af mere teknisk karakter. 

EKSEMPEL PÅ BRANDKLASSIFIKATION

I test-projektet blev der arbejdet med datasættet i en grafdatabase (en såkaldt Triplestore), som hedder RDFox. I denne video beskrives det, hvordan det opbyggede test-script sørger for at loade alle RDF-filer i databasen og aktivere motoren for logisk inferens (reasoning), og i denne video vises det, hvordan man kan udføre logiske forespørgsler (queries) ned i grafen. Videoen nedenfor viser, hvordan logiske regler sørger for automatisk at opdatere den viden om væggene ud fra informationer på de tilstødende rum.

For at få en dybere forståelse for hvad der sker, kan det være nødvendigt at kigge i dokumentationen for den fulde datamodel inkl. de logiske regler, som er beskrevet i dette dokument.

USER INTERFACE

For at visualisere hvordan et konkret koncept for brugergrænsefladen kunne se ud, så det kunne testes med potentielle brugere, er nedenstående videogennemgang udviklet. Interfacet er designet som et plug-in til Revit for yderligere at konkretisere. Men tanken er, at interfacet skal kunne fungere med andre typer modelleringsværktøjer.

Interfacet viser projektets simple testmodel, som indeholder rum med forskellige funktioner og relationer. Desuden illustrerer det brugerens flow ifm., at objekter, egenskaber og anbefalinger kobles til design/produktforslag. Af nedenstående fire punkter illustrerer interfacet flowet når en arkitekt vil tjekke, om der er produkter på markedet, der matcher dét design, arkitekten har modelleret, projektet meldes færdigt.

Interfacet viser konceptet for hvordan man tjekker en model, vælger hvordan man ønsker at modtage resultatet af modellen tjekket mod produktdatabaserne og til sidst, hvordan et resultat af et modeltjek kunne se ud.

Nyhedsværdi og innovationsniveau

Projektet har i høj grad nyhedsværdi, da det er knyttet til det større BART-projekt. BART projektet har det formål at automatisere BR18, og det bidrager dette pionerprojekt i høj grad til. Selve teknologien, der bliver anvendt er ikke ny (W3C er fra 90’erne), men anvendelsen af teknologien er sjældent anvendt i  byggebranchen, hvorfor  projektet har et  højt innovationsniveau på markedet. 

Projektresultater

I en brugertest blev det pointeret, at plugin-løsningen i praksis fungerer på samme måde som clash detection, og at tankegangen derfor ikke vil være ny for brugerne.  

Det blev imidlertid slået fast, at der er stor interesse for løsninger som denne, og at konceptet bidrager til at løse et reelt problem i branchen. Desuden blev det nævnt, at konceptet dels hjælper brugeren til at forstå, hvilke komplekse problemer der er i modellen i forhold til bygbarhed, og dels har potentiale til på sigt at kunne anvendes til evaluering af bæredygtighed og tilvalg af bæredygtige produkter. 

Der er dog fortsat et stykke vej, før man når en løsning, der kan implementeres og anvendes i byggeriet.Da projektet er et spinoff af et større projekt, bærer det præg af store visioner og planer, som et pionerprojekt, der forløbet over få måneder, ikke kan indfri alene.  

Projektgruppen valgte derfor at fokusere på et proof-of-concept (POC) for i alt fire regler fra bygningsreglementet, der er med til at afgøre, hvilket produkt/materiale, der skal vælges i et byggeprojekt. Et eksempel på en sådan regel kunne være ”hvis der er en døråbning, skal væggen ovenfor være stærkere.” Reglerne danner baggrund for den testmodel, som er vist ovenfor. 

Projektets potentiale

Hvis resultaterne skaleres og bruges bredt i byggebranchen, er der stort potentiale for at skabe bedre og mere effektivt samarbejde i branchen, da man eksempelvis kan undgå omkostningerne ved at justere materialevalg undervejs – noget der ofte medfører uforudsete omkostninger og ekstra arbejde. Der er tale om hjælp til at at tjekke designs ift. BR18 og om materialerne findes på markedet, hvilket er noget, som  mange virksomheder i branchen bruger enormt meget tid og mange ressourcer på i dag – den tid kan bruges på  vigtigere ting. 

For at konceptet fra dette pionerproblem kan blive til en færdig, implementerbar løsning, kræver det, at en stor andel af de tilgængelige produkter på markedet også er tilgængelige på platformen – hvilket kræver commitment fra producenter og leverandører.  En aktør fra ét sted i byggeriets værdikæde er langt fra nok til at drive løsningen frem. Der er i høj grad brug for etablere et fællesskab – og måske på bredere niveau end det nationale.  

ConTech Lab er åbne for at genoptage arbejdet, såfremt flere stærke partnere vil være med til at drive det mod næste fase.