1 / 39

C.A.A. (Computer Aided Assembly)

C.A.A. (Computer Aided Assembly). Lab.I.C. (Laboratorio di Ingegneria della Conoscenza) Università di Milano - Bicocca In collaborazione con: I.T.I.A. - C.N.R. Zanussi. Obiettivi di C.A.A.

ayasha
Download Presentation

C.A.A. (Computer Aided Assembly)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. C.A.A. (Computer Aided Assembly) Lab.I.C. (Laboratorio di Ingegneria della Conoscenza) Università di Milano - Bicocca In collaborazione con: I.T.I.A. - C.N.R. Zanussi

  2. Obiettivi di C.A.A. • Realizzazione di uno strumento di supporto alla selezione degli organi da presa esistenti o alla eventuale prima fase di progettazione di nuovi organi da presa. • Forma prototipale. • Dominio circoscritto. C.A.A.

  3. Descrizione del progetto • Committente: Zanussi. • Ambito: assemblaggio di gruppi di componenti del basamento lavabiancheria e del termostato frigorifero. • I casi applicativi scelti si posizionano nella famiglia dei pezzi medio-piccoli. • La linea di assemblaggio deve avere un altissimo indice di riconfigurabilità. C.A.A.

  4. Dominio di applicazione • Assemblaggio automatico. • Linea di assemblaggio. • Cella di assemblaggio: • robot; • componente da assemblare; • ambiente (processo). C.A.A.

  5. Architettura del Sistema • Sistema Basato sulla Conoscenza (realizzato a regole): • Rappresentazione della conoscenza: regole di produzione; • Database; • Interfaccia utente; • Interfaccia di integrazione. C.A.A.

  6. Scelte tecnologiche • Base della conoscenza: • Jess • Database: • Object Store • Interfaccia utente: • Java • Interfaccia di integrazione: • Web-based C.A.A.

  7. Team/Risorse • Componenti del team • Coordinatore: Stefania Bandini • Capo-progetto: Giuseppe Frisoni • Sviluppatori: • Paolo Mereghetti • Alessandro Saporiti • Augusto Vezzaro • Consulenza su architettura ed integrazione: Flavio De Paoli • Risorse • PC Pentium, Windows NT • PC Silicon Graphic presso ITIA C.A.A.

  8. Ciclo di vita • Studio di plausibilità: • analisi del dominio; • state of the art; • identificazione delle specifiche. • Acquisizione della conoscenza. • Sviluppo del Dimostratore. • Affinamento della conoscenza. • Sviluppo del Prototipo. • Installazione del Prototipo. C.A.A.

  9. Tempistica • 28 gennaio: consegna Dimostratore. • 28 febbraio: consegna Prototipo e installazione. C.A.A.

  10. Stato attuale • Stato di avanzamento dei lavori al 14/01/2000: • come previsto: KB e Interfaccia; • avanti: DB. Siamo pronti a sviluppare. C.A.A.

  11. Base della conoscenza

  12. Sistema esperto • Fatti • Regole • Motore inferenziale

  13. Sistema esperto: motore inferenziale • Tool • CLIPS (C Language Integrated Production System) • JESS (Java Expert System Shell) • JESS • Java http://herzberg.ca.sandia.gov/jess Jess 5.0 ver. b3

  14. Architettura della base della conoscenza • Regole • Suddivisione delle regole in sezioni • Fatti • Strutturazione ad oggetti

  15. Suddivisione delle regole • Determinazione della forma del polpastrello • Determinazione della morfologia dell’organo • Calcolo della forza di serraggio • Verifica della resistenza di superficie di presa • Scelta della tipologia di attuazione

  16. Fatti Organo da presa morfologia diti parametri attuazione

  17. Sviluppi futuri del sistema • Java • compatibilità • Fatti : Modello ad oggetti • espandibilità

  18. OODBMS e Object Store

  19. Basi di dati a oggetti o classiche relazionali? I modelli di basi di dati tradizionali sono adeguati per applicazioni di tipo gestionale ed amministrativo. Difficoltà nel gestire dati tipici di applicazioni più complesse (es. CAD o dati multimediali), le basi di dati orientate agli oggetti sono nate per soddisfare le esigenze di tali applicazioni.

  20. L’approccio ad oggetti infatti offre la flessibilità necessaria non essendo limitato ai tipi di dato (il sistema dei tipi di dati e estendibile) e ai sistemi di query language tradizionali. Gli OODBMS (Object Oriented Data Base Management System) in particolare permettono di gestire tipi di dati non strutturati (es. bitmap di immagini, lunghe stringhe di testo, disegni CAD) che saranno gestiti dall’applicazione ma la cui struttura non è nota al DBMS. Basi di dati a oggetti o classiche relazionali?

  21. Caratteristiche OODBMSnuovi concetti Scompare il concetto di tabella e compare il concetto di collection. Scompare il concetto di riga e compare quello di oggetto. Si passa da una visione passiva a una visione attiva dei dati memorizzati. La conoscenza diventa ‘viva’ e può cambiare il proprio stato rispondendo a ‘messaggi’ esterni. I primi ad usare questo approccio sono stati proprio gli sviluppatori di linguaggi per la rappresentazione della conoscenza.

  22. I sistemi di BDD tradizionali usano appositi comandi per l’inserimento persistente dei dati con le basi di dati a oggetti si usano due approcci: persistenza automatica tramite il comado new di calssi con proprietà estensionale. persistenza esplicita attraverso un apposito metodo che inserisce l’oggetto nella collection. Caratteristiche OODBMSpersistenza

  23. Caratteristiche OODBMScancellazione Anche la cancellazione può essere: esplicita tramite comado (problema per l’integrità referenziale). tramite garbage collector (assicura l’integrità referenziale).

  24. Object Store cos’è? nato per lo sviluppo di OODBMS in C++ fornisce un’estensione del linguaggio che permette di gestire la persistenza dei dati. attualmente è possibile sviluppare applicazioni anche in linguaggio Java. permette di gestire non solo collection di oggetti ma anche associazioni unarie e binarie tra le collection garantendo quella stutturazione rigorosa e formale che è il punto di forza dei BDD relazionali.

  25. la persistenza non è una caratteristica automatica ma per creare collection persistenti devo creare una root di tipo persistente nella quale inserire gli oggetti. L’integrità referenziale è garantita sulle associazioni permettendo anche propagazione delle cancellazioni. OS fornisce un query language SQL-like per interrogare le collection di oggetti e aggiunge funzionalità tipiche per gli oggetti. Object Store caratteristiche

  26. Perchè Object Store La nostra applicazione potrà trovarsi a dover gestire dati non strutturati come disegni CAD o VRML che possono essere gestiti in modo veramente efficente solo con un OODBMS. Il sistema su cui dovrà operare il prodotto è distribuito e browser-based quindi la possibilità che Object Store da di poter utilizzare un linguaggio come Java ci permette di gestire in modo ottimale questa situazione.

  27. La possibilità di usare Java permette anche una coerenza degli strumenti di sviluppo dell’intera applicazione che facilità l’integrazione degli stessi e permette all’applicazione di avere una struttura più omogenea. Perchè Object Store

  28. Aspetti tecnici e formali sulla struttura dellabase di dati

  29. ZonaPiana altezza- integer larghezza- integer singola- enum. [si, no] ferromagnetica- enum. [si, no] porosa - enum. [si, no] ZonaIrregolare areaContatto- integer ZonaCilindrica altezza- integer raggio- integer angolo- integer PARTE COMPONENTE E ZONA DI PRESA ZonaPresa codice zona- stringa delicatezza- enum. [++, +, -, --] cRiduzione- float distBaricentro- integer distRettaApp- integer cAttrito- float forzaMaxRottura- float forzaSerrAssemblaggio - float forzaSerrTrasporto - float forzaScelta - Float distanzaSuperfici - Integer areaAfferrata - float Componente nome- stringa peso- float zonePresaCilindriche- set (0,n) di oggetti ZonaCilindrica zonePresaPiane- set (0,n) di oggetti ZonaPiana zonePresaIrregolari- set (0,n) di oggetti ZonaIrregolare IS A IS A IS A

  30. Attuazione nome- enum. [elettrico, pneumatico, idraulico, elettropeumatico] costo- enum. [++, +, -, --] ingombro - enum. [++, +, -, --] esplosivo - enum. [++, +, -, --] peso - enum. [++, +, -, --] pulito - enum. [++, +, -, --] forza-enum. [++, +, -, --] Morfologia nome- enum. [tre_dita_autocentranti, tre_dita_indipendenti, due_dita_parallele, due_dita_angolari, magnete, ventose] costo- enum. [++, +, -, --] semplice - enum. [++, +, -, --] posizionano - enum. [si, no] peso - enum. [++, +, -, --] Diti nome- enum. [piatti, intaglio_a_V, intaglio_cilindrico, non_standard] delicati- enum. [++, +, -, --] duraturi - enum. [++, +, -, --] preciso - enum. [++, +, -, --] semplice - enum. [++, +, -, --] TIPOLOGIA ORGANO PRESA OrganoPresa attuazione - oggetto di tipo Attuazione morfologia - oggetto di tipo Morfologia diti - oggetto di tipo diti forzaSerraggio - integer corsa-integer regolazioneForza -integer cambioRapido - enumerazione [si, no] PART OF PART OF PART OF

  31. Processo accRobot - float forzaInserimento - float puliziaAmbiente-enum. [++, +, -, --] sicurezzaAmbiente -enum. [++, +, -, --] nome_componente - stringa nome_organo_presa - stringa PROCESSO

  32. TIPOLOGIA ORGANO PRESA ZONA PRESA IRREGOLARE ZONA PRESA PIANA COMPONENTE PROCESSO POSSIEDE POSSIEDE CONTESTUALE A CONTESTUALE A SCHEMA ENTITA’ RELAZIONI n 1 ZONA PRESA CILINDRICA n 0 1 0 1 1 POSSIEDE 0 n

  33. Interfaccia di Integrazione

  34. Modulo Software Modulo Software Interfacciadi Integrazione Modulo Software Modulo Software Obbiettivo • Organizzazione e gestione della cooperazione di moduli Software.

  35. Analisi dei moduli software: • Funzione. • Tecnologie coinvolte. • Analisi dei vincoli imposti dall’End User: • Caratteristiche hardware. • Disponibilità hardware per fasi di implementazione e test. • Tempi di sviluppo. • Scelta dell’architettura. • Scelta del linguaggio di programmazione (fortemente dipendente dall’architettura). Fase di Analisi e Fase Decisionale

  36. Moduli Software • Shell per lo sviluppo di Sistemi Basati sulla Conoscenza (Jess) • Rule Based. • Interamente scritto in Java. • Esistono vesrioni per i principali Sistemi Operativi. • Database (Object Store) • Sviluppato su piattaforma Windows. • Basato su Classi di Oggetti (Java o C++). • (Non) Richiede applicazioni server per la sua gestione. • Interfaccia Utente • Permette la gestione dell’intero sistema. • Scritta in un linguaggio di programmazione di Alto Livello. • User Friendly.

  37. Vincoli posti dall’End User • Database su piattaforma Windows e accesso dell’Utente da piattaforma Unix (Silicon). • Risorse temporali limitate per implementazione e testing del sistema su piattaforma Unix. • Vicinanza della Deadline del Progetto.

  38. Database Object Store Interfaccia Utente Interfacciadi Integrazione Sistema BasatosullaConoscenza ClientWeb Browser Web ServerWith Java Servlet Jess Architettura proposta • Sistema basato su Tecnologie Web.

  39. La scelta di Java • Facile integrazione fra i moduli. • Ampliamento delle funzionalità del Web Server con Servlets. • Creazione di interfacce utente User Friendly compatibili con i più comuni Web Browser (Netscape e Internet Explorer).

More Related