Er IFC utstyrt for å strukturere produsentenes data?

Det har vært noe forvirring i markedet om hvordan produsenter skal bruke IFC. Dette skyldes delvis at begreper som IFC, IFD, IDM som brukes i BIM-miljøet, fortsatt er svært uklare for allmennheten, og initiativene til å bruke klart språk for å beskrive alt i BIM  er fremdeles i en tidlig fase.

Produsenter har i økende grad begynt å forstå at for å digitalisere et produkt, må de formidle produktets kjennetegn i form av standardbaserte «egenskaper». Her starter forvirringen. IFC som ofte oppfattes som «BIM-formatet», tillater bruk av «egenskaper» som er innebygd i formatets logikk. Det leder produsentene til å tro at å tilby sine produkter «i IFC», gjør dem BIM-klare. I denne artikkelen skal vi se litt nærmere på forskjellene mellom dataformat og datastruktur.

Industry Foundation Classes (IFC) spesifikasjonen er et nøytralt, ikke-proprietært dataformat som brukes til å beskrive, utveksle og dele informasjon. IFC ble utviklet for å forenkle interoperabilitet, men det i seg selv sikrer ikke interoperabilitet. Alle slags data kan transporteres gjennom IFC, men det betyr ikke at dataene er strukturerte, nøyaktige eller egnet til formål. IFC er et utvekslingsformat – derfor bør det ikke brukes til å organisere, kvalifisere eller strukturere data.

IFC er utstyrt for å transportere data fra produsentene, og ikke for å strukturere data fra produsentene.

En IFC-entitet gir en god ide om hva egenskapene til Ifcwindow er, men den dekker ikke det fulle omfanget av disse egenskapene. Det gir heller ikke en troverdig kilde (for eksempel en produktstandard), testmetoder som brukes for å teste egenskaper som «U-verdi», eller noen ytterligere informasjon. Det betyr at hvis prosjekterende legger til et vindu med 20 egenskaper i en IFC-modell, og IFC-formatet bare støtter 4 egenskaper innenfor sin logikk, blir de andre 16 egenskapene lagt inn i et «egendefinert» egenskapssett. Egenskapene i dette settet blir ikke behandlet separat, noe som kan være problematisk hvis IFC-eksporten skal brukes i et annet system. Dessuten er det ikke sikkert at dataene i dette mangfoldige egenskapssettet er riktig definert. Her støtter IFC ikke interoperabilitet til sitt fulle.

Hva er alternativet?

Ifølge CEN 442-komiteen er Product Data Templates (PDT) måten for å strukturere interoperabile produktdata for BIM.

Product Data Templates (PDT) i en felles dataordbok løser problemet med hvilke egenskaper, testmetoder og enheter som beskriver et produkt i henhold til en bestemt standard. Derfor kan produsentene først bruke Product Data Templates (PDT) til å strukturere dataene sine. Når dataene er riktig strukturert med opprettede relasjoner og unike identifikatorer for alle egenskaper, kan IFC brukes til å transportere dem til forskjellige systemer. Deretter kan aktører som prosjekterende, innkjøpsledere, entreprenører, m.m., bruke Product Data Templates (PDT) til å angi sine datakrav og matche dem mot produsentdata.

En PDT definert i en felles dataordbok har flere fordeler over IFC.

Den bruker terminologi som er både forståelig og teknisk anvendelig i det lokale markedet. For eksempel har vinduene i IFC en parameter «sikkerhetsklasse». I henhold til den harmoniserte europeiske standarden EN 14351-1 som dekker vinduer, finnes det ingen parameter som heter «sikkerhetsklasse». I stedet finnes det tre andre parametere – «eksplosjonsmotstand», «motstand mot prosjektiler» og «innbruddssikkerhet». Alle disse er i en viss grad relatert til «sikkerhetsklasse». En slik forskjell kan se relativt liten ut, men den er faktisk ganske betydelig. Begreper og parametere som defineres av europeiske harmoniserte standarder, finner veien inn i diverse nasjonale standarder og forskrifter, og dermed brukes i alle faser av byggeprosessen. Hva skjer når prosjekterende må sette opp krav til alle tre parameterne, men programvaren gir ham bare en mulighet? Hva skjer hvis utførende i henhold til prosjektets datakrav må oppgi «sikkerhetsklasse» for vinduer?

Hvordan takler vi slike uklarheter?

Avvik i terminologi tvinger folk til å gjøre subjektive forutsetninger om hva den andre parten mener. Det fungerer dårlig i digitale prosesser. Byggenæringen jobber med konkret terminologi som også brukes i kommunikasjonen mellom de ulike aktørene. Product Data Template (PDT) gjør at folk kan bruke de presise begrepene de trenger. Dessuten er PDT-løsningen språknøytral da den bruker en felles dataordbok. GUID (globalt unik identifikator) for et begrep er også knyttet mot de respektive oversettelsene av begrepet til andre språk. For eksempel er både «innbruddssikkerhet» og den tyske oversettelsen «Einbruchshemmung» under samme identifikator. Resultatet er at en tysk produsent kan erklære de riktige produktdataene i en forståelig struktur slik at dataene kan valideres mot krav på hvilket som helst annet språk. IFC som er perfekt utstyrt som transport- og utvekslingsformat, dekker ikke dette behovet.

digital twin

Datastrukturer i en lokal kontekst

Et annet problem med IFC og spesielt egenskapene som er oppført i ISO 16739, er at de er for få. De er bare en abstraksjon av det som generelt erklæres, og dekker på ingen måte lokalindustriens krav. Viktige egenskaper som «flytefasthet» av stålelementer eller «U-verdi» av isolasjon mangler eller er skjult bak uforståelige attributter.

På den annen side inneholder IFC-egenskapssettene også egenskaper som er irrelevante utenfor BIM, som f.eks. «Status» og «Referanse», som henholdsvis viser til gjeldende status (ny, eksisterende, rive osv.) og den interne referansen til et objekt inne i modellen. Mens IFC har verktøyene til å bære produktdata, gir Product Data Templates (PDT) den aktuelle listen over viktige egenskaper for å dekke industriens behov. Product Data Templates er utviklet på bakgrunn av relevante lokale standarder og designkoder, og tilfredsstiller på denne måten både regulatoriske og praktiske behov.

IFC er «hvordan» og PDT er «hva»

I konklusjon: IFC er et godt verktøy for samarbeid som forenkler åpen datautveksling under byggeprosessen. På denne måten hjelper IFC produsentene til å få sine produktdata rett inn i modellen. IFC besvarer «hvordan», men ikke «hva». For å dekke «hva», må IFC jobbe hånd i hånd med den enkle, troverdige strukturen til Product Data Template.

2019-01-30T09:55:27+00:00september 21st, 2018|