Anche per questo esempio si è fatto riferimento alla struttura che IFC prevederà una volta rilasciata la candidate standard prevista con la versione 4.3. Tuttavia, questa impostazione non è attualmente implementabile da alcun software disponibile sul mercato, che richiedono ancora una strutturazione dell’organizzazione spaziale fortemente influenzata da quella prevista degli edifici civili.

Come elemento di partenza viene proposto un progetto, IfcProject, individuato in una specifica locazione attraverso la classe IfcSite. Allo stesso progetto, sono quindi associati due differenti elementi, da una parte la strada a cui verranno associate tutte le sue componenti non trattate in questo documento e relative alla classe IfcRoad, dall’altra il ponte oggetto di studio categorizzato secondo la classe IfcBridge. Dal momento che questo secondo caso studio è rappresentato da un ponte composito a travata in acciaio calcestruzzo, si è convenuto che l’enumerativo ad esso più adatto è rappresentato dal predefined type GIRDER, che raccoglie al suo interno tutti i ponti appartenenti alla tipologia a travata.

La versione 4.3 di IFC introduce una nuova procedura per la classificazione spaziale, introducendo la possibilità di scomporre l’asset secondo diverse direzioni attraverso l’attributo IfcFacilityUsageEnum, a seconda dell’uso e della scomposizione che si vuole effettuare per ottenere una migliore comprensione del progetto. La struttura spaziale di questo specifico caso viene strutturata secondo due differenti livelli, che fa uso di due diversi tipi enumerativi: viene quindi proposta a un livello superiore una scomposizione di tipo LATERAL per individuare rispettivamente la sovrastruttura e la sottostruttura del ponte attraverso [IfcBridgePartTypeEnum.SUPERSTRUCTURE] e [IfcBridgePartTypeEnum.SUBSTRUCTURE]. A livello inferiore, per la superstructure viene invece utilizzato l’enumerativo LONGITUDINAL per caratterizzare la campata del ponte, individuata con un nuovo enumerativo proposto in sede di studio e recante la dicitura SPAN. Questa scelta, seppur scelta non strettamente necessaria per questo specifico caso studio, è stata dettata dall’intento di generalizzare la scomposizione di questa tipologia di ponti, che può presentarsi anche composta da campate multiple. La parte di substructure invece fa nuovamente uso dell’enumerativo LATERAL per definire le componenti delle spalle, descritte con la classe IfcBridgePartTypeEnum [ABUTMENT]. Naturalmente, qualora un altro ponte fosse costituito da più campate, è stato già previsto l’utilizzo dell’enumerativo apposito PIER per classificare la pila di sostegno.

La corrispondenza tra le classi informative previste dallo standard IFC e la realtà fisica costituente il caso studio esame, descritta nell’introduzione, garantisce una corretta ed esaustiva rappresentazione di tale opera nel contesto più ampio dell’openBIM.

Quindi la logica alla base della decomposizione nelle varie componenti del viadotto in esame è stata fondata su alcuni principi base quali:

• definizione del caso d’uso del modello;
• coerenza con la struttura dati dello standard IFC.

 

In riferimento sempre allo standard IFC, dopo aver ragionato prima sulla definizione e la scelta della struttura spaziale più opportuna meglio rappresentativa dell’opera stessa, ogni componente del viadotto in esame è stata classificata definendo:

• l’opportuna classe rappresentativa e corrispondente (e.g. all’elemento trave fisica si fa corrispondere la classe IfcBeam e così via);
• lo specifico enumerativo di riferimento (e.g. per il concio di trave in acciaio ad esempio è stato associato, per la classe scelta IfcBeam, l’enumerativo specifico GIRDER_SEGMENT, ecc.);
• le relative relazioni tra le classi.

 

Come è possibile dedurre dunque, la mappatura avviene in accordo a due livelli distinti:

• uno superiore in riferimento alle classi;
• uno inferiore in riferimento invece agli enumerativi disponibili per queste classi;

come rappresentato a titolo di esempio nelle due figure seguenti.

Ovviamente il caso studio in esame ha richiesto l’analisi solo di alcune delle classi precedentemente mostrate e l’utilizzo di alcuni enumerativi presenti per le classi scelte.

Inoltre per alcuni elementi non è stata definita un’opportuna classificazione in quanto loro appartenevano:

• all’interfaccia tra la struttura del ponte e l’infrastruttura lineare;
• alle componenti della stessa infrastruttura (condotte di scolo, elementi di illuminazione, ecc.).

In questi casi, tali elementi sono stati assegnati a una struttura spaziale specifica e la classificazione degli oggetti è stata semplicemente rinviata a una seconda fase o a una classificazione integrata dello schema comune.

Coerentemente, quindi, con l’organizzazione spaziale definita per il caso in esame, l’attività di mapping delle diverse componenti costituenti il viadotto verso lo standard, è stata condotta analizzando la semantica propria e rappresentativa delle classi ed i predefined type ad esse associate.

Ciascuna componente inoltre è stata analizzata e quindi classificata tenendo in considerazione non solo la sua funzione strutturale, ma al contempo considerando anche le interazioni e le eventuali relazioni con gli altri elementi.

Pertanto con riferimento all’opera individuata nel suo contesto spaziale, in senso ascendente, dalla sottostruttura alla sovrastruttura individuata, si riporta di seguito qualche esempio che mostra la corrispondenza tra le componenti fisiche del ponte e le classi con i rispettivi enumerativi scelti. Partendo dalla sottostruttura, costituita dalle due tipologie di pile precedentemente descritte, è stata utilizzata per il gruppo di pali, relativo ad ogni fondazione di ciascuna spalla considerata, la classe ifcGroup. Essa rappresenta una raccolta di oggetti avente una specifica logica. Nel caso invece del singolo palo, costituente il gruppo, esso è stato mappato con la classe e specifico enumerativo IfcPile [BORED]. Per completare quindi la struttura di fondazione relativa si è deciso invece di considerare per il plinto in calcestruzzo armato la seguente classe e enumerativo IfcFooting [PILECAP].

La complessità costruttiva degli elementi in esame, in quanto insieme di componenti diverse, è stata invece interpretata per mezzo dell’utilizzo dell’assemblaggio di oggetti, IfcElementAssembly e i rispettivi PredefinedType. Nel caso in esame, per entrambe le spalle, si è deciso dunque di utilizzare tale assemblaggio con la selezione dell’enumerativo disponibile in riferimento proprio alle spalle di un ponte: IfcElementAssembly [ABUTMENT]. Questo assieme di elementi diversi e aggregati tra loro consente, in questo caso, di rappresentare al meglio, anche dal punto di vista relazionale tra le varie componenti costituenti, le spalle in esame.

Per quanto riguarda invece la struttura fuori terra delle spalle, essa è costituita da una serie di muri portanti in c.a. e altri invece a sostegno del riempimento circostante. Infatti per i primi sono state scelte le seguenti entities e PredefinedTypes associati quali IfcWall [SOLIDWALL]; mentre per i secondi, sia per il muro superiore che per i muri alari laterali, si è deciso per IfcWall [RETAININGWALL]. Proseguendo con l’operazione di mappatura delle spalle in esame, è stata trovata inoltre la corrispondenza tra la soletta di completamento, per la struttura scatolare afferente alla spalla relativa, con IfcSlab [FLOOR.] Per concludere, sono state mappate anche le seguenti componenti con le relative classi in aggiunta agli specifici enumerativi del caso per: soletta flottante con IfcSlab [APPROCHSLAB]; spinotto con IfcMechanicalFastner [DOWEL]; cuscinetto in neoprene con IfcCovering [MOLDING]; polistirolo con ifcCovering [MOLDING].

Menzione particolare è dedicata ai baggioli. Così come per i pali, essi, afferenti alla stessa spalla, sono stati raggruppati in un gruppo (IfcGroup). Essendo questi gli elementi strutturali sui quali vengono posizionati i dispositivi di appoggio, consentendo di gestire la pendenza desiderata per l’impalcato superiore, è stata considerata la classe IfcMember. Dalla documentazione HTML disponibile per lo standard IFC, si evince che essa può rappresentare un elemento strutturale di collegamento con orientamento non rilevante per la sua definizione e deve essere utilizzato se non può essere espresso più specificamente come IfcBeam o IfcColumn. Inoltre esso è dotato anche di una corrispettiva rappresentazione in un modello di analisi strutturale.

Nel caso in esame però, per tale classe (IfcMember), tra gli enumerativi a disposizione non ce n’era alcuno che potesse rappresentare al meglio l’esatta corrispondenza con la componente fisica presente. Pertanto si è deciso di utilizzare l’enumerativo USERDEFINED definendo la specifica PEDESTAL. A completamento, per le strutture di appoggio, la corrispondenza tra il dispositivo di appoggio utilizzato e la classe dello standard a disposizione con enumerativo relativo consiste in ifcBearing [ELASTOMERIC].

Figura 19 – Spalle del viadotto

Giungendo invece alla sovrastruttura, già descritta nei capitoli precedenti nella sua complessità ed eterogeneità dei materiali utilizzati, come già utilizzato per le spalle, sono stati logicamente considerati gruppi ed assiemi di oggetti.

In riferimento quindi all’unica campata di cui si compone il ponte e nello specifico alle strutture metalliche che costituiscono l’impalcato, è stato definito un assemblaggio di elementi sempre per mezzo di IfcElementAssembly [GIRDER]. Esso è comprensivo sia delle travi principali, assemblate per conci, che delle strutture controventate.

Figura 20 – Strutture metalliche d’impalcato

Per quanto riguarda le travi principali, ciascuna di esse è rappresentata da un assemblaggio di più conci IfcElementAssembly [GIRDER], quest’ultimi a loro volta classificabili come IfcBeam [GIRDERSEGMENT]. Oltre ai singoli conci vi è la presenza anche di altre componenti quali: saldature classificate come IfcFastener [WELD], irrigidimenti classificati come IfcPlate [STIFFENERPLATE], pioli saldati sui conci di trave classificati come IfcMechanicalFastener [STUDSHEARCONNECTOR], ecc.

Simile ragionamento vale per gli altri due assemblaggi individuati per la descrizione dei traversi reticolari a “K”, in campata, e traversi a parete piena, agli appoggi.  I primi ovviamente sono costituiti da elementi principali quali le aste metalliche classificate come IfcMember [BRACE] alle cui estremità sono presenti dei collegamenti bullonati costituiti sia da piatti di collegamento, classificati come IfcPlate [SHEET], che da bulloni, classificati come IfcMechanicalFastener [BOLT]. Nei secondi invece, in corrispondenza degli appoggi, gli elementi sono costituiti sempre da travi ad I, classificate come IfcBeam [GIRDERSEGMENT], con la presenza di collegamenti bullonati, precedentemente già classificati, che garantiscono il collegamento a monconi già saltati ai conci di trave principale.

A conclusione del mapping effettuato per la struttura d’impalcato, struttura mista acciaio-calcestruzzo articolata in un graticcio di travi appoggiate ad anima piena con traversi in campata e agli appoggi, si è individuato un ulteriore assemblaggio di elementi per rappresentare gli elementi strutturali posti al disopra del graticcio di travi. Nello specifico si fa riferimento alle lastre predalle prefabbricate tralicciate la cui sola parte di lastra in calcestruzzo è classificata come ifcSlab [USERDEFINED: PREDALLE], mentre i tralicci d’armatura come IfcReinforcingMesh. [USERDEFINED: TRALICCIO_PREDALLE], la soletta in c.a. classificata come IfcSlab [FLOOR] e i cordoli in c.a. classificati come IfcBeam [EDGEBEAM].

Figura 21 –  Impalcato in sezione composta acciaio-cls

Si è deciso inoltre di classificare anche alcuni elementi d’arredo, non propriamente strutturali quali il giunto di espansione come IfcDiscreteAccessory [JOINT] e le barriere laterali come IfcRailing [GUARDRAIL].

Figura 16 – Uno dei risultati ottenuti dalla Modellazione BIM del caso studio

Come è possibile comunque osservare, si è fatto riferimento all’opportunità di poter selezionare tra gli enumerativi disponibili, in riferimento alle classi scelte, l’opzione USERDEFINED.  Tale scelta è resa disponibile dallo standard IFC nel caso in cui non si trovi la giusta corrispondenza tra gli enumerativi disponibili e la realtà fisica da dover rappresentare. Pertanto tale opzione, in questi casi, è sempre disponibile qualora sussista il problema sopracitato. Infatti anche per il viadotto in esame, tale opzione è stata più volte adottata. Inoltre si è fatto anche riferimento a classi rappresentative di assemblaggi (IfcElementAssembly) oppure a gruppi di elementi (IfcGroup).

Autodesk Revit

Image	Problem	Solution
	Modelling techniques can affect the export results of IfcElementAssembly class.	It may be necessary to model elements belonging to an assembly (i.e. wall, pad footing, mat foundation) as individual components, avoiding nesting.
	Predalle reinforcing mesh modelling is not automatized.	It is however possible to create a suitable component for this element to satisfy IFC classification.
	Predefined structural connections could not cover some special cases.	It is however possible to create custom connections or modelling items as not combined elements.
	Tests performed revealed that elements connected through structural connections could not satisfy IfcElementAssembly class.	Further tests are required.
	Modelling techniques can affect the insertion of welds.	It is necessary to model structural elements using steel fabrication workflow of the software. Further tests are necessary.

 

Midas CIM

Image	Problem	Solution
	It is not yet possible to aggregate the single girder segments under one beam.	Grouping the components might be a solution, further testing is required.
	Bearing model is made up of different columns.	A fix for the software is on the way that will address bearing as its own.
	Modeling practice reflects to the exported Ifc class. The slab of the deck needed to be created as a beam due to its geometry.	Modeling the element properly can be very time consuming and is not always possible.

 

Tekla Structure

Image	Problem	Solution
	Footing modeling can be done using pad footing or slab feature	Using pad footing is required to create a custom profile if is not included in the one available. Using slab can be done more easily but does not fall into the right ifc classification. Tekla though allows to choose the ifc class for export. Nonetheless the properties remain associated to the methodology used to create the component.
	Footing model is built up of more sub object, so it can’t be export like a single object
	Curved element rebar: it’s difficult to place several group bars in this specific object.
	Many items can’t be easily to create, making the modeling hardworking.	Tekla tools are equivalent, then, every object will come classified properly.
	Placing properly the stiffeners by the application panel follow the z-axis model.	It was found the correct way to set the parameters in the application panel.
	Concrete element and steel assembly export according to the IFC4.3 classification.	In order to comply with the IFC4 spatial hierarchy, concrete pour units and steel assemblies shall be defined and named according to the ifctype of the element. Finally, in the IFC4 export window, “Pour” setting shall be selected.
	Color of the pour units and steel assemblies.	In order to diversify the pour unit and the steel element colors it is necessary to set a dedicated visualization filter, assigning color ranges to each part of the bridge. Finally, during the export procedure, it is necessary to select the newly created visualization filter in the “Object color” setting.
	Definition of the spatial hierarchy.	It’s necessary to use the Organizer tool: the Site, Building, Section and Floor levels shall be defined with the exact “ifc…” name. Finally, each assembly and pour unit shall be assigned to the relevant level using the Organizer dedicated option.
	Definition of level III and IV (ElementAssembly and ElementType) of the hierarchy.	Not found solution. In Tekla Structures it is only possible to define the levels corresponding to: Project, Site, Bridge, Part and SubPart.
	Export of the IFC model with the correct spatial Hierarchy.	During the export procedure, it is necessary to select “Spatial hierarchy from Organizer” setting.
	Geometric shape errors of pour units in the IFC exported model.	During the export procedure, it is necessary to set “ICF4precast view” Export Type.
	Steel rebar geometric errors: custom chair bars for foundation slabs.	Steel rebar model for chair bars shall be modelled with the dedicated tool “Chair Bar”.
	Steel rebar geometric errors: custom spiral rebars for foundation poles.	No solution found.
	Steel rebar geometric errors: custom stirrup bars.	No solution found.
	The “Predefined Type” parameter of the IFC assembly elements are NOTDEFINED. This parameter should contain the name of the relevant element assembly.	No solution found.