Pp5 B2 (1)

Automatisk check af BIM-modeller ift produktdata

Dette pionerprojekt er et spin-off af BART-projektet, der har fokus på at kode krav til byggeriet fra bygningsreglementet (BR18) med henblik på at kunne gennemføre et automatisk tjek. Projektet er lavet i samarbejde med NIRAS og byggevareleverandøren Saint-Gobain, med fokus på deres gipsvæg-system (Gyproc). Projektets formål har været at skabe et koncept for et plugin der kan hjælpe arkitekter med at tjekke om det modellerede kan bygges - altså om der findes produkter på markedet der matcher objekternes dimensioner og egenskaber i modellen.

Gipsvægge er et produkt der bruges i de fleste byggerier, men så snart man kommer udover en standardvæg kræver det en del viden for at vælge det mest optimale produkt. Således vil projektet identificere regler for at vælge de rigtige gipsvægge ift. omgivelserne, og bruge dette til at komme med feedback og anbefalinger til arkitekten, der projekterer gipsvæggen, således at det bliver muligt at vælge det rette produkt.   

For at teste potentialet er der i projektet udviklet en simpel testmodel, som er opbygget som en såkaldt knowledge graph i et framework til formålet kaldet Resource Description Framework (RDF). Der er arbejdet med logiske regler, som er i stand til at udlede afledte krav til gipsvæggene ud fra viden om de tilstødende rum.

For at tjekke om modellen lever op til de krav der stilles for at kunne anbefale det rette produkt, er der desuden udviklet en prægranskning. Denne er baseret på et sprog, som er udviklet til at beskrive forventninger til indholdet i en RDF knowledge graph kaldet Shapes Constraint Language (SHACL). Såfremt modellen består tjekket vil det på baggrund af denne være muligt for diverse leverandører af gipsvægge at foreslå produkter som opfylder de givne randbetingelser og måske endnu vigtigere påpege hvis der ikke findes et produkt i deres sortiment, som opfylder kravene. Hvis ingen af de tilgængelige leverandører har et produkt som opfylder randbetingelserne fortæller det designeren at noget må ændres, og dermed bliver løsningen til et granskningsværktøj.

Sammen med udviklingen af et teknisk proof of concept, så fokuseres der også meget på formidlingen af ideen til slutbrugeren. Formålet med dette er at teste efterspørgslen på konceptet, men også for løbende at kunne evaluere og tilrette konceptet så det lever op til brugerens krav og ønsker.  

 

Hvilket problem løser pionerprojektet?

Formålet med projektet er give mulighed for at gennemføre et automatisk tjek af om det modellerede kan bygges. Dette er en proces der kan tage lang tid (undersøge produkter på nettet, indhente dokumentation), og ved at automatisere processen kan der spares meget tid og arbejdskraft.

Med det koncept for et user interface der blev udviklet, blev det slået fast, at der er stor interesse for løsninger som denne, og at det kan løse et reelt problem i branchen. I en brugertest blev det pointeret at dette koncept fungerer på samme måde som clash detection, og at tankegangen derfor ikke vil være ny for brugerne. Desuden blev det nævnt, at konceptet, udover at hjælpe brugeren til at forstå hvor mange og hvor komplekse problemer der er i modellen i forhold til bygbarhed, også på sigt ville kunne bruges til at evaluere sin model i forhold til bæredygtige produkter på markedet.

Projektet

Materialet der blev udviklet i forbindelse med pionerprojektet er lagt på github i dette repository der indeholder en samling RDF-filer, som tilsammen udgør den knowledge graph, som beskriver modellen. RDF bygger på World Wide Web konsortiets (W3C) specifikationer og er udarbejdet til at definere ”ting” eller ressourcer ved at angive deres indbyrdes relationer samt metadata som beskriver dem. ”Ting” kan være både fysisk håndgribelige objekter (vægge, døre, dæk, personer) og ikke-fysiske ting (rum, organisationer mv.), som knyttes til viden i vores virtualisering af den virkelige situation (modellen). Modellen beskrives kort det i følgende.

Gennemgang af datamodel

I videoen nedenfor kan du se hvordan RDF datamodellen er opbygget.

Objekter identificeres her med ID’er på formen :XX. Kolon er en forkortelse for et præfiks i form af en URL-addresse. Da linked data og RDF forudsætter brug af webaddresser til at navngive ting, bliver det egentlige ID, som er 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 buttom 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 ydereligere at konkretiserer, selvom tanken er, at det også skal kunne fungere med andre modelleringsværktøjer.

 

 

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

Lyspaere Green

1.

Arkitekten får en design/modelleringsopgave

Raket Green

2.

… påbegynder modelleringarbejdet i Revit

Kaede Green

3.

... vil tjekke om der er produkter på markedet der matcher designet

Kran

4.

... designet færdigmodelleres.

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.

 

Samlet potentiel positiv indvirkning på byggebranchen

Hvis resultaterne skaleres og bruge bredt vil det kunne have stor positiv effekt på samarbejdet og effektiviteten i branchen. Der vil kunne undgås dyre løsninger og mange uforudsete omkostninger. Da der er tale om at tjekke designs ift BR18 og om materialerne findes på markedet, er det noget som enormt mange virksomheder i branchen bruger meget tid og ressourcer på i dag – den tid ville blive minimeret, og brugt på andre, forhåbentligt vigtigere ting.

 

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 meget ny (W3C er fra 90’erne), men anvendelsen af teknologien er ikke meget udbredt i byggebranchen, derfor bærer projektet også præg af et højt innovationsniveau på markedet.

 

Learnings

Da projektet er et spin-off af et større projekt, så bærer det præg af store visioner og planer, men da projektet kører over få måneder, så blev det hurtigt klart at vi måtte udvælge en mindre del og et mere konkret mål at løse. Projektgruppen blev derfor enige om at fokusere på et proof of concept til fire regler der afgør hvilket produkt der skal vælges. 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.” Konkretisering satte skub i projektet og der blev hurtigt herefter udviklet både den testmodel og -script som er vist ovenfor.

Pp5 B1

Med det koncept for et user interface der blev udviklet, blev det slået fast, at der er stor interesse for løsninger som denne, og at det kan løse et reelt problem i branchen. I en brugertest blev det pointeret at dette koncept fungerer på samme måde som clash detection, og at tankegangen derfor ikke vil være ny for brugerne. Desuden blev det nævnt, at konceptet, udover at hjælpe brugeren til at forstå hvor mange og hvor komplekse problemer der er i modellen i forhold til bygbarhed, også på sigt ville kunne bruges til at evaluere sin model i forhold til bæredygtige produkter på markedet.

Potentialer og next steps

Outputtet af pionerprojektet har modtaget en del positiv feedback – branchen kan se værdien i funktionalitet. For at platformen er for bliver relevant for arkitekter og ingeniører kræver det at en stor andel af de tilgængelige produkter er tilgængelige på platformen – så det kræver commiment fra producenter og leverandører. Da løsningen fra start skal drives i et fællesskab af producenter, en aktør er ikke nok. Spørgsmålet er også om det kræver en europæisk løsning. Projektet er for stort til ConTech Lab alene, så det kræver en stærk partner der vil drive projektet i næste fase med os.