La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

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.

Presentazioni simili


Presentazione sul tema: "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."— Transcript della presentazione:

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 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 Dominio di applicazione Assemblaggio automatico. Linea di assemblaggio. Cella di assemblaggio: –robot; –componente da assemblare; –ambiente (processo). C.A.A.

5 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 Scelte tecnologiche Base della conoscenza: –Jess Database: –Object Store Interfaccia utente: –Java Interfaccia di integrazione: –Web-based C.A.A.

7 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 Tempistica 28 gennaio: consegna Dimostratore. 28 febbraio: consegna Prototipo e installazione. C.A.A.

10 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 Sistema esperto Fatti Regole Motore inferenziale

13 C.A.A. 14 Gennaio 2000 Sistema esperto: motore inferenziale Tool –CLIPS (C Language Integrated Production System) –JESS (Java Expert System Shell) JESS –Java Jess 5.0 ver. b3

14 C.A.A. 14 Gennaio 2000 Architettura della base della conoscenza Regole –Suddivisione delle regole in sezioni Fatti –Strutturazione ad oggetti

15 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 Fatti morfologia parametri diti attuazione Organo da presa

17 C.A.A. 14 Gennaio 2000 Sviluppi futuri del sistema Java –compatibilità Fatti : Modello ad oggetti –espandibilità

18 C.A.A. 14 Gennaio 2000 OODBMS e Object Store

19 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 Caratteristiche OODBMS nuovi 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 C.A.A. 14 Gennaio 2000 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 OODBMS persistenza

23 C.A.A. 14 Gennaio 2000 Caratteristiche OODBMS cancellazione Anche la cancellazione può essere: –esplicita tramite comado (problema per l’integrità referenziale). –tramite garbage collector (assicura l’integrità referenziale).

24 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 Aspetti tecnici e formali sulla struttura della base di dati

29 C.A.A. 14 Gennaio 2000 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 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 ZonaCilindrica altezza - integer raggio - integer angolo - integer ZonaPiana altezza - integer larghezza - integer singola - enum. [si, no] ferromagnetica - enum. [si, no] porosa - enum. [si, no] ZonaIrregolare areaContatto - integer PARTE COMPONENTE E ZONA DI PRESA IS A

30 C.A.A. 14 Gennaio 2000 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] 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 PART OF

31 C.A.A. 14 Gennaio 2000 Processo accRobot - float forzaInserimento - float puliziaAmbiente - enum. [++, +, -, --] sicurezzaAmbiente - enum. [++, +, -, --] nome_componente - stringa nome_organo_presa - stringa PROCESSO

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

33 Interfaccia di Integrazione

34 C.A.A. 14 Gennaio 2000 Obbiettivo Organizzazione e gestione della cooperazione di moduli Software. Modulo Software Interfaccia di Integrazione

35 C.A.A. 14 Gennaio 2000 Fase di Analisi e Fase Decisionale 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 ).

36 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 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 C.A.A. 14 Gennaio 2000 Architettura proposta Sistema basato su Tecnologie Web. Database Sistema Basato sulla Conoscenza Interfaccia Utente Client Web Browser Web Server With Java Servlet Jess Object Store Interfaccia di Integrazione

39 C.A.A. 14 Gennaio 2000 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).


Scaricare ppt "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."

Presentazioni simili


Annunci Google