Digital twin e BIM

Cos'è l'IFC e perché è importante per lo scambio di dati?

Specifica ogni scambio IFC per scopo, verificalo con IDS e testalo in anticipo con il software che lo riceverà.

Scena concettuale di interoperabilità con elementi edificio scambiati tra postazioni diverse.
In questa pagina
  1. Cosa copre lo schema
  2. Restringere uno standard molto ampio
  3. Spiega a cosa serve ogni scambio
  4. Testare con il sistema che lo riceverà
  5. Applicazione pratica
  6. L'apertura deve essere scritta negli incarichi
  7. Fonti

IFC, abbreviazione di Industry Foundation Classes, è lo schema di dati aperti per lo scambio di informazioni BIM (Building Information Modeling) tra applicazioni software. È gestito da buildingSMART International, che lo descrive come indipendente dal fornitore, ed è pubblicato come standard ISO. L’edizione attuale, ISO 16739-1:2024, ha sostituito l’edizione del 2018 e ha esteso la copertura alle infrastrutture come ponti, strade, ferrovie e porti; Il repository di buildingSMART identifica l'edizione ISO con la versione IFC 4.3.2.0.

La sua importanza deriva dal modo in cui gli edifici sono realizzati e gestiti. Le informazioni di un edificio vengono prodotte in molte applicazioni, dalla progettazione architettonica, strutturale e dei servizi edilizi alla gestione dei costi, della programmazione e delle strutture, e passano tra molte organizzazioni nel corso di decenni. Uno schema aperto e pubblicato consente lo scambio e la lettura di tali informazioni senza dipendere dal formato file di alcun fornitore.

Un file IFC, tuttavia, non è una prova di interoperabilità. Ciò che conta è se l'informazione giusta, per uno scopo definito, arriva intatta al sistema ricevente.

Cosa copre lo schema

L'abstract dell'ISO descrive l'IFC come uno standard internazionale aperto per le informazioni BIM scambiate e condivise tra i software utilizzati dai partecipanti alla costruzione e alla gestione delle strutture, con definizioni che coprono edifici e infrastrutture durante il loro ciclo di vita. Include uno schema di dati, definizioni di proprietà e quantità e un formato di file di scambio. Il suo ambito spazia dalla struttura del progetto, dai componenti fisici e spaziali e dagli elementi di analisi attraverso processi, risorse, controlli, attori e contesto, attraverso le fasi del ciclo di vita fino al funzionamento e alla manutenzione, e per discipline tra cui i servizi impiantistici dell'edificio e la gestione delle strutture.

Restringere uno standard molto ampio

Poiché l’IFC è così ampio, nessun singolo scambio lo utilizza tutto ed esistono due meccanismi per restringere il campo.

Le definizioni della vista del modello (MVD) definiscono quale sottoinsieme di IFC un'applicazione software implementa per un particolare tipo di scambio. L'abstract dell'ISO rileva che il software conforme deve identificare la MVD a cui è conforme quando richiede la certificazione.

L'Information Delivery Specifica (IDS) è uno standard buildingSMART per specificare i requisiti informativi e verificare i modelli IFC rispetto ad essi. Un file IDS contiene specifiche leggibili dalla macchina, come "tutti i terminali dell'aria devono avere un identificatore di manutenzione e un codice di classificazione", ciascuno con una parte di applicabilità e una parte di requisiti. Gli autori del modello possono controllare il proprio lavoro prima della consegna e i destinatari possono controllare cosa arriva.

Per un proprietario, IDS trasforma "fornire IFC" in "fornire IFC che supera questi controlli", che è molto più facile da accettare o rifiutare.

Spiega a cosa serve ogni scambio

Il coordinamento tra i progettisti, il computo delle quantità e le informazioni sulle risorse operative necessitano ciascuno di contenuti diversi, quindi "IFC" da solo non è mai un requisito sufficiente. Ciascuno scambio dovrebbe indicare la versione IFC e, ove rilevante, la MVD; gli oggetti, gli identificatori, le classificazioni e le proprietà richieste; le unità ed i valori ammessi; come vengono referenziati i documenti; e come verrà verificata la conformità, idealmente con un file IDS rilasciato insieme ai requisiti.

Testare con il sistema che lo riceverà

Gli oggetti rappresentativi dovrebbero essere esportati nelle prime fasi del progetto e importati nell'applicazione ricevente stessa (CAFM, CMMS o piattaforma dati) anziché verificati in un visualizzatore di modelli di modelli. Il test verifica gli identificatori, le proprietà, le unità, le relazioni, i collegamenti dei documenti e la geometria laddove rilevante, e vengono registrate eventuali limitazioni note e soluzioni alternative concordate.

IFC supporta il trasferimento, non la sincronizzazione. Una volta scambiate le informazioni, un processo separato deve decidere quale sistema è autorevole e come fluiscono gli aggiornamenti.

Applicazione pratica

L'apertura deve essere scritta negli incarichi

Uno standard aperto aiuta solo quando gli scambi richiesti, il metodo di validazione e le responsabilità sono scritti nelle nomine. Scrivili, quindi dimostrali con uno scambio di prova nei sistemi che riceveranno effettivamente i dati.

Fonti

Questo articolo si collega al nostro lavoro su Digital twin.

Articoli correlati

Servizio collegato

Digital twin

Possiamo discutere come questo tema entra nel brief del progetto.

Contatta Pagin Consulting