La modellazione di sistemi informat

I primi studi per sviluppare un modello integrato di modello informativo di edificio erano sviluppati su software correnti, ossia basati su concezioni di sviluppo del software antecedenti. I lavori si focalizzavano sulla produzione di nuovi concetti, che rispondessero alle esigenze più marcate e specifiche quali la modellazione geometrica, la rappresentazione di oggetti, la gestione degli attributi e la modellazione di basi di dati. Da quel contesto l’ingegneria del software per la progettazione è cresciuta notevolmente. In alcune aree di lavoro sono state adottate molte applicazioni direttamente impiegate come supporto alla produzione. In queste aree le soluzioni particolari sono state sviluppate per risolvere problemi altrettanto specifici e isolati. Il successivo obiettivo presto evidente si pone in contrasto con questa tendenza alla loca- lizzazione delle applicazioni. I produttori di software non tardano a mostrare un interesse strategico rivolto ai processi di integrazione dei sistemi, quale risorsa e prospettiva di sviluppo del mercato del software.

Questa tendenza non ha incontrato immediatamente il sostegno esplicito da parte degli utenti finali. Non esistono infatti comunità di utenti che abbia- no fatto propri sistemi di progettazione particolarmente avanzati; l’industria ha mostrato effettivamente di comprendere a fondo quanto l’innovazione data exchange debba procedere di pari passo con un pesante processo di re- ingegneria dei processi. La cultura organizzativa dell’industria edilizia non ha

finora saputo coniugare l’utilizzo dell’IT per la riorganizzazione dei processi di produzione (la semplice gestione dei layer dei disegni in situazioni mana- geriali complesse sono tuttora una rara eccezione). Gli ambiti di affermazio- ne più evidente sono stati riscontrati negli studi sulla modellazione dell’infor- mazione di progetto, indirizzati allo sviluppo di problemi di progettazione come per lo sviluppo dei dettagli esecutivi del progetto attraverso:

• lo sviluppo di nuove aree di sviluppo delle applicazioni, quali CAD/CAM o di progettazione dell’efficienza energetica del progetto, che rimanda ad una richiesta di integrazione delle informazioni molto precisa;

• la dimostrazione di quali possano essere i processi di ristrutturazione del- l’industria delle costruzioni attraverso la modellazione dell’informazione di processo come di una tecnologia di servizio;

• la precisazione delle questioni tecnologiche legate alla modellazione del- l’informazione che riguardano la produzione per progetti dell’industria edile.

Tali questioni richiedono che vi siano più orientamenti di ricerca finalizza- ti sia all’applicazione in ambito organizzativo di strumenti di IT, sia a rendere più consistenti questi strumenti.

Probabilmente lo sforzo maggiore rispetto allo sviluppo di questi sistemi di informazione è stato compiuto all’interno della Comunità Europea cercan- do di avvicinare gli sforzi compiuti in questa direzione in contesti nazionali. Questo impegno deriva sostanzialmente dall’integrazione delle industrie nazionali in una struttura unica che richiede l’omogeneizzazione e la raziona- lizzazione dei prodotti edilizi, delle norme edilizie e dei processi contrattuali e legali in mezzo a molte altre questioni. Sono in effetti i partner economici del mercato delle costruzioni a sollecitare ed a richiedere una re-ingegneria del comparto delle costruzioni. Cercando di anticipare queste esigenze la CE ha promosso una serie di progetti per dimostrare la possibilità di utilizzare questi la modellazione dei sistemi di informazione in questa direzione. Il pro- getto COMBINE, ad esempio, è uno di quei progetti che ha portato molte industrie ad utilizzare sistemi di gestione delle informazioni molto più avan- zati di quelli utilizzati correntemente in US.

Vi sono molte questioni che legate alla lentezza dell’introduzione di siste- mi innovativi di gestione delle informazioni e non ultime sono quelle di ordi- ne tecnologico. La struttura dello standard STEP definisce una applicazione su tre livelli – un livello detto di riferimento, un livello interpretativo ed un livello di istanziazione – ed integra il protocollo con una libreria integrata di risorse, che è condivisa e riutilizzata fra modelli multipli di applicazioni.

Focalizzando l’attenzione sui dati di applicazione, STEP si indirizza alla modellazione dei componenti di sistemi complessi, nei quali la maggior parte delle componenti ha una singola funzione primaria.

La costruzione di navi per esempio viene suddivisa in servizi della nave – parte 215, formatura degli stampi della nave, parte 216, condotte per navi, parte 217, e strutture per navi, parte 218. In questo caso la metodologia

STEP interessa la scelta delle unità di medio livello del modello, che suppor- tano un’integrazione pezzo per pezzo. L’integrazione generale è lasciata ad una fase successiva quando saranno sviluppate una serie di modelli di alto livello e saranno testati. Il modo corrente di integrazione viene ottenuto attra- verso le risorse di integrazione.

In contrasto a questo approccio ciò che concerne maggiormente l’indu- stria delle costruzioni è il coordinamento fra i sistemi, in parte perché molti dei componenti dell’edificio – pareti, tetti, pavimentazioni e finiture – sono multifunzionali. Questi componenti definiscono gli spazi ed hanno prestazio- ni strutturali, acustiche e termiche. Sempre alla piccola scala le funzioni sono interessate da localizzazione, dimensione dei materiali delle pareti e dei con- trosoffitti. Ne risulta che molte aziende hanno pensato di sviluppare modelli per sistemi individuali che devono gestire geometrie e relazioni comuni defi- nite precedentemente con strumenti CAD appropriati. (Ad esempio l’applica- zione Elpos della PERI).

Per esempio mentre i modelli CIMsteel e COMBINE vengono sviluppati indipendentemente, derivano i rispettivi carichi l’uno dall’altro. L’involucro dell’edificio specificato con COMBINE deve adattarsi nella struttura definita da CIMsteel. Finché questi due sistemi non possono interagire ognuno deve definire il contesto richiesto ad hoc.

Molti nell’industria delle costruzioni pensano che l’integrazione fra i domi- ni delle applicazioni è il problema maggiore che si trova a fronteggiare l’IT. Questo nuovo livello è stato etichettato come building core o come building framework model. Si consideri l’esigenza di adattare un componente nuovo nell’architettura ISO-STEP. Il modello di sistema di informazioni viene utiliz- zato in settori industriali differenti da quello della cantieristica navale. Inizia- tive sono state prese per introdurre una concezione di sistema informativo di prodotto nel vocabolario STEP più adatto alle esigenze.

Dal 1988 il comitato AEC STEP ha intrapreso diversi studi e sperimenta- zioni per sviluppare un modello di informazione di prodotto, capace di strut- turare le informazioni necessarie per rappresentare un edificio. Due impor- tanti studi di riferimento furono il rapporto di James Turner sullo sviluppo di modelli di sistemi di informazione in AEC, e lo studio di Wim Ghielingh sui riferimenti generali per i modelli in AEC che porta il nome di GARM. Il lavo- ro di Turner incluse lo sviluppo di un modello NIAM che suddivideva l’edifi- cio in parti funzionali.

I sottosistemi funzionali dell’edificio erano classificati come:

• attivi: illuminazione, connessione, strutturale, spaziale, trasporti, servizi meccanici ed elettrici, idraulici, relativi all’aria condizionata, alla ventila- zione ed al riscaldamento;

• passivi: acustici, interni, chiusure.

I sistemi furono suddivisi nei loro componenti generali. I sistemi attivi hanno la seguente classe di componenti: risorse, percorsi, controlli, misure, archiviazioni, terminali. I sistemi passivi non hanno controlli espliciti. I

modelli di Turner mostrarono che un modello generico poteva essere definito almeno ad un alto livello di astrazione per essere utilizzato come struttura per modelli applicativi più dettagliati.

GARM di Gielingh si rivolge alla definizione di una struttura per gestire le questioni di modellazione piuttosto che proporre un modello in sé. Definisce una serie di questioni organizzative attraverso una scansione in fasi del pro- getto associate al lifecycle dell’edificio. Il rapporto GARM puntualizza i diffe- renti modi di descrivere la rappresentazione dell’informazione dell’edificio. Modalità descrittive differenti consistono, ad esempio, nella distinzione fra le forme geometriche dalle funzioni che riguardano tali forme. Ogni forma e descrizione di funzione richiede la sua propria vista del modello di edificio.

Nei termini di questioni relative alla definizione di prodotti edilizi, il rap- porto GARM utilizza una distinzione pratica fra le specificazioni parametri- che dei vari prodotti, una classe di specifiche di un prodotto di un particolare modello e dimensione, e gli oggetti specifici di una categoria che il modello installa in diverse localizzazioni di un edificio. Sono individuati tre livelli di specificazione e bisogna gestire le relazioni fra loro. Il rapporto GARM pun- tualizza quanta informazione viene dissimulata nella pratica delle diverse discipline di progetto, gli attributi di interesse, le dimensioni delle prestazioni e le loro misure.

Puntualizza inoltre come il team di progetto si accosta alla progettazione dell’edificio che risulta dalla scomposizione del lavoro di progetto in parti che sono ricomposte per generare la soluzione con ogni parte che risulta sotto la responsabilità dei vari progettisti.

Uno dei concetti propri del rapporto GARM è la struttura a strati del modello. Il processo di progettazione viene inteso come un processo top- down in cui al livello superiore vengono definite delle specifiche di alto livel- lo. Sul livello successivo le specificazioni funzionali sono risolte da una solu- zione tecnica. Una soluzione tecnica è una ulteriore attività di progettazione o di acquisto che comprende sia delle forme che una o più funzioni che sod- disfano le specificazioni di alto livello e che insieme definiscono un altro (più basso) livello funzionale che corrisponde alle parti richieste dalle soluzioni tecniche. Ogni sistema ha i suoi propri attributi. Questa struttura ha analogie con il modello di sistema proposto da Turner ma a differenza di questi è il solo che assegna ad ogni livello due set di valori – uno che definisce una unità funzionale e un altro che definisce una soluzione tecnica.

Per poter esprimere una valutazione entrambe i set di valori sono richie- sti. L’unità funzionale ha attributi che forniscono l’obiettivo specifico a cia- scun livello di astrazione, mentre la soluzione tecnica sottesa fornisce la risposta progettuale. Ad ogni livello la soluzione tecnica deve soddisfare alcu- ne funzioni, non soddisfarne altre e ottenerne altre ancora. L’idea di far corri- spondere ad ogni livello una coppia specificazione/soluzione tecnica centra una questione nodale della rappresentazione della conoscenza.

ve. Il progetto RATAS, finnico, è orientato a risolvere i problemi di base del modello (core model) funzionale dell’edificio. Affine è la parte 106 detta Buil- ding Core Construction Model (BCCM) correntemente sviluppato dalla comu- nità di ricerca ISO-STEP. Questa parte è stata definita alla luce degli studi di Turner e Gielingh. Il lavoro della IAI parte da queste considerazioni per svi- luppare IFC come kernel del modello di sistema di informazione.