Interoperabilità: IFC come “lingua franca”

Premesse

Abbiamo già visto nei post dell’anno scorso, come lo schema IFC sia tecnicamente progettato per essere neutro rispetto ai singoli software di modellazione. Quest’anno, con più progetti che iniziano a richiedere scambi reali tra attori diversi – complice la spinta normativa che stiamo seguendo in questi mesi – emerge con più chiarezza un limite pratico che la sola disponibilità dello standard non risolve: esportare in IFC non equivale automaticamente a ottenere un modello davvero riutilizzabile da chi lo riceve. Vale la pena capire perché.

Perché un’esportazione IFC tecnicamente valida può comunque essere inutile a chi la riceve?

Un file IFC può essere sintatticamente corretto – rispettare lo schema EXPRESS, aprirsi senza errori in un software di verifica – e allo stesso tempo essere semanticamente povero: oggetti esportati con il tipo IFC generico invece che con quello specifico più corretto, proprietà lasciate vuote o popolate con valori segnaposto, relazioni gerarchiche tra spazi e componenti non ricostruite correttamente. La validità tecnica del file e la sua utilità pratica per chi lo riceve sono due cose diverse, e la seconda dipende da scelte di modellazione fatte molto prima del momento dell’esportazione.

Che ruolo hanno le mappature tra classificazione interna e schema IFC?

Un modello che usa internamente una classificazione proprietaria – le proprie categorie di prodotto, la propria nomenclatura interna – deve essere mappato esplicitamente sulle strutture dello schema IFC perché lo scambio sia davvero utile: un oggetto classificato internamente come “serramento esterno tipo A” deve essere esportato con il tipo IFC corretto e con le proprietà nei campi standard, non lasciato nel formato interno con un tipo IFC generico di ripiego. Senza questa mappatura esplicita, definita e verificata prima dell’esportazione, il destinatario del file riceve un modello che sembra strutturato ma che, alla prova dei fatti, richiede una riclassificazione manuale praticamente completa.

Perché le regole di modellazione condivise contano più del software usato?

Due team che usano lo stesso software possono produrre esportazioni IFC di qualità molto diversa, a seconda di quanto seguano regole di modellazione condivise: come vengono nominati gli oggetti, quali proprietà vengono popolate sistematicamente e quali lasciate vuote, come viene gestita la gerarchia spaziale. Viceversa, due team che usano software diversi ma seguono le stesse regole di modellazione concordate nel BEP possono produrre esportazioni molto più compatibili tra loro di quanto farebbero usando lo stesso software senza alcuna regola condivisa. È la conferma di un principio che questa serie ha già toccato più volte: la tecnologia da sola non basta senza la disciplina organizzativa che la accompagna.

Come si verifica, in pratica, che uno scambio IFC abbia prodotto un risultato utilizzabile?

I team più maturi non si limitano a esportare e sperare: verificano il file IFC prodotto con strumenti dedicati che controllano la presenza delle proprietà attese, la correttezza dei tipi assegnati agli oggetti, la coerenza della gerarchia spaziale, prima di considerare lo scambio completato. Questa verifica, se fatta sistematicamente e non solo a campione, permette di individuare e correggere i problemi di mappatura prima che il file venga consegnato al destinatario, invece di scoprirli solo quando qualcuno prova a usarlo per uno scopo specifico e si accorge che mancano informazioni essenziali.

Perché il costo di una cattiva interoperabilità si scarica quasi sempre a valle, sul destinatario del file?

Chi esporta un modello mal mappato in IFC non subisce direttamente le conseguenze del proprio lavoro incompleto: il file “funziona” nel senso che si apre correttamente, e il problema emerge solo quando qualcun altro, più avanti nella filiera, prova a usarlo per un computo, per un’integrazione con un altro sistema, o per costruire un registro asset. Questa asimmetria – chi genera il problema non ne paga il costo diretto – è uno dei motivi strutturali per cui l’interoperabilità di qualità resta, nel 2016, un’eccezione praticata solo da chi ha un incentivo diretto a farlo bene, non una prassi diffusa lungo tutta la filiera.

Che effetto ha, per il Facility Management, ricevere un modello IFC tecnicamente valido ma semanticamente povero?

Il FM è, per definizione, l’ultimo anello della filiera a ricevere il modello – spesso anni dopo la sua produzione originaria – ed è quindi chi subisce più direttamente questa asimmetria: un modello che sembrava sufficiente al progettista che lo ha esportato può rivelarsi, alla prova dei fatti, privo delle proprietà essenziali per costruire un registro asset affidabile.

Conclusioni

L’interoperabilità basata su IFC oggi è tecnicamente matura, ma la sua efficacia pratica dipende da un lavoro di disciplina – mappature esplicite, regole di modellazione condivise, verifica sistematica – che la maggior parte dei progetti non applica ancora in modo rigoroso. È un tema che questa serie riprenderà con forza quando, negli anni successivi, l’obbligo normativo comincerà a imporre requisiti di interoperabilità più stringenti e verificabili.

Se vuoi un supporto qualificato sull’argomento puoi contattarmi qui