Una “Definizione della vista di un modello” (MVD) è un sottoinsieme dello schema IFC complessivo che descrive lo scambio di dati per un uso o flusso di lavoro specifico, restringendo l’ambito a seconda delle necessità del destinatario. Il metodo utilizzato da buildingSMART per definire tali requisiti di scambio è il “Manuale di consegna delle informazioni” (IDM) (anche ISO 29481).
Che cos’è un MVD?
In generale, un MVD, o “Definizione della vista di un modello”, è un sottoinsieme dello schema IFC che definisce uno scambio di dati per un uso o flusso di lavoro specifico. I MVD possono essere ampi quanto quasi l’intero schema (ad es. Per l’archiviazione di un progetto) o specifici come una coppia di tipi di oggetti e dati associati (ad es. Per la determinazione del prezzo di una parete continua). Documentare un MVD consente di ripetere lo scambio su vari progetti e piattaforme software, fornendo coerenza e prevedibilità.
Per supportare l’interoperabilità BIM tra centinaia di applicazioni software, settori industriali e regioni in tutto il mondo, lo schema IFC è progettato per adattarsi a diverse configurazioni e livelli di dettaglio. Ad esempio, un muro può essere rappresentato:
- come un segmento di linea (o curva) tra due punti;
- come uno dei molti tipi di geometria 3D per la visualizzazione e l’analisi (come solidi estrusi o superfici triangolate);
- come forme semplici o con dettagli costruttivi specifici (per esempio di singoli perni, tubi, cablaggi, ecc.) …
- … insieme a dati come proprietà ingegneristiche, personale responsabile, informazioni sui costi e la pianificazione dei lavori.
Ma non tutti gli esperti di dominio nei processi di progettazione, approvvigionamento, fabbricazione e manutenzione di un progetto necessitano delle stesse informazioni da fornire o ricevere. Un MVD restringerà tale ampio ambito a seconda della necessità del destinatario delle informazioni per un flusso di lavoro specifico.
Poiché IFC è uno schema indipendente dal fornitore software, gli MVD sono incentrati sui dati anziché sulle applicazioni. Ciò significa che sono i requisiti del flusso di lavoro e di scambio di informazioni con l’utente finale che determinano l’estensione e la forma della vista del modello, e non dipendono da specifiche capacità o limiti dei software disponibili sul mercato. Tuttavia, le specifiche di un MVD dovrebbero influenzare la capacità o esigenze dei software.
Esempio 1
Un architetto sta inviando al cliente un modello da inserire in un modello di contesto urbano più ampio, consentendo al cliente di visualizzare il progetto, non è necessario che l’architetto invii tutti i dati delle complesse operazioni di modellazione (ad es. CSG) e tutti gli attributi degli oggetti, ma può inviare un modello di geometria basato su superfici con una semplice mappatura di colori o texture.
Esempio 2
I produttori di prefabbricati definiscono come ricevere i dati IFC. Definiscono l’uso degli assiemi e la necessità di avere una geometria precisa rappresentata con i BREP. Inoltre, definiscono quali proprietà devono avere gli elementi Precast. Questo è un esempio di MVD IFC4Precast.
Come vengono utilizzati gli MVD?
Le parti interessate in un progetto (architetti, ingegneri strutturali, ingegneri degli impianti, imprese di costruzione, gestori di strutture, ecc.) hanno diverse responsabilità, competenze ed esigenze nella creazione e nell’uso dei dati di costruzione. In definitiva, devono condividere tali informazioni con gli altri operatori coinvolti nel ciclo di vita del progetto per svolgere diverse attività. Pertanto, è necessario chiarire quale sottoinsieme di tutti i dati è necessario scambiare per un uso particolare. Tali sottoinsiemi di dati possono essere definiti analizzando lo schema IFC complessivo in “viste di modello” più piccole, in cui vengono specificati i requisiti informativi necessari all’utente finale. I capitolati di progetto dovrebbero fare riferimento a queste specifiche di scambio per definire la consegna dei dati tra le parti. Un MVD descriverà quali oggetti, rappresentazioni, relazioni, concetti e attributi sono necessari affinché i riceventi possano svolgere l’attività desiderata con la loro applicazione software.
Esempi di MVD includono:
- Architectural Design to Structural Design (Dalla progettazione architettonica alla progettazione strutturale) – in cui l’architetto fornisce all’ingegnere strutturale uno “sfondo” di modello a cui può fare riferimento per il posizionamento e la progettazione di elementi strutturali.
- Architectural Design to Quantity Takeoff (Dalla progettazione architettonica al calcolo delle quantità) – in cui l’architetto fornisce all’impresa costruttrice un modello con un accurato posizionamento degli elementi utile all’estrazione di quantità e l’assegnazione di costo.
- Building Envelope Design to Energy Analysis – dove un architetto o un progettista / ingegnere che ha definito le caratteristiche dell’involucro dell’edificio fornisce al consulente energetico un modello con i tipi di materiali da costruzione con i valori termici specifici, nonché i valori di comfort termico per gli spazi interni per determinare le prestazioni dell’edificio.
- Construction Operations Building Information Exchange (COBie) (Scambio di informazioni dalla costruzione all’uso) – in cui un impresa di costruzione fornisce i dati al proprietario e al responsabile della struttura per la fase di utilizzo dell’opera.
Sebbene gli MVD possano essere utilizzati per richiedere l’inclusione di dati particolari, non possono da soli garantire che i dati siano corretti o coerenti. I dati esportati dalle applicazioni dovrebbero essere verificati e validati per poter gara
Gli MVD oggi
Per molto tempo, ognuno ha potuto creare il proprio MVD e rivolgersi ai fornitori di software per implementarlo. Ciò ha creato una situazione in cui molti degli MVD creati non sono interoperabili tra loro e richiedono ulteriori sforzi per l’implementazione negli strumenti software. Un software che supporta l’esempio 1 (Reference View) non può automaticamente supportare l’esempio 2 (Precast). Gli strumenti software devono aggiornare ed estendere il loro codice per supportare più MVD.
Se in passato le MVD sono state una buona soluzione per affrontare i limiti della tecnologia, nel mercato attuale gli utenti e i fornitori di software si aspettano un approccio diverso. Pertanto IFC 4.3.x avrà alcuni MVD di base definiti da buildingSMART come riferimento per diversi casi d’uso. Questo aumenterà l’interoperabilità tra i domini.
Lo standard IDS lavora fianco a fianco con IFC per poter definire requisiti di scambio interpretabili al computer per ogni caso d’uso.
Gli MVD nel prossimo futuro
In IFC5, questa limitazione sarà ulteriormente incrementata per garantire l’interoperabilità tra diversi domini e implementazioni software di IFC. IFC5 sarà modulare con una base condivisa che ha un numero limitato di livelli di implementazione (simile alle 3 MVD di base in IFC 4.3.x). La definizione dei requisiti di scambio sarà effettuata utilizzando le Information Delivery Specifications (IDS). Per ulteriori informazioni, consultare la pagina della tabella di marcia tecnica.
ntire un corretto utilizzo in altri strumenti e servizi BIM.
Chi supporta gli MVD?
Tutte le applicazioni software che supportano l’esportazione di dati BIM tramite IFC hanno un qualche tipo di MVD supportato. In genere, uno strumento di modellazione BIM avrà, nella sua interfaccia utente, un elenco di possibili MVD per l’esportazione in IFC. A seconda del tipo di strumento BIM, il MVD supportato differirà in base al dominio di utilizzo dell’applicazione.
Sviluppando e supportando l’implementazione di un MVD, le parti interessate standardizzano un flusso di informazioni, quindi questi scambi possono avvenire senza discussioni reiterative su cosa e come è ogni volta necessario scambiare. Gli scambi di informazioni possono quindi avvenire più frequentemente e coerentemente, con poco intervento.
Come partecipare?
L’ecosistema buildingSMART per gli utenti finali è costituito da IFC, IDS e bSDD. La creazione di MVD è lasciata ai modellatori di dati e ai fornitori di software.
