Dipartimento di Ingegneria Meccanica, E. e G.

Dipartimento di Ingegneria Meccanica, E. e G. UNIVERSITA DEGLI STUDI DI L AQUILA Lo scambio di dati fra sistemi CAD Luca Di Angelo, Paolo Di Stefano, L Aquila 2

Lo scambio di dati fra sistemi CAD Luca Di Angelo, Paolo Di Stefano, 1. Introduzione L impiego di strumenti CAD-CAE-CAM, realizzati su piattaforme hardware e software differenti, rende necessarie modalità di scambio dati che siano efficienti, complete e che escludano qualsiasi ambiguità di interpretazione. L implementazione dei metodi di sviluppo prodotto in strumenti integrati ha solo risolto parzialmente questa esigenza. Le diverse soluzioni proposte dai produttori di sistemi CAX non consentono spesso di soddisfare tutte le esigenze del processo di progettazione nell ambito di un unica piattaforma software integrata. L interscambio dati serve quindi al trasferimento di informazioni tra i diversi ambienti preposti a svolgere specifiche funzioni nel processo di sviluppo prodotto. Le informazioni da trasferire tra i vari sistemi sono prevalentemente di natura geometrica, ed infatti i formati di interscambio attualmente impiegati sono quasi esclusivamente destinati al trasferimento di questo tipo di dati. Nella fase di progettazione vengono analizzate le esigenze del prodotto identificabili nel suo intero ciclo di vita (tolleranze, cicli di lavorazione, materiali) e questo ha generato l esigenza di gestire informazioni di altro tipo che vanno ad integrare le strutture dati orientate alla sola descrizione della forma geometrica. Lo scambio dei dati tra i vari sistemi è però limitata da una serie di problemi ricorrenti: esigenze di scambiare dati tra sistemi CAD differenti dotati di proprie specifiche caratteristiche e di protocolli di rappresentazione dedicati; necessità di aggiornare un sistema CAD-CAX utilizzando i dati archiviati sulle sue precedenti versioni, trasferendoli alle nuove generazioni di software e hardware; difficoltà nel condividere le informazioni tra differenti gruppi di lavoro, che si occupano della progettazione concorrente di componenti (nell ambito della stessa azienda e con i fornitori esterni), sincronizzando le relative attività svolte e quindi aggiornando la base dati condivisa; necessità di descrivere lo schema di rappresentazione utilizzato al fine di garantire la portabilità nel tempo e nello spazio dei contenuti della rappresentazione. Nuove versioni di vecchi standard e nuovi protocolli di archiviazione di modelli CAX vengono proposti da organismi internazionali preposti allo scopo. Per molti aspetti i problemi precedentemente elencati richiedono ancora una soluzione. Nelle pagine seguenti sono descritti i protocolli più diffusi e vengono discussi i principali problemi di interpretazione degli stessi. 1

2. Modalità di scambio-dati Lo scambio dei dati fra sistemi differenti implica la traduzione delle informazioni da trasmettere; le soluzioni adottate per questo scopo possono essere raggruppate in due categorie: 1. utilizzo di traduttori diretti; 2. utilizzo di file neutrali ; 3. scambio dati tramite interfaccia. Quest ultima modalità di scambio dati consiste in un interfacciamento diretto tra sistemi i CAX colloquianti senza la generazione di un file di interscambio. I vantaggi che lo scambio dati tramite interfaccia offre sono nella garanzia della notifica e condivisione di ogni modifica applicata al progetto. Allo stato attuale dello sviluppo dei sistemi di scambio dati questa modalità ha una applicazione limitata ed è ancora oggetto di validazione sperimentale per un impiego diffuso. 2.1 Traduttori diretti I traduttori diretti, detti anche point-to-point translator, operano il trasferimento diretto delle informazioni tra una coppia di sistemi CAD. Questi traduttori, sfruttano una specifica conoscenza dei formati di rappresentazione dei sistemi sorgente e ricevente e sono in grado di effettuare un efficiente scambio-dati. Le operazioni di modellazione e le primitive geometriche che trovano delle corrispondenze tra i due sistemi sono adattate direttamente per l uso nel sistema ricevente, evitando processi di reinterpretazione e di conversione; in questo modo viene garantito un trasferimento di informazioni efficace e completo. Tale soluzione è ottimale se si prevede di effettuare lo scambio dati tra un numero molto ridotto di sistemi. Infatti, in un contesto in cui operano N sistemi CAD, poiché ciascuno di essi necessiterebbe di N-1 traduttori, si verrebbero ad avere N (N-1) traduttori in totale e l aggiornamento di uno solo dei sistemi comporterebbe la modifica, quindi, di 2 (N-1) traduttori (fig. 1a). Dato il gran numero di sistemi CAX presenti in commercio e la complessità e l elevato costo di realizzazione di ogni traduttore, l adozione di traduttori diretti è utilizzata solo tra sistemi molto diffusi. 2.2 File neutrali L idea alla base di questa modalità è di creare un formato per l interscambio indipendente dai vari sistemi CAX che li generano e che li riceveranno; una sorta di file scritto in un linguaggio universale (uno standard ), per il quale a ciascun sistema CAD sono necessari soltanto un traduttore in ingresso (pre-processore) ed uno in uscita (post-processore). In questo modo il numero 2

totale di traduttori è proporzionale linearmente (2 N) al numero N di sistemi e non al suo quadrato come nel caso precedente (fig. 1b). Data la varietà di sistemi presenti in commercio e la continua evoluzione legata all esigenza di gestire le informazioni sui prodotti da sviluppare sempre più complesse e complete, la realizzazione di un file neutrale comporta uno sforzo notevole e la necessità di una collaborazione internazionale intesa anche a coordinare e recepire le specifiche adottate delle numerose software-house. L obiettivo di realizzare un formato di interscambio dati efficace ed universalmente riconosciuto è stato, purtroppo, come apparirà chiaro nel seguito, solo parzialmente raggiunto dai vari formati di interscambio dati disponibile. Alcuni dei formati di maggiore diffusione sono: IGES, STEP, STL, DXF, VRML. 2.3 Problemi connessi con lo scambio-dati Di seguito vengono presentate i di problemi più comuni connessi con l interscambio dati. 2.3.1 Diversità dello schema di rappresentazione del modello Nella modellazione della geometria solida sono utilizzati vari schemi di rappresentazione (B-rep CSG, wireframe, FEM) i quali utilizzano primitive geometriche di rappresentazione molto diverse tra loro. Il trasferimento dei dati richiede un processo di conversione, dall uno all altro schema di rappresentazione, che è complesso e spesso fonte di perdita di dati. Il processo di conversione è una vera e propria ricostruzione del modello geometrico che comporta l interpretazione e traduzione delle entità primitive specificate dallo schema di rappresentazione di provenienza in quelle adatte al sistema di destinazione. Talvolta, tale traduzione diventa addirittura impossibile per la carenza di elementi di valutazione del modello insita nello schema di rappresentazione che è stato utilizzato (conversione di un modello B-Rep in uno CSG). Nell ambito dello stesso schema di rappresentazione esistono, poi, diverse modalità di descrizione di alcuni dati geometrici; ad esempio l organizzazione dei dati di un CAD B-rep, completamente parametrico ed associativo, è difficilmente esportabile in altri sistemi che ne accettano la geometria ma non i legami logici tra le entità che lo costituiscono. Gli schemi di rappresentazione di tipo procedurale, oggi comunemente adottati sui sistemi CAD commerciali, sono costruiti secondo un formato che è specifico di un sistema e che quasi mai trova un equivalente in uno differente. Questo rende sostanzialmente impossibile realizzare 3

l interscambio dati inteso come trasferimento della rappresentazione procedurale del modello. Il problema viene affrontato e risolto con la valutazione del modello (identificazione del modello geometrico) ed il trasferimento dei dati relativi esclusivamente alla rappresentazione della geometria, eliminando così ogni informazione di carattere procedurale. 2.3.2 Diversità nella tipologia di curve e superfici utilizzate Entità geometriche come curve e superfici trovano diverse modalità di rappresentazione. Esse possono essere descritte mediante spline, B-spline, NURBS, Bezièr, ecc. ossia utilizzando forme matematiche tra loro differenti. La conversione da un tipo all altro comporta approssimazioni spesso non accettabili; per esempio una geometria descritta con NURBS (funzione razionale) non può essere generalmente rappresentata mediante funzioni di Bèzier (funzione non razionale) senza introdurre una approssimazione del modello originario. Inoltre, all interno di una stessa tipologia di curve o superfici, può essere differente il grado dei polinomi utilizzati (ad esempio un sistema può usare NURBS di 3 grado ed un altro NURBS di grado) e non sempre il grado delle primitive del file di origine può essere accettato dal sistema di destinazione. 2.3.3 Approssimazioni numeriche nella valutazione del modello solido Il processo di costruzione del modello solido ha successo solo se le proprietà formali del modello [39, 1 e 2] sono rigorosamente rispettate. Sovente nella fase di modellazione si generano errori strutturali (come bordi liberi, superfici aperte) ed errori di accuratezza (come approssimazioni grossolane nel calcolo delle curve di intersezione, che possono portare ad un imperfetto combaciamento tra le superfici, con sovrapposizioni o fessure tra i patch). Questo problema costituisce una delle più frequenti limitazioni che si riscontra nella effettiva possibilità di utilizzare modelli geometrici scambiati tra applicazioni CAX. All origine di questi problemi ci può essere il tipo di precisione adottato nella rappresentazione numerica (singola o doppia). 3. Il formato IGES La necessità di realizzare un formato standard nell interscambio dati tra sistemi CAD divenne importante già nella seconda metà degli anni 7. Nel settembre del 1979, durante il meeting Air Force Integrated Computer-Aided Manufacturing (ICAM) negli USA, una rappresentativa della General Electric propose alle software house presenti di voler collaborare allo sviluppo di un file neutrale d interscambio dati. Questo invito venne immediatamente recepito e nel 198 l idea venne formalizzata dal National Bureau of Standards che pubblicò le specifiche del formato IGES (Initial Graphics Exchange Specification) che stabilivano la struttura base da usare per la rappresentazione digitale e la comunicazione dei dati fra sistemi CAD/CAM/CAE. L anno successivo l IGES versione 1. venne accettato e riconosciuto come Standard ANSI.

L IGES, originariamente sviluppato per lo scambio di semplici informazioni (modelli wireframe 2D/3D, testo, quote ed alcune tipologie di superfici), attualmente (versione 6) contempla la rappresentazione della maggior parte delle primitive geometriche utilizzate nei sistemi CAD e costituisce, di fatto, il formato di file neutrale più diffuso nel mondo. 3.1 Organizzazione dei dati nei file IGES Le specifiche IGES definiscono un file di interscambio neutrale che può presentarsi in tre formati: - ASCII; - ASCII compresso; - binario. La forma ASCII è la più comunemente usata. I dati nei file IGES sono organizzati in elementi detti entità. Tali entità sono suddivise in due categorie: geometriche e topologiche, alle quali è affidata la definizione della forma fisica del modello; a questa categoria appartengono ad esempio le entità: punto, linea, arco di circonferenza, curva e superficie spline o B-spline razionale, primitive solide quali parallelepipedo, sfera, ellissoide, ecc., relazioni di adiacenza tra le entità geometriche (inserite con la versione 5.6); non-geometriche, le quali contengo informazioni aggiuntive sul modello, quali, ad esempio: quote, annotazioni, proprietà delle linee (spessore, tipo, colore, ecc.), organizzazione in layers, ecc. Il file è suddiviso nelle seguenti 5 sezioni, ognuna delle quali è costituita da record (righe) di 8 caratteri ciascuno ed è identificata da una lettera maiuscola posizionata come 73 carattere del record: Start: contiene righe di testo che descrivono il contenuto del file (es.: nome del file); è identificata dalla lettera S; General: contiene informazioni utilizzate per interpretare il file (es.: caratteri separatore e delimitatore dei dati, numero di cifre significative nella rappresentazione in singola e in quella in doppia precisione, scala, unità di misura ecc.), oltre ad informazioni quali data ed ora di 5

creazione del file, nome del codice generatore e dell autore, versione dell IGES ecc.; è identificata dalla lettera G; Directory Entry (DE): costituisce una sorta di indice per il file e contiene informazioni sugli attributi generali di ciascuna entità contenuta nel file: tipo (es.: linea, arco, trimmed surface ecc.), posizione dei dati specifici nella corrispondente riga della parameter data ( puntatore al PD), livello, colore, spessore e tipo di tratto ecc.; è identificata dalla lettera D; Parameter Data (PD): contiene i parametri specifici per la definizione di ciascuna entità presente nella DE; ad esempio per le linee (segmenti di retta): le coordinate (x,y,z) degli estremi; per le curve B-spline: la sequenza dei nodi e le coordinate dei punti di controllo; per le trimmed surface: il puntatore alla riga PD che definisce le caratteristiche geometriche della superficie ed il puntatore alla riga PD che definisce il contorno esterno ecc.; è identificata dalla lettera P; Terminate: è costituita da un singolo record che contiene le lunghezze (n di righe) delle varie sezioni; è identificata dalla lettera T. In figura 2 è mostrato un esempio di file IGES nel quale ben si identificano le varie sezioni e le tipologie di dati in esse trascritte. 3.1.1 I modelli CSG in IGES. Per quanto riguarda i modelli solidi CSG, l IGES supporta le seguenti entità: Blocco (entità n 15); Cilindro (entità n 152); Sfera (entità n 158); Toro (entità n 16); Ellissoide (entità n 168); Solido di Rivoluzione (entità n 162); Solido di Estrusione Lineare (entità n 16); Istanza di un Solido (entità n 3); Albero Booleano (entità n 18); Solido Assemblato (entità n 18); Per entità solide n 15, 152, 158 16 e 168, la Directory Entry (DE) ha dei puntatori ai record della Parameter Data (PD) che contengono i dati dell oggetto come le coordinate dei vertici, i raggi, la lunghezza dei vettori. Il record nella PD, invece, per il Solido di Rivoluzione (entità n 162) 6

conterrà entità descriventi una curva, un punto, l asse ed infine un angolo di rotazione. Per il Solido di Estrusione Lineare (entità n 16), lo standard specifica nella PD una curva chiusa (rappresentante la sezione dell'estrusione) ed un vettore per definire la direzione e la distanza di estrusione della sezione. 3.1.2 I modelli B-rep in IGES. In figura 3 è riportata la struttura dati di un solido B-rep secondo lo standard IGES. L elemento base della rappresentazione è il trimmed-patch (Trimmed Parametric Surface entità n 1) che consiste di una superficie parametrica con associate le curve di trimming. Nella riga del PD di tale entità è contenuta una serie di puntatori: all entità che contiene le caratteristiche geometriche della superficie parametrica; all entità che contiene la rappresentazione del contorno esterno; alle entità che contengono la rappresentazione degli eventuali contorni interni (curve delimitanti fori o protusioni presenti sulla superficie). La superficie è descritta da una funzione parametrica e per definirne le caratteristiche geometriche le specifiche IGES prevedono due possibilità: 1. superficie spline parametrica (parametric spline surface, entità n 11); 2. superficie B-spline razionale (rational B-spline surface, entità n 128). Le curve dei contorni hanno una duplice rappresentazione: cartesiana (curve descritte da equazioni o punti nello spazio tridimensionale); parametrica (curve descritte da equazioni o punti nello spazio parametrico bidimensionale); in entrambi i casi il contorno è costituito da una curva composita chiusa (entità Composite Curve, o in breve Ccurve ) ossia dall unione di tratti di curve (segmenti di retta, archi, spline); l entità Ccurve contiene come informazione i puntatori alle entità curve componenti che contengono i dati delle caratteristiche geometriche delle curve (ad es. per la line: le coordinate degli estremi). Il formato IGES prevede le seguenti entità per la descrizione geometrica delle curve: 1. segmento di retta (line, entità n 11); 2. arco di circonferenza (circular arc, entità n 1); 3. arco di conica (conic arc, entità n 1);. curva spline parametrica (parametric spline curve, entità n 112); 5. curva B-spline razionale (rational B-spline curve, entità n 126). Con le ultime due entità è ovviamente possibile descrivere ogni tipo di curva: dai segmenti alle curve più complesse. 7

Le figure e 5 mostrano, rispettivamente, la scomposizione di un solido B-Rep in Trimmed Surface (fig. ) e di una Trimmed Surface nelle entità geometriche previste dal formato IGES (fig. 5). Topologicamente ogni curva di contorno è condivisa da due e soltanto due patch ed ogni faccia è a contatto con un altra tramite una sola curva. Fanno eccezione i patch rappresentanti superfici chiuse (ad es.: superficie laterale di un cilindro, o la superficie di una sfera) descritte tramite B-spline razionali; poiché le NURBS utilizzate non possono descrivere curve o superfici chiuse, esse vengono suddivise in due metà e sono pertanto doppiamente a contatto fra loro (fig.6). 3.3 Problemi del formato IGES L IGES è divenuto un importante protocollo di interscambio dati, tanto che praticamente tutti i sistemi CAX includono un traduttore per questo tipo di file. Tuttavia tale formato si è rivelato non privo di difetti, nonostante le valide idee che ne sono alla base; i problemi sono di molteplice natura e non tutti attribuibili agli sviluppatori di questo formato. Oltre alle possibili cause di perdita di informazioni riscontrabili in ogni scambio-dati e già discussi in precedenza, i principali problemi di questo formato sono raggruppabili nelle seguenti categorie: onnicomprensività del formato: per garantire la maggiore compatibilità possibile tra i vari CAD, il formato IGES prevede un notevole numero di tipologie di entità per descrivere la geometria di un modello: per esempio le superfici possono essere descritte tramite spline parametriche (entità n 11), oppure con B-spline razionali (entità n 128), talvolta come superfici ruled (entità n 118), o come superfici di rivoluzione (entità n 12), o, ancora, come entità analitica. Questa non univocità di rappresentazione comporta, per chi sviluppa il traduttore, il moltiplicarsi delle routine di conversione. Al fine di limitare questo problema molti sistemi CAD offrono la possibilità, nel generare il file IGES, di convertire tutte le primitive proprie in un unico tipo, ad esempio NURBS; differente versione dell IGES: utilizzare la stessa versione del formato neutrale è una condizione importante per garantire la compatibilità delle informazioni e quindi il corretto trasferimento dei dati; tuttavia non è sufficiente a garantire il successo del trasferimento: non c è, infatti, nessun impegno da parte di chi realizza il traduttore ad implementare le entità, previste in ogni nuova versione, entro un certo tempo; ne consegue che, a parità di versione, due traduttori di ditte diverse possono anche non supportare le stesse entità. È stato riscontrato che solo un quarto circa delle entità previste, e quindi potenzialmente utilizzabili per la rappresentazione degli oggetti, vengono supportate dai vari traduttori. Coloro che realizzano traduttori tendono a realizzare una sorta di personalizzazione dello standard che è in grado di scambiare soltanto le tipologie di entità conformi alla struttura interna del database dello specifico sistema di interesse; ciò comporta che il traduttore potrebbe ignorare molte delle informazioni presenti nel file; 8

problematiche relative al verso della normale: nei modelli geometrici B-Rep l orientamento delle superfici è un elemento indispensabile alla definizione del solido. A questo scopo viene assunto il verso della normale uscente di un punto di una superficie come elemento indispensabile per distinguere la parte esterna da quella interna di un modello. Tuttavia nelle specifiche IGES questo tipo di informazione non è prevista esplicitamente sotto forma di dato; in altre parole, nei dati geometrici di descrizione di una superficie non è presente un informazione quale, ad esempio: componenti del vettore normale. Essa deve, quindi, essere ricavata indirettamente, facendo riferimento alla coerenza di orientamento con le superfici adiacenti. Le modalità di valutazione della direzione della normale esterna possono essere tipicamente le seguenti: 1. il verso di percorrenza del contorno esterno della superficie; 2. la sequenza di archiviazione dei punti di controllo della superficie B-spline. Verso di percorrenza del contorno esterno Le specifiche IGES assegnano una direzione di percorrenza alla sequenza di curve che contornano ciascuna faccia dell oggetto. Assumendo, ad esempio che, osservando la faccia dall esterno, tale verso sia quello antiorario, l orientazione della normale sarebbe univocamente definita con il metodo della mano destra. In questo modo ogni spigolo deve essere definito due volte, con orientamento opposto per le due facce che lo condividono (fig. 7). Sequenza di archiviazione dei punti di controllo La sequenza di archiviazione dei punti di controllo per una superficie B-spline ricalca quello della griglia dei nodi dello spazio parametrico (u,v) ad essi corrispondenti; a titolo di esempio, la figura 8 riporta la sequenza per una faccia rettangolare. Anche in questo caso, assumendo la sequenza presentata in figura come quella che si osserva dall esterno, il verso della normale resterebbe univocamente definito. In alcuni traduttori IGES, si è riscontrato che in nessuno dei due casi si ha univocità di rappresentazione: in altri termini, né la sequenza di archiviazione dei punti di controllo, né il verso di percorrenza delle curve di contorno, pur essendo tra loro congruenti, sono correlati al verso della normale. Quanto affermato è posto ben in evidenza nell esempio riportato in figura 9a, riguardante il file IGES di un cubo realizzato con un sistema CAD di grande diffusione; di tale solido è visualizzato lo sviluppo della sua superficie e sono evidenziati i versi di percorrenza delle curve del contorno e la sequenza di archiviazione dei punti di controllo delle sue facce. Come si può facilmente notare, la faccia n 1 è incongruente rispetto alle altre, essendo per essa invertito il verso di percorrenza del contorno e la sequenza di archiviazione dei nodi e dei punti di controllo. Non potendo, pertanto, ricavare l informazione relativa al verso della normale 9

separatamente per ogni superficie, si deve far ricorso ad un analisi del solido nella sua interezza, così da evidenziare, come nell esempio del cubo di prova, le eventuali superfici incongruenti e provvedere al loro raddrizzamento (fig. 9b). Ovviamente questo tipo di analisi preliminare causa del rallentamenti nella fase di post-processing. Inoltre non si può escludere che questo tipo di elaborazione possa anche dare luogo ad interpretazioni ambigue del modello;. Il formato STEP Dal 198 l Organizzazione Internazionale per le Standardizzazioni (ISO) sta lavorando allo sviluppo di uno standard per lo scambio dati tra sistemi CAD. Il risultato di questo lavoro, che è stato definito il più grande sforzo sostenuto dalla ISO (negli ultimi diciotto anni alcune centinaia di persone, provenienti da stati diversi, hanno lavorato allo sviluppo di questo nuovo formato) è rappresentato dallo standard ISO 133 meglio noto come STEP (STandard for Exchange of Product information). Sin dalla prima versione, datata 199, coloro che hanno sviluppato lo STEP si sono prefissi i seguenti obiettivi: - Completezza: lo STEP dovrebbe fornire una rappresentazione completa del prodotto, includendo non solo i dati sulla geometria, ma tutte le informazioni di progettazione e produzione dello stesso: dalle caratteristiche fisiche dei materiali che lo compongono, alle modalità di fabbricazione ed assemblaggio, dalle tolleranze di lavorazione alla manutenzione. - Estensibilità: lo STEP dovrebbe avere una struttura nella quale sia possibile costruire delle estensioni. - Efficienza: lo STEP dovrebbe essere efficiente sia in termini di dimensione del file che di risorse del computer richieste per l elaborazione dei dati. - Compatibilità con altri standard: lo STEP dovrebbe essere compatibile con altri standard al fine di ottenere una facile migrazione da standard esistenti. - Minima ridondanza: dovrebbe esserci solo una via nella rappresentazione di un particolare concetto. - Indipendenza dal sistema di calcolo: l interpretazione del formato e la sua realizzazione dovrebbe essere indipendente da hardware/software. Tali obiettivi vanno ben oltre lo scopo dei altri file neutrali e tendono alla creazione di un database integrato tra tutte le risorse necessarie alla realizzazione dell oggetto. In questo modo il progetto, sviluppato con diversi sistemi CAX, può essere facilmente accessibile ed utilizzabile da tutti coloro che partecipano alla sua definizione: progettisti, analisti, tecnologi, manutentori, personale che prepara la documentazione, e così via. 1

L ISO 133 copre una grande varietà di differenti tipi di prodotti (automotive, elettronica, elettromeccanica, materiali compositi, meccanica, impianti di produzione, lamiere e costruzione di scafi) e di fasi del ciclo di vita dello stesso (progettazione, analisi, pianificazione del processo e realizzazione). Tale gamma è continuamente in espansione ed, attualmente, tutto lo standard è costituito da più di centodieci parti e diverse altre sono in fase di sviluppo..1 La struttura dello STEP Lo standard STEP è costituito da numerose parti, il cui sistema di numerazione riflette la seguente struttura: Parti Argomenti 1 Principi Fondamentali 11 13 Metodi di Descrizione 21 26 Metodi di Implementazione 31 35 Metodologie per il test e struttura principale 1 9 Risorse Generiche Integrate 11 16 Risorse di Applicazione Integrate 21 233 Protocolli di Applicazione (AP) 31 332 Abstract test suites 51 518 Costrutti delle Applicazioni interpretate.1.1 I Metodi di Descrizione I Metodi di Descrizione rappresentano dei linguaggi per la definizione e la modellazione delle informazioni relative ad un prodotto. Il metodo di descrizione fondamentale dello STEP è rappresentato dalla famiglia di linguaggi EXPRESS; utilizzata per esprimere le informazioni del modello e dei Protocolli di Applicazione essa costituisce la parte più sostanziosa dello standard. EXPRESS è stato originariamente sviluppato per fornire un formale, e processabile da computer, sistema di definizione dei dati necessari alla descrizione di un prodotto (dal microchip alla nave) attraverso il suo ciclo di vita, dal momento della concezione fino alla sua realizzazione e dismissione. In altri termini, esso è un linguaggio di specificazione, e non di programmazione, per la descrizione logica delle informazioni dei modelli. Gli aspetti fondamentali di EXPRESS sono: 1) modellazione di dati e di relazioni tra essi definito tramite un meccanismo generale e potente; 2) linguaggio di programmazione pienamente procedurale che consente di specificare vincoli su insiemi di dati. Nella figura 1 viene presentata la descrizione completa, utilizzando EXPRESS, dell entità cerchio. Gli elementi costitutivi del linguaggio, risultano: SCHEMA: è un insieme di elementi dell informazione. 11

ENTITY: definisce un oggetto costituito da proprietà e regole; ogni entità ha un unico nome nello schema. ATTRIBUTES: sono le proprietà dell oggetto; esse sono definite da un nome e da un tipo. In essi possono essere specificate anche delle caratteristiche addizionali come ad esempio delle regole derivate. TYPE: EXPRESS supporta sia i tipi base (Integer, Real, String, Boolean, Logical) che i tipi di dati complessi (Enumeration, Select, Complex). RULES: rappresentano le regole che devono essere rispettate dai dati del prodotto; un esempio è rappresentato dalla descrizione delle condizioni di regolarità di un istanza che può essere relazionata localmente ad un singola entità nella sua definizione o globalmente alla totalità delle entità presenti nella definizione dello schema. Con riferimento al manuale (part 11) [12], altri Metodi di Descrizione facenti parte della famiglia di linguaggi EXPRESS sono: EXPRESS-G: è un sottoinsieme grafico del linguaggio; esso consente una rappresentazione visuale, in forma compatta, delle informazioni relative al modello. Gli elementi base dell EXPRESS-G sono riportati in figura 11; in figura 12 viene mostrata la codifica in EXPRESS-G dell entità cerchio. EXPRESS-I: permette di generare istanze di entità i cui schemi sono definiti in EXPRESS che hanno i valori degli attributi invece di riferimenti a tipi di dati. Tale linguaggio, che è stato sviluppato principalmente per essere interpretato dagli operatori, viene utilizzato per due scopi differenti: - rappresentazione di dati, relativa alla singola entità, ad uno schema o ad un insieme di schemi; - Specificazione degli Abstract test cases. EXPRESS-X: è un sottoinsieme del linguaggio EXPRESS che possiede costrutti e semantica per definire la corrispondenza esistente tra le informazioni di un medesimo oggetto definito in diversi schemi EXPRESS. Le singole rappresentazioni delle corrispondenze esistenti vengono chiamate viste dei modelli originali. Le principali applicazioni di tale linguaggio sono: - relazione tra schemi che definiscono l oggetto con diversi livelli di astrazione; - relazione tra modelli EXPRESS ed altre applicazioni. La struttura definita da EXPRESS può essere tradotta in un qualsiasi linguaggio di programmazione basato sugli oggetti. 12

.1.2 I Metodi di Implementazione I Metodi di Implementazione definiscono le modalità con cui vanno scambiate le informazioni del prodotto definite con i Metodi di Descrizione. La caratteristica essenziale dello STEP di specificare i Metodi di Descrizione (come rappresentare i dati) separatamente ai Metodi di Implementazione (come scambiare i dati) fa sì che i primi siano indipendenti dai secondi ma siano comunque disponibili in una forma interpretabile. Nello STEP l implementazione di procedure scritte secondo i Metodi di Descrizione può avvenire su due diversi livelli: - file di Scambio (File Exchange); - Applicazione Interfacce di Programmazione (Application Programming Interfaces); File Exchange La Part 21 della ISO 133 definisce la sintassi del file STEP per lo scambio dati; un preprocessore converte le informazioni relative al prodotto in un file ASCII. Questo file, trasferito al software CAX ricevente verrà convertito secondo la propria struttura dati. In figura 13 viene mostrata la trascrizione nel formato STEP dei due cerchi di figura 1, utilizzando la struttura definita dall entità circle precedentemente presentata. Application Programming Interfaces Le Applicazioni Interfacce di Programmazione (API), utilizzate per manipolare le informazioni del modello espresse secondo i Metodi di Descrizione, sono definite nella ISO 133-22 e sono chiamate Standard dell Interfaccia di Accesso Dati (SDAI). Nella totalità dei casi, un applicazione software è scritta utilizzando uno specifico metodo di accesso dati per una specifica tecnologia di memorizzazione degli stessi. Se un applicazione esistente deve utilizzare differenti metodologie di memorizzazione o di accesso dati, l applicazione software deve essere significativamente modificata poiché ogni tecnologia di memorizzazione dati ha il proprio specifico set di operazioni. Lo scopo dello SDAI è quello di definire lo standard per l accesso ai dati STEP con il grande vantaggio di consentire agli sviluppatori delle applicazioni di riferirsi ai dati del prodotto in termini di definizioni concettuali EXPRESS e non ad una particolare struttura dati o tecnologia di memorizzazione. In altri termini, possono essere utilizzati diversi tipi di database senza dover alterare le interfacce utilizzate tra le applicazioni e il database stesso. Con lo SDAI, cioè, gli sviluppatori di database possono non preoccuparsi di come ogni applicazione tratta i dati, ed i programmatori delle applicazioni possono utilizzare le funzioni SDAI senza conoscere i dettagli della tecnologia dei database. 13

La figura 1 presenta un immagine schematica della condivisione di dati STEP utilizzando un singolo database; le applicazioni accedono ai dati STEP in un database comune attraverso lo SDAI. Il processo di memorizzazione dati da un sistema CAX in un database attraverso lo SDAI implica tre diverse fasi [8]: - traduzione: il risultato dovrebbe essere costituito da dati memorizzati nella struttura del software di interfaccia; - accesso: le funzioni di SDAI sono utilizzate per creare e manipolare le strutture dati dentro il database a valle; - memorizzazione: l implementazione SDAI traduce ogni funzione standard chiamata nelle operazioni necessarie per creare e popolare le strutture dati del database fisico. Lo SDAI non specifica, nella sua ultima versione, dettagli circa il controllo e la gestione delle operazioni di traduzione e connessione, poiché tali operazioni sono delegate ai sistemi di gestione di ogni database. Comunque, lo SDAI fornisce alcuni costrutti base di sistemi di condivisione dati..1.3 Risorse integrate (IR) Le IR costituiscono il primo livello delle informazioni dei modelli rese disponibili con lo STEP; esse infatti, forniscono un modello concettuale che è indipendente da ogni specifica implementazione o applicazione. Le IR si dividono in Generiche (parti 1 9), nelle quali vengono presentati i costrutti base per la rappresentazione in STEP di tutte le informazioni del prodotto ed Applicazioni (parti 11 16), riguardanti una gamma specifica di applicazioni (strutture di navi, connessioni elettriche ed elettroniche, elementi finiti, cinematica, ecc..). L insieme di tutte le IR fornisce una gamma di schemi riutilizzabili, interconnessi e non ambigui; un singolo concetto è rappresentato solo una volta nelle IR. In figura 15 viene mostrato un esempio di definizione di entità geometrica presente nella IR Geometric and topological Representation (ISO 133-2). L entità path eredita le proprietà da topological_representation_item ed è il supertype di altri tre tipi di path specializzati. Esso ha una lista di bordi (edge) come attributi, e la proposizione WHERE specifica la regola secondo cui l ultimo vertice di ogni bordo è uguale al vertice iniziale del bordo successivo..1. I Protocolli di Applicazione Le risorse integrate non sono sufficienti a supportare le informazioni del prodotto, in particolari campi di applicazione, senza l aggiunta di specifici vincoli o relazioni. Al fine di servire le richieste di determinate applicazioni, pur mantenendo una consistente standardizzazione, il formato STEP possiede la caratteristica unica di permettere una notevole 1

personalizzazione ed estensione dei modelli analizzabili. Questa particolarità è organizzata nei Protocolli di Applicazione (AP), ovvero in insiemi di entità scelti per uno specifico prodotto, processo o industria. Per esempio, ci sono AP dedicate alle industrie automobilistiche, aerospaziali e navali, così come per i processi che riguardano le lamiere. Ogni AP è un documento formale che descrive tutte le informazioni richieste per una porzione del ciclo di vita del prodotto e sono idealmente indipendenti l una dall altra. La costruzione di un AP prevede quattro fasi (fig. 16): 1. definizione dello scopo del modello in un documento chiamato Applicazione Attività del Modello (AAM); esso provvede a stabilire e rappresentare il dominio dell'ap e le attività che usano i dati del prodotto nel contesto dell'applicazione, specificando gli input, output ed i controlli presenti ai vari livelli della progettazione; 2. individuazione delle richieste del processi identificati in AAM in un documento chiamato Applicazione Riferimento Modello (ARM). ARM precisa le informazioni del contesto specifico che devono essere comunicate attraverso l AP; tali informazioni sono definite e documentate utilizzando l EXPRESS-G; 3. individuazione delle relazioni esistenti tra l IR ed i costrutti ARM; per produrre l Applicazione Modello Interpretato (AIM). Un AIM include uno schema EXPRESS e relaziona i costrutti di IR che sono utilizzati con gli schemi nei quali il costrutto è definito e con vincoli addizionali;. realizzazione di test su l ARM e AIM per verificare la conformità dei vincoli delle istanze in AIM. Le informazioni del modello generate con la suddetta procedura sono racchiuse in un singolo schema, il modello concettuale normalizzato presente in AIM..1.5 L applicazione Costrutti Interpretati Le Applicazioni Costrutti Interpretati (AIC) sono interpretazioni delle IR che possono essere condivise da varie AP, al fine di migliorarne la interoperabilità. In altri termini, un AIC fornisce un integrazione semantica tra diverse AP, quando requisiti comuni sono condivisi tra due o più AP; ad esempio, la rappresentazione geometrica (B-rep, modelli di superfici, ecc.) può essere utilizzata in differenti domini di applicazione come la progettazione automobilistica, la lavorazione delle lamiere e la costruzione di navi..1.6 Abstract Test Suites Gli Abstract Test Suites forniscono l insieme dei dati e dei criteri di test che devono essere effettuati per la verifica di conformità di ogni implementazione di nuove AP. Gli Abstract Test Suites sono 15

derivati della sezione delle richieste funzionali della AP in esame e sono sia leggibili dall operatore che processabili direttamente da computer. Essi vengono scritti in EXPRESS-I. 5. Il formato STL I files per la Stereolitografia (STL) sono stati introdotti dalla 3D Systems di Valencia (una delle prime compagnie a produrre sistemi per il rapid prototyping), come un metodo semplice per gestire le informazioni relative ad un oggetto 3D. Attualmente, il formato STL è impiegato soprattutto come standard per la realizzazione di modelli fisici tridimensionali con sistemi di prototipazione rapida di ogni tecnologia. Trovano applicazione anche in altri ambiti come quello del reverse engineering per la facilità di tradurre le nuvole di punti acquisite in modelli geometrici tessellati tipo STL. È quindi diventato un file per l interscambio dei dati geometrici quando l approssimazione della geometria in elementi triangolari piani non costituisce una limitazione all impiego del modello. 5.1 Specifiche del formato STL In un file STL il modello geometrico è descritto mediante la sua superficie esterna approssimata da una serie di facce piane triangolari. STL, quindi, può trasferire informazioni relative solamente a superfici; entità come punti, linee, curve ed attributi come i colori, non sono considerati. Ogni faccia è univocamente identificata dai valori numerici delle coordinate dei tre vertici e dei versori della normale ad essa. È evidente come diminuendo la dimensione dei lati dei triangoli si ottenga da un lato un approssimazione migliore della geometria del solido (fig. 17) mentre dall altro un notevole aumento delle dimensioni del file di interscambio. 5.1.1 Orientamento della faccia Poiché l insieme delle facce definisce la superficie esterna di un oggetto tridimensionale, ogni faccia rappresenta una separazione tra la parte piena dell oggetto e l esterno. L una è distinta dall altro sulla base dell orientamento della normale che è rivolta sempre verso l esterno dell oggetto. L orientamento delle facce è specificato in maniera ridondante in due modi (fig. 18): 1) i versori esprimono la normale esterna; 2) i vertici sono memorizzati in senso antiorario guardando l oggetto dall esterno. 5.1.2 Regola Vertice a Vertice I modelli STL sono Euleriani; conseguentemente ogni triangolo facente parte della superficie del modello deve condividere con quella adiacente due vertici ed un solo lato. In altri termini, non deve accadere che un vertice di un triangolo possa trovarsi sul lato di un altro (fig. 19). 16

5.1.3 Assi ed unità di misura L oggetto rappresentato deve avere tutte le coordinate definite positive (cioè non negative e non nulle) e sono espresse in unità arbitrarie. Il file STL non prevede la specificazione della scala. 5.1. Formato dei dati Lo standard STL include due tipi di formati dei dati: - ASCII, che è primariamente utilizzato per testare nuove interfacce CAD; infatti, esso da un lato risulta facilmente editabile utilizzando un qualsiasi editore di testi, mentre dall altro, la grande dimensione dei file che genera, lo rende praticamente inutilizzabile per le normali applicazioni. In figura 2 viene mostrata la sintassi di un file per la rappresentazione di una singola faccia STL ASCII. Il contenuto delle parentesi graffe è ripetuto più volte quando viene rappresentata una superficie estesa o un solido. A titolo esemplificativo, la figura 21 riporta il listato di un file STL ASCII di un tetraedro. - Binario, che non è facilmente editabile dall operatore ma che risulta, rispetto al precedente, estremamente più compatto. In figura 22 è mostrata la sintassi di un file binario. Il contenuto delle parentesi graffe può essere ripetuto più volte. 5.2.5 Errori comuni provenienti da STL Come ogni altro formato di interscambio dati, anche STL può contenere degli errori che possono compromettere l utilizzo del file: Molteplicità Sebbene non sia direttamente specificato nello standard STL, tutte le facce dovrebbero costituire una o più entità non molteplici in accordo alla regola di Eulero per i solidi rispondenti alle proprietà formali: F-E+V=2B dove F, E, V e B sono i numeri, rispettivamente, delle facce, dei lati, dei vertici e dei corpi separati del solido. Se la relazione non è soddisfatta, il modello STL risulta essere aperto, con conseguenti problemi durante la fase di prototipazione rapida. Arrotondamenti numerici Nel formato STL uno stesso vertice viene descritto tante volte quante sono le facce che in esso concorrono. A causa degli arrotondamenti numerici che vengono effettuati sulle coordinate del vertice si può verificare un non perfetto combaciamento dei vertici, e quindi modelli definiti da superfici aperte o con pezzi di superfici intersecanti. Facce degenere Diversamente dagli errori topologici precedentemente visti, la degenerazione delle facce raramente causa seri problemi nel processo di realizzazione del pezzo mediante rapid prototyping. 17

I tipi di degenerazione delle facce includono: 1) i tre vertici della faccia sono allineati o diventano tali dopo che i valori delle coordinate sono troncati dall algoritmo dell applicazione d importazione o per effetto di errori nella fase di tessellazione del modello CAD originario; 2) i tre vertici della faccia sono coincidenti o diventano tali dopo che i valori delle coordinate sono troncati dall algoritmo dell applicazione d importazione. Sebbene il problema della degenerazione delle facce non sia critico, ciò non vuol dire che esso possa essere ignorato. Infatti potrebbe tranne in inganno l algoritmo dell applicazione che prepara i dati per la realizzazione fisica del pezzo. 6. Il formato DXF DXF è un formato di file vettoriale ideato dalla Autodesk. Le specifiche, inizialmente presentate per il programma AutoCAD, sono state universalmente accettate nel campo della grafica tecnica ed oggi il DXF rappresenta un formato di interscambio di fatto divenuto uno standard. 6.1 Struttura generale del file Un file.dxf è un file standard di testo ASCII ed è essenzialmente costituito da coppie di codici e valori associati. Tali codici, detti codici di gruppo, indicano il tipo dell'elemento di dati che segue ed il significato di un elemento di dati per un determinato tipo di oggetto o record. La sua organizzazione generale è la seguente: 1. Sezione header 2. Sezione tables 3. Sezione blocks. Sezione entities 5. Sezione end of file. Ciascuna sezione inizia con un codice di gruppo seguito dalla stringa SECTION. Quest ultima è seguita da un codice di gruppo 2 e da una stringa indicante il nome della sezione (ad esempio HEADER). Ogni sezione è costituita da codici di gruppo e valori che ne definiscono gli elementi e termina con uno seguito dalla stringa ENDSEC. 6.1.1 La sezione HEADER. In essa sono contenute le informazioni generali riguardanti il disegno, ovvero i settaggi delle variabili associate con lo stesso (limiti, estensione, variabili di quotatura, ecc...). Ogni variabile è specificata dandone il nome, seguito da gruppi che ne forniscono i valori. La figura 23 riporta la struttura di tale sezione. 18

6.1.2 La sezione TABLES Questa sezione contiene le seguenti tabelle nelle quali sono riportate le caratteristiche di diversi oggetti: - Tabella dei tipi di linea (LTYPE); - Tabella dei tipi di layer (LAYER); - Tabella degli stili del testo (STYPE); - Tabella delle viste (VIEW); - Tabella del sistema di coordinate definito dall utilizzatore (UCS); - Tabella delle configurazioni Viewport (VPORT); - Tabella degli stili delle quotature (DIMSTYLE); - Tabella di identificazione delle applicazioni (APPID). in ognuna delle quali è presente un numero variabile di voci. L ordine con cui le tabelle vengono riportate nel file non può essere del tutto casuale; ad esempio la tabella LTYPE dovrebbe sempre precedere la LAYER. Come mostrato in figura 2, ogni tabella è introdotta dal codice di gruppo seguito dall etichetta TABLE. Essa è seguita dal gruppo 2 che identifica la particolare tabella (VPORT, LTYPE, LAYER, STYLE, VIEW, DIMSTYLE, UCS o APPID), dal gruppo 7 che specifica il numero massimo di voci che possono seguire e da gruppi addizionali che forniscono il valore dell entità della tabella. La fine di ogni tabella è indicata con il gruppo con il valore ENDTAB. 6.1.3 La Sezione BLOCKS Questa sezione contiene tutte le entità che consentono di costruire i blocchi presenti nel disegno, comprese le campiture e le quotature associative. Il formato dell entità di questa sezione è identico a quello della precedente (fig. 25). Tutte le entità nella sezione Blocchi compaiono tra le righe Block ed endblk; è importante sottolineare che le definizioni dei blocchi non possono essere annidate (cioè Block e/o endblk non possono comparire all interno della coppia Block - endblk). 6.1. La Sezione ENTITIES Questa sezione contiene le entità del disegno (linee, polilinee, archi, cerchi e tratteggi), inclusi riferimenti ad ogni blocco. Le entità compaiono con un formato del tutto analogo alle sezioni BLOCK che ENTITIES (fig.26). Ogni entità inizia con un intero che ne identifica il tipo, contiene il nome del layer sul quale risiede ed il valore della variabile ad essa associato. Alcuni gruppi che definiscono un entità sono sempre presenti, mentre altri sono opzionali e compaiono solo se i loro valori differiscono da quelli di default. La figura 27 mostra il listato di un file DXF relativo ad un quadrato di lato pari a mm. 19

7. Il formato VRML VRML (Virtual Reality Modeling Language) è un formato di file per l intercambio di oggetti ed ambienti tra sistemi grafici 3D integrati e multimediali. La sua nascita è da ricondursi al 199, anno in cui Mark Pesce e Tony Parisi svilupparono una prima applicazione hardware indipendente. Un file VRML è un semplice file ASCII che contiene al suo interno tutte le informazioni necessarie a descrivere una scena tridimensionale comprensiva di oggetti, espressi in termini di forma, colore, tessitura o altro, ma anche a posizionarli e spostarli in uno spazio 3D. Ai fini della visualizzazione ed interazione, ogni file è processato da un programma ( browser). il VRML è stato progettato per rispondere alle seguenti esigenze: - sviluppare applicazioni capaci di creare, editare gli oggetti, come, ad esempio, programmi per la conversione di altri formati 3D; - fornire la possibilità di utilizzare e combinare oggetti dinamici 3D garantendone la riutilizzabilità; - consentire di aggiungere nuovi tipi di oggetti non esplicitamente definiti nel formato; - permettere l implementazione di una notevole varietà di applicazioni; - permettere di introdurre ambienti 3D dinamici di dimensioni arbitrarie. VRML consente, quindi, di rappresentare ambienti 3D statici o dinamici ed oggetti multimediali collegati ad altri elementi come testo, suoni, filmati ed immagini. VRML può essere utilizzato in una grande varietà di applicazioni come visualizzazioni scientifiche ed ingegneristiche, presentazioni multimediali, pagine web ed ambienti virtuali. 7.1 Specifiche funzionali del formato VRML ISO/IEC 1772, Virtual Reality Modeling Language (VRML), definisce un formato di file che integra grafica e multimedialità. Concettualmente, ogni file VRML è uno spazio 3D temporizzabile che contiene degli oggetti che possono essere dinamicamente modificati attraverso una grande varietà di meccanismi. ISO/IEC 1772 non definisce dispositivi fisici o altri elementi dipendenti dalle applicazioni (ad esempio la risoluzione dello schermo ed i dispositivi di input); esso è inteso per una grande varietà di dispositivi ed applicazioni e permette un ampio raggio di interpretazioni ed implementazioni di funzionalità (ad esempio ISO/IEC 1772 non assume l esistenza di un mouse o di un monitor come unici elementi per l interazione e la visualizzazione della scena). Ogni file VRML: stabilisce implicitamente un sistema di coordinate spaziali per tutti gli oggetti definiti nel file; definisce e compone esplicitamente un insieme di oggetti 3D e multimediali; può specificare collegamenti ipertestuali con altri file o applicazioni; 2

può definire il comportamento di un oggetto. Un importante caratteristica del file VRML è la possibilità di comporre insieme file diversi sia per inclusione diretta che per mezzo di collegamenti ipertestuali. Ciò consente uno sviluppo modulare di strutture anche molto complesse; ad esempio, la realizzazione di un file VRML di un assieme meccanico può essere suddivisa, in successione, nell esecuzione di file che contengono i diversi gruppi, sotto-gruppi e particolari che lo compongono. L unica accortezza da seguire sarà quella di assicurare che ogni oggetto sia completamente descritto nel file che lo contiene. Quindi, una gestione gerarchica di file permette la creazione di ambienti dinamici di qualsiasi dimensione. 7.2 La struttura di un file VRML Un file VRML è costituito dai seguenti componenti principali: 1) header; 2) scene graph; 3) prototypes; ) event routing. 7.2.1 Header L header è una linea singola che identifica il file come un VRML ed il formato della messa in codice del file. Un esempio di header risulta, quindi: #VRML V2. utf8. In pratica questa riga serve al browser accertarsi che il formato del file sia effettivamente vrml. utf8, indica un particolare tipo di codifica che consente anche l'uso di caratteri non ASCII, laddove si scriva il files, per esempio, in cirillico. 7.2.2 Scene Graph Tale sezione contiene i nodi che descrivono gli oggetti e le loro proprietà. In altri termini, contiene le geometrie gerarchicamente raggruppate, per ottenere una rappresentazione audio-visiva dell oggetto, ed i nodi che partecipano alla generazione di eventi ed ai dispositivi di movimento. In figura 28 viene presentato la parte Scene Graph di un listato di un file VRML per la rappresentazione di una sfera di raggio unitario e colore rosso. Il nodo Shape serve per rappresentare, nel nostro caso una sfera; esso contiene al suo interno due fields (campi) che sono il field appearance e il field geometry. Si noti come i nomi dei nodi hanno sempre la prima lettera maiuscola. Il field appearance definisce le caratteristiche fisiche dell'oggetto, mentre il field geometry ne definisce la forma. La combinazione di questi due completa il nodo Shape. In questo esempio, all'interno del field appearance è presente il nodo Appearance, che a sua volta, contiene il field material. Lo Scene Graph può contenere diversi nodi 21