La struttura spaziale dell’infrastruttura è stata organizzata utilizzando tutti i livelli di scomposizione che lo standard IFC ammette. Come è noto, la nuova impostazione offerta in ambito infrastrutturale non è attualmente attualizzabile con gli strumenti BIM di comune utilizzo. I file IFC4 qui distribuiti si avvicinano a questa quanto più possibile, mantenendo ad esempio elementi tipici del sistema edilizio quali IfcBuilding. Di seguito viene comunque presentata l’impostazione secondo il candidate standard 4.3: il lettore potrà allo stesso tempo comprendere la nuova trattazione e confrontare la sua concretizzazione nel proprio strumento di BIM authoring.

Viene proposto un progetto iniziale, IfcProject, localizzato su una specifica area, IfcSite. Afferenti allo stesso progetto e sito si hanno poi due distinti asset, ovvero la tratta di ferrovia che passa sopra il ponte, IfcRailway, e la struttura del ponte, IfcBridge. Trattandosi di un ponte ad arco in muratura l’enumerativo che meglio lo descrive è ARCHED, nonostante questo rappresenti tutte le tipologie costruttive di ponti ad arco, compresi quelli in calcestruzzo e in acciaio.

La struttura spaziale relativamente ai tipi di parti di ponte in muratura è organizzata poi su più livelli: IfcFacility è costituita infatti da IfcFacilityPart che determinano una struttura aggregata la cui distinzione semantica è operata dalla scelta degli enumerativi. Essi ne descrivono il punto di vista dal quale si sta operando la scomposizione e la descrizione semantica. Nel caso specifico sia il primo che il secondo livello di scomposizione per quanto riguarda il punto di vista, IfcFacilityUsageEnum, sono operati secondo una vista di prospetto, LATERAL, grazie a questa uniformità, verranno quindi di seguito elencati solamente gli enumerativi scelti relativamente al IfcFacilityPartTypeSelect, che sono tutti riconduci all’elenco di enumerativi propri dei ponti, IfcBridgePartTypeEnum. Il primo livello di scomposizione è operato ed è costituito da sottostruttura, SUBSTRUCTURE, sovrastruttura, SUPERSTRUCTURE, e la parte finale di sostegno all’infrastruttura lineare, DECK, ciascuna di esse è poi scomposta a un livello inferiore in ulteriori IfcFacilityPart. La sottostruttura è quindi organizzata ulteriormente in due spalle, ifcFacilityPart [IfcBridgePartTypeEnum.ABUTMENT]. due pile IfcFacilityPart [IfcBridgePartTypeEnum.PIER] e due pile spalle [IfcBridgePartTypeEnum.USERDEFINED: PIER_ABUTMENT], esse, come si evince, non hanno un enumerativo già esplicitato dallo standard, ma considerandone l’importanza e il comportamento nelle diverse fasi esso è stato personalizzato, invece di utilizzare PIER. Il secondo livello di decomposizione per la superstructure e il deck ha tenuto conto del caso d’uso, ovvero la gestione di un ponte esistente e quindi l’impiego del modello per la descrizione dello stato di conservazione, per questo motivo è stato necessario introdurre un nuovo enumerativo SPAN per individuare la campata del ponte, essa infatti risulta essere l’unità chiave con cui i gestori localizzano i danni nella struttura.

La mappatura degli oggetti in muratura segue una logica molto particolare nelle buone pratiche di classificazione di ponti in IFC, dovuta alle loro caratteristiche intrinseche geometriche e alle tecniche costruttive legate al materiale. La conformazione geometrica e funzionale permette infatti di ricondurre gli elementi costruttivi alle classi appartenenti all’edilizia: più elementi del ponte sono infatti simili agli edifici in muratura, si trovano quindi in letteratura numerosi esempi della loro classificazione in IFC. Tuttavia, una volta contestualizzati in ambito infrastrutturale, il significato costruttivo dei medesimi elementi si modifica ed è per questo che alcune definizioni presenti nello standard collidono con l’interpretazione e il senso comune che vengono date a livello infrastrutturale.

Ciascun componente è stato classificato tenendo in considerazione non solo il suo significato strutturale, ma anche la sua funzione a livello globale nel ponte e le relazioni con gli altri elementi.

A partire dalla sottostruttura sono state facilmente identificate le spalle e le pile che sono esplicitati tra gli enumerativi di IfcElementAssembly. A meno di poche differenze, vi è uno schema comune tra gli elementi di sostegno appartenenti alla sottostruttura – pila, spalla, pila-spalla – si tratta infatti di un aggregato, IfcElementAssembly, di altre componenti tra cui ritroviamo la base di fondazione, IfcSlab [BASESLAB], muri esterni di sostegno, IfcWall, i cui enumerativi sono SOLIDWALL oppure RETAININGWALL, a seconda che il muro abbia anche funzione di sostegno del terreno retrostante. Per quanto riguarda invece la pila-spalla non vi è alcun tipo enumerativo specifico, si è scelto quindi IfcElementAssembly [USERDEFINED: PIER_ABUTMENT]. Una delle criticità maggiori è rappresentata dalla definizione semantica del riempimento strutturale interno, che non ha una sua definizione specifica tra le classi di buildingSMART. È stato perciò scelto di esportarlo come classe IfcWall specificando un enumerativo [USERDEFINED: FILLING]. Altre componenti secondarie sono la cornice di imposta definita come IfcBeam la cui specifica di enumerativo CORNICE è indispensabile per distinguerne anche nel nome la natura non strutturale, e le coperture a cappuccio identificate come IfcCovering con enumerativo COPING.

Gli elementi della sovrastruttura hanno richiesto delle riflessioni puntuali circa la loro classificazione poiché, come già detto, si tratta di geometrie complesse il cui significato strutturale assunto tipicamente per un ponte è in contrasto con le definizioni che ritroviamo nella documentazione HTML di IFC. Questo è il caso delle volte di sostegno, che in un ponte perdono il loro ruolo di copertura di un vano, tipico delle volte delle opere civili, a favore di quello portante degli elementi sovrastanti. Per rendere chiara questa caratteristica la classe è stata ricondotta a IfcSlab, con un enumerativo peculiare ovvero [USERDEFINED: VAULT]. Altri elementi di ciascuna campata della sovrastruttura sono gli archi di testata indicati come IfcBeam enumerativo personalizzato in ARCH, i timpani che sono facilmente individuabili nella classe IfcWall come SOLIDWALL. Sul prospetto di valle sono inoltre presenti dei contrafforti identificati come IfcColumn enumerativo PILASTER. Tale elemento va inteso come un aggregato di altri componenti quali murature di sostegno, IfcWall [SOLIDWALL], il riempimento centrale IfcColumn [PILASTER] e la cornice di finitura IfcBeam [CORNICE]. Gli elementi rimanenti, ovvero quelli che costituiscono la parte centrale del ponte, rinfianco, cappa e riempimento, sono stati definiti come IfcWall enumerativo personalizzato in [USERDEFINED: HAUNCHING] e per il riempimento, trattandosi di materiale sciolto è stato classificato come IfcEartworksFill [TRANSITIONSECTION].

Per la parte dell’impalcato del ponte che non afferisce strettamente alla infrastruttura ferroviaria superiore sono stati identificati gli elementi di protezione alla caduta, per i quali sono stati utilizzati IfcRailing [GUARDRAIL] e IfcWall [PARAPET], la parte strettamente strutturale che costituisce l’impalcato è stata poi definita come un IfcElementAssembly [DECK] costituito da cordoli di bordo, IfcBeam [EDGEBEAM], marciapiedi laterali e orizzontamenti, rispettivamente IfcSlab [SIDEWALK] e IfcSlab [FLOOR].

Le problematiche specifiche riscontrate per il ponte in muratura ad arco esistente sono riconducibili a tre differenti ambiti: il primo riguarda la ricerca della corretta combinazione tra l’elemento costruttivo reale e la corrispettiva classe ed enumerativo secondo lo standard, il secondo è relativo alla comprensione e alla declinazione dei sistemi per il management degli asset già in essere presso i gestori, e il terzo relativo alla riproduzione della struttura gerarchica individuata in IFC nel software impiegato (Autodesk Revit) e quindi una corretta esportazione finale. Non è sempre evidente come una problematica rientri nell’una o nell’altra questione, anzi molto spesso le difficoltà riscontrate sono state trasversali.

Per quanto riguarda il primo ambito la maggior parte delle problematiche individuate era relativo agli elementi geometrici complessi esclusivi dei ponti in muratura quali ad esempio rinfianco e cappa. Essi per la loro unicità di significato strutturale e rappresentazione geometrica dovrebbero essere riconducibili a una classe specifica, questa soluzione è pero inapplicabile da un punto di vista di standardizzazione dell’informazione. È stato quindi necessario operare una scelta di classificazione tenendo in considerazione non solo le caratteristiche degli elementi ma soprattutto l’uso agile del modello e la sua efficace interrogabilità. Ciò significa che sono stati utilizzati delle classi come IfcWall per coerenza di definizione, ma optando per un enumerativo personalizzato al fine di garantire l’unicità dell’informazione. In altri casi, invece, il problema è molto più evidente in quanto ha le sue radici già nelle prime classificazioni in ambito edilizio, ed è il caso questo di volte ed archi, questi due elementi infatti come nel caso precedente hanno una loro identità geometrica che determina il comportamento strutturale. Inoltre le volte in un ponte non diventano più degli elementi di chiusura di un ambiente, ma anzi in contrapposizione diventano sostegno di ciò che è presente al di sopra. Anche in questo caso quindi prediligendo prima la definizione della classe, la possibilità poi di personalizzare la struttura del modello è stata demandata alla scelta degli enumerativi.

Trattandosi di un ponte ferroviario, le principali problematiche relative ai sistemi di gestione del ponte sono riconducibili alla comprensione della struttura di DOMUS (software di gestione in uso dal gestore) e successive scelte della sua integrazione nell’organizzazione spaziale dello standard. Come anticipato, fin dall’inizio, l’approccio è legato all’armonizzazione tra modello BIM e sistema gestionale esistente nell’ottica di operazioni di interrogazione del database.

Analizzando il metodo di strutturazione dei dati del sistema DOMUS, la cui struttura poco si allinea con modelli digitali informativi IFC-based, la soluzione scelta per ovviare alle problematiche di integrazione è stata quella di non seguire l’organizzazione dello stato di degrado per ‘campi’, ma basarsi sull’organizzazione spaziale di IFC integrandola in itinere con il candidate standard IFC4.3 RC1.

La terza questione ha visto l’approccio alla scomposizione spaziale e degli oggetti dell’infrastruttura e applicazione dello standard IFC alla categorizzazione degli oggetti nel software di authoring. L’impostazione della modellazione condivisa in ambiente Revit ha sollevato alcune criticità rispetto la creazione di alcuni elementi, la loro corretta esportazione in IFC e la visualizzazione delle relazioni che intercorrono tra gli elementi del modello esportato. In particolare è emerso come molte procedure geometriche di creazione degli oggetti siano legate alla scelta della categoria. Risulta così ad esempio più semplice modellare una volta con il comando ‘tetto’, la cui classe di esportazione di default sarebbe IfcRoof. Ne consegue una necessaria personalizzazione in fase di produzione del modello IFC, che non sempre viene evasa dal software. Inoltre la pratica comune, che vede la creazione di famiglie complesse dal punto di vista delle componenti e dei parametri inseriti (ne sono un esempio le pile), comporta una errata semantizzazione in fase di export dei singoli elementi in essa contenuti: muri, riempimento interno, cornici, ecc. e della perdita della relazione di aggregazione tra questi stessi elementi. La perdita di questo sistema di relazioni non permette alcuni possibili automatismi in fase di definizione dello stato conservativo dell’elemento aggregato.

La necessaria soluzione di queste problematiche è stata parte stessa del processo di ricerca. In più casi si è determinate una strategia di modellazione specifica per rappresentare certi elementi così come un editing puntuale dei parametri necessari alla loro corretta esportazione in IFC.