Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S

Transkript

1 Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S

2 Problemstilling ved DBK integration i BIM Software Domæner og aspekter Det domæne, der primært skaber problemer i BIM software, er Resultat domæne 2. De 4 aspekter i dette domæne Funktions-, Produkt-, Placerings- og Formaspektet kan alle tilknyttes det samme objekt i en BIM model. Det skaber for så vidt ikke de store problemer, at håndtere Funktions- og Formaspektet, da disse er simple tabelopslag som brugeren skal tilføje det enkelte objekt manuelt. Dette kan også tilføjes et objekt før det indsættes i modellen. Placeringsaspektet kan styres manuelt ved opslag eller automatisk ved at benytte de referencer der i forvejen opbygges i en BIM model. Produktaspektet skaber langt større problemer, dette skyldes primært, at kodningen ikke kan påbegyndes, før objektet er placeret i modellen. Derudover vil de mange produktaspekter som eks. vis i installations systemer, kræve at brugere manuelt må opdele et anlæg i mange mindre systemer. Se figur 1. Figur 1 1

3 Den indbyggede reference struktur i klassifikationen samt den manglende entydighed i DBK-tabel 25: Bygningsdele, forekomster i produktaspektet, gør at det ikke er muligt entydigt at kode objekter på forhånd. Opbygningen i tabel 25 gør at en bygningsdelstype vil blive kodet forskelligt alt efter hvilket produktaspekt der vælges i niveau 1 & 2. Fordi bygningsdelstypen Ventil ikke er entydigt i tabellen får Ventiler nogle steder i modellen koden.07 og andre steder koden.03. Se figur 2. Figur 2 Forskellig kodning af objekter Der er ikke noget problem i at kode objektet i den samlede model, problemet er, at der mangler en entydig kode, når objektet ikke er indsat endnu. Hvis den førnævnte ventil kodes yderligere for at beskrive at det er en Afspærringsventil, får den tilføjet bogstavet A i koden derved.a07 eller A03. Fordi koden A opstår i alle produkttyper er det ikke tilstrækkeligt til at kode med i et objekt/produkt bibliotek. For at kunne håndtere de forskellige produkttyper i et bibliotek, kræver det en entydig nøgle på alle produkttyper og varianter. Figur 3 illustrerer nogle af alle de forskellige koder og klassifikationer der beskriver den samme Afspærringsventil, både i en model, et objektbibliotek, et produkt bibliotek og hos producenten. 2

4 DBK i BIM modellen I Objekt biblioteket OmniClass: Valves for Liquid Services A07 Ventil af typen Afspærringsventiler i Vandstik i Vandsystem A03 Ventil af typen Afspærringsventiler i Fjernvarmestik i Varmesystem I Produkt biblioteket I Producent biblioteket Bis Kode: (eksempel, Kode er ikke udviklet endnu.) Afspærringsventil eller VVS nummer: VVS nr. A B C D /4" 1/4" 50,1 33, /8" 3/8" 50,1 33, /2" 1/2" 61,7 40, /4" 3/4" 71,2 45, " 1" 83,3 53, /4" 11/4" 98,0 58, /2" 11/2" 109,0 72, " 2" 133,0 80,0 Figur 3 3

5 Forskellige klassifikationer En anden problemstilling er at der ikke kan oversættes 1 til 1 mellem de forskellige klassifikationer. Dette kan eksempelvis ses ved at der findes 10 forskellige typer ventiler i DBK, hvorimod den Amerikanske OmniClass indeholder 7 typer, som ikke er direkte sammenlignelige med DBK. Derfor er der et stort behov for en måde at oversætte begreber, typer og egenskaber mellem de forskellige klassifikationer og standarder. Denne oversættelse skal også kunne håndtere de forskellige niveauer i klassifikationerne. Eksempler: Meget detaljeret til mindre detaljeret. Afspærringsventil i DBK oversættes til en Valve i OmniClass Meget detaljeret til meget detaljeret. (1 til 1) En Kontraventil i DBK oversættes til en Non-Return Valve i OmniClass Meget detaljeret til meget detaljeret men helt anden produkt type. (1 til 1) En Bleeding Valve i OmniClass oversættes til en Luftudlader i DBK (Typen Udluftning ikke Ventil) En mulig løsning I dag foreligger der desværre ikke en færdig løsning der håndterer alle de forskellige klassifikationer der findes. Men der arbejdes på et projekt kaldet IFD (International Framework for Dictionaries). Projektet er et samarbejde under buildingsmart, som også udvikler IFC. IFD er tænkt som en måde at løse problemstillingen som beskrevet ovenfor. Dette opnås blandt andet ved at benytte en unik nøgle (Global Unique Identifier) som alle ensbetydende begreber peger på. Eks. Vindue (DK), Vindu (NO), Window (EN), ifcwindow (IFC), Fenster (DE) og Fenêtre (FR) refererer alle til denne nøgle 3vHUaooT0Hsm00051Mm008. Dertil kommer alle de egenskaber der også knytter sig til en Bygningsdel så som dimensioner, brandklasse, trykklasse mm. de vil også kunne oversættes ved hjælp af IFD. Se figur 4. Figur 4 4

6 IFD spænder langt bredere end de begreber der kan håndteres i IFC, et BIM system eller et prisberegnings program. Samtidig er der ingen begrænsning i IFD hvad angår begreber, typer og egenskaber og derfor ser jeg ikke nogen begrænsning i forhold til en integration af DBK i IFD. Læs mere omkring IFD her Kodningens struktur En problemstilling, der også tit er blevet nævnt i forhold til DBK i software, er brugen af speciel tegn som -, =, + og # i koden. Jeg vil tro at disse tegn er valgt ud fra et analogt synspunkt, men da DBK koder kun skal håndteres digitalt, vil det være mere hensigtsmæssigt med en tal- eller bogstavs kombination. Selve koden bør også altid skrives i sin fulde længde. De forskellige dele af koden er opdelt med et punktum, men antallet af karakterer kan variere. Dette skyldes at detaljeringsniveauet også kan variere eks. i forskellige faser. Software tænker ikke logisk, man arbejder ud fra de regler det programmeres til. Disse regler bliver unødvendigt komplekse med den opbygning der i dag er i DBK. Eks. den samme væg i 2 forskellige faser: Kort beskrevet Vægkonstruktion i Vægsystem Detaljeret beskrevet. -A20501.EB0111 Vægkonstruktion nr. 11 af typen Træskeletvægge med træbeklædninger-gipslader i Vægsystem nr. 1 af typen Ydervægge Kort beskrevet med mere entydighed i koden. PRx205xx.xx01xx Vægkonstruktion i Vægsystem Minus tegnet er udskiftet med PR for nemmere udveksling mellem software. x udgøre en placeholder så kodens længde altid er ens. På lige vilkår med Lag koder og Filnavngivning jf. bips. Internationalisering En af grundene til at DBK ikke har den højeste prioritet hos de store software huse er bl.a. fordi det ikke er en international standard. Selvom DBK bygger på ISO standarder er den stadig kun national og nationale klassifikationer findes der rigtig mange af på verdens plan. Der er 2 måder at løse denne problematik på, den ene er at få de andre nordiske lande til at støtte op omkring DBK og få den ophøjet til en ISO standard. Den anden er at tilføje DBK til IFD standarden. Løsningen vil først blive en national tilpasning til softwaren, da det sandsynligvis vil tage flere år før DBKs reference teknik er implementeret direkte i de internationale software løsninger. Ansvar For at vi som software leverandør samt brugerne kan være sikre på, at grundlaget for kodningen er korrekt, kræver det at hele DBK kodestrukturen leveres i XML. Ved at bygge software løsningerne direkte på XML filen/filer sikres det, at efterfølgende opdatering af klassifikationen hurtigt vil kunne tilføjes softwaren og samtidig bliver ansvaret for koden ikke lagt over til software leverandørerne. Dette vil også reducere sandsynligheden for fejl. 5

7 Konklusion For at DBK kan implementeres bedst muligt i software løsninger vil jeg anbefale følgende tiltag. 1. DBK indarbejdes i IFD 2. DBK i XML format indeholdende GUID fra IFD 3. Klar entydighed i kodens udformning, se Kodningens struktur Af: Nicolai Karved Application Engineer Betech Data A/S Distributør for Autodesk 6