Model View Definition: cos’è l'MVD nel BIM e nell’openBIM IFC?
MVD è l’acronimo di Model View Definition, cioè uno standard che definisce (Definition) i dati utili a scambiare informazioni per uno specifico scopo (View) selezionando opportunamente tra tutte le informazioni che un modello IFC (Model) potrebbe contenere.
Per esempio per scambiare informazioni tra professionisti che si occupano del progetto architettonico di una costruzione si selezionano solo informazioni utili a questo scopo, solo uno specifico IFC dataset dall’intero IFC schema.
L’IFC è un ampio insieme di definizioni, relazioni e proprietà che fanno riferimento alle entità di un modello. Queste convenzioni definiscono cosa sia un muro (IfcWall) ma anche cosa sia un sensore (IfcSensor) e descrivono anche entità meno conosciute come IfcCondition, che determina lo stato di un elemento in un particolare momento temporale, oppure IfcMove, ossia un’attività che comporta lo spostamento di persone o gruppi con tutti gli equipaggiamenti da un posto all’altro, e ancora IfcPermit, ossia un documento che registri il permesso di effettuare azioni in posti o all’interno di beni dove vigono restrizioni.
Tutto ciò rende l’IFC molto più di una sintassi o di un formato file.
Tutti questi aspetti sono spesso troppi per essere implementati in un singolo software.
Ci sono differenti domini e workflow rappresentati all’interno del formato IFC che sono distanti dall’obiettivo per cui molti tool e piattaforme software vengono sviluppati. Perciò, non ha senso richiedere ai produttori di implementare l’intero schema di dati perché nessun singolo tool necessita di tutti i tipi di informazione che il formato IFC definisce.
Le Model View Definition sono state create per risolvere questa situazione. In generale, tutti sembrano essere d’accordo che una MVD è costituita da una opportuna selezione di entità dallo schema IFC. Negli anni c’è stata una piccola modifica nella definizione. È stato introdotto il termine use-case.
Oggi si legge come definizione la seguente:
"Scambio di dati standardizzato per uno specifico use-case"
Oggi solitamente si configurano 3 layer/livelli di informazioni:
- Lo schema IFC;
- La MVD, una parte dello schema IFC;
- I requisiti informativi dell’use case specifico, che di solito si traducono in parte della MVD implementata all’interno dei software.
Le MVD non sono solo una porzione dello schema IFC ma di solito presentano vincoli e requisiti aggiuntivi.
I requisiti informativi tendono ad essere una selezione di una MVD per assicurarsi che gli utenti possono importare ed esportare questo Exchange Information Requirement (EIR), ma di solito questi requisiti sono estesi con classificazioni aggiuntive e proprietà che vanno aldilà della MVD o addirittura dello schema IFC.
Model View Definition e workflow operativi: criticità
Aspettative degli utenti: stando alle correnti modalità di definizione delle MVD, si dovrebbe concretizzare un’approvazione formale per ogni use-case (MVD) che dura alcuni anni. Un processo di implementazione e certificazione dedicata per scambiare un file IFC senza garanzie di riuscire ad importarlo nel proprio software.
Exchange information requirement (EIR) dinamici: ci sono diversi esempi di EIR che definiscono entità dall’IFC senza tener conto delle MVD e aggiungono differenti requisiti per le classificazioni e le proprietà. La definizione della ISO 19650 per gli EIR è molto più dinamica ed è basata sui Project Information Requirement.
Oggi correntemente c’è un mix tra le MVD formalmente definite, e quelle dinamicamente definite all’interno degli EIR. Le MVD non sembrano essere la soluzione più sostenibile rispetto alle richieste di mercato.
Interoperabilità: l’IFC è più di un formato di scambio tra software, e con l’incremento di Digital Twins e soluzioni CDE disponibili sul mercato è difficile l’implementazione di tanti subset del formato IFC. C’è il rischio di aggiunte su misura in uno o due MVD specifiche che diventerebbero non più interoperabili.
Workflow operativo: inoltre nell’immaginario collettivo, il processo di definizione, produzione, verifica ed aggiornamento degli Information Requirement coinvolge differenti stakeholder che utilizzano differenti strumenti e producono diversi deliverable per comunicare tra loro:
- Definizione: il cliente crea i requisiti informativi, più o meno aderenti allo standard IFC o al concetto di MVD, come allegato ad un Capitolato Informativo. Il deliverable prodotto è solitamente un documento non “Machine readable”.
- Produzione: il fornitore deve interpretare quanto richiesto dal cliente, valutare se esistono soluzioni di mercato che gli consentono di rispondere all’esigenza e modellare la struttura informativa all’interno di un BIM Authoring prima di valorizzarla. Il deliverable prodotto è un modello IFC che non risponde ad una MVD specifica, o in altri scenari, un modello IFC con l’aggiunta di ulteriori informazioni collegate al modello.
- Verifica: il cliente, o chi per lui, deve verificare il deliverable prodotto dal fornitore, implementando in una soluzione di “Model checking” i rule set che rendano i suoi Information Requirement “Machine Readable”.
- Aggiornamento: la manutenzione e l’aggiornamento degli Information Requirement, adottando un workflow operativo di questo tipo, prevede la necessità di reiterare il processo senza la possibilità di standardizzarlo.
Come superare le MVD con il nuovo standard IDS di bSI (buildingSMART International)
buildingSMART ha oggi introdotto il concetto di Information Delivery Specification (IDS) per rispondere più efficacemente alle esigenze che si è tentato di affrontare con MVD.
L’IDS rappresenta lo standard da utilizzare per definire il proprio Level Of Information Need o LOIN così come previsto dalla norma UNI EN 17412-1.
L’IDS consente la validazione dell’IFC da parte del cliente, abilita la possibilità da parte del gruppo di fornitura di condurre analisi automatiche sui modelli da produrre mediante appositi BIM Tool.
L’IDS rappresenta la soluzione per instaurare workflow di scambio dati prevedibili ed affidabili e rispondere a tutte le esigenze che si possono generare nella definizione di un Capitolato informativo, di un EIR e di tutto il processo di gestione dei dati che ne consegue.
Per creare un ids puoi usare il software usBIM.ids di ACCA. Il software si compone di tre BIM tool differenti:
- IDS creator per creare il documento IDS con le specifiche informative richieste
- IDS modeller per editare in maniera guidata le specifiche richieste
- IDS validator per validare i dataset consegnati tramite formato standard IDS
Il software permette di gestire tutto il processo di creazione, compilazione e validazione della richiesta informativa (EIR). In un processo tipo la richiesta informativa formulata in un capitolato informativo potrebbe:
- partire dalla creazione di un IDS specifico per la commessa;
- distribuire tramite piattaforma cloud;
- validare la consegna informativa con servizio della piattaforma in cloud.
Il processo informativo di creazione del modello BIM viene completamente supportato dal software con evidenti vantaggi di comunicazione, di coordinamento e di qualità del risultato atteso.