Lo scambio dati machine-to-machine tra CDEs

In Italia proseguono le attività di revisione della norma tecnica UNI 11337 in conformità allo standard internazionale di riferimento UNI EN ISO 19650:2019 e si perfeziona il quadro normativo di riferimento legato alle certificazioni degli esperti BIM, tra cui, non a caso, il CDE Manager o Gestore dell’ambiente di condivisione dati.

Tutto questo in accordo alla UNI 11337-7:2018 e alla recente UNI /PdR 78:2020 nata dagli sforzi congiunti di UNI e Accredia, l’ente italiano di accreditamento.

In contesto europeo, sono stati preliminarmente attivati in seno al CEN Technical Committee 442 Working Group 2 (“Exchange Information”) e Working Group 3 (“Information Delivery Specification”), due interessanti gruppi di lavoro che congiuntamente si ripropongono di curare l’implementazione di Common Data Environment in accordo alla ISO 19650:2018 e, soprattutto, la possibilità di normare le dinamiche di scambio aperto di dati tra soluzioni tecnologiche differenti.

Il concetto di Information Container

La volontà di far fronte alle crescenti necessità di produzione di deliverables eterogenei, spesso composizione di dati ricavati da sorgenti quali modelli informativi, documenti testuali, fogli di calcolo, disegni ecc. e l’esigenza di correlare semanticamente concetti in essi contenuti, sono stati i fattori trainanti della pubblicazione dello standard ISO 21597-1:2020 “Information container for linked document delivery — Exchange Specification — Part 1: Container”.

La prima parte della norma dettaglia il concetto di “information container”, pacchetto informativo generato da un particolare formato che consente sia archiviazione sia connessione di dati mediante riferimenti esterni, mentre la seconda parte approfondisce gli scambi informativi mediante link di dati. 

Lo standard ISO 21597-1:2020, oltre a rappresentare un riferimento per recenti attività normative finalizzate ad aggiornare ed evolvere i capisaldi comunemente accostati al Common Data Environment, applica gli schemi informatici del linguaggio ontologico utilizzato per la rappresentazione schematica e formale di concetti.

Con queste premesse l’information container si configura come un file RDF/OWL (Resource Description Framework schema / Ontology Web Language) avente estensione “.ICDD” (Information Container Data Drop) e contenente l’elenco di tutti i file esterni con relativi metadati associati al container, l’elenco di documenti interni al container con relativi metadati e link/riferimenti a set di dati. L’information container si struttura mediante due differenti risorse ontologiche:

1. la “container ontology”;
2. la “linkset ontology”.

La “container ontology” è ugualmente un file RDF/OWL comprendente la definizione delle classi e delle proprietà che fungono da metadati del container, mandatorie o compilabili opzionalmente. Si compone di oggetti, proprietà e proprietà relative agli oggetti. Esempi di oggetti sono la descrizione del container, riferimenti a documenti sia interni al container che esterni, utente e organizzazione a cui è riconducibile la paternità dei dati. I valori attribuibili agli oggetti apparterranno a tipologie di dato quali stringa, data temporale, testo, formato del file, status, URL, codice identificativo ID e versione. Gli oggetti sono a loro volta strutturati con ulteriori metadati relativi a loro proprietà intrinseche quali l’identificazione dell’utente che origina il dato e dell’utente che lo pubblica, le versioni precedenti e i link a containers differenti.

Figura 1 - Esempio di contesto del Container informativo

Diversamente, la “linkset ontology” definisce classi e proprietà degli oggetti che occorrono al container per “linkare” documenti a singoli elementi, elementi contenuti in un documento a elementi multipli relazionati in documenti multipli e set di elementi in un documento a elementi relazionati in documenti multipli. Tipicamente contiene classi di oggetti come:

• link tra due classi;
• link diretti;
• link diretti con rapporti da 1 a n;
• identificativi per entità contenute nei documenti quali stringhe, URL o query.

Nella “linkset ontology” le tipologie di dato associabili a tali oggetti saranno conseguentemente stringhe con relativo identificativo univoco, URL o query. La presenza di ulteriori metadati relativi alle proprietà intrinseche degli oggetti precedentemente definiti sarà in questo caso l’insieme delle possibili relazioni tra gli oggetti stessi. 

L’information container, così strutturato, rispetta la conformità al requisito tecnico di tracciabilità e successione storica delle modifiche apportate tipicamente correlato agli ambienti di condivisione dei dati rispondenti ai requisiti tecnici della UNI 11337-5:2017, consente di incrementare a discrezione dell’utente i metadati associabili agli oggetti e si presta a nuove tipologie di connessione tra database informativi permettendo, ad esempio, trasmissione/condivisione di deliverable progettuali eterogenei o di modelli/documenti con entità collegate e richiamate mediante link.

Cos'è il CDE

Il CDE è un ecosistema e gli strumenti utilizzabili per la sua definizione, in autonomia o in sinergia tra di loro, sono vari.


Il portfolio delle soluzioni per il CDE di Harpaceas è costituito dalle migliori piattaforme idonee ad implementare correttamente l’ambiente di condivisione dei dati. Attraverso un’approfondita analisi delle esigenze del cliente (committenti pubblici e privati, progettisti, imprese di costruzioni, produttori, general contractor, ecc.) e grazie alle sue forti competenze nel settore delle costruzioni e in ambito informatico, Harpaceas presenta soluzioni per il CDE tailor made, fatte su misura a seconda dell’ambito di competenza del cliente stesso.

>>> Scopri tutte le soluzioni

Modalità aperte di scambio dati

L’adozione di tali framework a livello informatico, la presenza di database relazionali alla base di numerose soluzioni tecnologiche e la necessità di convogliare all’interno del CDE i molteplici processi informativi tipici di ogni commessa, ha spinto il Comitato Europeo di Normazione ad orientare alcuni gruppi di lavoro verso la definizione di approcci aperti per i collegamenti di differenti applicativi software.

Questi ultimi saranno resi possibili mediante la definizione e la standardizzazione di “Open APIs”, le Application Programming Interfaces che rappresentano i protocolli di integrazione software. Le APIs solitamente instaurano un processo di scambio informativo basato su operazioni di richiesta (chiamata) e restituzione di dati (risposta) consentendo quindi il recupero di dati in lettura, anche quelli tipicamente associati alle logiche intrinseche del sistema e non esplicitamente evidenziati nelle interfacce utente, e operazioni in scrittura che possono attivare le funzioni dell’ACDat, in base a condizioni appositamente configurate, e permessi associati alla tipologia di utenza connessa. 

Figura 2 - Esempio di dialogo machine to machine tra soluzioni tecnologiche

Le operazioni di recupero e/o attivazione di operazioni di scrittura all’interno di una determinata soluzione software potranno presumibilmente interessare l’intero contenitore informativo, inteso come oggetto ontologico così come definito dalla ISO 21597-1:2020, o la sola parte di esso inquadrabile nell’ambito del set minimo di metadati a corredo, esplicitamente richiesti dallo standard UNI EN ISO 19650:2019.

Questo poiché l’Ambiente di Condivisione Dati registra informazioni quali ID univoco del contenitore spesso composto da campi delimitati da separatori, stato o idoneità ad indicare gli usi ammessi del contenitore stesso, classificazione adottata a progetto in accordo allo standard di riferimento UNI EN ISO 12006-2:2020, revisione e versione.

Rientrano tra i requisiti minimi anche i metadati di sistema che automaticamente registrano i passaggi di stato, comprensivi di marca temporale e utenza responsabile, particolarmente utili anche in considerazione degli stati di lavorazione e approvazione definiti dalla UNI 11337-4:2017.  

Rafforzando la richiesta di tracciamento dei passaggi di stato dei contenitori informativi, la serie ISO 19650 definisce anche la possibilità di generare tali passaggi all’interno di processi (workflow) che comprendono steps eseguibili da differenti applicativi software. In questi scenari i file contenuti nei contenitori, compresi i modelli informativi, potrebbero necessitare di ulteriori metadati appositi, dovendo contestualizzare la loro presenza contemporanea (se pur momentanea) all’interno di una piattaforma e nell’ambito di un workflow.

Occorre precisare che sia i deliverables dei contenitori sia gli scambi informativi dei processi, oggetto della definizione di protocolli aperti, derivano dalla pianificazione delle consegne durante il ciclo di vita di progetto nota come Information Delivery Plan (IDP). Il piano è tipicamente redatto in versione dettagliata a seguito dell’assegnazione dell’incarico formalizzata dalla firma del contratto tra soggetto proponente e soggetto contraente e riprende la matrice delle responsabilità (RACI – Responsible, Accountable, Consulted, Informed) integrandola con la pianificazione delle tempistiche.

L’IDP si compone di una pianificazione generale (Master Information Delivery Plan) e numerosi planning di dettaglio correlati alle singole unità operative di progetto (Task Information Delivery Plan) così come originariamente introdotto dalla PAS 1192-2:2013 inglese.

Il piano informativo delle consegne, inoltre, definisce ulteriori requisiti che non potranno essere ignorati dal Gestore dell’Ambiente di Condivisione Dati durante i processi digitali di commessa: 

• tempistiche limite di consegna dei “deliverables”;
• modalità di consegna e scambio delle informazioni; 
• formati ammessi e tipologie di dati;
• destinatari e/o revisori dei contenuti informativi;
• responsabili della consegna.

Quanto appena evidenziato rientra nelle attività di analisi funzionale finalizzata alla strutturazione dell’ACDat e conseguentemente comporta l’incremento del set di attributi riconducibili alla standardizzazione dei protocolli aperti a mezzo di APIs. Alcuni metadati sono direttamente ricavabili dalla codifica degli elaborati che specificatamente potrebbe riportare il codice del progetto, dell’organizzazione che origina il dato, della disciplina interessata e del livello di WBS. Gli altri potranno riguardare la fase/milestone progettuale, il riferimento all’attività inquadrata nel diagramma di Gantt, la responsabilità e la data limite prevista per la consegna informativa.

Le Open APIs per i Common Data Environments potranno rappresentare un importante scenario di miglioramento della maturità digitale, puntando su interoperabilità e affidabilità degli scambi informativi. Semplificheranno inizialmente le architetture composte da molteplici soluzioni tecnologiche, garantendo libertà di scelta tra le opportunità commerciali del momento a garanzia di un Ambiente di Condivisione Dati neutrale. Per gli utenti più esperti consentiranno lo sviluppo di applicativi perfettamente integrabili e finalizzati all’incremento degli automatismi nel dialogo machine to machine. Successivamente si individueranno le basi per la convergenza delle architetture multiple a soluzione, sempre neutrale, ma possibilmente univoca.

Chi è e cosa fa il CDE Manager: l'approfondimento