Knowledge Based Engineering

Transcript

1 Sviluppo di servizi e strumenti operativi per agevolare l introduzione nelle PMI della Provincia di Milano di soluzioni innovative di Progettazione Automatica basate su sistemi di Knowledge based innovative per Provincia di Milano Determina N 206 del 29 Novembre 2007 Milano, Settembre 2008 Alintec Scarl via Garofalo, Milano tel fax info@alintec.it P.Iva e C.F

2 Sommario 1 Richiami al progetto... 4 OUTPUT DEL PROGETTO Introduzione Indagine sullo Stato dell Arte nel settore dei sistemi tecnici KBE La conoscenza nei processi di sviluppo prodotto Definizione di conoscenza e processi di acquisizione La conoscenza nella progettazione Metodi di rappresentazione della conoscenza ingegneristica Tecnologie di rappresentazione della conoscenza basate su rappresentazione CAD I sistemi KBE e le loro funzionalità Definizione Classificazione Applicazioni Nell industria automobilistica Nell industria aerospaziale In altri ambiti industriali Analisi degli aspetti rilevanti nella Progettazione Automatica Rappresentazioni delle architetture di prodotto Rappresentazione del processo di progettazione Riuso e condivisione della conoscenza Integrazione delle applicazioni di PA con i sistemi PLM o PDM aziendali Definizione delle metodologie e degli strumenti ottimali per la realizzazione di sistemi KBE all interno di PMI MOKA KOMPRESSA DEKLARE Altre metodologie CommonKADS RAD Alintec Scarl - Milano, Settembre 2008 [2]

3 5.4.3 REFIT Analisi e formalizzazione dei processi di progettazione IDEF UML GRAI Net Progettazione di un servizio basato su sistemi KBE di supporto alla progettazione all interno di PMI Una metodologia per lo sviluppo di applicazioni di PA Definizione delle specifiche di progetto Acquisizione della conoscenza Formalizzazione della conoscenza Rappresentazione della conoscenza Implementazione operativa del servizio progettato nelle PMI Concetti generali MEDEA per la rappresentazione dell architettura di prodotto La famiglia di presse piegatrici di lamiere Acquisizione, formalizzazione e rappresentazione dell'architettura di prodotto MEDEA per la rappresentazione di processi di progettazione Lo scambiatore di calore Acquisizione e formalizzazione del processo di dimensionamento MEDEA per il riuso dell'applicazione La macchina utensile formatrice di molle Riuso del codice dell applicazione MEDEA per l integrazione con sistemi PDM/PLM L agitatore di fluidi Integrazione del sistema di progettazione automatica con'archivio aziendale dei componenti Risultati conseguiti Bibliografia Alintec Scarl - Milano, Settembre 2008 [3]

4 1 Richiami al progetto Il presente progetto vuole essere un contributo allo studio di alcuni aspetti inerenti la Progettazione Automatica (PA) nel campo del Prodotto Ingegneristico e nel contesto delle Piccole e Medie Imprese (PMI). Si propone una metodologia denominata MEDEA (MEthodology for DEsign Automation), che trae sostanza da una sintesi dello stato dell arte in diversi settori della gestione della conoscenza e dello sviluppo di applicazioni PA. Si vuole sperimentare MEDEA in alcuni contesti aziendali, caratteristici delle PMI del settore meccanico ed i risultati conseguiti ne hanno permesso la validazione. Il primo rilevante contributo del progetto è un analisi dettagliata dello stato dell arte nei settori dell acquisizione della conoscenza, delle tecniche di formalizzazione e dei metodi di rappresentazione. Un secondo contributo riguarda la definizione di problemi specifici della PA quali: la rappresentazione del prodotto e del processo di progettazione, il riuso e la condivisione della conoscenza, l integrazione delle applicazioni di PA con i sistemi aziendali di gestione documentale, quali i sistemi PDM (Product Data Management) e PLM (Product Lifecycle Management). Dopo la discussione sui punti precedenti, si vuole elaborare la metodologia MEDEA, che risponde ai requisiti definiti dalla trattazione sulla progettazione automatica e che prende in considerazione lo studio settoriale dello stato dell arte. In seguito, si vuole effettuare una sperimentazione della metodologia per verificarne la validità ed affinarne i contenuti. Tale sperimentazione viene eseguita in diversi contesti aziendali, su quattro tipi di prodotti, emblematici per evidenziare i diversi aspetti inerenti lo sviluppo di un applicazione di PA. In particolare, si presentano le fasi di acquisizione, formalizzazione e rappresentazione della conoscenza di prodotto nel caso di una pressa piegatrice di lamiere e del processo di progettazione per uno scambiatore di calore. Inoltre, si affrontano i problemi del riuso di parti di un applicazione sviluppata per il dimensionamento automatico di una macchina utensile per la produzione di molle e dell integrazione di un applicazione PA con un sistema PDM nel caso specifico della configurazione di un agitatore industriale di fluidi. Come risultato della sperimentazione, oltre allo sviluppo delle applicazioni citate, sono state affinate le varie fasi della metodologia MEDEA. Alintec Scarl Milano, Settembre 2008 [4]

5 OUTPUT DEL PROGETTO 2 Introduzione Questo progetto è anzitutto un contributo allo studio di alcuni aspetti inerenti la Progettazione Automatica (PA), con particolare riguardo alle applicazioni sviluppate con i sistemi Knowledge Based Engineering (KBE), nel campo del prodotto ingegneristico e nel contesto delle Piccole e Medie Imprese (PMI). Inoltre, esso intende proporre un possibile approccio alla soluzione della problematica considerata. Gli obiettivi fissati sono riassunti nei seguenti punti: - individuazione degli aspetti fondamentali relativi alla formalizzazione ed alla rappresentazione della conoscenza ed all integrazione delle applicazioni di PA nella rete informatica aziendale; - definizione di una metodologia ad hoc per lo sviluppo di applicazioni di Progettazione Automatica adattata alle esigenze e specificità delle piccole e medie imprese (PMI) operanti nel settore meccanico; - valutazione dell adeguatezza di metodologie e strumenti in tale contesto. Si intende per PA una metodologia che permette l automatizzazione della progettazione di un prodotto mediante strumenti IT. Essa si basa sulla rappresentazione delle procedure e delle regole che un esperto di dominio applica per raggiungere l obiettivo costituito dal nuovo prodotto. Nei casi di prodotti per i quali l architettura ed il processo di progettazione sono ben definiti, appare rilevante il contributo della tecnologia e degli strumenti KBE, che si dimostrano particolarmente adatti allo sviluppo di applicazioni di PA. La letteratura scientifica internazionale presenta numerosi contributi nei diversi settori specifici correlati all automazione della progettazione e, nello specifico all applicazione dei sistemi KBE. In particolare, molti studi settoriali sono stati compiuti per quanto concerne l acquisizione, la formalizzazione e la rappresentazione stessa della conoscenza, fornendo risultati molto interessanti. Tuttavia, questi risultati sono stati appannaggio esclusivo di grandi gruppi industriali ad elevato contenuto tecnologico, come industrie aeronautiche e automobilistiche. Il motivo risiede sostanzialmente nelle elevate competenze informatiche richieste al team di sviluppo, nella limitata facilità di utilizzo dei sistemi KBE, nella familiarità con i temi di integrazione delle risorse informatiche, nella disponibilità di procedure standardizzate e formalizzate per il processo di sviluppo prodotto. Inoltre, nel caso delle PMI, si somma un elevata inerzia psicologica e quindi un insufficiente motivazione all innovazione, oltre a limitate risorse finanziarie e umane. Negli ultimi anni, l evoluzione delle tecnologie IT sempre più accessibili e performanti ha teoricamente esteso il campo di utilizzo dei sistemi KBE anche alle PMI,oltre alle grandi realtà industriali. I vantaggi sono molteplici: automazione dei processi di progettazione, corretta applicazione delle Best Practice aziendali, supporto alla progettazione per i meno esperti, accelerazione del processo di sviluppo del prodotto. Ciononostante, si osserva che le tecnologie KBE e le applicazioni di PA non hanno ancora trovato campo fertile nel settore delle PMI. L obiettivo del progetto è quello di contribuire a rimuovere gli ostacoli alla diffusione di tali tecnologie nel settore delle PMI di tipo meccanico. Essa intende elaborare una metodologia pensata ad hoc che basi le proprie attività sullo studio e la sintesi di quanto esistente in letteratura per i campi tipici di Alintec Scarl Milano, Settembre 2008 [5]

6 applicazione della tecnologia KBE, ossia i settori aeronautico e automobilistico. Si intende svolgere la ricerca con la seguente metodologia. Innanzitutto, è necessario svolgere un indagine sullo stato dell arte nel settore dei sistemi KBE, dell acquisizione e della formalizzazione della conoscenza, delle metodologie di sviluppo di applicazioni di PA. Successivamente, si intende trattare alcuni argomenti fondamentali nella PA, relativi alla rappresentazione, al riuso e alla condivisione della conoscenza; di seguito, si vuole proporre una metodologia contestualizzata al settore specifico delle PMI conseguentemente, è indispensabile eseguire una sperimentazione mediante sviluppo di applicazioni di PA per prodotti meccanici tipici realizzate in collaborazione con PMI e, infine, si dovrebbe procedere ad un affinamento della metodologia secondo i risultati della sperimentazione. Il progetto è stato articolato in cinque fasi: - La fase 1 presenta lo stato dell arte di settori propedeutici alla ricerca riguardanti le metodologie di acquisizione, formalizzazione e rappresentazione della conoscenza. In particolare, si mostrano le tecnologie KBE, le metodologie per l acquisizione e la formalizzazione della conoscenza di prodotto e di processo e le tecniche di analisi. - La fase 2 tratta alcuni aspetti tipici della Progettazione Automatica. Essi sono la rappresentazione di prodotto e di processo, il riuso e la condivisione della conoscenza e l integrazione delle applicazioni con sistemi di gestione documentale come i PDM. - Le fasi 3 e 4 presentano una metodologia sviluppata dai proponenti del progetto e indirizzata allo sviluppo di applicazioni di PA per PMI. - La fase 5 presenta la sperimentazione della suddetta metodologia in contesto industriale, mostrando la sua validità negli aspetti tipici della progettazione automatica citati, nel contesto di quattro realtà industriali. Infine, sono state riportate le conclusioni dell intero progetto. Alintec Scarl Milano, Settembre 2008 [6]

7 3 Indagine sullo Stato dell Arte nel settore dei sistemi tecnici KBE Di seguito si illustra lo stato dell arte sui temi necessari allo svolgimento del progetto, prendendo in considerazione tre argomenti principali - metodi e strumenti di rappresentazione e analisi dei processi; - sistemi KBE e loro funzionalità; - principali metodologie di sviluppo di applicazioni KBE; Il primo gruppo raccoglie le tecniche di rappresentazione di prodotto utilizzate sia per la progettazione sia per la creazione di applicazioni di Progettazione Automatica. Inoltre, sono riportate le tecniche utilizzate nel campo dell analisi di processo per rappresentare e l ottimizzare i flussi di informazione e le procedure adottate in azienda. Nel gruppo sui sistemi KBE, si introducono le definizioni in merito, si mostrano le strutture principali di un sistema KBE, si studiano le funzionalità, si descrivono alcuni software in commercio e si riporta qualche esempio di applicazione. Nell ultimo gruppo, sulle principali metodologie di sviluppo, sono presentati gli studi condotti in merito, illustrando i principali risultati nel settore aeronautico ed automobilistico, dove le metodologie sono state sviluppate. Prima di trattare i tre argomenti, si vuole di seguito riportare una trattazione sulla definizione di conoscenza così come riportata nella Letteratura Internazionale. 3.1 La conoscenza nei processi di sviluppo prodotto Di seguito si presenta una trattazione sulla conoscenza ingegneristica, riportando alcune definizioni, contestualizzandola nel campo della progettazione meccanica e discutendo i metodi di rappresentazione della conoscenza Definizione di conoscenza e processi di acquisizione Wallace [Wallace; 1999], in un suo articolo, definisce la conoscenza a partire dai concetti di Dato, Informazione e Conoscenza. I dati possono essere descritti come "uno o più simboli che rappresentano qualcosa". I dati sono oggettivi ed indipendenti dalla possibilità di un osservatore di capirne il significato. In un contesto specifico, i dati si trasformano in informazioni: se l osservatore è in grado di interpretare l informazione, l informazione diventa conoscenza. Ciò che trasforma l informazione in conoscenza è il Know-How dell osservatore. Infatti, più si acquisisce esperienza dai casi passati e dallo studio della specifica letteratura, più si è in grado di accumulare altra con coscienza. La conoscenza è definibile, secondo Wallace, come il blocco elementare di esperienza che popola l intelletto umano. Inoltre, l acquisizione di nuova conoscenza avviene attraverso la conoscenza già acquisita, nel senso che rende gli esseri umani in grado di interpretare i nuovi dati e di trasformarli in conoscenza nuova. Nel contesto della progettazione meccanica, è importante definire quale tipo di conoscenza sia possibile acquisire e rappresentare. Perciò, è necessario definire come le informazioni si trasformino in conoscenza. Eder [Eder; Alintec Scarl Milano, Settembre 2008 [7]

8 2004] descrive il modo con cui conoscenza è acquisita. Nel suo articolo egli sostiene che la conoscenza è derivata dall informazione attraverso processi di deduzione, induzione, riduzione/adduzione, o innoduzione. Kerr [Kerr; 1990] descrive i processi di trasformazione dell informazione in conoscenza. Nel suo lavoro egli dichiara che i dati sono acquisiti dall intelletto umano attraverso gli stimoli sensoriali, quindi sono generalizzati e strutturati in gruppi al fine di creare entità di alto livello, tutte correlate fra di loro. Questo set di costrutti e di relazioni definisce l umana comprensione della natura e fornisce una nuova base per interpretare nuovi stimoli. La conoscenza umana è quindi il set dei costrutti definiti dalle nostre intelligenze. Le informazioni sono cosituite da ogni nuovo dato che modifica la struttura della conoscenza se interpretata in uno specifico contesto. Quindi i dati possono essere considerati oggettivi mentre le informazioni e la conoscenza sono soggettive. Prima di proseguire è necessario porre un altra caratterizzazione della conoscenza. Essa può essere: esplicita, se rappresentata; oppure implicita, se non è rappresentata. La conoscenza esplicita è quella generale e comunemente nota nel particolare campo d applicazione(come ad esempio la teoria di progettazione meccanica presente nei manuali tecnici), mentre la tacita è quella personale che deriva dalle esperienze che ogni progettista acquisisce durante le attività quotidiane e che possono essere anche soggettive (per esempio la particolare esperienza di un progetto passato) La conoscenza nella progettazione In letteratura sono presenti un gran numero di classificazioni della conoscenza usata in processi di progettazione. Nella sezione Knowledge Representation dell opera di Sriram [Sriram; 1997] è presentata una lista non strutturata dei tipi di conoscenza usati comunemente durante le attività di progettazione; essi spaziano dalla conoscenza ad Oggetti (e sue proprietà) alla conoscenza Procedurale, dall Euristica all Analogica, fino alla conoscenza delle Casualità, delle Assunzioni, delle Analogie, ecc. Ciò a prima vista indica come i processi di progettazione sono fortemente dipendenti dalla conoscenza e necessitano di diverse categorie di conoscenza per essere svolti. È inoltre importante notare che i problemi di progettazione possono essere indefiniti e talune conoscenze, quindi, provenienti dalle esperienze di progetti di successo. Sriram fa inoltre notare come questo genere di conoscenza abbia un certo grado di affidabilità intrinseco. Sekiya, Tsumaya e Tomiyama [Sekiya; 1998] presentano una classificazione della conoscenza ingegneristica utilizzata durante le attività di modellazione di prodotto (es: Modellazione CAD, CAM, FEA, ecc ); la classificazione della conoscenza è dedotta esplicitamente da un caso presentato nell articolo. Nell articolo di Caillaud e di Dupriieu [Dupriieu; 1999], è sinteticamente proposta una classificazione basata sui livelli di astrazione delle regole di progettazione dove la conoscenza di precedenti esperienze è tradotta in regole comuni usate per l'insieme di applicazioni (cioè conoscenza generica) in principi generali conosciuti ed espressi generalmente in letteratura tecnica. In Van Handenhoven, Trassaert [Van Handenhoven; 1999] è introdotta una importante distinzione fra conoscenza esplicita e tacita (o implicita): queste sono riportate come conoscenza tecnica generale e conoscenza know-how, riferita alla conoscenza soggettiva delle esperienze dei progetti passati. È interessante notare che mentre il primo è esplicito e invariante, il secondo è tacito e soggettivo: ciò lo rende difficile da catturare e formalizzare. Ishino e Jin [Ishino; 2002] rappresentano una mappa completa delle conoscenze funzionali di progettazione limitate all attività di singolo progettista, suddividendole in conoscenza di dominio e strategica. La prima è associata alla Alintec Scarl Milano, Settembre 2008 [8]

9 descrizione dei problemi di dominio ingegneristico, mentre la seconda è relativa ai processi ed alle scelte progettuali. Le due classi principali sono quindi suddivise in 14 categorie inferiori riportate in Figura 1 e dettagliatamente descritte nell articolo. Figura 1- Conoscenze associate al Processo di Progettazione secondo Ishino e Jin E opportuno notare che una volta di più è introdotta una distinzione fra conoscenza implicita (dominio) ed esplicita (strategica), ma che questa volta gli autori concentrano la loro attenzione sulla conoscenza personale per renderla disponibile all interno di sistemi di supporto alla progettazione. In [Sim; 2001], poi, Sim e Duffy propongono un ontologia della conoscenza delle attività di progettazione; ciò fornisce una categorizzazione completa delle attività di progettazione e dei relativi input, output e della conoscenza associati: le attività di progettazione sono generalizzate sulla base di un formalismo comune che considera la conoscenza degli input, l attività di progettazione, l obiettivo e la conoscenza dell output e sono quindi categorizzate. La loro categorizzazione corrisponde a tre gruppi principali, che sono definizione di progetto, valutazione di progetto e gestione di progetto. La prima è associata alle attività di sintesi del progettista ed alla relativa creazione di nuove soluzione progettuali; la seconda si occupa della riduzione della complessità dello spazio di solutivo e della complessità del decison making; la terza è correlata alla gestione delle soluzioni e del processo di progettazione. Queste categorie principali sono, poi, suddivise sottoattività di dettaglio e per ciascuna è specificata la conoscenza associata. Un esempio delle attività detailing della classe definizione di progetto è riportata in Figura 2 Alintec Scarl Milano, Settembre 2008 [9]

10 Figura 2- La conoscenza associata alle attività di Progettazione di dettaglio in Sim e Duffy [Sim; 2001] Metodi di rappresentazione della conoscenza ingegneristica La conoscenza ingegneristica, a seconda dello strumento di rappresentazione assume diverse forme, che comunicano specifiche informazioni mirate al dominio di competenza del progettista. L informazione e la conoscenza di cui sopra vanno rappresentate utilizzando strumenti opportuni, siano essi un linguaggio di programmazione strutturato o ambienti di sviluppo complessi ed articolati. Tali strumenti offrono una rappresentazione della conoscenza con minore o maggiore complessità e articolazione. Strumenti molto utilizzati a supporto della progettazione sono ad esempio quelli CAD, di analisi strutturale FE, di analisi cinematica e dinamica, ma anche fogli elettronici, linguaggi di programmazione, shell esperte. Con questi strumenti si ottiene un primo livello di rappresentazione delle informazioni e delle conoscenze utilizzate nella fase di progettazione; si tratta di informazioni e conoscenze limitate ad uno specifico aspetto per esempio geometrico/topologico, funzionale, di resistenza strutturale piuttosto che cinematico o dinamico. In particolare si rileva il ruolo di fondamentale importanza che nella progettazione industriale ricopre la morfologia dei componenti ed altrettanto si può dire per i vincoli e le relazioni che permettono di aggregare le parti in assieme. Pertanto, anche il solo prototipo virtuale di un prodotto rappresenta, in modo implicito nella forma dei componenti e nei vincoli tra le parti, un elevata quantità di informazioni e di conoscenze. Le informazioni e le conoscenze trattate a questo livello sono sia di tipo di dominio che strategico; ad esempio, la caratteristica morfologia di un albero con sezioni di diametro diverso è determinata sulla base di conoscenze di dominio mentre il valore di un raggio di raccordo o la finitura di una superficie possono essere ritenuti di tipo strategico, in quanto possono essere determinate sulla base delle specifiche competenze aziendali o personali. Si ha un secondo livello di rappresentazione della conoscenza quando si integrano almeno due tipologie di informazioni e conoscenze sul prodotto, per esempio quelle di tipo geometrico e topologico con quelle di criteri di dimensionamento e di verifica. Questi ultimi spesso ben si prestano alla codifica in algoritmi e quindi alla rappresentazione con linguaggi di programmazione strutturata o con fogli di calcolo elettronici. Un esempio tipico è dato dalle applicazioni di dimensionamento automatico di parti e semplici complessivi realizzate integrando modelli geometrici parametrici e fogli di calcolo; il dimensionamento può essere ottenuto semplicemente correlando parametri geometrici, oppure valutando formule matematiche più o meno complesse o iterando procedure e verificando condizioni fissate. Molte applicazioni di ausilio alla progettazione sviluppate in piccole e medie aziende sono realizzate seguendo questo approccio. Anche l integrazione di informazioni e conoscenze di tipo geometrico e funzionale (strutturale, cinematica e via dicendo) rappresenta un esempio tipico di questo livello. Una rappresentazione della conoscenza basata su algoritmi si rivela però limitata in molti casi, ad esempio nella gestione di sistemi con architettura Alintec Scarl Milano, Settembre 2008 [10]

11 complessa oppure quando si devono gestire varianti di progetto che richiedono parti diverse, come nel caso si intendano sostituire dei gruppi funzionali con altri. Anche in questo caso, la conoscenza da rappresentare è sia di dominio sia strategica, aziendale o personale. Un terzo livello di rappresentazione della conoscenza è richiesto quando si intendano realizzare applicazioni in grado di gestire situazioni quali ad esempio quelle citate precedentemente, cioè architetture di prodotto complesse con varianti per alcune parti. A questo scopo si è dimostrata particolarmente adatta la metodologia object-oriented; diversi sono gli strumenti per lo sviluppo di applicazioni realizzati negli ultimi anni e basati su questo approccio. La potenzialità di questo approccio nel rappresentare informazioni e conoscenza dipende dal fatto che l architettura di moltissimi prodotti è intrinsecamente object-oriented, cioè strutturata in entità a livelli gerarchici diversi, diversi, caratterizzate da attributi che possono essere determinati da metodi che implementano regole di celta oppure procedure di calcolo, dimensionamento verifica e via dicendo. A questo livello di rappresentazione della conoscenza corrisponde un ruolo non più dominante dell informazione e della conoscenza implicitamente rappresentata nel modello geometrico e funzionale, che finisce per assumere un importanza paritaria a quelle relative ad altri aspetti, per esempio tecnologico, normativo, dei materiali. Si noti però che un approccio di tipo object-oriented presenta difficoltà nel rappresentare il processo di progettazione in modo indipendente dall architettura del prodotto; infatti, le procedure di scelta, configurazione, dimensionamento vengono rappresentate con metodi associati alle parti, senza definire una sequenza cronologica delle attività. Il quarto livello porta al superamento dei limiti prima indicati mediante l integrazione della rappresentazione dell architettura del prodotto, con le corrispondenti informazioni e conoscenze di tipo geometrico e funzionali, e del processo di progettazione con la relativa conoscenza. L architettura di prodotto anche in questo caso è rappresentata utilizzando un approccio object-oriented, mentre in parallelo si può rappresentare un processo tipicamente sequenziale quale quello che connette le diverse attività previste per lo sviluppo prodotto. Uno strumento che permette la realizzazione d applicazioni con queste caratteristiche è per esempio RuleStream dell omonima società di sviluppo software Tecnologie di rappresentazione della conoscenza basate su rappresentazione CAD Le tecnologie basate su rappresentazione CAD prediligono la rappresentazione grafica del dato geometrico rispetto ad altri tipi di dati. Come introdotto in precedenza, esse non permettono una rappresentazione completa della conoscenza, seppur possibile, ma il loro utilizzo è talmente diffuso che se ne presentano comunque in questa sede le principali caratteristiche. Il dato geometrico che esse rappresentano è solitamente gestito attraverso parametrizzazione mediante utilizzo di software che permettono l inserimento di formule come ad esempio tool presenti nei software CAD stessi, fogli di calcolo elettronici o applicazioni create ad hoc per il modello geometrico mediante uso di linguaggi di programmazione. I più diffusi sistemi CAD permettono, grazie all approccio feature based, la gestione dei parametri di configurazione del prodotto, quali le quote, il materiale, la quantità o l esistenza, avendo così una maggiore strutturazione del dato geometrico, che si presenta sotto forma di unità costruttive parametriche e non sotto forma di intersezione di forme basilari. Alintec Scarl Milano, Settembre 2008 [11]

12 Il primo metodo consiste nello sfruttare alcune funzionalità che sono già implementate all interno di diversi software CAD e che permettono la scrittura di regole di parametrizzazione. Di seguito, si descrivono queste funzionalità implementate in alcuni tra i maggiori software CAD presenti nel mercato. SolidEdge SolidEdge di Unigrapics Siemens permette la parametrizzazione dei prodotti mediante due approcci. Il primo, attraverso l uso di tabelle, abilita l utente a modificare i valori dei parametri mediante formule e collegamenti con altri parametri, appartenenti al file stesso o ad altri file, sia nei file di tipo part sia in quelli di tipo assembly. Il secondo approccio prevede invece la gestione di famiglie di parti e di assemblati, nelle quali è possibile definire quali componenti selezionare per una particolare struttura di prodotto, come assemblarli, quali feature attivare, quali parametri modificare. In tal modo, con un solo file, si può tenere traccia di diverse configurazioni ed estrapolare quella richiesta. SolidWorks SolidWorks della Dassault Systemes si approccia anch esso alla parametrizzazione mediante due sistemi. Il primo consiste in un tool in cui si possono editare ed elencare formule, il secondo consiste in un elenco di configurazioni definite a priori. Nel primo caso, le formule vengono compilate e mostrate mediante interfaccia ad elenco. Nel secondo caso, una volta modificate le quote di riferimento, è possibile salvare nel file primario la configurazione scelta e richiamarla successivamente dalla tabella delle configurazioni. Catia La suite Catia della Dassault Systemes offre, nel pacchetto Mechanical Design qualche strumento in più per la parametrizzazione dei componenti e degli assemblati. Infatti, essa fornisce uno strumento per l implementazione di regole, una per la definizione di formule più complesse scritte in linguaggio proprietario o in VB, uno strumento per il controllo degli eventi e uno per il controllo degli errori. Un altro strumento interessante, concettualmente a metà strada fra CAD parametrico e KBE è Power Copy, che permette di selezionare componenti, prodotti da poter riutilizzare in un altro contesto, trasformandoli in librerie di oggetti utente alla quale si accede attraverso un interfaccia di inserimento dati principale. NX4 NX4 della Unigraphics Siemens, offre all incirca gli stessi strumenti offerti da Catia. Il linguaggio di sviluppo è C++. User Defined Object è lo strumento simile a Power Copy di Catia. L integrazione con fogli di calcolo avviene grazie alle funzionalità dei modellatori CAD che permettono il collegamento dei parametri di modellazione alle celle del foglio di calcolo, potendo così gestire le formule per la parametrizzazione dall esterno del modello CAD. Tale approccio, a differenza del primo, permette eventuali integrazioni con software che si interfacciano anch essi con fogli di calcolo. 3.2 I sistemi KBE e le loro funzionalità Dagli anni 60 nel campo militare aeronautico e dal 1984 nei campi civili di aviazione e automobilistica, i sistemi Knowledge Based Engineering (KBE) permettono di configurare e progettare un prodotto in maniera automatica e di formalizzare il Know - How e il Know - Why dei processi di progettazione e di renderli Alintec Scarl Milano, Settembre 2008 [12]

13 disponibili a tutti i progettisti. Con un sistema KBE è possibile ridurre anche fino al 90% il tempo speso nella progettazione a seguito delle seguenti caratteristiche: - supporto al progettista durante l'intero processo di progettazione con gestione degli errori; - automazione delle attività ripetitive; - ricerca automatica delle informazioni, aggiornate e corrette; - generazione in automatico dei modelli CAD e dei documenti relativi al prodotto Definizione In letteratura troviamo diverse definizioni di tecnologia KBE (Knowledge Based Engineering). Una delle più rappresentative è data da Javed [Javed; 2004], che sostiene che la tecnologia KBE è "il processo di combinazione della conoscenza ingegneristica, delle sue metodologie, regole e best practice, con la conoscenza e le best practice dei processi di progettazione per la realizzazione di modelli che descrivono la definizione delle attività di progettazione del prodotto e le relative analisi ingegneristiche". Stokes [Stokes; 2001] sostiene che l'approccio KBE è "la tecnica dell'uso di software avanzati che riducono il tempo di sviluppo attraverso la cattura e il riuso della conoscenza di prodotto e di processo in maniera integrata". Più in generale, secondo Gonzales e Dankel [Gonzales; 1993], un sistema KBE è un"sistema computerizzato che usa conoscenza di un determinato dominio per arrivare alla soluzione di un problema di quello stesso dominio. La soluzione è sostanzialmente la stessa a cui arriverebbe una persona che ha la conoscenza di quel particolare dominio di applicazione se affrontasse quello stesso problema. Partendo da queste definizioni possiamo affermare che un sistema KBE è un ambiente computerizzato che guida l utente a raggiungere nello spazio delle soluzioni possibili di un problema quella migliore, alla stessa maniera con cui egli stesso/ella stessa avrebbe proceduto alla risoluzione utilizzando la propria conoscenza di dominio. La soluzione è raggiunta in maniera automatica, recuperando informazioni da più fonti, definendo la struttura finale dei prodotti e il dimensionamento dei loro componenti. I risultati delle operazioni sono generalmente visualizzati in tempo reale attraverso interfacce che solitamente includono i software di sviluppo come CAD o FEA. Col tempo la struttura dei KBE si è evoluta in maniera tale da diventare esso stesso un sistema di gestione della conoscenza ingegneristica in senso lato, in sostanza quello che nel settore viene definito un sistema di Engineering Knowledge Management (EKM). Infatti, i moderni strumenti KBE sono concepiti come integrazione di più componenti che realizzano lo scopo dei sistemi EKM. Si prenda ad esempio quello sviluppato da Kulon et Alteri [Kulon; 2004] e rappresentato in Figura 3. L'architettura di questo server KBE è composto da: - un ambiente di programmazione che usa un linguaggio logico o funzionale (in questo caso GDL/GWL (General purpose Declarative Language/Generative Web Language), sviluppato da Genworks International e derivato dall'anspi Common Language), che rappresenta il motore KBE vero e proprio; - un web - server, che l'utente utilizza per comunicare con l'intero sistema; - un Knowledge Repository, composto in questo caso da un database manager (contrassegnato da DBMS, DataBase Manager System) che colloquia col motore KBE attraverso un sistema client e nel quale sono contenuti i database relativi a regole di progettazione, materiali, unità di produzione, progetti già sviluppati con relativi documenti, gestione delle applicazioni; Alintec Scarl Milano, Settembre 2008 [13]

14 - applicazioni CAD e FEA che generano modelli in accordo con le regole di progettazione e di definizione dell'architettura definite dal motore KBE. Figura 3. - Architettura del sistema KBE sviluppato da Kulon et Alteri. Un sistema KBE è una soluzione per la gestione della conoscenza che si focalizza sulla descrizione di architetture di prodotto e di processi di progettazione. Utilizzando un linguaggio di tipo logico (il più usato per questo tipo di applicazione è Prolog) o di tipo funzionale (come il LISP), questi sistemi permettono la gestione di processi di progettazione come eventi a cui associare determinate azioni definite da regole. Per esempio, la scelta di un cuscinetto è un evento che, se attivato, mette in moto una serie di operazioni basate su regole che finalizzano l'operazione: calcolo dei carichi e delle direzioni del carico, verifica degli ingombri, scelta del componente attraverso l'uso di tabelle da database, creazione del modello CAD, creazione di tavole 2D e documenti in genere. Per far questo la maggior parte dei sistemi KBE sfrutta la logica ad oggetti con la quale si permette di rappresentare il prodotto sottoforma di struttura gerarchica ad albero contenente classi di oggetti rappresentati gruppi funzionali e componenti meccanici che, in base alle regole e ai parametri di entrata, attraverso l'uso degli eventi citati in precedenza, il cui insieme rappresenta il processo da seguire, prende la forma di un prodotto definito chiamata istanza di prodotto. Per esempio il prodotto ascensore è rappresentato tramite una struttura ad albero nella quale sono presenti le macro classi gruppo sollevamento, gruppo motore o puleggia, ma anche le classi elementari vite, bullone o cuscinetto. Queste classi non rappresentano un particolare tipo di vite; piuttosto, esse rappresentano l'insieme generale delle viti e contengono proprietà (intese come variabili) e collegamenti a dati di tipo geometrico, procedurale, regole di Alintec Scarl Milano, Settembre 2008 [14]

15 dimensionamento e documentazione varia. In base alle regole fornite, la classe "vite" genera il prodotto "vite M10", con tanto di modello CAD e documentazione relativa. Una regola può essere del tipo riportato in (1): vite.diametroreale = sqrt(vite.sezioneresistente) / π (1) dove si nota come vengono in genere indicate le proprietà (es. DiametroReale) in relazione alla classe a cui a appartengono (vite) Classificazione La trattazione che segue descrive una possibile classificazione dei sistemi KBE in base alla loro struttura. Essi possono essere divisi in tre macrogruppi a cui corrispondono le seguenti caratteristiche: - primo gruppo: sistemi autosufficienti; - secondo gruppo: sistemi incorporati; - terzo gruppo: sistemi integrabili. La discriminante sulla definizione è la relazione con i modellatori CAD, con cui i sistemi KBE generano i modelli 3D e la geometria dei prodotti. Nel primo caso il sistema CAD è integrato con il kernel del sistema KBE pertanto è autosufficiente e non ha bisogno di ulteriori software; nel secondo caso il sistema KBE si presenta come un plug-in incorporato in un modellatore CAD e non esiste a prescindere da questo; nell ultimo caso, il sistema KBE è un software che funziona indipendentemente dal CAD a cui lo si interfaccia ed è integrabile con diversi modellatori. Di seguito sono rappresentati nel dettaglio i tre Gruppi, riportati in ordine cronologico di apparizione, con qualche esempio riportato, dove è possibile comprenderne le caratteristiche principali. Primo Gruppo: sistemi autosufficienti Il primo gruppo di sistemi KBE per uso commerciale nasce nel 1984, quando esce a volta sul mercato ICAD, di KTI, ora della Dassault Systemes. Alla prima generazione appartengono tutti quegli strumenti che, come ICAD, integrano completamente tutte le funzionalità di un KBE in un solo strumento. All interno dello strumento si trova infatti: - un modellatore grafico, generalmente CAD 3D, - un ambiente di sviluppo regole nella quale è possibile rappresentare l'albero del prodotto e il processo di progettazione; - l'ambiente di progettazione per l'utente finale, nel quale si modella il prodotto specifico. Di seguito si presenta una lista di alcuni fra i più utilizzati KBE di questa generazione. KTI- The ICAD System Il sistema ICAD di KTI- Dassault Systemes è probabilmente il più diffuso e famoso KBE al mondo. La piattaforma di sviluppo è pensata per creare soluzioni locali e si chiama Standard Application Architecture" (SAA). Consta di fatto di un ambiente di sviluppo delle toolkit, di una metodologia per lo sviluppo, l applicazione ed il rilascio di quest ultima. Le principali caratteristiche del SAA sono: Alintec Scarl Milano, Settembre 2008 [15]

16 - albero dell'applicazione: costituito di elementi che possono essere assembly, subassembly o applicazioni. Le applicazioni sono spesso complesse e scritte da utenti esperti di programmazione; - rappresentazione delle regole. Sono di diversi tipi tra cui si trovano quelle di tipo diagnostico e generativo. Le regole di tipo diagnostico sono regole per la validazione del modello e generano messaggi di errore, invitando al controllo del modello. Le regole di tipo generativo, invece sono quelle che permettono la scelta ed il dimensionamento dei componenti. I loro output sono modelli 3D, disegni costruttivi, BOM, codici dele parti. Esistono inoltre regole per la creazione di interfacce tramite GUI, regole per l utilizzo di tabelle e database e regole per il rilascio del prodotto; - sistema di versioning - - interfaccia utente, cioè l ambiente di configurazione; - - modulo di integrazione CAD; - viewer, per la visualizzazione del prodotto finale. Concentra Corporation The Selling Point Selling Point (Concentra Corporation) è uno strumento KBE basato su tecnologia Object-Oriented che permette la gestione di oggetti, dette parti, (per esempio componenti meccanici), dei relativi parametri (dimensioni, forze, materiali, ecc) e le relazioni fra di loro. Gli oggetti sono organizzati in una struttura gerarchica ad albero che include le regole di assemblaggio delle parti attraverso regole. Grazie a questa caratteristica Selling Point è adatto alla configurazione di prodotti che includono diversi sottogruppi funzionali. Selling Point gestisce i modelli attraverso il linguaggio GSL (Generative Specification Language) e librerie annesse, tra cui quelle grafiche. Una volta terminata la modellazione della struttura ad albero, mediante la definizione dei nodi (ossia la definizione della struttura stessa del modello), il sistema genera un applicazione finale che permette la configurazione del determinato prodotto, attraverso un interfaccia appositamente creata. Engineering Intent (Autodesk) The Intent (ora Autodesk Intent) Intent gestisce l architettura di prodotto in maniera simile ai precedenti, mediante l uso di strutture gerarchiche ad albero che includono oggetti che hanno in sé metodi e parametri. Oltre all ambiente di modellazione e all applicazione per l utente finale, Intent dispone di moduli per la cattura e il riutilizzo della conoscenza ingegneristica e di quello che viene comunemente detto intento razionale. In definitiva, Intent è include i seguenti moduli e ambienti: - un ambiente di modellazione ad albero che gestisce le relazioni tra assemblati e sottoparti; - una libreria di funzioni e di oggetti, che include, oltre alle librerie standard di oggetti (ISL), anche librerie grafiche e oggetti database (di tipo ODBC); - un editor di formule, per la realizzazione semplificata di formule, - un navigatore di regole, un foglio di calcolo specializzato per ingegneri, che permette la creazione e il riuso delle regole di progettazione, - un ambiente di controllo, che permette in maniera veloce e configurabile di tenere sotto controllo e di eventualmente modificare tutti gli oggetti, le regole e le proprietà create nell albero. E composto da tabelle che riportano regole e parametri e di un modulo interprete che permette l esplorazione di tipo what if. Alintec Scarl Milano, Settembre 2008 [16]

17 L interfaccia finale è creata attraverso un generatore. Negli ultimi anni la casa produttrice (Engineering Intent, acquisita da Autodesk) ha implementato nel suo prodotto la possibilità di integrarsi coi maggiori prodotti di modellazione CAD, proponendolo di fatto come modellatore KBE affine a quelli della terza generazione (vedi avanti). La casa Autodesk lo ha inserito nella suite Autodesk Productstream. Secondo Gruppo: sistemi incorporati Il secondo gruppo di sistemi KBE include tutti i software plug in incorporati in modellatori CAD. Nascono all inizio degli anni 90 quando cominciarono ad affermarsi modellatori CAD 3D basati su features piuttosto che su intersezioni ed unioni di geometrie primitive. La naturale predisposizione all Object Oriented dei modelli 3D creati ha fatto in modo che i sistemi KBE apportassero solo alcune informazioni in più rispetto al modello CAD, annegando le regole, i parametri e i metodi di progettazione all interno dell albero delle parti CAD. Tipicamente, un sistema come questi, con alcune eccezioni, consta di un modulo per la creazione di regole di dimensionamento e di gestione di assemblati che vengono associate alla parte in questione. Un sistema KBE di questo tipo non può esistere quindi a prescindere da un modellatore CAD. Di seguito si prresenta una lista di alcuni fra i più utilizzati KBE di questo gruppo. Dassault Systemes CATIA V5 KnowledgeWare CATIA V5 KnowledgeWare è uno strumento usato soprattutto in ambito aereonautico. Fa parte della suite CATIA della Dassault Systemes ed è integrato con altre funzionalità del sistema, costituendo così un unico ambiente di progettazione. Si compone dei seguenti componenti - Knowledge Advisor: per creare formule, controlli e regole. Utilizza un linguaggio proprietario simile al C oppure Basic. Automatizza la progettazione e riduce gli errori. - Knowledge Expert: estensione del precedente per utilizzi condivisi all interno dell azienda. Permette ai progettisti di automatizzare le fasi della progettazione che dipendono da modifiche esterne al progetto. Utilizza macro VB, file di testo o file URL. - Product Knowledge Template: permette la standardizzazione di alcune feature piuttosto che parti o assiemi mediante la creazione di cataloghi personali contenenti non solo geometrie ma anche parametri e regole di progettazione. - Business Process Knowledge Template: permette di catturare la conoscenza aziendale, le best practice e tutti i processi di progettazione eseguiti in azienda. Crea un interfaccia dedicata all utente che può così procedere alla configurazione di prodotto. Unigraphics NX Knowledge Fusion Wave Unigraphics NX (di Unigraphics- Siemens) incorpora una serie di moduli per l automazione della progettazione basata su regole, che vanno sotto il nome di KnowledgeFusion, di derivazione Engineering Intent, già descritto in precedenza. In particolare, il modulo Wave permette la creazione di applicazioni simili a template per il riutilizzo di componenti, prodotti o anche solo feature. Il template permette di catturare l intento di progettazione oltre a metodi di progettazione e gestisce anche assemblati complessi, gestendo tutte le modifiche e le verifiche, anche per applicazioni che coinvolgono più utenti. Tutto ciò avviene mediante la specifica di Alintec Scarl Milano, Settembre 2008 [17]

18 parametri e di relative regole che sono organizzate in determinate tabelle. Il risultato è la possibilità di poter riutilizzare progetti e parti già utilizzate in precedenza inserendole man mano nell ambiente di progettazione. Molto utile è anche la possibilità di associazione di parti o assemblati fra prodotti diversi, per gestire eventuali caratteristiche in comune. Ciò garantisce miglior manutenzione e aggiornamento fra vari prodotti. Eventuali modifiche ad un prodotto si propaga automaticamente agli altri, mantenendo così ogni prodotto in versione aggiornata. I moduli principali di Wave sono: - Wave Geometry Linker: gestisce le relazioni fra componenti e assiemi durante le fasi di modellazione; - Associativity Manager: gestisce gli aggiornamenti delle parti durante le fasi di modifica; - Geometry, Part and Link Browsers: gestisce le associatività fra vari prodotti; La modellazione con Wave si può applicare alla progettazione di dettaglio, alla produzione ed anche alla definizione di layout concettuali. Terzo Gruppo: sistemi integrabili L ultimo gruppo di sistemi KBE apparsi sul mercato ripercorre per alcuni versi la strada intrapresa dagli sviluppatori dei sistemi del primo gruppo. In particolare, questi sistemi sono veri e propri programmi come quelli del primo gruppo ma si differenziano da questi per il fatto che non hanno motori e librerie grafiche interni. Al contrario, essi sono però in grado di interfacciare diversi modellatori CAD 3D, sfruttando le loro caratteristiche grafiche e la modellazione feature based. Sono inoltre capaci di integrarsi con strumenti di gestione dati come server database o PDM. Infine, molti di essi sono dotati di moduli web service per l utilizzo on line su reti. Di seguito si riportano alcuni di questi sistemi. RuleStream Sys RuleStream della RuleStream Corporation è un sistema KBE in grado di gestire le fasi di progettazione di prodotti complessi sia sul piano della struttura di prodotto che su quello dei processi di progettazione. Ha come scopo la cattura ed il facile utilizzo della conoscenza impegnata nei processi di progettazione. Il sistema una volta generato il modello dell albero dell architettura di prodotto, permette la definizione logica dei passi da seguire durante la progettazione attraverso la creazione di un applicazione utente che si configura come un ambiente di configurazione vero e proprio dove i dati, i componenti, gli assiemi e sottoassiemi dei prodotti sono resi disponibili e configurabili mediante l uso di successive interfacce. È composto di diversi moduli, a seconda che l applicazione sia di tipo stand alone o client server. Il sistema si interfaccia al momento con i seguenti strumenti: i modellatori CAD SolidWorks e Pro/Engineer, i server database Microsoft SQL e Oracle, i PDM Smart Team e MatrixOne e, siccome il sistema genera un applicazione scritta in Visual Basic 6.0 o.net, a seconda della versione, si può integrare con diversi altri strumenti come i pacchetti di tipo Office, quali Visio ed Excel. I principali moduli sono: - RuleStream Architect, per la cattura della conoscenza e la generazione di modelli di prodotto attraverso una rappresentazione ad albero. I dati vengono salvati su database. - RuleStream Platform, per la gestione dei database. - RuleStream Engineer e RuleStream Sales, ambienti virtuali di progettazione e configurazione anche on line, integrati con CAD, database e PDM. Alintec Scarl Milano, Settembre 2008 [18]

19 Design Power - Design ++ Design++ della Design Power è indirizzato ad aziende che fanno ordini su commesse. Funziona presentanto all utente una struttura ad albero nella quale si creano delle regole, usando delle formule, che definiscono quali componenti utilizzare o creare. Il linguaggio usato è proprietario (Design++ Rule Language, DRL) ed è semplice da usare. Il sistema guida un qualsiasi dei modellatori integrati a creare modelli 3D e relativa documentazione. Il modulo Design++ Visual Modeler (DVM) aiuta a scomporre il prodotto in una lista gerarchica di componenti come modello di assemblati e parti. L interfaccia è simile concettualmente a quella di un foglio di calcolo, dove cellette e formule concorrono alla formazione dell albero. Il sistema fornisce due tipi di ambienti, quello di sviluppo e quello di test. Le regole sono editate grazie all uso di Design Rule Editor, che aiuta alla compilazione nel linguaggio DRL. Il sistema ha tre ambienti per la validazione del modello: Dynamic Configurator, Execution Order Controller e Intelligent Change Manager, che controllano la bontà delle regole, il loro ordine e la propagazione dei cambiamenti. KB4 Limite-DriveWorks è un software capace di analizzare componenti e assemblati esistenti creando regole per la loro modifica. Le regole e la conoscenza associata al prodotto sono archiviate in database creati appositamente. Il sistema non richiede conoscenze di programmazione e si presenta con un interfaccia concettualmente simile a quella di folgi di calcolo.permette la creazione di BOM e può madare informazioni a PDM ed ERP. Il sistema si interfaccia con SolidWorks ed il sistema di costruzione del modello è guidato da un semplice wizard. Imaginestic i-config Come altri sistemi presentati in questa sezione, i-config crea applicazioni automatiche indirizzate alla progettazione, all ingegnerizzazione e alla vendita e al supporto di prodotti. È integrato con i maggiori sistemi CAD ed ERP. Le applicazioni generate possono essere indirizzate sia a venditori che a progettisti che a personale di supporto o fornitori. Funziona anche attraverso internet. Rule Matrix permette all utente di definire un proprio processo di configurazione. Regole, parametri e dati sono archiviati in repository esterni come Oracle o Microsoft SQL. Il sistema crea applicazioni utente mediante linguaggio Java e si interfaccia con diversi modellatori CAD. permette il riutilizzo di componenti e progetti passati. Emergent Systems Emergent System offre diverse un ambiente di progettazione con diversi moduli. In particolare, KBE Manager permette la gestione di regole di configurazione di prodotto. Integrato in un ambiente di progettazione chiamato E2ks, esso permette la cattura, la formalizzazione, la condivisione e il riuso del Know How aziendale. Altri sistemi EASA system (AEA Technology), EnCapta (Vistagy) and isight Engineous Software) sono sistemi KBE che permettono all utente di creare ambienti integrati con diversi sistemi CAD, FEM, PDM, ecc. Si stanno diffondendo in questi ultimi anni sistemi KBE che non si appoggiano sulla rappresentazione di prodotto, ma si basano sulla rappresentazione procedurale di attività informatiche da svolgere nel caso alcuni eventi vengano attivati.per esempio il software RuleDesigner non permette la rappresentazione dell albero di prodotto, ma la Alintec Scarl Milano, Settembre 2008 [19]

20 gestione del modello mediante procedure pre-compilate per la gestione di un modello tipicamente CAD. La stessa cosa si ritrova nel software della CadWorksSoftware, anche se la gestione passa attraverso un foglio di calcolo Excel (da non confondere con una semplice parametrizzazione di prodotto) piuttosto che attraverso procedure compilate. Questi software costruiscono (o caricano su un modellatore CAD) il modello CAD man mano che le procedure definite lo richiedono. Per esempio se in un determinato punto della rappresentazione procedurale vi è un nodo in cui si richiede di scegliere un particolare compone (es. tramite un paradigma IF THEN ELSE) in base alle scelte, utente che in genere avvengono mediante interfaccia specifica, il sistema importa dati del componente corretto (sia esso un file CAD piuttosto che una serie di parametri). Di seguito si riporta in Tabella 1 alcuni sistemi KBE ed i loro riferimenti. Tabella 1. Alcuni riferimeni KBE commerciali. 3.3 Applicazioni I sistemi KBE possono essere utilizzati per risolvere varie problematiche di progettazione nel campo ingegneristico, che sia quello aerospaziale o automobilistico, quello di prodotti industriali o nell ambito delle scienze delle costruzioni Nell industria automobilistica L azienda automobilistica Jaguar è stata una delle prime compagnie europee ad utilizzare un sistema KBE sviluppando delle applicazioni che hanno permesso una riduzione dei tempi per la produzioni di nuove tipologie di autovetture. In una pubblicazione del 1999 sul Engineering Designer, Harper, responsabile del settore Vehicle Packaging and Analysis della Jaguar, ha affermato [Harper; 1999] che il solo software KBE (ICAD), introdotto per le nuove applicazioni, ha permesso a Jaguar di risparmiare molte ore lavoro dei tecnici e ha permesso un ottimizzazione sullo sviluppo dei componenti. Questa azienda ha introdotto inizialmente il sistema KBE per lo sviluppo dei pannelli di rinforzo del cofano (Figura 4) e per i fanali anteriori (Figura 5) delle loro autovetture. E stato dimostrato che, ad esempio per questo Alintec Scarl Milano, Settembre 2008 [20]

21 ultimo componente, i tempi di configurazione si sono ridotti in alcuni casi di quattro, in altri addirittura di otto settimane. In effetti, prima del loro sviluppo mediante ICAD, Jaguar si trovava di fronte al problema che, ad ogni modifica effettuata su un modello di carrozzeria, bisognava ridefinire la parte fari, sia in base alla funzionalità del modello sia in base alla zona di mercato in cui doveva essere venduta. A fronte di un investimento iniziale nel reperire tutte le informazioni necessarie alla programmazione del sistema, Jaguar ha ottenuto un vantaggio sia nella diminuzione dei tempi di progettazione e relativa documentazione, sia nella diminuzione dei costi di produzione. Inoltre il software viene utilizzato tutt ora per la configurazione di nuovi prodotti, aiutando gli ingegneri nell analisi di fattibilità del prodotto, indicando la disponibilità di materialie dando informazioni sul costo di produzione [Calkins; 1996]. Figura 4. - ICAD - Progettazione cofano. Figura 5. - ICAD per la progettazione fanali anteriori. Il caso Dallara La Dallara Engineering S.p.A., azienda che si occupa della progettazione e produzione di autoveicoli sportivi da competizione, ha utilizzato il sistema KBE Selling Point, della Concentra Corporation, per la determinazione Alintec Scarl Milano, Settembre 2008 [21]

22 automatica delle proprietà di massa di una autovettura sportiva, destinata alla competizione IRL (Indy Racing League) [Susca; 2000]. Questa scelta è stata effettuata per ottimizzare il compromesso tra l ottenimento di alte prestazioni e la sicurezza per il pilota. Figura 6. - Architettura del prodotto. Attraverso il sistema KBE si è cercato perciò di ottenere un applicazione che gestisse autonomamente le scelte progettuali dell automobile e i suoi parametri. L applicazione è stata suddivisa in quattro fasi: l acquisizione della conoscenza, la sua formalizzazione, l implementazione del processo e il test di prova. Generalmente nello sviluppo dell applicazione devono essere coinvolte persone differenti, quali i tecnici esperti del settore, gli analisti e i programmatori. In questo specifico caso, queste ultime due figure risultavano la stessa persona, in quanto l applicazione è stata scritta da un ingegnere esperto dell ambito delle corse sportive, riducendo così ulteriormente la complessità dello sviluppo. La struttura dell automobile è stata formalizzata per mezzo di un albero di prodotto, riportato in Figura 6.Tutte le conoscenze riguardo il prodotto, derivanti dall esperienza nel settore, sono state immagazzinate in un database per il loro successivo riutilizzo. L utente finale interagisce con il prototipo inserendo i parametri di input per mezzo di un interfaccia, guidando così il programma a generare automaticamente le varie configurazioni della macchina. Il sistema è stato testato comparando i dati ottenuti automaticamente dal sistema con quelli ottenuti sperimentalmente, in varie condizioni di utilizzo. Con l implementazione di questo programma sono state ottenute importanti informazioni per le automobili Dallara. Per esempio è stato chiarito come il baricentro della macchina e il baricentro del serbatoio del carburante debbano essere allineati verticalmente per ridurre la variazione di assetto durante la corsa. Alintec Scarl Milano, Settembre 2008 [22]

23 Figura 7. - Interfaccia di configurazione. Il sistema DART Uno dei più grandi risultati auspicabili nell industria automobilistica è quello dell integrazione degli strumenti di disegno e di progettazione concettuale con gli strumenti di analisi strutturale, specie per quell area del veicolo denominata BIW (Body-in-White), che racchiude in se tutti i componenti strutturali. Il telaio di un veicolo è infatti composto da molte sottostrutture, unite insieme a formare un unico corpo. Tale componente deve adempiere poi a molte funzioni, deve per esempio assorbire gli urti in caso di impatto, distribuire gli sforzi durante il funzionamento, e comunque essere il più leggero e conveniente possibile. In definitiva il telaio di una macchina è uno dei fattori maggiormente influenzante le caratteristiche di un veicolo. Uno degli aspetti fondamentali durante la progettazione di tale elemento è l ottimizzazione della struttura, essenziale a livello produttivo, e basata fondamentalmente su processi di tipo iterativo. La procedura utilizzata nella definizione di un telaio può essere essenzialmente formalizzata in quattro passaggi: definizione, pre processamento, analisi, post processamento del modello. Naturalmente tale procedura viene eseguita iterativamente fino a che il risultato finale non soddisfa tutti i requisiti richiesti. Il passaggio di analisi vera e propria richiede delle informazioni che solitamente non sono veicolate dal sistema CAD tradizionale, per esempio carichi, distribuzione di pesi e caratteristiche dei materiali, per cui questo è un valore aggiunto che deve essere necessariamente fornito al ciclo di progettazione affinché esso possa essere eseguito. Tradizionalmente la fase di produzione ed analisi del modello fa capo a diversi progettisti che a loro volta utilizzano diversi strumenti. Generalmente poi tali strumenti non sono neanche totalmente compatibili, per cui ogni volta che si passa da uno all altro viene richiesto uno sforzo di pre processamento per rendere fruibili le informazioni tra di loro. Spesso tale fase è una delle più onerose in termini di tempo, in quanto un modello creato in CAD può risultare incoerente ed ambiguo e può richiedere significative modifiche nella preparazione, Alintec Scarl Milano, Settembre 2008 [23]

24 per esempio, alla fase di esecuzione della mesh [Jones; 1995]. Gli analisti spesso decidono di ricostruire ex-novo un modello per la fase di mesh, basato naturalmente sul modello CAD fornito dai progettisti. In alternativa lavorano su una copia del modello originale stravolgendolo a loro beneficio. Questa fase non può essere evitata anche se alcuni sistemi utilizzano delle routine automatiche di meshatura, in quanto le esigenze delle due fasi di progettazione sono diverse, per cui le informazioni richieste e fornite in ognuna di esse risultano sensibilmente differenti. Uno dei primi passaggi del pre processamento è per esempio la semplificazione del modello. Ai fini dell analisi numerica infatti un modello particolareggiato non è utile, porterebbe infatti a maggiori tempi di calcolo ed a maggiori possibilità di errore. E chiaro che in tale analisi conta enormemente l esperienza dei tecnici, in quanto il procedimento di semplificazione di un modello ha una forte componente soggettiva. Le successive due fasi sono l analisi numerica, eseguita interamente dal calcolatore, ed il post processamento, in cui i risultati vengono raccolti ed analizzati dai tecnici per fornire ai progettisti informazioni circa le modifiche da apportare al modello. Uno dei sistemi KBE sviluppati per ottimizzare questo procedimento è il sistema DART [Craig; 2001]. Il primo input al sistema è costituito dalle specifiche OSD (outer surface definition ) del veicolo, che non sono altro che le forme e gli ingombri forniti generalmente dal reparto design e aerodinamica, a cui il telaio dovrà adattarsi. Un secondo input è definito dagli ingombri interni, quali possono essere motore, cambio, abitacolo ecc, che costituiscono un ulteriore set di vincoli da rispettare. Tutti questi input possono essere forniti attraverso diverse metodologie: - importazione di file CAD in formati standard come IGES o STEP; - insieme di coordinate di punti caratteristici; - importazione di file CAD in formato proprietario; - importazione di precedenti modelli già utilizzati e memorizzati in un database del sistema. Se non sono presenti specifiche richieste rispetto a questo tipo di vincoli, si può comunque procedere con l iter progettuale anche senza questi vincoli prettamente geometrici. Il secondo passo consiste nella definizione delle interazioni tra i vari elementi presenti ed il telaio. Si fissano quindi ulteriori vincoli, che in questo caso però sovrintendono alle relazioni tra i componenti del veicolo. Per esempio si fissano in questa fase le geometrie degli attacchi delle sospensioni, il collegamento del motore, ma anche vincoli non propriamente geometrici come rigidezza del telaio, materiale etc. In base a tutti questi dati si costruisce quindi un primo modello della struttura, soggetto esso stesso ad un primo controllo di fattibilità riguardo a geometrie non realizzabili o non compatibili con i vincoli introdotti. In questo stadio della produzione il modello può essere cambiato in ogni istante, con un conseguente immediato controllo sulla sua realizzabilità. Oltre a fornire una prima analisi di fattibilità, questo modello può servire anche al reparto commerciale per eseguire una valutazione di costi e convenienza. Una volta che l analista FEM riceve il modello CAD dal progettista inizia la sua semplificazione cancellando porzioni di struttura e sostituendole con parti più semplici, tutto questo procedimento è guidato da una parte dall esperienza mentre dall altra dai requisiti richiesti dal sotware FEM in uso. Il motore per esempio viene generalmente ricondotto ad una massa concentrata, evitando le complesse geometrie del modello CAD. Ad ogni modo il procedimento con cui l analista semplifica e schematizza il modello originario è lo stesso indipendentemente dalle dimensioni e dalle geometrie del modello questo significa che le lamiere vengono per esempio sempre schematizzate da degli elementi piastre, per cui la geometria deve essere adattata a tal fine. Tale adattamento Alintec Scarl Milano, Settembre 2008 [24]

25 generalmente consiste nell eliminare i piccoli spazi che rappresentano le giunzioni tra le lamiere nel modello cad, oppure eliminare le nervature o le incisioni effettuate a scopo stilistico, e così dicendo. Queste operazioni, spesso ripetitive e tediose in quanto costringono l analista a lunghe sedute di modifica del modello originale, possono essere eseguite da un sistema KBE. Anche dal punto di vista della realizzazione di un telaio le problematiche sono le stesse. La stessa struttura viene per lo più realizzata con elementi finiti piastra, tranne per alcune sezioni in cui si usano le travi. In questo particolare caso molta importanza rivestono i giunti tra gli elementi del telaio, molto influenti riguardo le caratteristiche di rigidezza e resistenza dell intera struttura. Un particolare set di istruzioni modella tali elementi in maniera dipendente dal materiale in uso, simulando in pratica i diversi metodi di saldatura dei materiali. Nel sistema DART quindi il terzo passo non è altro che l applicazione delle regole da parte del sistema KBE per rendere automatizzato il processo di semplificazione delle geometrie. Una volta adattato il modello si passa alla fase di meshatura, che può essere effettuata da software esterni, ma anche dallo stesso sistema. In questo caso un set di regole sono state implementate al fine di assegnare l elemento adatto ad ogni parte del telaio. Tenendo conto che le analisi effettuate sono due, una per la rigidezza ed una per la resistenza, le mesh generate presentano differenti conformazioni per meglio adattarsi alla successiva fase di calcolo. Questo ultimo passo, completamente automatizzato prelude alla fase di analisi vera e propria, tramite strumenti esterni, alla quale segue un fase di post-processing dei dati, ed un eventuale modifica del modello CAD originario, a cui seguono nuovamente in maniera iterata le fasi appena esposte. Per l analisi di una struttura automobilistica si usano dagli ai elementi finiti, con un tempo di pre processamento che può arrivare anche alle 50 settimane lavorative. Per questo motivo tale analisi era relegata ad un ultimo studio di realizzabilità del progetto, solo per controllare se la messa in produzione del telaio era accettabile senza dover ricorrere alla prototipazione fisica. L introduzione di tale sistema ha portato ad una diversa ottica di progettazione, il risparmio di tempo da esso causato ha permesso di introdurre l analisi FEM come parte integrante dell iter progettuale, e non solo come ultimo strumento di controllo. Inoltre si sono rese possibili analisi sull uso di nuovi materiali, questo grazie al fatto che la semplificazione delle geometrie dipende dal tipo di materiale solo nelle zone di giunzione, per altro anch esse schematizzate automaticamente. L ESD della New Design Paradigm Un altro caso interessante riguarda il sistema ESD (Electrical Systems Design),un applicazione basata sul KBE realizzata dalla New Design Paradigm LTD, al fine di rendere più agevole la realizzazione del sistema elettrico di autoveicoli ed aeromobili [Cooper; 1999]. Tale sistema ha permesso di passare da tempi di produzione di alcuni mesi con i metodi tradizionali, ad alcuni giorni. Contrariamente al sistema tradizionale, che richiedeva grandi team di ingegneri al lavoro su dettagli di basso livello, l ESD ha permesso l uso di pochi progettisti per definire le specifiche di alto livello, per poi relegare la definizione dei dettagli al sistema. Tale cambiamento ha inoltre permesso un maggiore controllo del progetto, essendo relegati al sistema automatico tutti i compiti routinari di calcolo. Questo caso è indicativo di come l introduzione dei sistemi KBE sia stata usata per reingegnerizzare disfunzioni nella progettazione industriale su vasta scala; nei precedenti 20 anni infatti le aziende hanno da una parte accelerato vari aspetti del processo produttivo tramite l ausilio di strumenti CAD e CAE, ma contemporaneamente non sempre sono state altrettanto attente ad evitare la formazione dei cosiddetti colli di Alintec Scarl Milano, Settembre 2008 [25]

26 bottiglia nello stesso iter progettuale. In questo particolare caso il problema risiedeva nel fatto che nella progettazione dei sistemi elettrici si usavano due distinte rappresentazioni, una 3D ed una 2D. La prima delegata agli studi degli ingombri e delle caratteristiche meccaniche, la seconda riguardante il lato prettamente elettrico. Entrambe dovevano naturalmente sottostare a specifiche estremamente rigide. Ogni modifica al progetto originale obbligava gli ingegneri a ricontrollare entrambi gli schemi, e spesso ad eseguire ex novo la progettazione, inoltre la validazione del prodotto ed i relativi test potevano essere eseguiti solo alla fine della produzione, obbligando in caso di insuccesso ad un nuovo cammino di definizione dei circuiti. L architettura KBE è stata realizzata utilizzando il sistema ICAD, è bastato quindi addestrare tale strumento tramite la raccolta e la formalizzazione delle conoscenze del team di ingegneri. Ogni componente del sistema è stato codificato come un singolo VPM (Virtual Product Model), un entità che al suo interno conteneva sia le sue caratteristiche meccaniche che quelle elettriche. Il circuito completo risulta quindi come insieme di VPM. Tale architettura permette anche di formalizzare la progettazione a diversi livelli di complessità, raggruppando più modelli virtuali tra di loro al fine di schematizzare a proprio piacimento l intero sistema. Questo risulta molto utile in fase di test, in cui gruppi di componenti possono essere validati indipendentemente. Infine l introduzione del sistema KBE ha permesso una maggiore razionalizzazione delle risorse, in quanto sfrutta preferenzialmente componenti e schemi già realizzati precedentemente, che quindi non hanno bisogno di un ulteriore fase di test. Il caso CORUS Corus [Corus; 2000] è un azienda fondata nel 1999 in conseguenza alla fusione di British Steel e di Koninklijke Hoogovens, tale gruppo è il terzo più grande produttore di acciaio nel mondo, e trae il 20% dei suoi introiti dall industria automobilistica. Prima di tale fusione era operativo fin dal 1996 il progetto Automotive Engineering Group (AEG), il cui scopo era quello di colmare il gap tra la ricchezza di conoscenze riguardo l industria dei materiali, e la loro reale applicabilità al campo automobilistico, con lo sviluppo di nuovi processi produttivi. AEG iniziò a collaborare con ICAD nel 1998, sviluppando delle applicazioni il cui scopo era quello di aiutare gli ingegneri a sfruttare in maniera migliore i materiali a disposizione. Una di queste applicazioni è la Corus Hydroform Design For Manufacture conosciuta come DFM, che riguardava lo studio del processo di Hydroforming dei materiali metallici. Tale processo consiste nel far espandere in uno stampo un tubo metallico a seguito di una forte pressione applicata con un fluido introdotto al suo interno [Twelves; 2000]. Prima dell applicazione della pressione il tubo deve essere preparato con un iniziale deformazione, al fine di facilitare il processo. Alla fine della formatura il risultato deve essere rifinito per eliminare bave o eccedenze di lavorazione. Figura 8. - Confronto tra i due metodi di progettazione. Alintec Scarl Milano, Settembre 2008 [26]

27 Il processo di progettazione per l hydroform prevede due fasi, una prima di calcolo a basso livello, ed una seconda di simulazione mediante l uso di elementi finiti. Dalla Figura 8 si può vedere quali siano i vantaggi derivanti dall utilizzo di tecniche KBE. L analisi di fattibilità di un prodotto tramite l hydroforming consiste nell esecuzione di un numero di passi discreti, i più importanti dei quali risultano la sectional e la prebend analyses. La prima analizza ogni sezione del pezzo da ottenere ed in base a questa determina il diametro e lo spessore che il tubo dovrà avere prima di essere sottoposto a pressione. Eseguendo in automatico quest operazione è anche più facile la realizzazione di numerose variazioni di sezione nel pezzo risultante, in quanto la determinazione del pezzo di partenza risulta più accurata di quanto non succeda tramite calcoli manuali. Figura 9. - Il processo di Hydroform. Una volta determinato il manufatto di partenza bisogna comunque realizzare tale elemento, generalmente questi non è altro che un foglio di lamiera sagomato opportunamente e chiuso su di un lembo al fine di formare un elemento tubolare. L analisi di fattibilità di tale elemento è la sopra citata prebend analyses, e implica l uso di tecniche agli elementi finiti. Con il nuovo sistema tutto il processo (Figura 9) viene automatizzato, a partire dall introduzione delle richieste, alla definizione del manufatto di partenza il quale viene preparato per essere passato al software di analisi e quindi classificato come realizzabile o meno. Nel caso di risposta negativa il sistema poi procede iterativamente modificando alcuni parametri dell analisi sezionale (come per esempio il materiale utilizzato o gli sforzi residui accettabili), fino all ottenimento di un prodotto realizzabile. I vantaggi dell introduzione di tale strumento si risolvono non solo in un minor tempo di sviluppo, ma anche in una miglior ottimizzazione del prodotto (essendo possibile iterare più volte i risultati in funzione di un parametro specifico) e di un minor rischio di errore a causa dell eliminazione del fattore umano durante il processo di calcolo. Naturalmente anche questa applicazione è soggetta ai benefici dovuti alla formalizzazione del know how aziendale Nell industria aerospaziale ICAD ed Airbus Alintec Scarl Milano, Settembre 2008 [27]

28 Airbus è un consorzio europeo per la costruzione di aerei di linea. Ad ognuna delle aziende partecipanti è assegnata la progettazione di un componente dell aeromobile, tra queste figurano British Aerospace, e Aerospatiale, la prima con delega alla progettazione delle ali e della fusoliera, la seconda incaricata della progettazione del cockpit. Un caso interessante di utilizzo dei sistemi KBE (usati in maniera estensiva da questo tipo di industria) riguarda la progettazione di un aereo per le piccole medie tratte con una capienza di circa 100 passeggeri da sviluppare per il mercato cinese. La soluzione esistente infatti non rispondeva a pieno alle esigenze di tale mercato, individuando proprio nel cockpit e nell ogiva del mezzo uno dei problemi maggiori. Per questo problema si sono presentate due possibili soluzioni, la prima prevedeva l adattamento e l inserimento nella fusoliera del cockpit gia utilizzato da un altro aero, l A320, mentre la seconda prevedeva la progettazione di ex novo di tale elemento, nel quale però inserire la strumentazione utilizzata per l A320. Aerospatiale sviluppò la prima strategia, ottenendo una fusoliera adattata alle esigenze tramite un mix di superfici a curvature complesse per il rivestimento e pannelli piani per i finestrini per un approccio CAD centrico e di complesse analisi fattibilità delle varie strutture proposte, seguita da un ulteriore analisi finale di controllo più approfondita della variante scelta. British Aerospace invece seguì la seconda via, sfruttò un precedente sistema KBE sviluppato per la RJX ed utilizzato per la progettazione di ogiva, cockpit, fusoliera e layout dei sedili, e lo adattò al nuovo problema. Questo significava anche prevedere una soluzione nuova e mai realizzata da Airbus, cioè quella dell utilizzo di vetrature sagomate, già sfruttata nella costruzione di Business Jet ma mai considerata per aerei di linea. L utilizzo di tale soluzione permise a British Aerospace l analisi di 60 possibili soluzioni sviluppate completamente e ad alto livello di dettaglio prima di scegliere quella più opportuna per il sistema KBE, in luogo dell unica proposta dal gruppo di lavoro di Aerospatiale, con la quale è comunque stato un fatto sia un lavoro di comparazione ma anche di importazione delle soluzioni sviluppate al fine di sfruttarle nel KBE stesso. Il sistema KBE ha inoltre dimostrato un ampia versatilità ma soprattutto una potenziale integrazione nelle dinamiche aziendali prima d ora sottovalutata, infatti in primo luogo è stato utilizzato un sistema sviluppato per altri scopi, quindi è stato possibile adattarlo alle proprie esigenze, in secondo luogo tale sistema ha necessitato di uno stretto collegamento con Aerospatiale stessa e con i suoi sistemi, in quanto era questa specifica azienda delegata alla progettazione dei cockpit, e quindi depositaria di tutta la conoscenza al riguardo. Va fatta notare anche la grande potenzialità in fatto di analisi strutturali del sistema, in quanto durante la progettazione è stato fatto massiccio uso di questi strumenti per verificare la resistenza e realizzabilità del prodotto. Il MOB Computer Design Engine Una delle parti degli aerei che ben si presta all uso di sistemi KBE sono le nervature delle ali; tali elementi sono morfologicamente simili e ripetuti più volte con opportuni dimensionamenti e rinforzi lungo lo sviluppo dell ala. Il dimensionamento di queste è naturalmente dipendente dallo stress a cui gli elementi sono sottoposti, inoltre devono essere comunque ottimizzate al fine di pesare il meno possibile ed integrarsi al meglio nella struttura esistente, infatti la loro forma è comunque legata all aerodinamica dell ala, per cui sono soggette ad un numero non indifferente di vincoli. Un minimo cambiamento nell aerodinamica dell ala, e quindi nella sua forma porta spesse volte alla ridefinizione del numero, della posizione, e della forma di tutte le nervature; si comprende quindi l importanza di un sistema che renda il più automatizzata possibile la definizione di tali elementi. Airbus Alintec Scarl Milano, Settembre 2008 [28]

29 ha sviluppato un sistema che genera un modello delle nervature in base ai dati forniti in entrata dopo di chè questo modello è soggetto ad analisi numerica, ottimizzazione ed in base ai risultati viene ridefinito totalmente. Figura Lo schema del MOB. Il processo (Figura 10) è quindi automatico ed iterativo. Un sistema simile ma esteso alla progettazione strutturale dell ala e non solo alle nervature, denominato MOB (Multi disciplinary design and Optimisation for Blended wing body configuration), è stato sviluppato tramite l ausilio di KTI ICAD [La Rocca; 2002]. Il cuore del sistema è il MMG (Multi Model Generator), in cui risiede una descrizione completamente parametrizzata dell oggetto in analisi, tale sistema riceve in input i requisiti richiesti, e rigenera completamente il modello in maniera funzionale ai vari strumenti utilizzati successivamente. L MMG è stato sviluppato in ambiente ICAD, va precisato che il modello che risiede in tale modulo del sistema non è un modello puramente geometrico, comprende infatti oltre alle geometrie in gioco anche le regole di accoppiamento delle varie parti, i requisiti di resistenza richiesti e le strategie di ottimizzazione, per cui è identificabile a tutti gli effetti come un sistema KBE. Data la similarità tra gli elementi, tale sistema può essere utilizzato non solo per la progettazione delle ali, ma anche degli alettoni e delle appendici in genere. Questo sistema è un esempio del forte legame che i sistemi KBE possono instaurare con software esterni in particolare con quelli di analisi. Il prodotto risultante infatti è fortemente determinato dalle analisi strutturali ed aerodinamiche operate in corso di progettazione, molto spesso definite ed attivate in automatico In altri ambiti industriali Un sistema KBE per la progettazione di contenitori per liquidi Un adeguata progettazione è un requisito fondamentale per evitare rischi di rottura nel caso di contenitori per liquidi esposti ad ambienti corrosivi [Chau; 2003]. La progettazione di queste strutture è abbastanza specializzata, e richiede l integrazione sia di regole Alintec Scarl Milano, Settembre 2008 [29]

30 euristiche, che di procedure strettamente codificate a livello ingegneristico. Richiede inoltre un attenta analisi di requisiti legati al carico, alle condizioni geotecniche dell installazione, alle caratteristiche dei venti e delle temperature di esposizione, ai materiali usati ed alle tecniche costruttive. I sistemi attualmente in uso sono in grado solamente di effettuare alcune parti della progettazione completa, generalmente stadi riguardanti analisi di sforzi e di produzione di modelli solidi, mentre risulta più difficile raccogliere le regole empiriche in un ambiente più convenzionale alla costruzione di un algoritmo. Per risolvere tale problema è stato costruito un sistema, il LIQSTR, che agisce come un componente Active X sotto l ambiente di programmazione Visual Studio, che combina in se metodologie riguardante i sistemi esperti, la programmazione objectoriented, i database, e delle capacità grafiche. In pratica il sistema esperto funge da contenitore e coordinatore tra i diversi moduli, permettendo lo scambio di informazioni in maniera adeguata. Il sistema prevede anche l integrazione con il software di analisi Abaqus, sfruttando una funzionalità di questi che consiste nel poter definire un analisi anche tramite un file di testo; viene infatti prodotto un opportuno file in maniera automatica, e da qui mandato in esecuzione. Una volta che questa viene completata i risultati sono letti ed opportunamente elaborati. Il sistema funziona come illustrato in Figura 11. Un analisi preliminare del progetto consiste nella definizione delle misure di massima della geometria e della struttura del sistema. Questo include il dimensionamento geometrico dei volumi e delle grandezze, ma anche conoscenze euristiche riguardanti casi pregressi. In questa fase il sistema fornisce diverse alternative, in base alle quali vengono definite diverse tipologie di rinforzi dello stesso contenitore, l alternativa dal costo minore è quella segnalata come la migliore. L utilizzo di regole empiriche permette un risparmio dei tempi di configurazione delle varie alternative di notevole entità, essendo minori le regole da applicare e quindi il conseguente sfruttamento di potenza di calcolo. Una volta scelta la configurazione, il sistema procede a dettagliarla in maniera migliore, fornendo anche dati più specifici riguardo ad essa, il tutto è necessario anche per la fase successiva di analisi strutturale, infatti il sistema provvede ad applicare dei carichi standard calibrati sulle condizioni di utilizzo a cui il prodotto sarà soggetto (se per esempio è una struttura interrata o sospesa). A questo punto viene prodotto un file di testo da passare ad Abaqus per la relativa analisi strutturale, in base a questa, tramite diverse iterazioni tra i due sistemi viene eseguita un ottimizzazione del sistema. Il sistema continua ad iterare fino al raggiungimento di un obbiettivo di convergenza stabilito a priori in fase di definizione del progetto. Il prodotto così configurato passa quindi in produzione. In conclusione si è visto che il sistema non solo è utile a livello pratico, ma anche per testare la validità di un processo produttivo; infatti la costruzione di un sistema funzionante è una prova del fatto che i concetti che stanno alla base del processo stesso sono riproducibili e consistenti. Costruire un sistema automatico o comunque fortemente automatizzato, permette di definire in maniera precisa ed universale il cammino e le regole seguite normalmente dai progettisti, elementi che generalmente non sono formalizzati ma fanno parte del know how aziendale ad un livello astratto, in questo modo si facilità anche l addestramento di eventuali nuovi progettisti, ed un più razionale sviluppo futuro del prodotto stesso. Alintec Scarl Milano, Settembre 2008 [30]

31 Figura Il processo implementato dal LIQSTR. La YIT Corporation e Design++ La YIT è un azienda di costruzione di beni immobili operante in Finlandia; dal 1999 ha iniziato lo studio di uno strumento tecnologico per la progettazione denominato COVE [YIT; 2006] (Cost and Value Engineering) che sebbene sia solo il primo passo di un lungo processo di informatizzazione dell azienda, ha gia fatto segnare decrementi dei costi di progettazione dell ordine del 20%. Lo scopo di tale sistema è principalmente quello di fornire una veloce via di valutazione delle soluzioni costruttive, ed allo stesso tempo una rapida stima dei costi di queste. Per far questo si necessita un integrazione a livello di sistemi aziendali pre-esistenti, ma anche con quelli facenti capo a fornitori esterni, per esempio fornitori di condizionatori, studi di architettura ed ingegneria esterni ed altri ancora. Il sistema COVE parte ricevendo in input dei disegni forniti dagli architetti realizzati con Autocad, nel quale vengono identificati gli elementi costruttivi (come muri, finestre e spazi abitativi) e le loro dimensioni. Tale fase di input fa capo ad una specifica finestra di dialogo. Mentre si completa questa fase di input il sistema KBE Design++ crea uno schema logico (Figura 12) contenente gli elementi sensibili del modello. Successivamente viene generato anche un modello 3D del prodotto, di solito un edificio intero, utile sia per verificarne la completezza, che per vedere immediatamente l effetto che delle modifiche possono operare. Alintec Scarl Milano, Settembre 2008 [31]

32 Una volta che il prodotto è stato configurato la fase successiva è quella di identificare tutte le possibili metodologie per realizzarlo, per cui viene messa a disposizione una suite di metodi costruttivi, da scegliere in base alle esigenze. Il grande vantaggio del sistema è la possibilità di cambiare materiali, geometrie e metodi costruttivi, sia per l intero edificio che per parti di esso, e di valutarne immediatamente i costi in termini di tempi ed investimenti finanziari. Il sistema è composto da diversi software, AutoCAD, un Database, il motore KBE Design++ ed un modulo di rappresentazione dei risultati, che trasforma in viste 3D da visualizzare con AutoCAD il modello configurato. Il sistema Design++ divide le regole in tre categorie: - regole di configurazione: queste regole sono usate per determinare quali componenti sono necessari ai fini funzionali (per esempio muri portanti, finestre) - regole di selezione: con questo set di regole si sceglie quali, tra i vari modelli di componenti individuati con le regole precedenti, utilizzare realmente; per esempio che tipo di finestre utilizzare, che tipo di muri, etc. - regole di dimensionamento: queste regole ordinano il dimensionamento dei componenti identificati nelle fasi precedenti. Naturalmente tali set di regole possono essere modificati ed ampliati in qualunque momento. Figura 12. Diagramma ad albero del prodotto in Design++. Tradizionalmente la costruzione di edifici è ben documentata e strettamente CAD centrica, questa centralità del CAD d altra parte mette un po in secondo piano le esigenze dei reparti commerciali. Con il nuovo sistema, ciò che guida il tutto sono le regole di configurazione, il modello CAD è solo un modo di rappresentare i risultati; certamente ricopre un ruolo centrale, permettendo di visualizzare eventuali modifiche, ma è comunque legato ad un modello logico che sta ad un livello superiore, e che risulta anche facilmente interfacciabile con il reparto commerciale. Alintec Scarl Milano, Settembre 2008 [32]

33 4 Analisi degli aspetti rilevanti nella Progettazione Automatica In questa sezione sono trattati alcuni aspetti di rilievo nella progettazione automatica. In particolare, si indaga i temi della rappresentazione di prodotto e di esso, il riuso e la condivisione della conoscenza e l integrazione delle applicazioni PA con i sistemi PLM/PDM aziendali. Una prima osservazione su questi temi riguarda la corrispondenza di quanto si discute nei processi di progettazione tradizionali. È infatti interessante l analisi di Gorti [Gorti; 1998], che afferma che, in un tradizionale processo di progettazione, c è spesso sovrapposizione fra varie attività e, in particolare, spesso non è definito quando un progettista lavora per definire l architettura di un prodotto o esegue alcune procedure per scegliere o dimensionare componenti. Nelle applicazioni di Progettazione Automatica, invece, questa distinzione deve essere fatta per definire dove sta la conoscenza di prodotto piuttosto che quella di processo. Secondo Gorti, la Letteratura che si occupa di progettazione riflette tutto questo mostrando una dicotomia fra rappresentazione di processo e progettazione di prodotto. Le due caratteristiche principali nella rappresentazione della conoscenza in un applicazione di progettazione automatica sono quindi la rappresentazione delle architetture di prodotto e la rappresentazione dei processi di progettazione. Accanto a questi due principali aspetti se ne collocano altri a supporto della rappresentazione di prodotto e di processo, tra i quali quelli qui discussi: riuso e condivisione della conoscenza; integrazione fra sistemi di progettazione automatica con sistemi PLM e, in particolare, sistemi PDM e archivi aziendali. Di seguito si riportano i temi appena descritti: -rappresentazioni delle architetture di prodotto; - rappresentazione dei processi di progettazione; - riuso e condivisione della conoscenza; - integrazione dei sistemi per la Progettazione Automatica con i sistemi PDM/PLM presenti in azienda. 4.1 Rappresentazioni delle architetture di prodotto La rappresentazione delle architetture di prodotto è, assieme a quella di processo, alla base della progettazione automatica. Esistono diversi modi di poter rappresentare un prodotto. Il metodo più diffuso, soprattutto negli uffici tecnici di progettazione, la progettazione si esegue avendo come riferimento alla distinta base relativa al prodotto associato. La distinta base, o bill of materials (BOM), è un elenco comprendente tutti i componenti presenti in un assieme ordinati secondo un codice identificativo univoco. In questo elenco non vi è alcuna distinzione fra componenti morfologicamente o funzionalmente simili e non vi sono informazioni sulle relazioni e le gerarchie funzionali tra i componenti stessi. Due anelli Seeger di diverso diametro, per esempio, sono elencati alla stessa maniera di qualsiasi altro componente e, fra di loro, con caratteristiche distintive l uno dall altro, anche se funzionalmente e morfologicamente identici. Per esempio, con questa rappresentazione di prodotto un riduttore potrebbe essere composto di: - un albero di diametro principale 30 mm; - un albero di diametro principale 32 mm; Alintec Scarl Milano, Settembre 2008 [33]

34 - una cassa aventi dimensioni 750 mm; - un copri cuscinetto di diametro 50 mm e spessore 2 - un copri cuscinetto di diametro 52 mm e spessore 2; - una ruota dentata conica di 21 denti e modulo 1.5; - ecc Naturalmente, una distinta base non è composta in questo modo, ma attraverso una codifica dei componenti ben precisa, che offre informazioni di tipo morfologico e (talvolta) funzionale dei componenti. Nonostante questo tipo di rappresentazione sia largamente diffuso, esso non mette in risalto alcuna informazione di tipo funzionale o gerarchico, e non è adatta, secondo i proponenti del progetto a rappresentare con efficienza un prodotto da configurare con tecniche di progettazione automatica. Un livello di completezza maggiore è fornito dalla rappresentazione CAD, la quale permette di raccogliere, organizzare e arricchire le informazioni di prodotto aggiungendo alle informazioni riportate in una distinta base, informazioni di tipo gerarchico e relazionale. Infatti, questo tipo di rappresentazione, grazie alle funzionalità di assemblaggio dei componenti, permette di generare una struttura logica di assiemi e sottoassiemi che danno informazioni di appartenenza e di relazione ad altri componenti. In più, la rappresentazione eseguita con modellatori CAD parametrici, se integrati con opportuni strumenti, forniscono anche informazioni dimensionali e permettono la gestione di regole di dimensionamento. I modelli CAD parametrici sviluppati mediante integrazione di linguaggi di programmazione o fogli di calcolo permettono la configurazione automatica di molti prodotti. Questo approccio ebbe grande sviluppo durante gli anni 80 del secolo scorso ed è tuttora molto popolare, specialmente nelle PMI. Colombo ed altri [Colombo, 1992] hanno presentato un esempio di questo approccio per la progettazione automaticadi un recipiente in pressione mostrato in Figura 21, con la tecnica dell integrazione di un modellatore Cad con un foglio di calcolo. Questo approccio presenta tuttavia qualche limite di gestione nella configurazione di prodotti con architetture complesse. Per superare questi limiti, già dalla fine degli anni 80 si cominciò ad adottare un approccio di tipo Object Oriented (O-O), che permetteva la decomposizione del prodotto in parti e sottoparti migliorando così gestione dei modelli perché non più gestiti in maniera globale. Un esempio di tale approccio è presentato in [Cugini; 1992]. L aspetto più interessante dell approccio O-O è, oltre alla rappresentazione ad albero, in grado di rappresentare gerarchicamente, e quindi logicamente, la struttura di prodotto, la possibilità di prevedere e gestire varianti di modello in maniera più semplice, utilizzando regole di scelta dei componenti facilmente implementabili anche in prodotti con elevata complessità architettonica. Per questo motivo, Gorti e altri [Gorti; 1998], Colombo e altri [Colombo; 2005; Colombo; 2006] indicano la rappresentazione di tipo O-O come la più adatta a rappresentare un architettura di prodotto. In [Gorti; 1998], per esempio, è presentato un modello di rappresentazione della conoscenza mediante approccio O-O, derivato da un metodo denominato SHARED. In tale modello, è possibile rappresentare sia la conoscenza di prodotto che quella di processo. L approccio O-O, grazie al concetto di classe, permette di considerare ogni componente od ogni gruppo di componenti come piccole applicazioni finalizzate alla configurazione dell elemento o del gruppo a cui si riferisce, facilitandone il Alintec Scarl Milano, Settembre 2008 [34]

35 riuso in contesti diversi, sia all interno della rappresentazione dello stesso prodotto, che in altri prodotti. Esse acquisiscono le caratteristiche del contesto in cui sono inserite e si dimensionano in maniera automatica. Figura 21. Configurazione parametrica di un serbatoio in pressione mediante integrazione di un modellatore CAD con fogli di calcolo. Molti sistemi KBE adottano la rappresentazione ad oggetti, che permette la rappresentazione logica della struttura funzionale del prodotto e consente più agevolmente di modificare, aggiungere o eliminare parti o gruppi funzionali, senza dover pesantemente modificare le relazioni interne tra le parti stesse o le proprietà. 4.2 Rappresentazione del processo di progettazione La rappresentazione di prodotto è il secondo aspetto fondamentale della progettazione automatica. Essa ha il compito di guidare i progettisti durante le fasi di progettazione e configurazione di prodotto, garantendo la corretta applicazione delle Best Practice aziendali. [Summer; 2003] sostiene che il processo di progettazione è il metodo usato per affrontare un problema e contiene la conoscenza di dominio disponibile al progettista. La conoscenza di dominio può essere espressa esplicitamente con regole, procedure, manuali, soluzioni precedenti, ecc. La conoscenza può anche essere implicita e appartenete solo al progettista. In definitiva, il processo di progettazione include sia i metodi che il come applicare questi metodi. Chung e altri [Chung; 2002] sostengono, dopo aver presentato una discussione sul tema della rappresentazione di processo di progettazione nel settore meccanico, che esiste il bisogno di un approccio alla gestione del processo che sia un misto di automazione e giudizio umano. Essi sostengono che l automazione può essere utile in molti casi, ma che non avrebbe senso, in termini di costo, sviluppare applicazioni di tipo generico per prodotti di tipo standard (gli autori confrontano i prodotti meccanici anche con quelli elettronici). Il motivo che adducono è che, in generale, gli strumenti di sviluppo richiedono specifiche funzionali dettagliate e modelli fisici accurati. Tuttavia, essi osservano che, nel caso di rappresentazione di processo, non è richiesto avere dati completi per creare un modello funzionante. Modelli parziali, infatti, possono integrarsi con l esperienza del progettista che può ricoprire le lacune presenti nei Alintec Scarl Milano, Settembre 2008 [35]

36 processi rappresentati. In definitiva, gli autori sostengono che il dibattito che esiste attorno al problema della rappresentazione di processo, che di fatto si riduce alla disputa fra chi ritiene che non è necessario rappresentare nulla e chi afferma che invece è necessario rappresentare col massimo dettaglio, possa essere risolto risolto con un misto di modelli parziali e esperienza umana. Per esempio, si può lasciare la scelta di un materiale al progettista e far fare i calcoli al computer. Esistono diversi approcci alla rappresentazione di processo, dipendenti dalle tecniche utilizzate. Oltre agli approcci procedurali e O-O, dei quali si tratterà in seguito e che rappresentano la maggior parte delle applicazioni di progettazione automatica in cui il processo di progettazione è chiaramente definito, enorme sviluppo hanno le applicazioni generate con sistemi inferenziali, o con metodi quali reti neurali, fuzzy logic e algoritmi genetici, che si prestano molto bene a rappresentare processi di tipo decisionale non definito che varia a seconda delle condizioni al contorno. In generale, possiamo comunque affermare che, ad eccezione di applicazioni tipo quelle citate nel precedente capoverso, i metodi di rappresentazione di processo per lo più utilizzati anche nei sistemi KBE, nei casi dove i processi sono fortemente determinati, sono essenzialmente tutti riconducibili a due principali approcci, quello procedurale e quello O-O. Il primo metodo consiste essenzialmente nell esecuzione di procedure informatiche che elaborano informazioni in input per fornire degli output. Per esempio, dati come input il valore dei carichi, delle velocità di rotazione e degli ingombri, la procedura scegli_cuscinetto è in grado di produrre specifici output quali il codice del cuscinetto o la geometria associata. Tali procedure operano direttamente sui sistemi di rappresentazione del prodotto (KBE o modellatori CAD che siano) e racchiudono in se tutti quei costrutti tipici della programmazione: cicli, iterazioni, costrutti IF- THEN ELSE ecc. Un esempio può essere il seguente, scritto in linguaggio C: double Albero (double flessione_rotante, double lunghezza, max_ten, char identita) { double diametro_calc; carica_file_cad (albero.sldprt, identita); diametro_calc := calc_diametro (flessione_rotante, lunghezza, max_tens); varia_quota (albero.sldprt; Diametro!Schizzo1.Estrusione1, diametro_calc); varia_quota (albero.sldprt, Lunghezza!Estrusione1; lunghezza); return (diametro); } Tale procedura rappresenta il processo di dimensionamento di un albero che, a partire dai valori di flessione rotante, sforzo ammissibile del materiale e lunghezza, restituisce il diametro nominale dell albero (il richiamo al database è nella procedura interna diametro_calc) per successivi calcoli di scelta supporti, ecc Questa procedura aggiunge anche un file CAD rappresentante l albero in un assieme, dimensionandolo e rinominandolo. Procedure come queste, inseriti anche più volte in codici più estesi, permettono la completa configurazione di prodotto. Alcuni sistemi di progettazione automatica permettono la generazione guidata dei Alintec Scarl Milano, Settembre 2008 [36]

37 codici corrispondenti per la rappresentazione del processo, come per esempio alcuni sistemi KBE come RuleDesigner. L altro metodo di rappresentazione del processo è quello di tipo O-O, dove le procedure di dimensionamento e scelta componente sono implicitamente scritte nei metodi associati alle classi della struttura gerarchica rappresentante il prodotto. Per esempio, la classe Albero, che contiene le proprietà variabili Diametro, Momento_Rotante, ecc e la proprietà file CAD albero.sldprt, contiene anche i metodi diametro_calc( ) o varia_quota( ) che elaborano le suddette proprietà. La differenza sostanziale fra il primo e il secondo metodo è la maniera di interagire con il modello di prodotto. Nel primo caso, il modello viene costruito man mano che si forniscono le informazioni per farlo, mentre nel secondo caso, esistendo un modello O-O alla base, e dovendo esso assumere un istanza con valori di dimensionamento o scelta componenti iniziali, esiste già un modello di partenza che assume la configurazione finale per via incrementale a partire dal modello di partenza, man mano che i dati vengono modificati. In entrambe i casi, tuttavia, è diffuso l utilizzo di interfacce web o tipo form che rendono esplicite le procedure di progettazione e semplificano l applicazione della corretta procedura da parte dell utente. La tendenza è quella di rappresentare il processo di progettazione attraverso la rete e, ormai, un gran numero di strumenti di sviluppo permettono la creazione di ambienti web-base. In [Chung; 2004] è presentato un esempio di strumento collaborativo in rete che permette il superamento di tutti quei contrasti che insorgono quando più partecipanti al progetto eseguono uno stesso processo. 4.3 Riuso e condivisione della conoscenza Legato al tema della rappresentazione di prodotto e di processo, è quello del riuso e condivisione della conoscenza. Si intende per riuso della conoscenza la capacità di poter usufruire dei risultati di un attività diverse volte senza dover ripetere tali attività. In questo caso, una volta creato un modello di prodotto, si intende riuso la possibilità di estrapolare parte di codice e riproporlo in altri contesti. Per fare questo in maniera agevole, è necessaria la modularità delle applicazioni, requisito più semplice da realizzare con un sistema O-O. Si intende invece condivisione della conoscenza la possibilità che il riuso sia appannaggio di mo lti utenti. In questo caso, l utilizzo di database comuni dove riporre le applicazioni e i moduli è un valido metodo. La tendenza degli ultimi anni è quella di creare apposite librerie di parti, prodotti e gruppi funzionali utilizzabili da tutti i partecipanti. Interessante è l analisi che Arango conduce nel 93 [Arango; 1993]. Nell articolo, l autore si chiede quando ha senso di parlare di applicabilità del concetto di riuso della conoscenza. Egli, considerando il panorama tecnologico dell anno in cui scrive l articolo, risponde che ciò ha senso: quando ci sono sistemi su larga scala con vincoli ben definiti, per ammortizzare i costi; quando si lavora a progetti in cui la conoscenza coinvolta ha alta probabilità di essere riutilizzata, come nel caso di utilizzo di database, famiglie di prodotti di lunga vita, prodotti altamente configurabili; quando le aziende hanno cicli di vita produttivi cortissimi e alti costi di mantenimento. Sainter [Sainter; 2000] afferma che vi è concetto di riuso e condivisione della conoscenza di progetto laddove la conoscenza di prodotto può essere condivisa all interno dello stesso dominio di conoscenza, ma in differenti posti, e dove si permette alla conoscenza di dominio di essere riusata in nuove situazioni. Cheung [Cheung; Alintec Scarl Milano, Settembre 2008 [37]

38 2005] afferma inoltre che il riuso della conoscenza è l adattamento della conoscenza esplicita (di dominio o strategica, formalizzata per essere rappresentata) di pratiche di successo tali da generare nuove idee utili. Markus in [Markus 2001] considera tra l altro la conoscenza esplicita come l unica rappresentabile dalle tecnologie IT. Egli dichiara che il concetto di conoscenza esplicita include: - i metodi di comunicazione con i quali i progettisti condividono le loro osservazioni; - gli archivi dove la conoscenza può essere strutturata per il riuso e la condivisione. In un applicazione KBE, si può identificare la conoscenza legata ad una singola parte, intesa come elemento meccanico elementare (albero, piuttosto che ruota dentata), di una struttura di prodotto o di una procedura di progettazione. Nel caso di una singola parte, essa si può considerare come pillola elementare di conoscenza, nel senso che non è possibile dividerla ulteriormente. Per esempio, la conoscenza coinvolta nella scelta di una vite include le regole per il dimensionamento, la geometria, i documenti di riferimento, le procedure per la configurazione. Questa pillola di conoscenza è considerata come indivisibile; lo stesso approccio può essere esteso a tutte le parti s tandard, ai gruppi ed ai sottoinsiemi che possono essere usati in prodotti diversi. Il numero ed i tipi degli elementi immagazzinati negli archivi della conoscenza (tipicamente dei database) dipendono dalle applicazioni KBE che si intendono sviluppare. Lo sviluppo di un archivio di conoscenza richiede alcune considerazioni sull integrazione con i PDM aziendali. Questo strumento può controllare tutti i dati ed informazioni dell'intero ciclo di vita di prodotto; ma, seppur avanzati, non sono in grado di memorizzare la conoscenza di dominio e strategica. Di conseguenza, si distingue il ruolo di un di archivio di conoscenza, che può essere visto come indipendente e complementare al sistema PDM, da quello del PDM stesso. Il primo controlla la conoscenza esplicita richiesta per compiere le mansioni di disegno, quali le regole per quotare le parti, la conoscenza di architettura e la conoscenza procedurale relativa alla progettazione. Il secondo gestisce le parti CAD, la documentazione, i dati sui materiali, le revisioni e così via. Per concludere, si osserva che la comunicazione fra le applicazioni KBE e i PDM è molto studiata in letteratura [Bilgic; 1997; Noel; 2003; Szykman; 2001]; un'applicazione KBE costruita usando gli elementi contenuti in un deposito di conoscenza deve comunicare con un PDM in senso bidirezionale. L'applicazione di KBE può cercare e richiamare le parti specifiche da PDM ed immagazzinare le nuovi parti, sottoinsiemi e prodotti nella base dati del PDM. L'applicazione KBE genera dati riferiti ad una componente specifica o ad un prodotto, mentre il PDM li organizza. La conoscenza memorizzata nell archivio può essere riutilizzata diverse volte, producendo sempre un prodotto differente. 4.4 Integrazione delle applicazioni di PA con i sistemi PLM o PDM aziendali Nelle piccole e medie imprese, notevole importanza riveste la possibilità di integrare il sistema di progettazione, automatico o non, con il sistema di gestione documentale o, in generale, con il sistema di archiviazione documenti che contiene lo storico aziendale. I vantaggi derivanti dal recupero di documenti che rappresentino componenti o progetti già realizzati sono evidenti. Infatti, il modello CAD di un componente esistente in un archivio, per esempio, significa che esso è già stato progettato e, con buona probabilità, anche ingegnerizzato, con conseguente risparmio di costi e tempo. I moderni strumenti PDM (Product Data Management) permettono di tenere traccia dei documenti presenti in azienda e di gestire il flusso di lavoro fra i partecipanti ad un progetto, Alintec Scarl Milano, Settembre 2008 [38]

39 sfruttando le reti interne aziendali. I documenti, in formato digitale, possono essere archiviati o in uno spazio digitale condiviso, o essere contenuti in più database a seconda della necessità di dover attribuire particolari proprietà e funzionalità ai componenti che essi rappresentano. Tipicamente, questi documenti sono sotto forma di parti CAD 3D, disegni 2D, documenti di videoscrittura o tabelle o fogli di calcolo e il sistema PDM li classifica secondo attributi e parametri che vengono definiti ad hoc. Il sistema PDM, che non riconosce il contenuto del file vero e proprio, ma ne tiene traccia solamente attraverso le proprietà associate, di fatto non viene integrato, salvo particolari applicazioni specifiche, a nessun sistema di produzione dei documenti stessi, quali, ad esempio, i sistemi CAD. In realtà, i moderni sistemi PDM sono anch essi dotati di questa caratteristica. Pertanto, appare evidente che, se si volesse integrare il sistema KBE o, in generale, l applicazione di PA con il sistema PDM, bisognerebbe adottare il metodo utilizzato dal PDM per fare la ricerca nel proprio sistema. In altre parole, questo significa realizzare un interrogazione avendo come linguaggio di interlocuzione il sistema di codifica adottato nelle aziende. Il sistema di PA deve, in definitiva, essere in grado di recuperare i file da un PDM sfruttando il sistema di codifica. Indiscutibilmente, è necessario adottare un sistema di codifica che permetta un riconoscimento univoco del componente, il cui codice possa essere calcolato in automatico dal sistema in base alle caratteristiche richieste.il problema della codifica in ambito industriale è stata ampiamente approfondito in letteratura. Se ne riporta di seguito una breve trattazione. Marchetti [Marchetti; 2005], afferma che la codifica è la determinazione di una serie di caratteri alfanumerici designati ad identificare univocamente gli attributi delle parti, mentre per Philpott, [Philpott; 1994], invece, è più semplicemente il sistema di notazione abbreviato che permette lo sviluppo di un database di oggetti classificati. Da queste due definizioni si desume che la codifica permette il riconoscimento di parti attraverso attributi descriventi la morfologia o la funzionalità delle parti stesse e che essa sia funzionale per permettere l archiviazione dei componenti in database o archivi. Ne consegue che la scelta della codifica è essenziale per una corretta archiviazione dei componenti e un successivo recupero. La scelta degli attributi dipende spesso dal campo di applicazione. Nel contesto della progettazione, infatti, assumono in generale notevole importanza le dimensioni di massima e le funzioni svolte, mentre nel contesto produttivo, si prediligono solitamente materiali e finiture superficiali. In definitiva possibile classificare e raggruppare i vari pezzi in base a metodi differenti: - secondo caratteristiche morfologiche; - mediante caratteristiche tecnologiche; - in base ad entrambe le caratteristiche. Cagno [Cagno, 2005] classifica i sistemi di codifica raggruppandoli in tre diverse tipologie: - strutturale, che comprende i tipi gerarchico, a catena o misti; - dimensionale; - funzionale. In letteratura sono presenti diversi metodi di codifica, tra i quali si cita il codice Opitz. Si riporta di seguito una breve descrizione a titolo esemplificativo di uno fra i più utilizzati, in accordo con la trattazione di Iyer e Nagi [Iyer 1997] il Codice Optiz. Codice Optiz Alintec Scarl Milano, Settembre 2008 [39]

40 Ampiamente diffuso a partire dagli anni 70, questo sistema considera sia aspetti inerenti la progettazione che aspetti di tipo produttivo. Esso presenta una formulazione strutturale mista e risulta articolato secondo una serie di cifre così raggruppabili: - prime 5 cifre: codifica morfologica mista (inerente alla geometria del pezzo); - seconde 4 cifre codifica tecnologica a catena (informazioni supplementari relative al ciclo di lavorazione); - terze 5 cifre codifica gerarchica per applicazioni particolari(informazioni complementari tipiche della specifica azienda). Si riporta a titolo d esempio quanto proposto da Marchetti [Marchetti, 2005] in cui si evidenzia lo schema classico di un sistema di codifica secondo il metodo Optiz, Figura 22. In Figura 23, si riporta un ulteriore esempio esplicativo inerente alla struttura del codice, secondo quanto proposto da J. W. Sutherland, [Sutherland; 2004]. Figura 22. Codice Optiz secondo Marchetti Figura Rappresentazione del codice Opitz secondo Sutherland Alintec Scarl Milano, Settembre 2008 [40]

41 5 Definizione delle metodologie e degli strumenti ottimali per la realizzazione di sistemi KBE all interno di PMI Per sfruttare appieno le funzionalità di un sistema KBE ed integrarle con il processo di sviluppo prodotto di un azienda è necessario adottare strumenti e metodi che facilitino l adozione di tali tecnologie. Dal momento che per lungo tempo la tecnologia KBE è sempre stata appannaggio delle grandi industrie aeronautiche e automobilistiche, le quali potevano allocare risorse dedicate al progetto e disponevano di conoscenza già formalizzata, la PMI, al contrario, non ha mai avuto grandi vantaggi nell introdurre tale tecnologia. Oggi, con il proliferarsi di tecnologie sempre più avanzate e user friendly, i sistemi KBE stanno cominciando a ritagliarsi un ruolo sempre più importante anche nella PMI. Le metodologie di sviluppo a cui prima si accennava, però, sono sempre state indirizzate alla grande azienda e, così come sono solitamente presentate, non sono direttamente applicabili alle PMI per i motivi discussi nella sezione introduttiva. Lo studio di tali metodologie, tuttavia, è necessario per poter disporre di un punto di partenza su cui definire una nuova metodologia di sviluppo pensata ad hoc per PMI. Diverse sono le soluzioni che sono state proposte e, fra queste, i risultati più interessanti sono sicuramente stati quelli legati al progetto MOKA (Methodology and tools Oriented to Knowledge based engineering Applications), al progetto KOMPRESSA (Knowledge-Oriented Methodology for the Planning and Rapid Engineering of Small-Scale Applications) e il progetto DEKLARE (Design Knowledge Acquisition and Redesign Environment). Queste metodologie forniscono anche strumenti di acquisizione e formalizzazione della conoscenza che sono stati il punto di partenza per la definizione della nuova metodologia. Nei prossimi paragrafi, saranno descritte nel dettaglio tali metodologie. 5.1 MOKA Il progetto MOKA (Methodology and tools Oriented to Knowledge based engineering Applications) [MOKA] è nato in seno all industria aeronautica europea, con partner accademici. Hanno partecipato al progetto università quali quella di Coventry in Gran Bretagna e aziende come Airbus. Il progetto, aveva come obiettivi principali: - ridurre il tempo di sviluppo delle applicazioni KBE di almeno 20% nell industria aerospaziale; - fornire metodi e strumenti appropriati per lo sviluppo e il mantenimento delle applicazioni; - porre le basi per uno standard internazionale metodologico. I risultati principali ottenuti furono: - identificazione del KBE Life Cycle ; - sviluppo di modelli formali e informali per l acquisizione, la formalizzazione e la rappresentazione della conoscenza; - creazione di un framework per sviluppo di applicazioni KBE. Le considerazioni da cui i ricercatori sono partiti si possono riassumere nelle seguenti due considerazioni (0 e 0), e cioè che: 1.- i diversi tipi di informazione scambiati durante il ciclo di sviluppo prodotto limitano lo scambio di Alintec Scarl Milano, Settembre 2008 [41]

42 dati stessi; 2.- la rappresentazione della conoscenza nelle aziende è limitata, nel senso che non esistono modelli che la possano esplicare totalmente. Questa ultima considerazione è condivisa dai proponenti del progetto, mentre la prima si riferisce ad un contesto più vecchio di sei anni rispetto a quello nel quale questa trattazione è portata. Proprio il fatto che le tecnologie moderne hanno migliorato alcuni aspetti di usabilità da parte degli utenti, ha permesso di estendere gli studi del settore non solo alle grandi industrie ma anche alle PMI, da cui, l ideazione della Metodologia presentata più avanti. Considerazioni iniziali del progetto MOKA Il progetto MOKA parte dalla considerazione dei seguenti punti: - i diversi tipi di informazione scambiati durante il ciclo di sviluppo prodotto limitano lo scambio di dati stessi; - la rappresentazione della conoscenza nelle aziende è limitata. Limitazioni dovute ai diversi tipi di informazione prodotte dalle varie tecnologie a supporto della progettazione Secondo Klein [Klein; 2000], e come si è già detto in 2.1 citando [Eder; 2004; Ishino; 2002; Kerr; 1990; Wallace; 1999] e simili, la conoscenza ingegneristica è complessa e varia. Molti aspetti della conoscenza, dalle leggi fisiche e geometriche, delle tecniche di base alle funzioni euristiche, esperte e altamente specializzate, rientrano in tutto il ciclo di progettazione di un prodotto. Il complesso della progettazione è la soluzione dei problemi di ingegneria: può essere considerata come interazione di tutte le fasi: analisi di requisiti, concept, problem solving, attività di ottimizzazione, ecc., interagiscono tra loro in questo processo. La soluzione dei problemi di ingegneria tipicamente fa partecipare gruppi di persone con background differenti di tipo ingegneristico. La complessità della conoscenza coinvolta, sia dei domini in gioco che dei processi ingegneristici annessi, provoca una grande diversità di strumenti: Cad, strumenti numerici di simulazione, FEM, PDM, ecc. Ciascuno di loro segue il relativo proprio metodo di soluzione dei problemi, ha proprie strutture e requisiti di informazioni, relative conoscenze di fondo, ecc. I generi di conoscenza usati in questi sistemi sono molto differenti e un sistema KBE deve essere in grado di integrarli e permette il trasferimento dall uno all altro. Problemi di rappresentazione della conoscenza La complessità e la diversità della conoscenza ingegneristica deve poter essere rappresentata adeguatamente per permetterne la sua corretta applicazione nei vari campi di dominio. Essa, pertanto, deve essere il più possibilmente completa, coerente e concisa. Nonostante i vari sforzi compiuti per la rappresentazione della conoscenza, i ricercatori del MOKA hanno riconosciuto una mancanza di capacità di modellazione della conoscenza adeguata. Inoltre, volendosi limitare alla rappresentazione della sola informazione, i modelli di approccio alla modellazione come per esempio l O-O o i formati STEP, oppure le tecniche di rappresentazione della conoscenza general purpose, come il CommonKADS [De Hoog; 1996], non forniscono sufficiente completezza e rigore formale come le piattaforme per la modellazione della conoscenza. Infatti [Klein; 2000], il CommoKADS, pur essendo un potente strumento di modellazione di conoscenza generica, non è completamente espressivo del dominio ingegneristico. Risultati Il progetto MOKA ha fornito i seguenti risultati: Alintec Scarl Milano, Settembre 2008 [42]

43 - identificazione del ciclo di vita di un applicazione KBE; - definizione di un modello di conoscenza formale e informale per l organizzazione e la formalizzazione della conoscenza ingegneristica; - definizione di meta modelli per la strutturazione della conoscenza esplicita; - un framework a supporto della modellazione della conoscenza finalizzata allo sviluppo delle applicazioni. Nei paragrafi successivi, si descrivono i vari punti nel dettaglio. Ciclo di vita delle applicazioni KBE Il primo risultato ottenuto dal MOKA è l individuazione del ciclo di vita di un applicazione KBE. In Figura 13, sono mostrate le fasi dall identificazione e la definizione dei requisiti dell applicazione, la cattura della conoscenza la formalizzazione, l implementazione. Fino all installazione e avviamento. Figura Ciclo di vita delle applicazioni KBE secondo il progetto MOKA. Introduzione e definizione di modelli per l acquisizione della conoscenza e la successiva formalizzazione Il progetto MOKA ha messo a disposizione degli sviluppatori alcuni strumenti per la cattura della conoscenza e la sua descrizione sia in maniera informale (durante le fasi di acquisizione con la presenza degli esperti del dominio industriale) che in maniera informale (finalizzata alla creazione delle applicazioni). Lo strumento principale realizzato per la descrizione informale della conoscenza è il modello ICARE. Esso consta di una serie di moduli che permettono la descrizione e le relazioni di immagini, attività, entità, regole e vincoli, per quanto riguarda la cattura della conoscenza di prodotto, e diagrammi che regolano le relazioni fra i moduli ICARE stessi, per definire la conoscenza di processo. In Figura 14 è mostrato un esempio di modulo ICARE, dove si possono notare i campi da compilare per la descrizione delle entità dell applicazione. Per la formalizzazione della conoscenza finalizzata alla creazione di applicazioni KBE, il MOKA ha ripreso i concetti della modellazione UML inquadrandoli nel contesto KBE. È nato un linguaggio chiamato MML (MOKA Modelling Language), un cui esempio è mostrato in Figura 15. Alintec Scarl Milano, Settembre 2008 [43]

44 Figura Esempio di modulo ICARE. Lo strumento principale realizzato per la descrizione informale della conoscenza è il modello ICARE. Esso consta di una serie di moduli che permettono la descrizione e le relazioni di immagini, attività, entità, regole e vincoli, per quanto riguarda la cattura della conoscenza di prodotto, e diagrammi che regolano le relazioni fra i moduli ICARE stessi, per definire la conoscenza di processo. In Figura 14 è mostrato un esempio di modulo ICARE, dove si possono notare i campi da compilare per la descrizione delle entità dell applicazione. Per la formalizzazione della conoscenza finalizzata alla creazione di applicazioni KBE, il MOKA ha ripreso i concetti della modellazione UML inquadrandoli nel contesto KBE. È nato un linguaggio chiamato MML (MOKA Modelling Language), un cui esempio è mostrato in Figura 15. Figura Esempio di lingaggio MML. Alintec Scarl Milano, Settembre 2008 [44]

45 Framework per la formalizzazione della conoscenza Il progetto MOKA ha fornito infine uno strumento di modellazione della conoscenza che supporta gli sviluppatori nella formalizzazione della conoscenza, prelevando le informazioni dai modelli ICARE e trasformandoli in modelli UML. In Figura 16, uno screenshoot del software realizzato. Figura 16.- Lo strumento di formalizzazione messo a punto all'interno del progetto MOKA. Considerazioni finali sul MOKA Il progetto MOKA ha senza dubbio messo in luce il problema della formalizzazione della conoscenza finalizzata alla creazione di applicazioni KBE, definendo una metodologia di acquisizione e formalizzazione della conoscenza e fornendo gli strumenti per poterla seguire. Due considerazioni vanno però fatte: la prima riguarda la copertura di questa metodologia attraverso il contesto operativo dello sviluppo di applicazioni KBE, il secondo considera l applicabilità di tale metodologia nelle PMI. La metodologia MOKA, infatti, copre i passaggi di acquisizione e formalizzazione della conoscenza ma non tocca, a mio avviso, alcuni aspetti fondamentali dello sviluppo di applicazioni, come lo studio dell integrabilità dell applicazione con ciò che è già esistente in azienda (soprattutto dal punto di vista documentale) e l analisi dell impatto che l introduzione di un applicazione di progettazione automatica può indurre sul processo di progettazione. Se tali lacune non sono apprezzabili nel campo delle grandi industrie come quella aeronautica, alla quale è indirizzato il progetto MOKA, dove per questioni di lungo termine è giustificata la messa a punto di un applicazione che coinvolga tout court il processo di progettazione, queste sono invece considerevolmente onerose nel contesto della PMI, dove è necessario non stravolgere i cicli processuali al fine di non appesantire troppo l onere dell allocazione delle risorse e dove il recupero dell esistente è necessario per non dover ulteriormente modificare i propri modelli informativi aziendali. Alintec Scarl Milano, Settembre 2008 [45]

46 La metodologia di sviluppo presentata nella sezione 6 cerca di superare queste lacune, per fornire anche alle PMI quegli strumenti necessari per l acquisizione, la formalizzazione e l organizzazione della conoscenza senza dover stravolgere la realtà di processi e documenti presenti in azienda. 5.2 KOMPRESSA Il progetto KOMPRESSA (Knowledge-Oriented Methodology for the Planning and Rapid Engineering of Small-Scale Applications) è un progetto indirizzato anche alla piccola impresa. È adatta a progetti di taglia ridotta e applicabile anche da utenti inesperti. Essa copre l intero ciclo di vita di sviluppo di un applicazione. Il fine della metodologia è quello di fornire: - linee guida per l analisi di attività e prodotto; - istruzioni per la definizione di pratiche standardizzate per il mantenimento e il riuso della conoscenza; - formati per la rappresentazione e la gestione della conoscenza; - tecniche di implementazione per la condivisione delle esperienze e competenze a vantaggio dei nuovi progettisti; - suggerimenti per la stesura di documenti. La metodologia prevede alcune fasi, che sono: - indagine iniziale; - classificazione dell applicazione; - analisi dei requisiti; - cattura della conoscenza e progettazione applicazione; - selezione dello strumento; - implementazione; - validazione, verifica e testing; - realizzazione del sistema; - mantenimento. Fasi della metodologia Indagine iniziale L attività iniziale indaga su quali siano le caratteristiche dell azienda in termini di mercato, struttura organizzativa, prodotti, flusso di informazioni e livello di automazione di uso della conoscenza. Attraverso opportuni strumenti, essa crea una serie di modelli tra loro correlati che identificano o giustificano l area di applicazione. Classificazione dell applicazione La seconda fase prevede la classificazione dell applicazione secondo una catalogazione definita in base all analisi di caratteristiche condivise con altre applicazioni. In questa maniera, si differenziano alcune delle attività successive. Analisi dei requisiti La fase di analisi dei requisiti prevede lo studio e la definizione delle seguenti caratteristiche: - prestazione e rendimento dell applicazione; Alintec Scarl Milano, Settembre 2008 [46]

47 - funzionalità dell applicazione; - definizione di massima di una user interface; - conoscenza coinvolta. Cattura della conoscenza e progettazione dell applicazione La fase di cattura della conoscenza ha lo scopo di pianificare e documentare come soddisfare i requisiti. Essa include fasi di: - acquisizione della conoscenza; - modellazione della conoscenza; - validazione della conoscenza, in rapporto ai requisiti richiesti, attraverso l approvazione della sua correttezza. Alla fine di questa attività, si definiscono le relazioni fra le parti, le componenti in gioco e gli utenti. I linguaggi più utilizzati in questa fase sono i diagrammi IDEF, i flow chart e l UML. Selezione dello strumento La fase di selezione dello strumento KBE riguarda l analisi delle funzionalità dei diversi sistemi KBE commerciali e la scelta del software più appropriato per lo sviluppo dell applicazione secondo le specifiche definite nella fase di classificazione dell applicazione e analisi dei requisiti. Implementazione La fase di implementazione corrisponde alla modellazione KBE con lo strumento prescelto. Validazione, verifica e testing Per validazione si intende l analisi della corretta interpretazione della conoscenza da parte dell applicazione, mentre per verifica si intende quella eseguita per accertare la corretta traduzione della conoscenza con il software KBE durante la fase di implementazione dell applicazione. Infine, viene eseguito il testing dell applicazione. Realizzazione del sistema Per realizzazione del sistema si intendono le sottofasi di: - installazione dell applicazione; - training; - preparazione dei manuali utenti. Mantenimento La fase di mantenimento avviene durante la vita produttiva dell applicazione ed è finalizzata a verificare il suo perfetto funzionamento. Ha anche il compito di mantenere aggiornata l applicazione, provvedendo all adeguamento del modello KBE. Per permettere ciò, è necessario che si verifichi che la conoscenza sia sempre valida, consistente e aggiornata. Discussione La metodologia KOMPRESSA è una delle poche realmente indirizzata alla PMI. Essa comprende le fasi di acquisizione e formalizzazione della conoscenza e di implementazione. Inoltre, essa include anche le fasi di testing, installazione e mantenimento dell applicazione. La metodologia fornisce anche strumenti appositi di cattura, modellazione e implementazione, nonché le specifiche per la verifica della bontà del modello KBE. Alintec Scarl Milano, Settembre 2008 [47]

48 5.3 DEKLARE La metodologia DEKLARE [Forster; 1997] e [Fothergill et al.; 1995] (Design Knowledge Acquisition and Redesign Environment), similmente a quella MOKA, ha il fine di supportare lo sviluppo di applicazioni Knowldge Based Engineering fornendo ai progettisti strumenti per l acquisizione, la rappresentazione e il riuso della conoscenza. Essa nasce nel contesto del progetto ESPRIT e consiste di tre strumenti principali: DEKLARE Design Analysis Methodology (D-DAM), metodologia per l acquisizione della conoscenza dell azienda nello specifico dominio di prodotto; Design Description Language (DDL), linguaggio per la rappresentazione formalizzata della conoscenza acquisita con il D-DAM; Design Advisory System (DAS), un software di supporto per lo sviluppo di applicazioni, partendo dal D- DAM. Una caratteristica interessante della metodologia, è che questa permette, ad ogni livello di intervento, di decidere, controllare e scegliere il metodo di risoluzione preferito. Di seguito, sono presentati i primi due strumenti del DEKLARE. DEKLARE Design Analysis Methodology (D-DAM) La DEKLARE Design Analysis Methodology è una serie di fasi che devono essere eseguite in sequenza per sviluppare un modello di dominio in un modo graduale. Durante l'analisi, l esperto di dominio, con l'aiuto di un progettista e di una documentazione storica che riguarda i progetti passati, segue i punti specificati nel manuale utente specifico creato apposta per il D-DAM [DEKLARE; 1995], per acquisire il know how dell'azienda per la progettazione del particolare prodotto. Il D-DAM sviluppa un modello di conoscenza di tipo estensivo, ossia è utilizzabile non soltanto per modellare la conoscenza tecnica di un prodotto, ma anche per modellare conoscenza di tipo general purpose. Tuttavia, esso non permette la modellazione della conoscenza di tipo strategico. In particolare, con il D-DAM, la conoscenza di tipo problem solving è solamente una decomposizione ad alto livello di scelte di disegno e, la sua rappresentazione e implicita nel modo in cui il Design Advisory System supporta gli sviluppatori e i progettisti dell applicazione KBE. In Figura 17 sono rappresentati i principali step della metodologia D-DAM. In particolare, si può osservare come l acquisizione della conoscenza venga effettuata in due momenti distinti: analisi e sintesi. l analisi considera l acquisizione vera e propria di tutte le informazioni e i dati di prodotto e di processo, mentre durante la sintesi si identificano i rapporti che questi hanno fra di loro. Design Description Language (DDL) I risultati della fase di acquisizione della conoscenza tramite la metodologia D-DAM deve necessariamente essere trascritta in maniera formale, al fine di preparare la base per la successiva implementazione. Il linguaggio DDL descrive la conoscenza acquisita, con supporto anche grafico, utilizzando tre diversi modelli: - Modello Funzionale: decomposizione delle funzioni del prodotto, con la rappresentazione di concept di prodotto, soluzioni tecniche e aspetti generici di progettazione; - Modello Fisico: rappresentazione di prodotto vera e propria, con componenti, assemblati, proprietà; Alintec Scarl Milano, Settembre 2008 [48]

49 - Modello di Processo: attività da svolgere attraverso la rappresentazione ad albero di fasi e metodi. Figura I principali passi della D-DAM Figura 18. Modelli dei dati per il linguaggio DDL. Il linguaggio DDL è implementato in un framework che permette la rappresentazione O-O di classi compilate in C++. Come si può notare in Figura 18, i modelli appena elencati per la descrizione della conoscenza includono la Alintec Scarl Milano, Settembre 2008 [49]

50 rappresentazione delle entità descrittive del prodotto e del processo mediante procedure descrittive della conoscenza. Osservazioni La metodologia DEKLARE fornisce gli strumenti per la cattura, la formalizzazione e il riuso della conoscenza, attraverso una metodologia di acquisizione, un linguaggio di modellazione e un tool di sviluppo. Nonostante l indirizzo della metodologia non sia valido solo per le grandi industrie ma anche per le piccole e, nel complesso, essa permetta una precisa rappresentazione della conoscenza con possibilità di riuso, non sembra tuttavia completa e di facile implementazione da parte delle PMI. Infatti, come accade per le altre metodologie citate in precedenza, non si accenna minimamente al recupero dello storico aziendale e all analisi dell impatto di un applicazione di tipo KBE nel processo di progettazione aziendale. 5.4 Altre metodologie Altre metodologie interessanti per lo sviluppo di applicazioni KBE sono il sistema GRAI [Girrard; 2003], il metodo introdotto con l utilizzo di CommonKADS [Kingston; 1992], il RAD [Pinfold; 2006]o il REFIT [Lovett; 2000] CommonKADS Il CommonKADS [Kingston; 1992] è una metodologia di sviluppo di applicazioni Knowledge Based, risultato principale dell Esprit-II project (P5248) KADS-II. Esso non si rivolge solo alle applicazioni KBE, ma anche a quelle KB in generale. È qui riportato perché, nonostante ciò, è rimasto per un po di tempo il termine di paragone con le altre metodologie presentate in precedenza, nonché il loro punto di partenza. CommonKADS supporta la maggior parte di aspetti legati allo sviluppo di applicazioni KB, come la gestione del progetto, l acquisizione e l analisi della conoscenza, la modellazione, l interazione e la progettazione. La metodologia rappresenta lo sviluppo di un applicazione sotto due diversi punti di vista: - prospettiva tecnica: insieme di modelli che descrivono e supportano l applicazione durante il suo ciclo di vita; - prospettiva di gestione del progetto: un modello generico risk driven rappresentativo del ciclo di vita dell applicazione. Per la prospettiva tecnica, di seguito si riportano i modelli che supportano la metodologia: - Organisation Model, descrive l organizzazione aziendale in cui l applicazione è usata; - Task Model, descrive le attività assegnate all applicazione; - Agent Model, descrizione ad alto livello degli agenti coinvolti (es, il sistema KB, gli utenti, i computer, ecc ); - Communication Model, che descrive le interazioni fra gli agenti durante lo svolgimento delle attività; - Expertise Model, descrive la conoscenza usata dal sistema per svolgere le attività. Include una libreria di generici componenti di modellazione come per esempio attività, metodi di problem solvine, e ontologie di dominio. Alintec Scarl Milano, Settembre 2008 [50]

51 - Design Model, cioè lo strumento di implementazione dei modelli precedenti a computer RAD Il Rapid Application Development (RAD) offre metodi ben definiti e strutturati per sviluppo di applicazioni KBE, con lo scopo di ridurne il tempo di implementazione. Le tecniche del RAD sono complementari al metodo tradizionale di progettare del progettista e dello sviluppatore e sfruttano l approccio O-O. Il RAD consiste, fondamentalmente, di cinque fasi: - raccolta delle informazioni - analisi - progettazione dell applicazione - sviluppo - deployment Raccolta delle Informazioni Questa fase consiste di diverse attività. Di seguito, la descrizione di queste attività. Processo di acquisizione del Business. In questa fase, gli analisti studiano i processi di business del cliente servendosi di colloqui specifici con il cliente stesso e chiedendogli di analizzare a fondo i processi rilevanti, passo per passo. I risultati dell attività sono uno o più Activity Diagram. Analisi del Dominio. L'analista intervista l esperto di dominio con lo scopo di acquisire le entità principali del prodotto del cliente. Alla conversazione tra l'analista e l esperto, prende parte anche un altro membro del team il quale prende accuratamente nota di tutto. In particolare, si cerca di porre particolare attenzione ai termini chiave del dominio che vengono appuntati come possibili Classi. Al termine di tale analisi, alcuni termini dell'analisi diverranno attributi mentre determinate azioni, che sono, anch'esse, ritenute di rilevante importanza, saranno etichettate come Operazioni delle Classi. Al termine di tale sezione si produce un Class Diagram ad alto livello ed una serie di appunti. Gli strumenti maggiormente usati in questa attività sono i linguaggi di tipo UML. Identificazione della possibile correlazione tra sistemi. All'inizio del processo di sviluppo, il team di sviluppo identifica esattamente le dipendenze tra i vari sistemi, ovvero da quali eventuali sistemi esistenti il nuovo sistema dovrà dipendere e, viceversa, quali sistemi dovranno dipendere dal nuovo. Il responsabile di tale fase è, solitamente un System Engineer. Al termine di tale sezione si produce un Deployment Diagram. Identificazione dei requisiti di sistema. Questa fase rappresenta la prima sessione di sviluppo misto (Joint Application Development - JAD). Infatti, ad essa partecipano i responsabili dell'organizzazione del cliente, i potenziali utenti e i membri del team di sviluppo. Può essere utile la presenza di un supervisore che si pone come obiettivo quello di riuscire a carpire dai responsabili e dagli utenti ciò che essi realmente desiderano dal sistema. Almeno due membri del team dovrebbero prendere appunti e rifinire il Class Diagram disegnato nella precedente fase di Analisi del Dominio. Presentazione dei risultati al cliente. Quando il team reputa concluse le operazioni di raccolta delle informazioni, il Project Manager presenta i risultati di tale analisi all esperto del dominio dell azienda. Analisi Alintec Scarl Milano, Settembre 2008 [51]

52 A questo punto, il team è pronto per approfondire la conoscenza del problema. Alcune delle azioni di Analisi iniziano, in realtà, proprio durante la fase di raccolta delle informazioni quando viene abbozzato uno "schizzo" del Class Diagram. Comprensione dell'utilizzo del sistema. In una sessione JAD (Joint Application Development) con i potenziali utenti, il team di sviluppo lavora con gli utenti per definire gli Actor (persona o sistema) che interagiscono con ogni singolo Use Case (caso d'uso) sia come beneficiari che come iniziatori dello stesso Use Case. È questo il momento in cui vengono prodotti gli Use Case Diagram. Consolidare gli Use Case. Con gli utenti, al fine di verificare ogni singolo Use Case in base alla sequenza di azioni che ognuno di essi descrive, viene aggiunta una descrizione testuale ai singoli passi di ogni Use Case Diagram. Rifinire i Class Diagram. La persona incaricata di modellare gli oggetti, durante la sessione JAD, dovrà porre la massima attenzione alle discussioni e alle richieste degli esperti aziendali al fine di rifinire i vari diagrammi delle classi. Tale operazione può consistere nel dare dei nomi appropriati alle classi, alle associazioni, alle classi astratte, alle generalizzazioni e alle aggregazioni (vedi). Durante questa attività il Class Diagram diviene più dettagliato. Analizzare i cambi di stato negli oggetti. Durante la creazione dei modelli, sarà importante anche porre attenzione alla descrizione di eventuali cambi di stato di un oggetto, dove questo si renda necessario. Vengono prodotti in questa fase gli State Diagram. Definire le interazioni tra gli oggetti. Fino ad ora il team di lavoro ha soltanto descritto una serie di Use Case e di Class Diagram più o meno rifiniti. In questa attività si definiscono come gli oggetti descritti interagiranno tra di loro. Il responsabile della descrizione dei modelli dovrà sviluppare un insieme di diagrammi che includano i cambi di stato. Si producono i Sequence Diagram e i Collaboration Diagram. Analizzare l'integrazione del sistema da sviluppare con gli altri sistemi preesistenti. Il System Engineer, procedendo in parallelo con tutte le fasi descritte precedentemente, scopre ed analizza tutti i dettagli relativi all integrazione del sistema che si intende sviluppare con eventuali sistemi pre-esistenti o comunque sistemi con i quali sarà necessario cooperare. In tale fase verranno costruiti i Deployment Diagram. Progettazione dell applicazione In questa fase, il team lavora in base ai risultati che sono stati forniti dall'analisi, al fine di progettare l applicazione finale. Le fasi di Progettazione e Analisi necessitano, a questo punto, di essere aggiornati vicendevolmente fino alla definizione dell applicazione. Sviluppare e rifinire gli Object Diagram. I programmatori leggono il Class Diagram e generano tutti gli Object Diagram necessari anche in base all'esame di ogni operazione. Parallelamente si sviluppa un corrispondente Activity Diagram. Tale Activity Diagram costituirà la base per la maggior parte della scrittura del codice nella fase di sviluppo. Sviluppare i Component Diagram. Durante tale fase i programmatori visualizzano i componenti che prenderanno parte nella fase successiva e mostrano le dipendenze tra loro. In questa fase vengono prodotti i Component Diagram. Pianificare il Deployment del sistema. Dopo aver costruito il Component Diagram, il System Engineer inizia a pianificare il Deployment dell'intero sistema per gestire le varie interazioni con altri sistemi. I diagrammi così creati mostreranno dove i componenti risiederanno. Alintec Scarl Milano, Settembre 2008 [52]

53 Disegnare e creare un prototipo dell'interfaccia utente. Tale fase richiede un'altra sessione JAD con gli utenti come continuazione della precedente. Tale fase costitusce un punto intermedio tra Analisi e Progettazione. Un analista GUI (Graphical User Inteface) lavora con gli utenti per sviluppare prototipi su carta di come il sistema si interfaccerà con l'utente finale. In questa fase vengono prodotto delle stampe dei prototipi delle possibili interfacce utente. Sviluppo dei Test. Per sviluppare questa fase è consigliabile avvalersi di uno sviluppatore o di un tester esperto che non appartenga però al team di sviluppo del sistema. Egli utilizzerà gli Uses Cases diagram per sviluppare dei Test Case che siano, preferibilmente, automatizzati. Inizio della Documentazione. Uno o più specialisti della documentazione lavorano con i progettisti del sistema per iniziare la documentazione ed arrivare man mano ad una struttura di alto livello per ogni documento. Viene prodotta in questa fase una bozza di documentazione. Sviluppo In questa fase si utilizzano i risultati della fase di Progettazione per sviluppare l applicazione. Le sottofasi sono descritte di seguito. Implementazione del Codice Con i Class Diagram, gli Object Diagram, gli Activity Diagram e i Component Diagram a disposizione, i programmatori implementano il codice per il sistema. Test del Codice. Ogni nuova implementazione del codice sarà, necessariamente interfacciata con una opportuna fase di test. Queste due fasi sono iterate fino a quando il codice supera tutti i livelli di test sviluppati nella fase di disegno. Vengono prodotti in questa fase i risultati del Test. Costruzione della Interfaccia Utente e collegamento al codice. Questa fase si può considerare come un legame tra Progettazione e Sviluppo. Qui, uno specialista GUI costruisce dei prototipi di interfaccia e che dovranno essere collegati al codice. Naturalmente tale collegamento necessita di una opportuna fase di test e verifica. A questo punto si dovrebbe avere a disposizione il Sistema funzionante completo con l'interfaccia utente. Completamento della documentazione. Il completamento del sistema permette agli esperti della documentazione di terminare la stesura di tutto il materiale necessario per descrivere il sistema. Deployment Quando la fase di sviluppo è completata, il sistema viene installato sull'hardware appropriato ed integrato con i sistemi con cui deve interagire. Questa fase prende il nome di Deployment. Pianificare un piano per il backup ed il recupero delle informazioni. Questa fase, in realtà, può anche iniziare molto prima che lo sviluppo del sistema inizi. Il System Engineer crea un piano che descriverà i passi da seguire nel caso in cui il sistema dovesse andare in crash (Piano di Crash Recovery). Installare il sistema completo sull'hardware appropriato. Questo passo viene eseguito dal System Engineer con l'eventuale supporto necessario da parte dei programmatori. Testare il sistema installato. Dopo aver installato il software sulle macchine appropriate, il team di sviluppo testa il sistema. Le domande che sarà opportuno chiedersi in questa fase sono del tipo: Il sistema si comporta come ci si aspettava? Il piano di backup e di recovery funzionano? A seconda del risultato di tali test si deciderà se è opportuno un ulteriore raffinamento del sistema. Alintec Scarl Milano, Settembre 2008 [53]

54 5.4.3 REFIT La metodologia REFIT (Revitalisation of expertise in foundries using information technology) [Lovett; 2000] è indirizzata alle piccole e medie industrie e consiste di attività divise in gruppi che danno differenti risultati. La metodologia è flessibile, nel senso che molte attività possono essere omesse se inappropriate e vi possono essere iterazioni fra attività diverse o svolgimenti in parallelo. Di seguito, in Tabella 2, si riportano le attività divise per gruppi. Tabella 2. - Tabella dei gruppi, delle attività e dei risultati annessi. 5.5 Analisi e formalizzazione dei processi di progettazione Nelle sezioni precedenti si è discusso di sistemi KBE e di metodi per implementarli nelle imprese, al fine di creare applicazioni di progettazione automatica. Dall analisi delle varie metodologie è emerso che, nelle fasi di cattura della conoscenza, specifico ruolo ha avuto l analisi del processo di progettazione adottato in azienda. L analisi di processo aziendale è una disciplina che si inserisce in un contesto di ottimizzazione delle risorse, dei tempi e dei costi di gestione delle attività di progettazione. A questo si aggiunge lo studio dei risultati di un Alintec Scarl Milano, Settembre 2008 [54]

55 processo, inteso come flusso di informazione e documenti prodotti dalle varie attività componenti il processo stesso. Le attività principali di un analisi di processo sono: - acquisizione della conoscenza di processo; - rappresentazione della conoscenza secondo le specifiche e le finalità del tipo di analisi conseguita; - applicazione di metodi di ottimizzazione dei processi, quali i sistemi di cost analysis per abbattere costi e tempi di esecuzione del processo stesso. Di seguito, si riportano alcune tecnologie (strumenti o metodologie) sviluppate per condurre un analisi di processo IDEF Descrizione IDEF (Integrated Definition, vedi è un gruppo di metodi di modellazione che possono essere usati per descrivere le attività di un impresa. I metodi previsti sono 16 e si identificano con la sigla da IDEF0 a IDEF14, con l aggiunta del metodo IDEF1X. Ogni metodo è designato per catturare diversi aspetti della conoscenza, attraverso una formalizzazione che avviene per modellazione di processi. I metodi IDEF sono usati per generare rappresentazioni grafiche di vari aspetti processuali della conoscenza aziendale, analizzarne la bontà, permetterne il miglioramento e assisterne l applicabilità in contesti differenti. Originariamente sviluppato per il campo manifatturiero aeronautico militare, IDEF0 è ora largamente usato in numerosi campi e contesti, anche in quello della progettazione. La suite IDEF inizialmente conteneva solamente tre diagrammi, ognuno avente compiti specifici per quanto riguarda la modellazione, ovvero l IDEF0, l IDEF1 e l IDEF2. Successivamente sono stati aggiunti un gran numero di costrutti al fine di soddisfare le richieste che provenivano dal mondo della modellazione. In quest ottica si affermarono come standard i modelli IDEF1x, e successivamente, all inizio degli anni 80 gli IDEF3. Negli anni 90 il numero di viste aumentò. Prima la nascita dei diagrammi IDEF4 e IDEF5, poi via via gli altri diagrammi fino ad arrivare all IDEF14. I diagrammi più recenti, a partire dall IDEF 5 in avanti sono per lo più ancora in via di sviluppo e non hanno trovato per ora un utilizzo pratico. Di seguito, si riporta un elenco dei metodi IDEF con un breve commento: - IDEF0: Function Modelling; - IDEF1: Information Modelling; - IDEF1X: Data Modelling; - IDEF2: Simulation Model Design; - IDEF3: Process Description Capture; - IDEF4: Object-Oriented Design; - IDEF5: Ontology Description Capture; - IDEF6: Design Rationale Capture; - IDEF7: Information System Audit Method; Alintec Scarl Milano, Settembre 2008 [55]

56 - IDEF8: User Interface Modelling; - IDEF9: Scenario-Driven IS Design; - IDEF10: Implementation Architecture Modelling; - IDEF11: Information Artefact Modelling; - IDEF12: Organisation Modelling; - IDEF13: 3-Schema Mapping Design. Da notare che in generale, a parte applicazioni più specifiche, i metodi dallo 0 al 4 sono i più usati e permettono una rappresentazione completa della maggior parte dei processi di quasi tutte le aziende, e, tra questi, gli IDEF 0, 1, 1x e 3 coprono la maggior parte delle applicazioni. Pertanto, di seguito si riporta una descrizione più dettagliata di questi ultimi. IDEF0 È una tecnica utilizzata per la rappresentazione di modelli funzionali. Prende spunto dal metodo SADT (Structured Analisys and Design Tecnique) sviluppato da Douglas Ross alla SofTech negli anni settanta e consente di descrivere i processi specificando gli input, gli output, i controlli e i meccanismi, denominati ICOMs nel gergo del linguaggio, rappresentati in Figura 19, da frecce. Figura 19.- Generico diagramma IDEF0. Di seguito una breve descrizione: - input: risorse trasformate o consumate dal processo; - output: elementi creati attraverso il consumo o la trasformazione degli input; - controlli: sono le entità guida del processo e generalmente sono rappresentate da leggi, standard, linee guida o politiche aziendali; - meccanismi: agenti che eseguono le attività contenute nel processo (persone, manuali e strumenti), che non vengono consumati o trasformati dalle attività. Informazioni specifiche sul linguaggio IDEF si possono trovare in [IDEF0]. Un aspetto molto importante è il fatto che IDEF0 è un diagramma che fornisce una rappresentazione statica dei processi, ovvero che risulta essere slegata dalla variabile temporale. I diagrammi di IDEF0 possono essere decomposti per ottenere delle viste di dettaglio di una certa attività o processo. Si parla in questo caso di diagrammi figli. Alintec Scarl Milano, Settembre 2008 [56]

57 IDEF1 e IDEF1x I diagrammi IDEF1 nascono con l intenzione di catturare le informazioni esistenti riguardanti gli oggetti che popolano l impresa. Inizialmente essi sono stati utilizzati nell ambito della Computer Integrated Manufacturing (CIM) principalmente per: - mettere in luce quali informazioni erano disponibili all interno dell organizzazione; - mettere in luce i problemi causati dalla mancanza di una gestione appropriata delle informazioni; - specificare le informazioni che necessitavano di essere gestite nell implementazione di un TO BE. Il diagramma IDEF1 permette di modellare le informazioni che hanno a che fare con il business, ovvero quali informazioni tale business ha necessità di conoscere e gestire, attraverso un approccio implementation indipendent, inadeguato allo scopo di progettare e realizzare un database. Permette semplicemente di modellare entità, relazioni, attributi e attributi chiave. IDEF1x completa l IDEF1, supportando il data modeling. Costituisce un valido metodo per disegnare database relazionali e possiede una sintassi progettata al fine di supportare i costrutti necessari per lo sviluppo di schemi concettuali. Per schema concettuale si intende una definizione singola e integrata dei dati aziendali che non risenta della particolare applicazione, della tipologia di accesso o dal sistema di immagazzinamento dei dati. A causa di queste sue caratteristiche non è uno strumento particolarmente adatto nell analisi dell AS-IS, sebbene sia spesso utilizzato in alternativa all IDEF1. E maggiormente utile nella progettazione di database logici, dopo che tutte le informazioni sullo stato presente di un sistema sono state raccolte e sono state prese le decisione atte all implementazione di un nuovo database relazionale. IDEF3 L IDEF3 si divide in P.F. (Process Flow) e OSTN (Object State Transition Network). Il P.F. è stato creato specificatamente per catturare le descrizioni di sequenze di attività. Nel diagramma Process Flow si rappresentano le attività che fanno parte del processo (rettangoli) e le dipendenze causali e temporali fra attività (frecce), cioè vincoli del tipo l attività A precede l attività B oppure dopo aver eseguito l attività A occorre necessariamente svolgere l attività B. Per guidare il flusso del processo si fa ricorso ad alcuni operatori logici come AND, OR e XOR. Il secondo tipo di IDEF3, cioè l OSTN (Object State Transition Network) fornisce invece una vista del processo incentrata sugli oggetti, rappresentando i cambiamenti di stato degli stessi come transizioni attraverso un attività o una serie di attività. Alcuni strumenti che permettono la modellazione di tipo IDEF - Microsoft Visio - IDEF Tools (fornitore: Knowledge Based Systems, Inc) - AI0 Win 6.0 (supporta la modellazione IDEF0) - SmartER 5.0 (supporta IDEF1-IDEF1X) - ProSim 6.0 (supporta IDEF3) - SmartClass (supporta IDEF4) - Business Modelling Workbench (fornitore: IDEFine) Alintec Scarl Milano, Settembre 2008 [57]

58 - Workflow Modeller - Workflow Simulator - Workflow Generation - WizdomWorks! (fornitore: Wizdom Systems, Inc.) - WorkFlow Modeler (fornitore: Meta Software) - AllFusion Process Modeler (fornitore: Advantage Software Limited) - System Architect (fornitore: Popkin Software) Commenti La metodologia IDEF è utilizzata dagli esperti di analisi di processo per capire e catturare la conoscenza aziendale e per definire e ottimizzare il sistema dello scambio di informazioni. Il linguaggio fornisce un valido strumento per il Business Process Engineering (BPE) e la re ingegnerizzazione di processo. Vi sono molte analogie con la modellazione UML, trattata di seguito, di cui alcune elencate di seguito: - IDEF0 è l analogo del diagramma UML Activity versione estesa alle aziende, usato per la modellazione di processi; - IDEF1 e IDEF1X sono simili ai diagrammi UML Class e UML Object che descrivono in maniera statica l architettura di un prodotto; - IDEF2 lo si può ricondurre ai generici diagrammi di collaborazione, attività e di stato del linguaggio UML; - IDEF3 può essere visto come l equivalente anch esso del diagramma UML Activity e può essere ricondotto anche ad altri diagrammi; - IDEF4 è specificatamente indirizzato alo sviluppo di software e pertanto riconducibile alla caratteristica della rappresentazione UML in classi, oggetti, attività e diagrammi di stato; - IDEF5, infine, può essere comparato con i meta-modelli dell UML, dove sono definite le ontologie di linguaggio UML Lo Unified Modeling Language (UML) fu creato da Grady Booch, James Rumbaugh e Ivan Jacobson all inizio degli anni 90. Successivamente questo linguaggio fu adottato come standard dalla Object Management Group (OMG nel 1997). E un linguaggio di tipo visuale che nasce inizialmente come strumento per coloro che analizzano e progettano sistemi orientati agli oggetti per visualizzare, costruire e documentare sistemi software. UML sta ancora evolvendosi come standard, e in un prossimo futuro è destinato a diventare uno standard internazionale, riconosciuto dall Organizzazione Internazionale per la Standardizzazione (International Organisation for Standardisation, ISO). UML è composto di nove diagrammi predefiniti: - Class Diagram. Descrivono la struttura di un sistema, partendo dalle classi e dalle relazioni tra esse. Le classi sono delle entità in grado di rappresentare e strutturare le informazioni, i prodotti, i documenti e l organizzazione; - Object Diagram. Esprime le possibili combinazioni di oggetti inerenti uno specifico Class Diagram. E tipicamente utilizzato per esemplificare un Class Diagram; Alintec Scarl Milano, Settembre 2008 [58]

59 - Statechart Diagram o State Diagram. Esprime i possibili stati di una classe o di un sistema; - Activity Diagram. Descrive le attività e le azioni svolte all interno di un dell organizzazione; - Sequence Diagram. Permette di visualizzare le sequenza temporale dei messaggi scambiati tra i vari oggetti del sistema; - Collaboration Diagram. Come il Sequence Diagram permette di descrivere i messaggi scambiati tra gli oggetti focalizzandosi sulle relazioni funzionali; - Use-case Diagram. Illustra le relazioni tra casi d uso. Un caso d uso descrive una parte delle funzionalità tipiche del sistema. Molti progetti in ambito di sviluppo software partono dai casi d uso, poiché essi costituiscono un valido strumento per ottenere una visione d insieme di quello che sta accadendo nel sistema esistente o che deve avvenire in quello di nuova implementazione; - Component Diagram. E una speciale tipologia di Class Diagram utilizzati principalmente per descrivere i componenti di un sistema software; - Deployment Diagram. Si tratta anche in questo caso di particolari Class Diagram utilizzati per descrivere le componenti hardware connesse alle funzionalità degli applicativi. Di questi nove diagrammi, solo alcuni possono essere utilizzati proficuamente nell ambito della modellazione dei processi di business. A loro si aggiungono particolari estensioni sviluppate appositamente a questo scopo. Una delle più significative e interessanti è la cosiddetta Eriksson-Penker Business Extension particolarmente utile nel campo del business modeling GRAI Net Le GRAI (Graphes à Résultat et Activités Interreliés) Net sono parte del metodo GRAI per la modellazione e l analisi di sistemi di produzione automatizzati, sviluppato presso Università di Bordeaux tra la metà degli anni 70 e la metà degli anni 80. Il metodo GRAI ha costituito la base per lo sviluppo della metodologia GIM (GRAI Integrated Methodology) per la modellazione d azienda. Le GRAI Net sono state sviluppate per modellare i centri decisionali dei sistemi di produzione automatizzati e, per questo motivo, non permettono di modellare attività che cooperano, ad esempio, attraverso scambi di messaggi. Inoltre con questo linguaggio non si riescono a rappresentare neanche i flussi di controllo circolari, i flussi di dati e/o oggetti, le sincronizzazioni tra le attività e l impiego ed il consumo delle risorse. Per questi motivi tale modelli non si presentano come un buon supporto per la simulazione del processo. Il metodo GRAI è un linguaggio essenzialmente descrittivo. Esso fornisce i seguenti costrutti con rappresentazione grafica, come in Figura 20: - il costrutto State, rappresentato da un cerchio con etichetta, è usato per modellare gli stati del processo. - il costrutto Activity, rappresentato da una freccia con etichetta, è usato per modellare attività, ovvero trasformazioni che comportano la transizione da uno stato iniziale ad uno stato finale. Lo stato iniziale e lo stato finale descrivono rispettivamente i dati/oggetti necessari per l attivazione e i dati/oggetti prodotti. Si distinguono: - Execution activity, contraddistinte da layout orizzontale, che trasformano dati/oggetti. Alintec Scarl Milano, Settembre 2008 [59]

60 - Decision-making activity, contraddistinte da layout verticale, che modellano attività decisionali. Esse sono caratterizzate da obiettivi e variabili decisionali, entrambi rappresentati da rettangoli. - il costrutto Support, rappresentato da un rettangolo, è usato per modellare le informazioni e le risorse che supportano lo svolgimento di un attività. Le Activity sono connesse da flussi di controllo, modellati tramite i seguenti Link: - Sequential link, che modella flussi sequenziali; - And link, che modella flussi paralleli - Fan-in, che modella flussi paralleli convergenti - Fan-out, che modella flussi paralleli divergenti - OR link, che modella flussi alternativi - Fan-in, che modella flussi alternativi convergenti - Fan-out, che modella flussi alternativi divergenti GRAI consente di strutturare il modello per livelli di dettaglio, associando alle Activity GRAI Net che ne dettagliano le funzioni. Figura 20.- Costrutti del metodo GRAI. Alintec Scarl Milano, Settembre 2008 [60]

61 6 Progettazione di un servizio basato su sistemi KBE di supporto alla progettazione all interno di PMI In questa sezione si presenta la metodologia MEDEA (MEthodology for DEsign Automation), che gli esecutori del progetto hanno sviluppato sintetizzando lo stato dell arte presentato in precedenza sui sistemi KBE, i metodi di acquisizione e formalizzazione della conoscenza e le metodologie di implementazione dei sistemi di PA, con le problematiche evidenziate nella sezione 2, dove si sono discussi alcuni temi tipici della progettazione automatica sulla rappresentazione di prodotto e di processo di progettazione, il riuso e la condivisione della conoscenza, l integrazione dei sistemi di progettazione con i sistemi PLM presenti nelle PMI. È stata pertanto desunta una metodologia di sviluppo di applicazioni di PA che è stata poi affinata mediante sperimentazione in contesto industriale. Di seguito si presenta dunque MEDEA, così come è stata definita grazie alla sperimentazione. In particolare, si presentano innanzitutto i diagrammi IDEF0, anti a formalizzazione della metodologia. Successivamente, vengono presentate le fasi principali di MEDEA più nel dettaglio. 6.1 Una metodologia per lo sviluppo di applicazioni di PA Dallo studio e dalla sintesi dello stato dell'arte dei metodi di rappresentazione e analisi dei processi di progettazione, dei sistemi di implementazione di applicazioni di PA, in particolare dei sistemi KBE, e dall analisi di alcuni aspetti caratteristici della progettazione meccanica, è emerso come sia necessario definire una metodologia a supporto delle PMI per lo sviluppo di applicazioni di PA che permetta di formalizzare e rappresentare correttamente i problemi ingegneristici. A tal scopo, è stata dedotta una metodologia di sviluppo indirizzata alle piccole e medie aziende e sperimentata in contesto industriale. Il fatto che sia stata sperimentata in diversi casi di studio, ha permesso di poterla generalizzare e indirizzare proprio alle PMI che hanno, nello specifico, esigenze diverse da quelle della grande industria. Una fra le differenze sostanziali tra l'approccio utilizzato nelle metodologie presentate nei capitoli precedenti, adatte ad un contesto industriale ad alto contenuto tecnologico e questa, adatta per PMI, è che la maggior parte delle prime generalmente richiedono un approccio tout - court allo sviluppo, mentre la seconda può operare anche solo parzialmente. In altre parole, mentre per i motivi citati in precedenza la grande azienda può permettersi di convertire tout - court tutto un sistema e un processo di progettazione, nel caso delle PMI questo si traduce sicuramente in uno svantaggio dal momento che, durante lo sviluppo di un eventuale applicazione di PA, è più difficile sostituire i normali processi aziendali che vengono coinvolti nello sviluppo. Un altro punto a favore delle PMI lo segna il fatto che in questa metodologia è dato ampio campo allo studio dell integrazione dei sistemi di gestione documentale aziendali, come, per esempio, i PDM. Per fare ciò, è quindi necessario definire alcune fasi in più rispetto alle tradizionali metodologie di progettazione. Esse riguardano lo studio di integrabilità dei sistemi di progettazione e gestione documentale già presenti in azienda e lo studio di applicabilità dei sistemi di tipo KBE ai processi aziendali. I risultati dell applicazione della metodologia riparano alle criticità espresse in precedenza e sono: - capacità di strutturare la conoscenza sia di dominio che di processo; Alintec Scarl Milano, Settembre 2008 [61]

62 - - analizzare e ottimizzare i propri processi di progettazione; massimizzare il riuso e la condivisione della conoscenza; - integrare sistemi e documenti in un'applicazione di configurazione automatica di prodotto. Nelle prossime pagine sono rappresentati i diagrammi IDEF0 che esplicitano nel dettaglio le fasi di MEDEA. Si tenga presente che un diagramma IDEF0 non descrive il flusso temporale delle attività, ma il flusso delle informazioni e dei documenti che passano attraverso le attività stesse. A prima vista potrebbe sembrare che una modellazione temporale delle attività, come per esempio l utilizzo del linguaggio IDEF3, sia più idonea a descrivere la metodologia. Si ritiene, invece, che, essendo MEDEA una metodologia generalizzata per vari contesti, e ciò è stato fatto grazie alla sperimentazione, il flusso temporale delle attività può essere diverso da caso a caso,mentre il flusso delle informazioni rimane pressoché costante. Pertanto, è stata preferita la modellazione IDEF0 che permette la descrizione del flusso delle informazioni. Figura 24. MEDEA Alintec Scarl Milano, Settembre 2008 [62]

63 Figura 25. Fasi principali di MEDEA (A0) Alintec Scarl Milano, Settembre 2008 [63]

64 Figura 26. MEDEA Acquisizione della conoscenza A2 Alintec Scarl Milano, Settembre 2008 [64]

65 Figura 27. MEDEA Definizione dell architettura di prodotto A21 Alintec Scarl Milano, Settembre 2008 [65]

66 Figura 28. MEDEA Definizione del processo di progettazione A22 Alintec Scarl Milano, Settembre 2008 [66]

67 Figura 29. MEDEA Acquisizione del formato dei documenti presenti nell archivio aziendale A23 Alintec Scarl Milano, Settembre 2008 [67]

68 Figura 30. MEDEA Formalizzazione della conoscenza A3 Alintec Scarl Milano, Settembre 2008 [68]

69 Figura 31. MEDEA Formalizzazione della conoscenza di prodotto A31 Alintec Scarl Milano, Settembre 2008 [69]

70 Figura 32. MEDEA Formalizzazione della conoscenza di processo A32 Alintec Scarl Milano, Settembre 2008 [70]

71 Figura 33. MEDEA Rappresentazione della conoscenza A4 Alintec Scarl Milano, Settembre 2008 [71]

72 Figura 34. MEDEA Rappresentazione delle architetture di prodotto A41 Alintec Scarl Milano, Settembre 2008 [72]

73 Figura 35.. MEDEA Rappresentazione dei processi di progettazione A42 Alintec Scarl Milano, Settembre 2008 [73]

74 Di seguito si descrivono nel dettaglio le fasi rappresentate nei diagrammi IDEF0, attraverso l analisi delle macro attività riprodotte nel diagramma A Definizione delle specifiche di progetto Questa fase, codificata A1, è eseguita dal progettista che, intervistando l esperto aziendale stabilisce le specifiche di progetto, cioè definisce quali sono le finalità dell applicazione e decide con quali criteri rendere riutilizzabili parti di progetto. 6.3 Acquisizione della conoscenza Questa fase (A2) è indirizzata all acquisizione delle conoscenze di dominio e di processo ed è importante per formalizzarle successivamente. Il risultato di questa attività è la raccolta dei dati di processo e di prodotto e i metodi di integrazione fra il sistema di progettazione automatica da implementare e i sistemi di gestione documentali quali PDM o archivi in generale. Inoltre, si definiscono quali sono i gruppi eleggibili di riusabilità e in che modo renderli generalizzabili per archiviazione in libreria, in modo da facilitare l implementazione di futuri progetti. L attività si divide in tre fasi principali che sono: - definizione dell architettura di prodotto; - definizione del processo di progettazione; - acquisizione del formato degli archivi aziendali. Definizione dell architettura di prodotto Questa attività (A21) è mirata a definire le specifiche tecniche di usabilità, come.2 e a specificare i dati di prodotto in termini di definizione di gruppi funzionali, architettura di prodotto e suoi componenti. Le sottofasi di quest attività sono: - intervista all esperto aziendale e raccolta del materiale relativo alla descrizione prodotto, alla sua conformazione architettonica e ai sui componenti costitutivi; tali dati si presentano ancora non organizzati. - organizzazione del materiale mediante prima definizione dei gruppi funzionali, con generalizzazione dei componenti e dei sottogruppi candidati al riutilizzo per la creazione della libreria personale; - definizione gerarchica dell architettura di prodotto mediante rappresentazione ad albero; - definizione dei componenti del prodotto e delle varianti architettoniche. Definizione del processo di progettazione L attività di acquisizione del processo di progettazione (A22) ha l intento di ottenere i dati relativi al processo di progettazione sotto forma di flusso di attività e di informazioni. Come nell attività di definizione dell architettura di prodotto di paragrafo 0 esiste l attività di intervista e raccolta materiale il cui risultato è una serie di dati e documenti organizzati che vanno successivamente suddivisi. Pertanto a questa prima fase, eseguita con l epserto aziendale, seguono le fasi di - ripartizione del materiale raccolto secondo la gerarchia dei gruppi funzionali; - definizione delle procedure di scelta dei componenti, con la specificazione delle regole e dei metodi di scelta; Alintec Scarl Milano, Settembre 2008 [74]

75 - definizione delle procedure dei metodi di dimensionamento dei componenti con la definizione delle regole di dimensionamento. Acquisizione formato archivi aziendali In questa fase (A23), svolta dal progettista, si indaga il sistema di archivio aziendale o il sistema PDM presente. Lo scopo è quello di determinare le specifiche di integrazione fra la futura applicazione di progettazione automatica e il sistema di gestione documentale stesso. In altre parole, si indaga in che modo l applicazione deve interrogare gli archivi per verificare l esistenza dei componenti già progettati e ingegnerizzati e procedere alla loro scelta in base ai calcoli di dimensionamento effettuati. I vantaggi del poter utilizzare componenti già ingegnerizzati, che potrebbero in verità essere sovradimensionati, rispetto ad un componente progettato ad hoc, risiede ne fatto che le successive attività di ingegnerizzazione stesse, quali analisi a elementi finiti, definizione delle modalità di produzione, ecc, sono costose. Il riutilizzo di prodotti già esistenti, invece, riduce il costo sia di progettazione che di produzione. La fase di acquisizione dei formati documentali consta delle seguenti attività: ati dei documenti archiviati, con individuazione - acquisizione delle tecnologie di gestione documentale, dove si elencano tutte le funzionalità dei sistemi e la loro attitudine all integrazione fra software; - acquisizione dei formati dei documenti archiviati, con individuazione dei parametri di integrazione; - definizione dei metodi e delle proprietà di integrazione, con la definizione delle specifiche tecniche di integrazione 6.4 Formalizzazione della conoscenza Le attività di formalizzazione della conoscenza (A3) sono indirizzate alla descrizione formalizzata della conoscenza acquisita. Come per le attività di acquisizione, le attività di formalizzazione riguardano prevalentemente tre argomenti: l architettura di prodotto, il processo di progettazione e l interazione fra sistema di progettazione automatica, utenti e sistemi di gestione documentale. I risultati di quest attività sono: - modelli UML Static Class Diagram, che descrivono, mediante rappresentazione di classi, proprietà e metodi associati alle classi, le relazioni fra i componenti e le loro interdipendenze a livello progettuale; - modelli IDEF0 e IDEF3 che descrivono rispettivamente il flusso delle informazioni e delle attività fra una fase e l altra del processo di progettazione; - modelli UML Activity Diagram, che specificano come avvengono le interazioni fra le componenti in gioco; - specifiche di integrazione tra sistema di progettazione automatica e sistemi PLM/PDM. Le attività principali di questa fase sono: - formalizzazione della conoscenza di prodotto; - formalizzazione della conoscenza di processo; - formalizzazione delle interazioni fra sistemi, utenti e sistemi PLM/PDM. Formalizzazione della conoscenza di prodotto Alintec Scarl Milano, Settembre 2008 [75]

76 La conoscenza di prodotto (A31) può essere formalizzata utilizzando le specifiche UML Activity Diagram presentate in precedenza. Questo tipo di rappresentazione raffigura i componenti e i gruppi funzionali di prodotto sotto forma di classi O-O, complete di proprietà e metodi associati. E pertanto possibile definire le dipendenze fra le proprietà di classi diverse, specificando i metodi di definizione delle stesse. Per esempio, la proprietà Momento Torcente della classe Albero, a cui è associato il metodo Calcola Diametro, potrebbe dipendere dalla proprietà Potenza Trasmessa della classe Motore. Le attività principali di questa fase sono le seguenti: - definizione delle classi rappresentanti il prodotto, i gruppi funzionali e i componenti, come, ad esempio, un gruppo motore ed una ruota dentata; - definizione dei parametri delle classi rappresentanti le caratteristiche principali delle classi, come, ad esempio, la proprietà passo di una ruota dentata o la proprietà geometria di un albero di trasmissione di potenza; - definizione dei metodi associati alle classi, che descrivono le procedure di calcolo da eseguire sulle proprietà, come, per esempio, il calcolo del passo della ruota o la generazione della geometria; - analisi di riducibilità delle dipendenze, in cui si identificano le proprietà caratteristiche della classe e si definiscono quelle derivate con metodi esclusivamente interni alle classi stesse; - - creazione dell UML Class Diagram, dove si mettono insieme i risultati delle attività precedenti. Queste attività, in accordo con le specifiche UML, possono essere eseguite con l ausilio di modellatori UML. Il risultato finale sono i diagrammi UML Class Diagram del prodotto. Tale rappresentazione è alla base dell attività di rappresentazione della conoscenza mediante strumenti KBE, grazie alla sua struttura O-O. Formalizzazione della conoscenza di processo La conoscenza di processo (A32) è formalizzata attraverso l esecuzione di tre fasi: - modellazione del flusso temporale delle attività di progettazione, dove si descrive, con la modellazione IDEF3, l ordine temporale delle attività; - modellazione del flusso delle informazioni e dei documenti, dove con la modellazione IDEF3 si raffigura il percorso delle informazioni dei dati e dei documenti attraverso le varie attività; - definizione delle proprietà dei diagrammi IDEF; - dove si definiscono gli output, gli input e le risorse da allocare per le varie attività. L insieme di queste attività genera i modelli IDEF0 e IDEF3 che descrivono il processo di progettazione adottato in azienda. Si ricorre all uso di modellatori IDEF, secondo le nome specifiche. 6.5 Rappresentazione della conoscenza Nella fase di Rappresentazione della conoscenza (A4) si accomunano tutte le attività di sviluppo dell applicazione effettuate mediante uso di sistemi KBE. Tale fase deve assicurare il funzionamento dell applicazione e pertanto include anche le sottofasi di testing ed installazione dell applicazione. Essa si divide in: - rappresentazione delle architetture di prodotto; - rappresentazione dei processi di progettazione - testing e installazione. Alintec Scarl Milano, Settembre 2008 [76]

77 Da osservare che, a seconda del sistema KBE utilizzato, non tutte le attività vengono eseguite. Per esempio, molti sistemi KBE non permettono la rappresentazione del prodotto e si basano solamente sulla rappresentazione di processo. In questo caso, la prima fase è da considerarsi implicita nella seconda. Si ricorda che i diagrammi IDEF0, che sono stati qui utilizzati per descrivere il processo di rappresentazione della conoscenza, descrivono solamente il flusso delle informazioni tra un attività e l altra. Pertanto, tale rappresentazione si addice, ad ogni modo, sia al caso in cui si utilizzano sistemi basati sulla rappresentazione di architetture di prodotto, che, infine sui sistemi che si basano su una rappresentazione mista di prodotto e processo. Per esempio sia utilizzando un sistema come RuleStream, che si basa sulla rappresentazione sia di prodotto che di processo, sia utilizzando un sistema come RuleDesigner che si basa sulla rappresentazione di processi l applicazione di MEDEA rimane tale e quale. Rappresentazioni delle architetture di prodotto La fase di rappresentazione delle architetture di prodotto (A41) consiste nella realizzazione del prototipo di progettazione automatica che ha i seguenti requisiti: - progettare nuovi prodotti, utilizzando anche parti di applicazioni già eseguite; - riprodurre lo storico aziendale; - avere facile manutenzione (modifiche e aggiornamenti); - essere riutilizzabile o avere parti riutilizzabili; - integrarsi col sistema di gestione documentale aziendale. I risultati principali di questa fase sono: - I modelli CAD; - la definizione della libreria di parti di applicazioni; - l albero di controllo del modello KBE. Questa fase consta di 4 attività principali: - modellazione CAD, dove vengono modellati e parametrizzati i componenti e gli assiemi del prodotto, riutilizzando anche i modelli già esistenti negli archivi aziendali; - creazione delle parti e delle sottoparti, delle proprietà e dei metodi associati alle parti, utilizzando il sistema KBE; - creazione delle librerie personali formate da parti di applicazioni che hanno la caratteristica di poter essere generalizzate e quindi riutilizzate in altri contesti; - creazione dell albero di controllo del modello. Rappresentazione del processo di progettazione La fase di rappresentazione del processo di progettazione (A42) è indirizzata alla creazione del modello di processo. Il modello di processo può presentarsi sotto due forme diverse, come riportato nel sezione sulla rappresentazione dei processi di progettazione, e cioè sotto forma di interfacce formate da maschere con cui l utente controlla il modello di prodotto, soluzione per lo più adottata nei sistemi KBE basati sulla rappresentazione di prodotto, oppure come una serie di attività descriventi le operazioni che il sistema stesso Alintec Scarl Milano, Settembre 2008 [77]

78 deve effettuare per configurare il prodotto, soluzione invece adottata maggiormente nei sistemi in cui non è definita la rappresentazione di prodotto. Le attività principali di questa fase sono: - la definizione dei passi da seguire per la configurazione del prodotto; - la creazione di regole per interfacciare il sistema al modello di prodotto, ove possibile; - la creazione delle regole di interfacciamento con sistemi esterni come CAD, fogli di calcolo, database, PDM, archivi in generale, sistemi PLM; - la creazione delle interfacce grafiche di controllo. Alintec Scarl Milano, Settembre 2008 [78]

79 7 Implementazione operativa del servizio progettato nelle PMI Questa sezione descrive la sperimentazione di MEDEA in PMI del settore meccanico. La sperimentazione ha condotto alla definizione finale della metodologia presentata nella sezione precedente. Dopo un introduzione di carattere generale, si presentano in quattro distinte sezioni esempi di applicazioni di PA, che permettono di valutare l impatto di MEDEA per gli aspetti specifici della progettazione automatica presentati nella sezione 2, ossia rappresentazione di prodotto e di processo, riuso e condivisione della conoscenza, integrazione dei sistemi PLM con i sistemi di PA. 7.1 Concetti generali E stata condotta una sperimentazione della metodologia MEDEA nel contesto industriale delle PMI meccaniche. Tale sperimentazione ha permesso di indagare più profondamente alcuni aspetti già evidenziati in letteratura e, inoltre, di definire alcune linee guida su come implementare applicazioni di PA, in modo da: - permettere l automazione dei processi di progettazione; - assicurare l'applicazione delle best practices aziendali; - facilitare il riutilizzo di applicazioni sviluppate, trasferendole in altri contesti, per accelerare il processo di sviluppo di nuove applicazioni; - integrare le informazioni contenute in vari formati negli archivi aziendali nel sistema di progettazione aziendale, per permettere la scelta di componenti già progettati, con netto risparmio di tempo e costi nelle operazioni di ingegnerizzazione successive alla progettazione. I quattro casi descritti sono emblematici di situazioni tipiche e ricorrenti nelle PMI per quanto riguarda lo sviluppo prodotto. Ciascuno di essi ha portato allo sviluppo di un applicazione che ha richiesto l espletamento di tutti gli step descritti precedentemente. In questa sezione vengono però descritti solo gli aspetti più significativi e tipici di ciascun esempio. Essi sono: - per la rappresentazione del prodotto, il caso di una famiglia di macchine utensili per la piegatura di lamiere che presenta interessanti aspetti di gestione dell architettura; - per la rappresentazione del processo si tratta il caso della progettazione di uno scambiatore di calore; - per il riuso della conoscenza, si riporta la descrizione di come è stata organizzata, rappresentata e formalizzata la conoscenza utilizzata nella progettazione di una famiglia di macchine per molle, con lo scopo di rendere riutilizzabili il codice rappresentativo dell applicazione, creando apposite librerie; - per l integrazione con sistemi PLM/PDM di gestione documentale, si presenta un esempio che riguarda la configurazione di una famiglia di agitatori di fluidi. In precedenza è stato sottolineato come le attività di acquisizione, formalizzazione e rappresentazione di prodotti e di processi apportino al processo di sviluppo prodotto indiscutibili vantaggi. Innanzi tutto, lo svolgimento di tali attività è utile alla PMI per migliorare competenze e conoscenze sui propri prodotti e processi.infatti, come rilevato, uno dei punti di discontinuità riscontrati nella gestione del progetto nella maggior parte delle PMI rispetto alle grandi imprese, riguarda la difficoltà di strutturare in maniera organica la propria conoscenza, a causa Alintec Scarl Milano, Settembre 2008 [79]

80 delle limitate risorse disponibili, della scarsa conoscenza dei prodotti stessi e dell'applicazione di procedure derivate da una continua "rimessa a punto" delle preesistenti, comportamento, questo, tipico delle PMI. In secondo luogo, favorisce il trasferimento della conoscenza all interno dell azienda. È questa oggi una chiave fondamentale per poter crescere e migliorare. Infatti, migliorare ed uniformare il know-how degli esperti di prodotto e, nel contempo, formare in breve tempo i nuovi arrivati, sono aspetti che conferiscono slancio all'innovazione ed allo sviluppo di nuovi prodotti. Terzo punto, più specifico nella trattazione che viene qui fornita, essa permette l'automazione di procedure ripetitive e di basso livello intellettuale, permettendo ai progettisti di occuparsi maggiormente di questioni inerenti le metodologie o le tecniche anche innovative da adottare piuttosto che spendere la maggior parte del tempo nel recupero di informazioni, esecuzione di calcoli (con possibilità di errore) e altre attività noiose. Nelle sezioni successive si descrivono nel dettaglio i quattro casi appena presentati,accompagnati dalla descrizione dei risultati ottenuti più importanti. 7.2 MEDEA per la rappresentazione dell architettura di prodotto In molti casi l aspetto principale nello sviluppo prodotto è la definizione dell architettura del prodotto; si tratta di situazioni nelle quali le attività principali del progettista prevedono la scelta del componente più adatto, il dimensionamento di parti, la scelta tra varianti di configurazione stabilite dai valori assunti da determinati parametri. Lo sviluppo di un applicazione di PA in situazioni di questo tipo è centrata sulla rappresentazione dell architettura del prodotto. Come ampiamente illustrato nelle precedenti sezioni, questo fatto coinvolge anche la fase di formalizzazione in quanto formalizzazione e rappresentazione sono strettamente correlate dovendo la prima essere finalizzata alle scelte implementative. La quasi totalità dei sistemi KBE adotta un approccio di tipo O-O per la rappresentazione del prodotto;, esso utilizza come entità elementari le classi con le relative proprietà e i metodi associati. Si tratta di una metodologia di rappresentazione particolarmente adatta per l architettura di prodotto essendo quest ultima nella stragrande maggioranza dei casi di tipo ad albero, per quanto riguarda i componenti essenziali. La metodologia di formalizzazione che meglio si adatta alla rappresentazione O-O è quella UML; il modello del prodotto rappresentato con questo formalismo può essere tradotto direttamente in una rappresentazione ad oggetti. Nel seguito si descrive un caso di studio rappresentativo della tipologia in esame; si segnala il fatto che in questi casi anche gli strumenti CAD, ed in particolare quelli parametrici, offrono strumenti per sviluppare applicazioni di PA. Esse però soffrono di limitazioni dovute sostanzialmente alla difficoltà di gestire varianti, di essere strettamente dipendenti dal modello geometrico e di non permettere la gestione distinta di sottoassiemi e singole parti La famiglia di presse piegatrici di lamiere La pressa piegatrice di lamiera [Carrera; 2005; Pugliese; 2005] (Figura 36) è una macchina utensile adibita alla piegatura di fogli di lamiera per la produzione di parti utilizzate per realizzare armadi e scaffali metallici, case per svariati fini, ripiani ed un infinità di altri prodotti. Nelle presse idrauliche, la movimentazione del punzone è affidata ad una coppia di pistoni idraulici e ad una pompa di cilindrata fissa o variabile. Oltre a questi elementi Alintec Scarl Milano, Settembre 2008 [80]

81 meccanici, è anche previsto un controllo numerico per regolare l afflusso del liquido, secondo le esigenze della piega, che agisce, oltre che sulla corsa e sulla posizione del pestone, anche sulla loro velocità di discesa. Figura Una pressa piega lamiere Il controllo numerico si interfaccia con righe ottiche poste sul punzone per individuarne la posizione e per determinarne la velocità e con la pompa e le valvole del circuito idraulico per correggere attivamente eventuali anomalie. Al controllo numerico fanno anche riferimento i vari sistemi di sicurezza ed un eventuale coordinamento con un altra pressa collocata in serie alla prima come illustrato in Figura 37, per ottenere lunghezze di piega maggiori. La gestione del parallelismo e della posizione del pestone è di tipo master/slave; un pistone funge da elemento guida nel movimento del punzone, determinandone posizione e velocità, mentre l altro lo segue subendo eventuali correzioni in caso di anomalie rilevate dalla riga ottica. La sperimentazione della metodologia è stata eseguita in questo particolare ambito perché esso è rappresentativo di casi di sviluppo prodotto nei quali la definizione dell architettura del prodotto e il proporzionamento dei componenti hanno una notevole importanza e richiedono notevoli risorse. Infatti i modelli di una famiglia di macchine sono numerosi e si differenziano per il valore della forza massima di piegatura e per le dimensioni caratteristiche; i clienti possono richiedere personalizzazioni per quanto riguarda alcune dimensioni caratteristiche e per determinati accessori. Il livello tecnico dell azienda produttrice è elevato e le procedure di progettazione sono ben codificate; nel caso di una richiesta che richieda la progettazione di un modello non compreso nell archivio aziendale, l attività di progettazione è mirata alla modifica di un modello esistente. Il processo non richiede praticamente fasi di calcolo e dimensionamento, piuttosto un onerosa attività di modifica dei modelli e dei disegni al CAD parametrici e di scelta di nuove parti, attività che richiede mediamente una settimana di lavoro di un progettista esperto. Come premesso, i due approcci possibili a questa problematica sono la progettazione di tipo parametrica integrata con fogli di calcolo o linguaggio di programmazione, e l approccio KBE. Una prima esperienza di PA sviluppata su questo specifico prodotto è rappresentata da un applicazione del primo tipo, realizzata mediante l integrazione di un sistema CAD parametrico ed un linguaggio di programmazione. L applicazione di progettazione automatica, sviluppata in Visual Basic, permette il dimensionamento corretto e l assemblaggio dei Alintec Scarl Milano, Settembre 2008 [81]

82 Figura Due macchine in serie per lavorazioni più ingombranti. componenti e la produzione dei documenti tecnici, gestendo parametricamente complessi assiemi CAD. Una completa descrizione la si può trovare in [Grassi; 2004]. L applicazione basata su tecnologia KBE dai proponenti del progetto realizzata presenta sostanzialmente i seguenti vantaggi: - universalità dell applicazione, ossia possibilità di riutilizzo di parti e gruppi funzionali in macchine di diverse famiglie, risparmiando risorse nello sviluppo di nuove applicazioni; - facilità di estensione, che si può effettuare senza dover pesantemente modificare la struttura dell applicazione stessa; - maggiore facilità di manutenzione dell applicazione; - possibile gestione indipendente di sottoassiemi.. L applicazione KBE è stata sviluppata con il sistema RuleStream, dell omonima società americana. Nelle sezioni seguenti, si presentano aspetti significativi delle fasi di formalizzazione e rappresentazione della conoscenza per questo caso Acquisizione, formalizzazione e rappresentazione dell'architettura di prodotto L analisi dell architettura della pressa ha permesso di descrivere lo schema architettonico riportato in Figura 38. Si riconoscono i tre gruppi funzionali principali: - gruppo di pressaggio; - struttura portante; - accessori e sicurezza. Sono state create, per ogni componente, tabelle riportanti le proprietà che servono al corretto dimensionamento, con eventuali dipendenze e descrizione. Di seguito se ne riportano alcune, a titolo di esempio: Alintec Scarl Milano, Settembre 2008 [82]

83 Figura Architettura della pressa. Pestone Tabella 3. - Le proprietà dell elemento pestone e le sue dipendenze Spalla Tabella 4. - Le proprietà dell elemento spalla e le sue dipendenze Traversa inferiore. Tabella 5. - Le tabelle del database utilizzate nella parte Alintec Scarl Milano, Settembre 2008 [83]

84 Una volta definite le tabelle di tutti i componenti, sono stati creati i grafici UML. Nella figura seguente (Figura 39), è rappresentato il diagramma UML statico con una profondità di tre livelli. Figura Rappresentazione UML statica dell'architettura del prodotto secondo la dipendenza delle classi, le proprietà e i metodi associati Più in dettaglio, si presentano i diagrammi UML per il Gruppo Pressaggio e la Struttura Portante (Figura 40 e Figura 41) Figura Diagramma UML statico del gruppo pressaggio della pressa Alintec Scarl Milano, Settembre 2008 [84]

85 Figura Diagramma UML statico della struttura portante della pressa. Rappresentazione dell architettura della pressa Una volta formalizzata la conoscenza relativa all architettura di prodotto, è stato sviluppato il codice. È stato utilizzato uno strumento KBE di tipo O-O che ha permesso la codifica della conoscenza di prodotto rappresentando gerarchie, relazioni e varianti fra componenti e formule di dimensionamento e di scelta. Tale strumento RuleStream dell omonima casa sviluppatrice statunitense, è stato utilizzato creando diverse applicazioni quanti sono i gruppi funzionali della macchina in esame, che sono poi state compilate in un unica soluzione. In Figura 42 A, si può vedere come è stato rappresentato l albero di prodotto, in accordo con i precedenti diagrammi UML Con lo strumento RuleStream, per gestire le varianti, si introducono i concetti di Famiglia di Parti e Sottoparte. Il primo concetto si traduce proprio in un oggetto di tipo parte, inteso come classe in cui sono correlate proprietà e metodi. Il secondo,invece rappresenta la struttura vera e propria del prodotto, in quanto fa da correlatore fra le varie parti e, oltre a definirne l attivazione o meno, ne regola la quantità e l indicizzazione delle singole parti. La parte è marcata nell albero di prodotto con un quadrato blu, la sottoparte con un quadrato più piccolo e accompagnato da un segno di parentesi graffa. Ogni parte è considerata, come accennato in precedenza, come una classe di tipo O-O che contiene proprietà e metodi. Per esempio in Figura 42B, si riporta la parte DIN3760A, rappresentante un anello di tenuta normato di tipo MIM, contenuto in alcuni componenti rotanti della macchina. La proprietà DAlbero mostrata in Figura 42 B risulta così dichiarata: Display Name: D Albero System Name: DAlbero Data Type: Double Alintec Scarl Milano, Settembre 2008 [85]

86 Units: mm (millimiters) Formula: result = this!parent!diametro_di_montaggio Visibile: Yes Enabled: Not Il file CAD di SolidWorks è invece così dichiarato: Geometry Type: SolidWorks Valid Part Files: FINALE_18 - Anello MIM - DIN 3760 A.SLDPRT Driven Properties: dest = RotazioneAnello.Schizzo1.dest dint = RotazioneAnello.Schizzo1.dint h = RotazioneAnello.Schizzo1.h dove si evince che le proprietà dest, dint e h della classe sono quelle che permettono al disegno di modificarsi. Infine, la proprietà Database AnelliditenutaMIM è dichiarata come segue: Display Name: Anelli di tenuta MIM System Name: AnelliditenutaMIM Table: Anelli MIM Sort Column: Diam Interno Bindings: ATipo = Tipo dest = Diam Esterno h = Altezza Criteria: WHERE [Diam Esterno] = this!dalbero dove, ancora, si osserva che le proprietà dest e h, ossia quelle geometriche, sono tabellate, per rispettare le norme DIN La tabella Anelli MIM è contenuta in un Database Server SQL, contenente le colonne Tipo, Diam Esterno e Altezza. Nella Figura 43, è infine visibile l interfaccia utente per la configurazione finale di prodotto, sviluppata con RuleStream, dove si possono vedere sia l architettura del prodotto (così come risulta a seguito delle scelte progettuali), posta a destra, sia la lista delle fasi da seguire per la configurazione, posta a sinistra. In centro, nella parte alta, la maschera di inserimento dati, che varia a seconda della fase di progettazione, e, in basso, il visualizzatore CAD 3D utilizzato per modellare geometricamente i componenti, SolidWorks. Alintec Scarl Milano, Settembre 2008 [86]

87 Figura 42 A. - L'albero con struttura gerarchica fino al terzo livello sviluppato in RuleStream. B. - Contenuto della parte denominata DIN3760A: si possono osservare le proprietà di tipo geometrico e quelle analitiche. Si osserva anche un attributo grafico e un collegamento ad una tabella di un database. Figura 43.-L'interfaccia di configurazione prodotto in RuleStream, con la rappresentazione di prodotto a destra e quella di processo a sinistra. Alintec Scarl Milano, Settembre 2008 [87]

88 7.3 MEDEA per la rappresentazione di processi di progettazione Nei paragrafi precedenti si è trattato un caso emblematico di processo di sviluppo prodotto focalizzato sulla rappresentazione dell architettura di prodotto; in molti altri casi l accento è invece sul processo di progettazione. Si tratta di casi nei quali l applicazione di procedure di calcolo, di dimensionamento di normative prevale sulla scelta di componenti e sulla configurazione di varianti architettonici. Spesso anzi l architettura è fissata ma vi sono lunghe ed onerose attività di dimensionamento e di ottimizzazione, anche con l utilizzo di strumenti informatici. Il processo è solitamente strutturato in una sequenza di attività, con la presenza di eventuali iterazioni ed in questo caso il linguaggio grafico più opportuno per formalizzare conoscenza e procedura è l IDEF0. Qualora si utilizzi per l implementazione uno strumento KBE basato su una logica di programmazione di tipo O-O, come avviene nella maggioranza dei casi, non è possibile operare una traduzione diretta della formalizzazione nel codice dell applicazione. In questi casi la rappresentazione del processo viene annegata negli attributi e metodi nelle classi che rappresentano i vari componenti. Nel seguito si presenta un caso tipico di sviluppo prodotto nel quale l accento è posto sul processo di progettazione; si tratta di uno scambiatore di calore a fascio tubero Lo scambiatore di calore In impiantistica, lo scambiatore di calore è un componente in cui si realizza uno scambio di energia tra due fluidi a temperature diverse. In generale gli scambiatori sono sistemi aperti che operano senza scambio di lavoro, ovvero presentano un flusso costante di fluido e una distribuzione di temperatura a regime costante. Gli scambiatori a miscelazione, più semplici, operano una semplice miscelazione dei fluidi, che di conseguenza si portano alla stessa temperatura. Un esempio è il degasatore di un ciclo a vapore, dove viene normalmente miscelato uno spillamento di vapore. La maggioranza degli scambiatori di calore, al contrario, mantengono distinti i fluidi evolventi, e sono detti "a membrana". In uno scambiatore a membrana si riconoscono due lati, contenenti i fluidi. In virtù del primo principio della termodinamica, i corpi devono essere a temperature diverse perché vi sia trasferimento di energia termica da uno all'altro, e si definiscono quindi un lato caldo ed un lato freddo. Questi lati hanno caratteristiche diverse a seconda del tipo di scambiatore. La sperimentazione è stata effettuata sul tipo detto "a fascio tubiero", il cui schema costruttivo è rappresentato nella Figura 44. Esso è di gran lunga il modello più utilizzato, specie per le grandi quantità di calore scambiate, con superfici che possono arrivare a decine di migliaia di metri quadrati. Figura Scambiatore a fascio tubiero. Alintec Scarl Milano, Settembre 2008 [88]

89 Si distinguono le testate di estremità che delimitano il volume costituito dalla parte interna dei tubi e che è detto lato tubi, i tubi stessi che sono fissati ad una lamiera forata di forte spessore detta piastra tubiera, l involucro esterno che delimita il volume esterno ai tubi, detto lato mantello. Esternamente a questo è rappresentato un distributore, usato solo in caso di fluidi gassosi lato mantello (1 nella figura). Nel mantello possono essere presenti (non raffigurati) dei piatti di lamiera trasversali detti diaframmi che hanno lo scopo di controllare il regime idraulico nel mantello stesso. Lo scambiatore raffigurato è detto a singolo passaggio, o più comunemente ad un passo in quanto, sia lato tubi che lato mantello, i fluidi entrano, attraversano lo scambiatore una volta ed escono. Gli scambiatori a fascio tubiero, essendo i più utilizzati, sono anche quelli meglio definiti dal punto di vista di unificazione e di normativa. In questo ambito fanno testo le indicazioni di dell'associazione statunitense TEMA (Tubular Exchanger Manifacturers Association), che pubblica un'esauriente raccolta di norme relative alla classificazione, dimensionamento e costruzione degli scambiatori. I tubi dello scambiatore non devono necessariamente essere rettilinei - si è già parlato dei serpentini, che però sono dei fasci tubieri impropri - è anzi pratica comune l'uso di tubi curvati ad U (tipo TEMA U), a raggi variabili, uniti mediante la piastra tubiera a formare delle chiome di tubi. Il vantaggio risiede nella estraibilità del fascio tubiero, che può essere facilmente separato dal mantello per ispezione e pulizia, al costo di una minore stabilità meccanica del fascio, che essendo supportato a sbalzo, è sottoposto a maggiori sollecitazioni anche di carattere dinamico per le vibrazioni. Il tipo più semplice di scambiatore a fascio tubiero è il doppio tubo, in pratica un unico tubo circondato da una camicia. Questa è l unica configurazione che permette di realizzare un profilo termico in equicorrente o contro corrente perfetti. Varianti dello scambiatore a fascio tubiero, o piuttosto ibridi tra fasci tubieri e piastre sono gli scambiatori a lamella e derivati con varie denominazioni, in cui il fascio tubiero è sostituito da lamiere grecate tra loro saldate e quindi simile allo scambiatore a piastre, ma che realizzano un passaggio rettilineo simile a quello del tubo. Il processo di progettazione di uno scambiatore a fascio tubiero è alquanto complesso in quanto richiede l adozione di procedure per il calcolo termico e per la definizione della disposizione del fascio tubiero che sono spesso di tipo iterativo. Tali procedure sono state oggetto della sperimentazione ed in questa parte sono descritte le operazioni di acquisizione e fromalizzazione del processo di calcolo e dimensionamento termico. Lo studio dei metodi di calcolo e dimensionamento consistono nella acquisizione delle regole per la costruzione, ovvero norme di calcolo, criteri di progettazione, formule di verifica, ecc Tali conoscenze acquisite sono successivamente implementate per effettuare il dimensionamento e la verifica dei singoli componenti che compongono lo scambiatore di calore Acquisizione e formalizzazione del processo di dimensionamento In questa sezione sono riportate le fasi di acquisizione, formalizzazione e implementazione della conoscenza relativa al processo di progettazione dello scambiatore di calore. Alintec Scarl Milano, Settembre 2008 [89]

90 Acquisizione della conoscenza Attraverso interviste in azienda e studio di manuali tecnici, è stato acquisito il processo di progettazione dello scambiatore adottato in azienda. Esso consta di quattro fasi principali: - definizione delle specifiche, dove si determinano i requisiti del progetto; - dimensionamento dello scambiatore, dove vengono calcolati tutti i dati utili alla costruzione e alla modellazione dello scambiatore - modellazione CAD dello scambiatore, che produce l'assemblato dello scambiatore; - generazione documentale, che produce la lista materiali, i disegni costruttivi e l offerta commerciale. Si sono anche definite le regole di dimensionamento dello scambiatore. Tramite relazioni note in fisica tecnica è possibile determinare: - potenza termica da scambiare (in kw); - portata massica di vapore necessaria (in kg/h); -variazione di temperatura media media logaritmica (in C); - coefficiente di scambio termico (in kw/m 2 C); - la superficie di scambio necessaria (in m 2 ); - temperatura di esercizio di ogni componente. Disposizione del fascio tubiero Disposizione del fascio tubiero La descrizione del metodo di valutazione impiegato per la disposizione del fascio tubiero non presenta formule vere e proprie ma discende da una serie di considerazioni logiche e basate sull esperienza che vengono descritte. Nota la superficie di scambio, il diametro del tubo utilizzato e l ingombro assiale è possibile valutare il numero di tubi necessario a tale scopo. Si passa quindi alla disposizione di detti tubi per creare il fascio tubiero, occorre cioè scegliere un posizionamento che contenga il numero di tubi prefissato, tale posizionamento deve essere tale per cui i tubi completino tutta l area disponibile. Può facilmente accadere che il completamento dello spazio disponibile necessiti di un numero di tubi differente da quello ipotizzato, l impiego di un differente numero implica la necessità di ricalcolare la lunghezza del fascio (per la costanza dell area di scambio e quindi del soddisfacimento dei requisiti termici) con la conseguente variazione nelle dimensioni finali dello scambiatore. Ci si trova prossimi ad una scelta che viene così effettuata: - utilizzare un minor numero di tubi significa avere un ingombro radiale minore ed una lunghezza del fascio maggiore, con conseguente aumento della dimensione assiale dello scambiatore. Poiché il cliente impone un ingombro assiale massimo non è possibile utilizzare questa soluzione; - utilizzare un maggior numero di tubi significa avere un ingombro radiale maggiore e una lunghezza del fascio minore, con conseguente riduzione della dimensione assiale dello scambiatore. Poiché il cliente impone un ingombro assiale massimo è questa la soluzione impiegata. La valutazione della disposizione consente anche la determinazione del diametro esterno del fascio che consente successivamente la stima del diametro interno del mantello. Si tratta quindi di ottimizzare il posizionamento di un dato numero di tubi, ricercando la soluzione fra predefiniti pattern; detta ottimizzazione può essere relativa al numero di tubi o all ingombro. Accade spesso che la disposizione con numero di tubi prossimo a quello Alintec Scarl Milano, Settembre 2008 [90]

91 ipotizzato (approssimato per eccesso) abbia un ingombro diametrale superiore ad un altra disposizione che contiene più tubi, la ragione di questa apparente incongruenza va ricercata nella configurazione base del pattern per cui ad un pattern dato l aggiunta di una serie di tubi sulla circonferenza richiede un differente numero di tubi. Formalizzazione Le quattro fasi descritte nel paragrafo precedente sono riportate nel diagramma IDEF0 rappresentato in Figura 45. Definizione delle specifiche di progetto E la prima fase nella quale il responsabile della progettazione, interagendo con il cliente, acquisisce le informazioni necessarie per poi procedere nella progettazione dello scambiatore. I dati acquisiti sono: - temperatura iniziale e finale del fluido da riscaldare - portata massica del fluido da riscaldare; - pressione del vapore utilizzato per il riscaldamento; - ingombri massimi. In questa fase è richiesta anche la scelta dei materiali da impiegare che viene fatta considerando la natura dei fluidi in transito e gli eventuali problemi di corrosione e costo. Attraverso il know how aziendale vengono trasformate le esigenze del cliente in specifiche indispensabili per la configurazione dello scambiatore. Dopo avere acquisito tutte le informazioni necessarie è possibile procedere alla progettazione vera e propria descritta negli step successivi. Dimensionamento dello scambiatore Questa fase (Figura 46) è suddivisa in sottofasi riguardanti la progettazione degli assiemi e dei componenti dello scambiatore. Dimensionamento fascio tubiero, piastra e mantello La necessità di riscaldare una data portata di fluido da una temperatura ad un altra consente di calcolare la potenza termica richiesta; tale potenza viene fornita dal vapore in fase di condensazione ad una certa pressione. Il progettista senior, esperto determina, attraverso un analisi termica, la superficie di scambio necessaria e definisce con sistemi di drafting il fascio tubiero, ovvero il loro numero di tubi, il loro diametro e spessore, la lunghezza ed il tipo di disposizione. Definito il fascio è possibile configurare alcune delle componenti costituenti il corpo centrale come i settori, il mantello e la parte della piastra tubiera condivisa con il fascio. I settori vengono stabiliti in numero e posizione a seconda della lunghezza dei tubi e del diametro del fascio. Il mantello, che costituisce l involucro del fascio tubiero, viene dimensionato con i tronchetti posizionati su di esso secondo le normative noto il diametro esterno del fascio, mentre la lunghezza è proporzionale a quella del fascio. La parte della piastra tubiera condivisa con il fascio è la parte centrale contenente la foratura, note le dimensioni del fascio, le pressioni e le caratteristiche dei materiali impiegati è possibile dimensionarla. Alla fine di queste operazioni sono risulta completamente definito il tubo, il fascio tubiero, il mantello con i tronchetti, i settori e la zona centrale della piastra tubiera. In Figura 47 è rappresentato il diagramma IDEF0 relativo a questa fase. Configurazione della flangiatura corpo centrale e testate Alintec Scarl Milano, Settembre 2008 [91]

92 Noto il diametro del mantello, la conformazione della foratura sulla piastra tubiera per l inserimento dei tubi e le pressioni in esercizio è possibile la configurazione dell accoppiamento che consiste nella scelta della guarnizione, del numero e diametro dei bulloni; nonché nel calcolo degli spessori delle piastre e nella caratterizzazione delle impronte per il centraggio. In questa fase (Figura 48) il progettista senior si avvale di: - fogli elettronici per dimensionare la bullonatura, la guarnizione e gli spessori delle flange; - database per estrarre le dimensioni dei bulloni standardizzati. A seguito di questa configurazione risultano completamente definite la piastra tubiera, la controflangia, la guarnizione ed i bulloni. Configurazione delle testate La fase di configurazione delle testate (Figura 49) consiste nel dimensionamento del fondo bombato, vincolato dalle dimensioni della controflangia e della connessione. La definizione di queste due parti deriva dalla conoscenza delle dimensioni della piastra precedentemente configurata, delle pressioni e delle portate in transito. Il progettista esperto, con sistemi di calcolo come fogli elettronici dimensiona e verifica le parti, rispettando le norme. Risultano completamente definiti il fondo bombato e le connessioni. Modellazione CAD Questa fase (Figura 50) è divisa in quattro sottofasi. Le prime tre riguardano la modellazione delle parti e dei sottoassemblati dello scambiatore, mentre l'ultima fase concerne l'assemblaggio completo. Le operazioni vengono svolte da un disegnatore con un sistema CAD 3D. I risultati della fase è la produzione di parti e assemblati 3D dello scambiatore. Analisi costi e generazione documenti Noti nel dettaglio tutti i componenti è possibile valutare le materie prime da reperire in commercio ed i tempi di lavorazione associati alla realizzazione del singolo componente o dell assemblaggio; queste operazioni consentono di stimare tutti i costi e di calcolare un prezzo di vendita dell oggetto, tale stima è considerata molto attendibile in quanto nella valutazione sono state considerate tutte le fonti di costo. Per lo sviluppo di questa fase sono necessari il disegnatore ed il progettista junior. Il disegnatore rifinisce e ultima i disegni 2D creati partendo dai modelli 3D; il progettista junior analizza tutti i materiali impiegati, considera gli eventuali sovrametalli, li confronta con i grezzi disponibili in commercio e crea la distinta dei materiali. In ultimo, consulta i listini contenenti i prezzi dei semilavorati e della bulloneria, stima le ore per le lavorazioni e calcola la categoria di rischio del recipiente in pressione al fine di definire il prezzo dello scambiatore. Risulta completamente definito lo scambiatore in ogni sua parte, è compito ora dell ufficio commerciale formalizzare la vendita al cliente. Questa fase è rappresentata nel diagramma IDEF0 di Figura 51 Alintec Scarl Milano, Settembre 2008 [92]

93 Figura Diagramma IDEF0 del processo di progettazione dello scambiatore di calore Alintec Scarl Milano, Settembre 2008 [93]

94 Figura Diagramma IDEF0 del processo di dimensionamento dei componenti dello scambiatore. Alintec Scarl Milano, Settembre 2008 [94]

95 Figura Dimensionamento piastra tubiera, fascio e mantello. Alintec Scarl Milano, Settembre 2008 [95]

96 Figura 48 Dimensionamento flangiatura: diagramma IDEF0 Alintec Scarl Milano, Settembre 2008 [96]

97 Figura Dimensionamento delle testa Alintec Scarl Milano, Settembre 2008 [97]

98 Figura Modellazione CAD 3D. Alintec Scarl Milano, Settembre 2008 [98]

99 Figura Analisi costi e generazione documenti Rappresentazione del processo di dimensionamento dello scambiatore Una volta formalizzati i processi, le regole e i metodi di progettazione, la sperimentazione è passata alla fase di implementazione dell applicazione. Anche in questo caso, come per l applicazione di PA della pressa per lamiere Alintec Scarl Milano, Settembre 2008 [99]

100 trattate in precedenza, lo strumento adottato è RuleStream della Rulestream Corp. Essendo in tale sistema, le regole e i metodi associati alle parti rappresentati nell albero di controllo del modello, per rappresentare il processo vero e proprio il programma mette a disposizione uno strumento per la creazione di interfacce che rappresentano ogni fase del processo, riproponendo così il processo di progettazione così come da formalizzazione. Attraverso questo strumento, si creano delle GUI che permettono la visualizzazione e la modifica delle proprietà dichiarate nell albero di prodotto, che mediante l applicazione delle regole associate, permettono di configurare e dimensionare il prodotto ed i componenti. In più, esse includono anche procedure per la generazione in automatico della Distinta Base, dei disegni 2D e della documentazione generica di prodotto. Con questo sistema, si garantisce l applicazione delle Best Practice aziendali guidando il progettista nelle varie fasi di sviluppo prodotto in maniera corretta. Si riporta ora il modo con cui si è rappresentato il processo di dimensionamento termico le regole riportate nel paragrafo precedente e la successiva fase di definizione della disposizione del fascio tubiero. Quest ultima fase riporta un esempio di integrazione dello strumento per la creazione delle GUI con un foglio di calcolo. Tale integrazione è stata dettata dal fatto che esisteva già un codice scritto creato come macro di Excel per calcolare la disposizione geometrica dei tubi,pertanto è stato deciso in fase di definizione delle specifiche, di utilizzare quello. In Figura 52, si osserva come il sistema, in base alle scelte effettuate durante le fasi precedenti offre al progettista dati già corretti, ma con la possibilità di modificarli in base a particolari esigenze. Tali dati (in figura, per esempio, sono la scelta del diametro nominale del tubo e lo spessore), vengono calcolati in base ai metodi contenuti nelle classi dell albero di prodotto. Figura Tabella di definizione delle dimensioni dei tubi dei fascio tubiero. Nella fase di disposizione del fascio tubiero avvengono le operazioni di export, import e esecuzione delle macro in Excel per la disposizione del fascio tubiero. Le operazioni da compiere in questa fase sono: - selezione del comando EXPORT : viene attivata la procedura di esportazione delle proprietà contenute nel tab Parametri da esportare in Excel ed eseguito il file per l avvio della disposizione in Microsoft Excel; - attendere la fase di estrazione e calcolo che termina con la visualizzazione del form Visual Basic di riepilogo; durante questa procedura vengono generalmente visualizzate due finestre in sequenza relative alla creazione del file del pattern. Alla fine del processo di calcolo appare una finestra riassuntiva, mostrata in Figura 53: Alintec Scarl Milano, Settembre 2008 [100]

101 Figura Finestra di riepilogo della disposizione del fascio tubiero. - selezione del comando di IMPORT : viene attivata la procedura di importazione delle proprietà, che vengono visualizzate nel tab Parametri importati in Excel. Tali proprietà sono contenute in celle grigie, per cui non sono editabili, e sono di colore blu derivando come dati da un ambiente esterno. I valori vengono importati correttamente,ma talvolta è necessario fare un refresh dello step per una visualizzazione corretta. Il refresh dello step si attiva semplicemente cliccando nel processo sul nome dello step corrente. - chiusura del form Visual Basic. La serie delle fasi è rappresentata in Figura 54, mentre in Figura 55, è rappresentata la fase iniziale di definizione delle specifiche di progetto. Figura Le fasi di dimensionamento dello scambiatore. Ad ogni fase è associata un'interfaccia diversa che supporta il progettista nella progettazione. Alintec Scarl Milano, Settembre 2008 [101]

102 Figura Fase iniziale di definizione delle specifiche 7.4 MEDEA per il riuso dell'applicazione Accanto alle due tematiche fondamentali nello sviluppo di applicazioni di PA, cioè la rappresentazione di prodotto e di processo, si evidenziano altri aspetti di elevata importanza tra le quali, senza dubbio, quella del riuso della conoscenza è attualmente molto avvertita. Riutilizzare la conoscenza significa poter riutilizzare parti, metodi d analisi, processi di definizione sviluppati per una determinata applicazione in altre applicazioni e contesti operativi, con gran risparmio di risorse, altrimenti spese nel ripercorrere strade progettuali già battute. In un applicazione di progettazione automatica, il riuso si traduce nella scelta di generalizzare e strutturare opportunamente parti di codice e di renderli disponibili per lo sviluppo di svariate applicazioni. Si tratta di un concetto ben noto nel settore dell Ingegneria del software e, purtroppo, assi meno nel settore della PA con strumenti di tipo KBE. La rappresentazione di tipo O-O permette, rispetto ad altri metodi, una maggiore versatilità d azione in quanto, grazie alla natura gerarchica del suo approccio, permette il raggruppamento logico dei componenti, consentendo di creare classi di oggetti funzionalmente ricollocabili. Inoltre, essa permette la creazione di librerie nelle quali archiviare le classi per poterle riusare in applicazioni diverse. A fronte di un allocazione iniziale di risorse relativamente maggiore rispetto al normale i vantaggi di questo approccio, nello sviluppo di applicazioni successive sono molteplici: Alintec Scarl Milano, Settembre 2008 [102]

103 - diminuzione del tempo speso nella definizione della nuova applicazione, grazie al riutilizzo di parti di codice già compilate; - minor tempo di verifica della bontà del prodotto creato dovuto al fatto che un oggetto in libreria si suppone ampiamente testato; - facile manutenzione dell applicazione, soprattutto nelle attività di aggiornamento e sostituzione componenti. Un esempio di questo approccio è disponibile in molti modellatori CAD che permettono di salvare come oggetti di librerie componenti assemblati od anche soltanto una serie di feature che possono essere richiamate in altri oggetti come riferimenti geometrici e valori di proprietà specifiche definite e priori. Per esempio CATIA V5, con lo strumento Power Copy, consente di creare delle librerie personali di oggetti di tipo Part, Assembly o semplicemente composte da alcune feature che possono essere richiamate più volte in diversi contesti progettuale attraverso la definizione di specifici parametri richiesti. I sistemi KBE che basano la rappresentazione di prodotto su rappresentazione O-O consentono previa corretta formalizzazione, di creare librerie di procedure e di parti con associate regole e metodi opportuni. Per le procedure si pensi ad esempio ad una verifica di resistenza essa è di carattere generale, non associata ad alcun componente specifico ma può essere utilizzata in moltissimi casi applicativi diversi specificando un set limitato di parametri caratteristici. In generale, gli oggetti non contengono solo informazioni di tipo geometrico, ma anche funzionali, tecnologiche ed anche metodi per la scelta, il dimensionamento, l ottimizzazione. Un errore, che spesso occorre quando le fasi di acquisizione e formalizzazione della conoscenza non sono state eseguite proficuamente, è quello di non identificare correttamente i parametri di configurazione globali e quelli invece interni, locali alle classi. Per esempio, nel definire un gruppo funzionale, quale un riduttore di velocità, oggetto di libreria, deve essere chiaro quale sono le proprietà che da sole bastano a definire la configurazione dell oggetto. La posizione degli elementi geometrici di riferimento, il rapporto di trasmissione, la potenza trasmessa e la velocità dell albero d ingresso, sono i parametri di carattere globale che devono consentire all applicazione di configurare e dimensionare correttamente il riduttore. I parametri locali, quali per esempio i diametri degli alberi o i tipi di supporto, non devono apparire allo sviluppatore che riutilizza l oggetto riduttore. Questo approccio è stato sfruttato nell applicazione illustrata nel seguito, dove alcune parti di codice, identificate come classi raggruppate secondo una logica funzionale, vengono generalizzate per essere trasformate in librerie e riutilizzate in applicazioni diverse. L esempio che segue [Pugliese; 2006] è tratto dalle attività di sviluppo di un applicazione creata per la configurazione automatica di una macchina utensile formatrice di molle La macchina utensile formatrice di molle La macchina formatrice di molle (Figura 56) è una macchina utensile che lavora fili di acciaio di diverse misure, prelevandoli con continuità da bobine di grandi dimensioni. Essa ha 9 assi di azione che producono la formatura delle molle di diversi diametri, lunghezze, passi, inclinazioni, piegamenti, anche non costanti, lavorando al ritmo di oltre 100 pezzi al minuto. Alintec Scarl Milano, Settembre 2008 [103]

104 Figura Macchina formatrice di molle. L elevato numero di assi e le diverse funzionalità che queste macchine possono fornire, hanno spinto i progettisti a considerare l ipotesi di poter riutilizzare parti di modelli già riutilizzate per ricavare e assemblare nuovi prodotti, rendendo così le macchine modulari. Nel processo AS IS di progettazione, il progettista adotta già una strategia di riutilizzo di parti giù utilizzate. Il metodo è semplice: si aprono gli assemblati già modellati con un modellatore CAD e si procede alla modifica manuale degli stessi. Gli assemblati finali vengono montati di nuovo assieme in un nuovo file che successivamente viene archiviato. Lo sviluppo del prototipo KBE, mirato alla modularità dell applicazione, ha permesso di suddividere i gruppi funzionali della macchina in sottogruppi e generalizzare la progettazione per un più largo campo di applicazioni. L applicazione di MEDEA in questa applicazione ha dato informazioni su come implementare la funzionalità dei KBE sul riuso della conoscenza, modularizzando l applicazione. In particolare, l idea è stata quella di creare delle apposite librerie rappresentanti gruppi e sottogruppi funzionali, tali da poter essere riutilizzati in differenti contesti e applicazioni. È evidente che, per realizzare una tale generalizzazione, è fondamentale ridurre al minimo le dipendenze delle proprietà fra classi appartenenti a gruppi diversi. Alintec Scarl Milano, Settembre 2008 [104]

105 In altre parole, per ogni oggetto libreria deve essere chiaro quali sono le proprietà indipendenti che determinano l esecuzione dei metodi delle classi a cui appartengono e durante la definizione delle stesse è necessario ridurle al minimo per facilitarne l esportazione in diversi contesti. Per esempio, un ipotetico gruppo Albero con supporti, deve poter permettere la sua configurazione solo mediante alcuni parametri rappresentativi del gruppo stesso, quali diametro, potenza da trasmettere, velocità, lunghezza. I metodi interni alle classi e alle sottoclassi devono essere in grado, mediante i loro parametri locali, di poter configurare l albero secondo le regole di progettazione canoniche, scegliere i supporti e generare i modelli e la documentazione relativa. Tutto questo deve avvenire indipendentemente dal contesto/progetto nel quale il gruppo è inserito Riuso del codice dell applicazione Per comprendere meglio il paragrafo sul riutilizzo dell applicazione, si illustrano brevemente qui di seguito i risultati dell attività di acquisizione dell architettura di prodotto. Dalla rappresentazione dell architettura della macchina per molle, si osserva come la ripetitività di certi gruppi funzionali sia evidente. In Figura 57, sono stati colorati con lo stesso colore gruppi, sottogruppi e componenti che hanno affinità funzionali, come, per esempio, tutti i gruppi motore, i gruppi di trasmissione di potenza o i leveraggi. Figura 57. Architettura della macchina. Con lo stesso colore, i gruppi, i sottogruppi e i componenti della macchina con stessa funzionalità Modularità dell architettura e riuso della conoscenza Dall analisi architettonica presentata nel paragrafo precedente, si è osservato come alcuni gruppi e componenti potessero venire raggruppati secondo funzionalità più generiche. Pertanto, gruppi quali il sistema di trasmissione a cinghia, quello con ruote dentate, quello con un riduttore epicicloidale e i giunti universali sono stati raggruppati in un unica soluzione che le comprenda tutte e che ha la caratteristica di poter essere riusata molte volte con istanze diverse. In Figura 58, è mostrato come il gruppo Trasmissione abbia valenza generale e comprenda le 4 soluzioni differenti descritte precedentemente. Alintec Scarl Milano, Settembre 2008 [105]

106 Figura La generalizzazione del gruppo "Trasmissione", che include diverse soluzioni. Si è pensato, allora, di creare delle librerie di oggetti così formati, in modo da poter essere richiamati più volte. Chiaramente, ogni oggetto include proprietà di tipo geometrico (tipicamente oggetti CAD), di tipo numerico (es. dimensioni o quantità) o booleane (esiste non esiste), e metodi, quali, per esempio, le regole di scelta e dimensionamento componenti e modalità di recupero dati di progettazione nei database aziendali, creati ad hoc per ogni componente. Implementazione dell applicazione Durante l implementazione dell applicazione, ogni volta che si doveva inserire un tipo di trasmissione di potenza, si importava dalla libreria personale il gruppo Trasmissione che, dopo aver legato le proprietà macroscopiche a quelle del contesto in cui si inseriva, prendeva ogni volta conformazione diversa, con le caratteristiche richieste. La Figura 59 mostra come il gruppo Trasmissione sia stato utilizzato con diverse soluzioni (giunto universale, trasmissione a cinghia, a ruota dentata o riduttore epicicloidale) nello stesso contesto di un tipo particolare di macchina. Tuttavia, essendo la libreria esterna all applicazione, lo stesso gruppo può essere riutilizzato anche in diverse applicazioni, che hanno diversi contesi. Ovviamente, la prima volta che si implementerà un applicazione, le risorse investite saranno sempre minori della volta precedente, grazie alla modularità creata. Un ultima osservazione riguarda l aggiornamento dell applicazione. Questo non viene fatto su un unico prodotto, ma, aggiornando un gruppo specifico nella libreria, i cambiamenti si ripercuoteranno su tutti i prodotti. Alintec Scarl Milano, Settembre 2008 [106]

107 Figura Riuso del Gruppo Trasmissione in diversi contesti 7.5 MEDEA per l integrazione con sistemi PDM/PLM Una delle questioni più importanti nello sviluppo di applicazioni di progettazione automatica e, di conseguenza di applicazioni KBE è la necessità di poter riutilizzare la documentazione prodotta durante la storia dell azienda e di poterla inglobare nel sistema di progettazione automatico. Si parla in questo caso più specificatamente, di integrazioni con sistemi PLM/PDM. Un vantaggio tangibile che si ricava dall integrazione fra sistemi di archiviazione documentale e un'applicazione di progettazione automatica è che l'adozione di un componente o di un gruppo già progettato, significa non dover ripercorrere anche le fasi di verifica e validazione del componente (esempio analisi FEM, messa a punto, ecc...), che richiedono ulteriore tempo e denaro Diversi sono i sistemi di gestione documentale. Tra essi soprattutto sono in uso i sistemi PDM. Questi sistemi permettono, otre la gestione dei documenti presenti in azienda (dove sono, chi li ha, di chi sono i diritti di creazione, lettura e modifica ecc...), anche la gestione del flusso di lavoro che serve per produrli. È di fatto uno strumento importante che sta via via diffondendosi sempre più in molte aziende e pertanto uno studio di integrazione specifico deve essere fatto. La sperimentazione di MEDEA, tra le cui fasi è contemplato fra archivi aziendali e applicazioni KBE, fornisce alcune indicazioni su come indagare sull'esistenza o meno di componenti adatti ad un certo prodotto all'interno di archivi, e quindi già progettati. Nella sezione seguente è presentato il caso di un miscelatore di fluidi industriale [Pugliese; 2007; Saturno Spurio; 2006], un prodotto per cui in ogni commessa si riutilizza circa l'80% dei componenti già progettati in altri ordini. I componenti progettati sono archiviati in forma di file CAD 3D e 2D e di tabelle di riepilogo. Alintec Scarl Milano, Settembre 2008 [107]

108 7.5.1 L agitatore di fluidi L agitatore industriale di fluidi (Figura 60) è un miscelatore che viene montato in grandi recipienti contenenti liquidi alimentari come vino, champagne, birra e simili. Lo scopo è quello di aiutare l amalgamarsi dei fluidi durante la mescitura. Essendo un prodotto di assai semplice composizione, la tecnologia utilizzata è pressochè semplice e l unico oggetto degno di studio è la girante, che a seconda del liquido su cui si deve utilizzare, assume caratteristiche diverse Il prodotto è ormai talmente assodato che, per ogni commessa, viene riutilizzato circa l 80% di materiale già ingegnerizzato, i cui disegni e modelli sono conservati negli archivi aziendali. Questa è una situazione tipica di molte aziende dove la produzione, anche se on demand, è per lo più caratterizzata dal riutilizzo di oggetti già usati. L applicazione sviluppata per la progettazione di questo prodotto ha permesso all azienda di poter verificare l esistenza o meno di componenti già ingegnerizzati nel vasto archivio aziendale. Il sistema, in caso di risposta affermativa, durante le fasi di progettazione ripropone i componenti già ingegnerizzati e adatti al conteso in cui si vuole inserirli. Il sistema lascia la facoltà di scegliere fra quelli adatti, oppure di procedere a nuova progettazione. Figura Agitatori meccanici per fluidi alimentari industriali La sperimentazione su questo prodotto ha dato interessanti informazioni in termini di affinamento della Metodologia, incidendo soprattutto nelle fasi di formalizzazione della conoscenza e sviluppo dell applicazione. L agitatore (Figura 61) è composto di tre gruppi principali: motore; statore; rotore. È una struttura pressoché statica, ossia l intera famiglia presenta la stessa architettura di base con eventualmente qualche modifica sul numero e sulla forma delle pale della girante, il tipo di girante stessa, qualche altro dettaglio come il numero dei grani per l accoppiamento dell albero col collare. Il processo di progettazione del miscelatore prevede tre fasi principali: - scelta del tipo di agitatore, in base alle specifiche del cliente - recupero progetti e componenti già progettati dall archivio aziendale; - progettazione nuovi componenti. Il processo può essere rappresentato con l utilizzo di un sistema KBE. Questo comporta che non c è bisogno di stravolgere l intero Alintec Scarl Milano, Settembre 2008 [108]

109 ciclo progettuale e che l impatto dell introduzione della nuova tecnologia è basso. Per sviluppare l applicazione è stata necessaria la formalizzazione della conoscenza acquisita finalizzandola alla creazione dell applicazione. La rappresentazione UML dell applicazione è servita ad organizzare le relazioni che le parti e le proprietà hanno l una con l altra e a stabilire le interazioni fra utente, sistema e archivio aziendale. Figura Architettura del miscelatore In Figura 62 è mostrata una rappresentazione UML ad alto livello dell applicazione sviluppata, che presenta i tre gruppi principali funzionali: motore, statore e rotore. Nella Figura 63, si possono notare le relazioni che le parti e le proprietà del gruppo rotore hanno fra di loro e fra il gruppo motore e alcune parti del gruppo statore. I gruppi motore e statore sono invece rappresentati rispettivamente in Figura 64 e Figura 65. Alintec Scarl Milano, Settembre 2008 [109]

110 Figura 62- Rappresentazione UML ad alto livello dell'applicazione KBE da sviluppare. Si possono notare i tre gruppi funzionali principali: motore, statore e rotore Figura Diagramma UML del gruppo rotore. Si possono osservare le relazioni col motore e con alcune parti dello statore Alintec Scarl Milano, Settembre 2008 [110]

111 Figura Diagramma UML motore. Figura Diagramma UML dello statore. Alintec Scarl Milano, Settembre 2008 [111]

112 7.5.2 Integrazione del sistema di progettazione automatica con'archivio aziendale dei componenti È stata studiata la mappa delle iterazioni fra utente, sistema e archivio, di cui se ne formalizzano i risultati mediante linguaggio UML Activity Diagram. L utente, come visualizzato in Figura 66, attraverso la definizione delle specifiche iniziali, è guidato dal sistema a ricercare, all interno dell archivio aziendale (qui rappresentato come PDM) l esistenza di eventuali componenti o prodotti adatti alla configurazione. Il sistema presenta solo quei componenti, già presenti nel PDM, che rispondono ai requisiti di ricerca posti dall utente, tralasciando i componenti inadatti a svolgere la funzionalità richiesta. L utente, a questo punto, può decidere se adottare il componente opzionato o procedere a nuova progettazione. L eventuale nuovo componente progettato, il quale dovrà successivamente essere ingegnerizzato, sarà archiviato anch esso nel PDM a fine progettazione e reso disponibile a successive configurazioni di prodotto. Anche i disegni 2D e la lista dei materiali sono documenti che sono archiviati nel PDM. Sviluppo applicazione Lo sviluppo dell applicazione include, oltre la modellazione KBE, anche lo studio delle modalità di integrazione dell applicazione al sistema PDM. In particolare, nel prototipo realizzato per l'azienda di riferimento, si è supposto che la funzionalità di archivio, esplicata dal PDM, avvenisse attraverso la gestione di particolari Cartelle condivise in rete e alcune tabelle inserite in un database comune. Al fine di studiare le modalità di interrogazione nel PDM, si è definito un sistema di codifica dei componenti o di gruppi di componenti simile a quelli utilizzati in azienda. Un esempio di tale codifica è il seguente (15): ALBERO 25/572 CON 1 (15) Essa si riferisce ad un ad un albero di diametro di 25 cm, lunghezza 572 e conicità del primo tipo. Il sistema genera un simile codice derivandolo dalle regole di progettazione definite e lo compara con quelli presenti nelle tabelle del PDM. Un esempio di formula implementata per effettuare la ricerca è la (16): result = "ALBERO " & this!calculeddiameter*1000 & "/" & this!shaftlenght*1000 & " " & this!tapertype (16): I parametri this!calculeddiameter, this!shaftlenght e this!tapertype sono calcolati in base a delle formule legate per esempio alla flessione rotante agente sull'albero o sulla profondità del silo nel quale il miscelatore lavora. Se l'albero (1) calcolato con la formula (2) è trovato anche nel PDM, il sistema preleva l'oggetto già ingegnerizzato dall archivio e lo usa per continuare la configurazione di prodotto, altrimenti (o comunque) sono offerte all'utente due possibilità: - progettare ex novo l'oggetto; - selezionare un oggetto simile (per esempio con un diametro più grande) dal PDM. L'utilizzo di un albero sovradimensionato, piuttosto che la progettazione di uno nuovo, permette di evitare tutte le successive attività di ingegnerizzazione del componente, come per esempio l'analisi FEM, permettendo di risparmiare tempo e denaro. In Figura è presentato il funzionamento dell'applicazione. Dall'ambiente di progettazione, il progettista, attraverso l'attivazione delle procedure di configurazione di prodotto e di dimensionamento dei componenti (procedure e regole presenti nei database generati dal sistema KBE), può Alintec Scarl Milano, Settembre 2008 [112]

113 Figura Diagramma UML delle interazioni fra utente, sistema e archivio generale. visualizzare all'interno dell'archivio la presenza o meno di componenti che rispondano alle proprie esigenze e, una volta accertatosene, può decidere se utilizzare tali componenti o progettarne di nuovi. Alintec Scarl Milano, Settembre 2008 [113]

114 Figura Schema di funzionamento dell'applicazione. Un esempio dei risultati ottenuti con questa applicazione è riportato di seguito. In Figura 68 si riporta il caso in cui, durante la fase di configurazione dell albero, si inseriscano valori, alcuni normati, altri no, che conducano il sistema ad identificare nel sistema PDM un componente già esistente. In questo caso, come evidenziato in Figura 69, sotto la cartella Codice, il sistema restituisce il codice dell albero esistente ed importa il modello CAD corrispondente ed i valori dei parametri associati. Figura Maschera di definizione dei parametri per il dimensionamento dell'albero. Nel caso in cui tale ricerca dia esito negativo, il sistema permette o la selezione di componenti esistenti (Figura 70), ma sovradimensionati, dando sempre le soluzioni solamente applicabili, o la progettazione di un nuovo componente albero (Figura 71), che sarà dotato di nuovo codice e salvato in una cartella specifica nel sistema PDM. Alintec Scarl Milano, Settembre 2008 [114]

115 Figura Caso in cui l'albero è stato identificato nel PDM: i campi sono non modificabili. È possibile tuttavia, selezionando Generare Nuovo, creare un nuovo modello. Figura Caso in cui l'albero non è stato identificato nel PDM. È possibile la scelta di alberi sovradimensionati. Figura Caso in cui si voglia, indipendentemente dal fatto che l'albero esista o meno, configurare un nuovo albero. Alintec Scarl Milano, Settembre 2008 [115]

116 In Figura 72 è mostrato un esempio di tabella contenente i dati degli alberi esistenti nel PDM, con le varie codifiche specifiche. L applicazione interroga tali tabelle per recuperare i componenti presenti nel PDM e li ripropone all interno del sistema di progettazione. Infine, in Figura 73, è presentata l interfaccia finale dell ambiente di progettazione, in cui si evidenzia, nel campo a sinistra, la sequenza delle fasi da eseguire per la configurazione finale. Figura Tabella di riferimento dati alberi esistenti nel PDM. Figura Interfaccia di configurazione del miscelatore. Alintec Scarl Milano, Settembre 2008 [116]