Dette avsnittet inneholder detaljert teknisk forklaring på hvordan importen kan konfigureres og hvordan dette fungerer i forhold til en IFC modell som krever litt kjennskap til den underliggende modellen. Du trenger ikke lese dette avsnitte med mindre du vil gjøre endringer i hvordan importen fungerer.

Bakgrunn

Når man lager en BIM modell som rådgiver er ett av hovedfokusene å produsere en geometrisk 3D-modell som er god nok for å kunne bygge etter. I en åpen BIM (IFC) er derfor naturlig nok mesteparten av innholdet informasjon om alle de ulike delene/elementene. Når det er snakk om FDV, merking og dokumentinnsamling er det noen av elementene som er mer sentrale enn andre. IFC import i TIDA lar deg både hente underlaget for dokumentasjon direkte fra rådgivers modell og hjelper til med å gruppere de ulike elementene som bør dokumenteres som en post.
MERK: Selv om vi slår sammen flere instanser til en post i TIDA ved import så tar vi vare på alle instans GUID-ene så vi vet hvilke objekter i BIM-en det er snakk om. Grupperingen gjøres da først og fremst for at det skal bli enklere å finne frem og forenkle arbeidet med dokumentasjonen.

I følgende eksempel (illustrert over) finnes det et radiatorsystem. I IFC-modellen består dette av 333 ulike deler (objekter/instanser), men det er sannsynligvis ikke ønskelig å dokumentere hver og en av disse. I IFC modellen har vi også informasjon om typer og en type objekt inneholder felles informasjon om flere instanser. I dette eksempelet finnes det 102 ulike typeobjekter. Grunnen til dette er blant annet at et rett rør, en skjøt eller en vinkel er representert med ulike typer og det er det heller ikke ønskelig å dokumentere 102 ulike poster om dette radiatorsystemet.
Om instanser, typer og IFC klasser:
En IFC klasse er den definisjonen i IFC standarden som angir hvordan objekter som betyr noe bestemt skal lagres i en IFC modell. F.eks. så skal alle rom i en IFC modell lagres som IfcSpace. Et rom i en IFC modell er da et objekt med IFC klassen IfcSpace. Både instanser og typer har en bestemt (men forskjellig) IFC klasse.
En instans er en bestemt forekomst av et element i modellen, f.eks. en forekomst av en lampe i et rom. Alt du "ser" i en IFC modell er instanser. De har ofte ganske lite informasjon med unntak av plassering og informasjon som er unikt for denne instansen. Felles informasjon om alle lampene som er like bør settes på typen som denne instansen relaterer til. En type er således et virtuelt objekt du ikke ser i IFC modellen, men som benyttes for å legge felles informasjon om flere instanser på. Ikke alle instanser må ha en type, men ofte og spesielt for tekniske fag vil de ha det.
Med tanke på drift og en rasjonell dokumentinnsamling ønsker man kanskje en enda bredere gruppering av disse rørene. IFC import i TIDA har derfor en konfigurerbar gruppering der brukeren selv kan bestemme hvilke poster som skal slås sammen og ikke.
Ett eksempel kan være at man kun ønsker å ha en sekkepost for alle rørene i radiatorsystemet uavhengig av f.eks. dimensjon, som man ønsker dokumentert, men at man ønsker en unik post for hver av ventilene fordi de skal merkes på bygningen:

Gruppering ved import til TIDA

Det som blir avgjørende for å få et ønsket resultat inn i TIDA er derfor at man setter opp de riktige reglene for hvordan man ønsker å dokumentere dataene. I en IFC-modell vil du ha mange instanser som er knyttet til et system. Hver av disse instansene kan være av forskjellige klasser i IFC modellen. Instansene kan også ha en relasjon til et typeobjekt av en bestemt type. Hvis du tenker deg all informasjonen om de ulike instansene og deres typer for et gitt system som en utflatet tabell kan det se noe sånt ut:

Tabell 1: Instanser og typer for et eksempel system
Konfigurasjonen kan da settes opp til å bestemme hvilke rader man ønsker å "slå sammen" ved en import til TIDA. De første to radene representerer to ulike forekomster av den samme radiatoren, men som i IFC modellen kommer ut med ulike typeobjekter. Hvis man ønsker at disse skal være en post i TIDA kan man da lage seg en regel som sier at alle instanser som har en type av ifc-klassen IfcSpaceHeaterType og som har samme navn på typen skal grupperes. I Eksemplet over ville man da fått en post i tida med navn "MC11-508" som representerte begge disse radiatorene.
Tilsvarende kan man f.eks. sette opp regler om at alle ventiler ønsker vi at skal være unike uansett fordi man ønsker unik merking. Da kan man lage regel om at alle av IfcValveType skal grupperes unikt (ikke slås sammen).
Når man ser på rør eksemplene så kommer de ut som to ulike ifc klasser, både på instansene og på typene, men med tanke på dokumentasjonsinnsamling er det kanskje ikke ønskelig å lage to ulike poster bare fordi den ene representerer et rett rør og den andre et bøyd rør. Da kan du lage en grupperingspost som gjør at alle instanser av enten den ene klassen eller den andre vil bli slått sammen.
Den siste raden viser at man i en IFC fil ganske ofte også vil finne instanser som ikke har knyttet noen type til seg. Siden klassene som benyttes for å beskrive en instans ofte er veldig generelle er det vanskelig å gi noe kvalifisert svar på hva det er så brukeren må selv klassifisere det riktig.
Ved å benytte konfigurasjonen som angitt over vil en gruppering ved import gjøre at følgende vil vises ved import av denne filen:

Redigering av TIDA IFC importkonfigurasjon

Du kan redigere importkonfigurasjonen ved å gå til Administrasjon -> Rediger TIDA IFC importkonfigurasjoner på menylinjen. Du må være administrator for å redigere importkonfigurasjoner.
En importkonfigurasjon definerer regler for hvordan forekomstene skal grupperes i komponenter ved import til TIDA. Konfigurasjonen består av en eller flere komponentkonfigurasjoner som definerer hvilke IFC klasser som skal grupperes sammen og importeres når denne konfigurasjonen benyttes. For hver komponentkonfigrasjon angir man så en liste med instansattributter og/eller typeattributtsom definerer hvilken verdi på objektet det skal grupperes på. Den kan også definere hvilken TIDA attributt som det skal importeres til.
Eksempel: Hvis du har en komponentkonfigurasjon som gjelder for ifc klassen IfcFanType som har type attributtene ApplicableOccurrence og Name satt betyr det: For et gitt system - gruppér sammen alle instanser som har et type objekt av typen IfcFanType som har samme verdi i både ApplicableOccurrence og Name i typeobjektet. Videre så kan man som i eksemplet under angi at verdien som ligger i ApplicableOccurrence skal importeres til Navn i TIDA. Ved å definere denne reglen betyr det at alle objekter i IFC modellen som har en type av IfcFanType vil følge denne reglen. Siden det finnes en konfigurasjon for denne klassen betyr det også at disse forekomstene vil bli huket av for import.
De forekomstene i IFC modell som ikke har noen komponentkonfigurasjon blir som gruppert sammen med alle av samme ifc klassen og samme verdi i Name. De vil ikke være huket av for import.
Når du velger å redigere en importkonfigurasjon åpnes et vindu som vist i skjermbildet under.
654321

1. Velge hilken importkonfigurasjon du ønsker å redigere, slette eller lage ny.
2. Viser alle komponentkonfigurasjonene som er definert for importkonfigurasjonen. Her kan du også legge til og fjerne en komponentfigurasjon fra importkonfigurasjoneen.
3. Her bestemmer du hvilken IFC klasse komponentkonfigurasjonen gjelder for, evt legger til flere om du ønsker å gruppere flere IFC klasser sammen i en komponentkonfigurasjon. Du kan endre klassen ved å velge en annen i rullelisten.
4. Her kan du velge og legge til attributter på instans og type du ønsker at den valgte komponentkonfigurasjoen skal gruppere på. Det lønner seg å gruppere kun på type verdier da det å gå gjennom verdier for alle instanser i en større modell vil være svært tidkrevende.
5. For det valgte attributtet må du bestemme hvilket IFC attributt den skal gruppere på. Du kan også sette hvor det skal importeres til i TIDA. TIDA attributten velges fra rullelisten. Den inneholder et sett med kjernedata samt et valg for å velge tekniske data. Når du har valgt en teknisk data attributt så legges den til nederst i rullelisten for at man raskt skal kunne velge det samme attributtet senere.
6. Lagre endringer i den valgte importkonfigurasjonen.