Nel secondo articolo sul formato IFC abbiamo già compreso che sono le relazioni a definire "cos’è cosa": un muro è tale in virtù delle interdipendenze con tutti gli altri elementi. Ma come interagiscono fra di loro le relazioni?
Se non hai letto la parte 2, la trovi qui: L'identità dell'oggetto nel formato IFC.
Le relazioni, denominate IfcRelationship, ricadono in 5 categorie principali:
Le Relazioni più evidenti sono quelle di tipo spaziale, ascrivibili alla categoria IfcSpatialStructureElement. IFC, come avviene comunemente nella maggior parte dei software di modellazione, è strutturato secondo la gerarchia:
Progetto – Sito – Edificio – Piano – Building Element
I Building Elements possono a loro volta ospitare altri elementi (ad esempio la finestra nel muro). Bisogna fare attenzione all’appartenenza, un piano che può anche non corrispondere con la sua posizione effettiva: per cui un muro può trovarsi fisicamente ad una quota che corrisponda a un piano superiore ma appartenere di fatto al piano inferiore.
Un Oggetto può trovarsi ad una determinata quota, ma se lo assegniamo alla categoria del Sito, verrà automaticamente rimosso da qualsiasi Piano; analogamente, un qualsiasi Oggetto identificato come IfcSite verrà assegnato al Sito senza alcuna possibilità di assegnarlo a un dato Piano. Attenzione a distinguere fra piani fittizi, generati per facilitare la visualizzazione di parti del modello, e piani reali dell’edificio.
Ogni Progetto può anche ospitare più edifici (Buildings) i quali sono a loro volta suddivisi in Piani, e così via.
Il prossimo schema IFC 4x3, la cui uscita è prevista per fine 2020, introdurrà una descrizione molto più ampia e articolata del Sito, che potrà quindi ospitare non solo gli edifici ma anche categorie infrastrutturali quali Ferrovie, Strade, Tunnel, Porti e Aeroporti, ecc. insieme a caratterizzazioni di suolo e sottosuolo. IFC come lo conosciamo oggi è solo una piccola parte dell’IFC di domani.
A seconda dell’uso possono essere istituite diverse relazioni. Per la gestione e manutenzione avremo bisogno di identificare non solo la posizione assoluta degli Oggetti ma anche la loro allocazione rispetto alle unità spaziali: non è sufficiente stabilire a che piano si trova un sensore antincendio, dovremo anche identificare la stanza in cui si trova per poterlo localizzare con esattezza e distinguerlo, a parità di caratteristiche, da tutti gli altri. Questa relazione prende il nome di IfcRelSpaceContainment ed è alla base della Model View Definition nota come Basic FM Handover.
Abbiamo già incontrato questa relazione nell’articolo precedente, parlando di oggetti quali i CurtainWall, le scale o i parapetti. In fase di esportazione IFC possiamo gestirli come un unico oggetto o mantenere la gerarchia.
Per l’analisi energetica è importante invece istituire una relazione topologica fra gli spazi e le sue superfici di confinamento, ovvero le facce interne dei muri che li delimitano. Questa relazione prende il nome di IfcSpaceBoundaries.
Le entità Oggetti non sono solo dei manufatti fisici, ma comprendono anche entità spaziali e altre entità astratte come processi e lavorazioni (ad esempio gli scavi), le risorse (ad esempio l’uso di macchinari di cantiere), gli attori (Architetto, Ingegnere), i tempi, ecc.
Detto che i software di modellazione sono basati sulla scomposizione in prodotti e non in lavorazioni come avviene normalmente in un computo metrico (non modelliamo i casseri dei cementi armati, ne stimiamo le superfici), non è possibile strutturare i modelli secondo la logica di scomposizione di una WBS. Possiamo però creare degli insiemi di elementi e legarli a una delle voci relative agli Assignment di cui prima.
Per operazioni particolarmente significative, il progettista può quindi predisporre delle relazioni che verranno poi gestite dal computista o dal Project Manager con gli strumenti più adatti allo scopo. In pratica gli IfcAssignment sono le categorie deputate alla connessione verso il 4, 5 e 6D: è possibile creare degli IfcGroup a cui assegniamo diverse proprietà e al suo interno delle relazioni a cui attribuiamo un tipo di relazione (Processo, Gruppo, Actors, ecc.).
Non tutte le informazioni che ci occorrono per la commessa BIM sono contenute all’interno del modello stesso: abbiamo necessità quindi di associare ai Building Elements dei riferimenti esterni, quali le voci di Classificazione, documenti, codifica COBie, link verso modelli multimediali, ecc. Queste relazioni fra le Entità del modello e la documentazione esterna prendono il nome di IfcRelAssociates e sono sviluppate per diversi scopi: usare le classificazione permette di fare riferimento a listini e database esterni con i quali condividono la codifica di identificazione; il COBIE predispone il modello per la gestione dell’Asset nel tempo, ecc.
La documentazione esterna, così come tutte le informazioni necessarie alla definizione di costi, misure, vincoli, ecc. vengono incorporate allo schema IFC come IfcResource. Le entità nel layer Risorse non sono entità autonome (non dispongono di un GUID) e non possono quindi sussistere indipendentemente e sono definite da Nome, Descrizione, Categorie, ecc.
In IFC i materiali sono considerati come risorsa e non come entità indipendenti, quindi è la IfcRelAssociatesMaterial a regolare il modo in cui i materiali vengono assegnati ai BuildingElements o ai BuildingElementType. In IFC 4 sono state apportate delle migliorie che permettono di associare e misurare non solo singoli materiali ma anche stratificazioni di materiali con la possibilità di leggerne quantità e proprietà.
All’inizio dell’articolo abbiamo detto che gli elementi sono strutturati attraverso le due relazioni fondamentali “fa parte di” (“part of”) e “è del tipo” (“type of”). IfcRelDecomposes indaga la natura delle relazioni fra un Building Element e le sue parti e viceversa: un muro è composto da strati, la staffa è parte di una capriata insieme alla catena, il monaco e puntone. La differenza con l’assegnazione a un gruppo è che la staffa senza gli altri sub-componenti non ha nessuna funzione in sé.
Sono sottotipi della categoria IfcRelDecomposes, l’IfcRelAggregates e l’IfcRelNesting.
L’utente è in grado di scomporre o meno il Building Element nei suoi sub-elementi costitutivi “esplodendo” la geometria e rendendo espliciti i dati di ogni strato; altrimenti, mantenendo inalterata la geometria è comunque possibile ricavare i loro dati come attributi di un elemento ancora unico . Scomporre le geometrie delle stratigrafie facilita molto il lavoro dei computisti che non devono così astrarre le quantità dello strato calcolandone il volume con formule del tipo “superficie muro per spessore strato” (metodo piuttosto impreciso se consideriamo tutti i nodi e le connessioni con altri muri e altri strati), ma possono valutare i volumi effettivi (o le superfici, perimetro, ecc) di ogni strato e di ogni componente.
Quest’ultima relazione definisce come le proprietà vengono assegnate agli elementi: queste possono essere di quattro tipi:
IfcRelDefinesByObject: definisce la relazione fra un oggetto parte di un insieme e il tutto. È una relazione “1 a molti” che definisce l’assegnazione di un set di proprietà condiviso fra le parti e l’insieme. Questa condivisione può avvenire solo fra elementi di uno stesso tipo, quindi nella scomposizione in parti (una stratigrafia) ma non nell’aggregazione di parti eterogenee (assemblaggio di elementi di una capriata).
IfcRelDefinesByProperties: definisce la relazione fra un set di Proprietà e gli oggetti. Questi possono essere attribuiti alla singola istanza di un oggetto, altrimenti possono essere attribuiti al tipo e da questi trasferiti alla singola istanza (istituendo la relazione byType del punto successivo). E’ una relazione “molti a molti” poiché a ogni Set di Proprietà possono essere attribuiti diversi oggetti e viceversa.
IfcRelDefinesByTemplate: istituisce la relazione fra un insieme di proprietà (IfcPropertySet) e le singole Proprietà (IfcProperty). È una relazione “1 a molti” perché ogni PropertySet Template può essere applicato a più Property Set ma ogni Property fa riferimento a un solo PropertySet.
IfcRelDefinesByType: definisce la relazione fra i PropertySet e il Tipo Oggetto. È una relazione “1 a molti” perché lo stesso PropertySet può essere applicato a uno o più tipi e da qui alle istanze che ne fanno parte.
E’ questa relazione a stabilire quali sono e con quali criteri vengono identificate le Proprietà condivise fra tutti i BuildingElements che costituiranno le categorie dei BuildingElementTypes come già visto durante il primo articolo della serie.
Nel prossimo articolo approfondiremo la definizione delle Geometrie in IFC: queste possono essere considerate parte integrante della definizione dei Building Elements ma ora, avendo già alcune nozioni circa le relazioni fra le parti e l’insieme, è più facile comprenderne la natura e l’uso.
Per una visione d'insieme, ecco i link a tutti gli articoli sul formato IFC: