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.

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.
14 Gennaio 2000
C.A.A.
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à.
14 Gennaio 2000
C.A.A.
Dominio di applicazione
Assemblaggio automatico.
 Linea di assemblaggio.
 Cella di assemblaggio:

– robot;
– componente da assemblare;
– ambiente (processo).
14 Gennaio 2000
C.A.A.
Architettura del Sistema

Sistema Basato sulla Conoscenza
(realizzato a regole):
– Rappresentazione della conoscenza:
regole di produzione;
– Database;
– Interfaccia utente;
– Interfaccia di integrazione.
14 Gennaio 2000
C.A.A.
Scelte tecnologiche

Base della conoscenza:
– Jess

Database:
– Object Store

Interfaccia utente:
– Java

Interfaccia di integrazione:
– Web-based
14 Gennaio 2000
C.A.A.
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
14 Gennaio 2000
C.A.A.
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.
14 Gennaio 2000
C.A.A.
Tempistica
28 gennaio: consegna Dimostratore.
 28 febbraio: consegna Prototipo e

installazione.
14 Gennaio 2000
C.A.A.
Stato attuale

Stato di avanzamento dei lavori al
14/01/2000:
– come previsto: KB e Interfaccia;
– avanti: DB. Siamo pronti a sviluppare.
14 Gennaio 2000
C.A.A.
Base della conoscenza
Sistema esperto
Fatti
 Regole
 Motore inferenziale

14 Gennaio 2000
C.A.A.
Sistema esperto: motore inferenziale

Tool
– CLIPS (C Language Integrated Production System)
– JESS (Java Expert System Shell)

JESS
– Java
Jess 5.0 ver. b3
http://herzberg.ca.sandia.gov/jess
14 Gennaio 2000
C.A.A.
Architettura della base della
conoscenza

Regole
– Suddivisione delle regole in sezioni

Fatti
– Strutturazione ad oggetti
14 Gennaio 2000
C.A.A.
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
14 Gennaio 2000
C.A.A.
Fatti
Organo da
presa
morfologia
diti
parametri
attuazione
14 Gennaio 2000
C.A.A.
Sviluppi futuri del sistema

Java
– compatibilità

Fatti : Modello ad oggetti
– espandibilità
14 Gennaio 2000
C.A.A.
OODBMS e Object Store
14 Gennaio 2000
C.A.A.
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.
14 Gennaio 2000
C.A.A.
Basi di dati a oggetti o classiche
relazionali?


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.
14 Gennaio 2000
C.A.A.
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.
14 Gennaio 2000
C.A.A.
Caratteristiche OODBMS
persistenza

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.
14 Gennaio 2000
C.A.A.
Caratteristiche OODBMS
cancellazione

Anche la cancellazione può essere:
– esplicita tramite comado (problema per
l’integrità referenziale).
– tramite garbage collector (assicura
l’integrità referenziale).
14 Gennaio 2000
C.A.A.
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.
14 Gennaio 2000
C.A.A.
Object Store
caratteristiche

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. 14 Gennaio 2000
C.A.A.
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.
14 Gennaio 2000
C.A.A.
Perchè Object Store

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.
14 Gennaio 2000
C.A.A.
Aspetti tecnici e formali
sulla struttura della
base di dati
14 Gennaio 2000
C.A.A.
PARTE COMPONENTE E ZONA DI PRESA
ZonaPresa
Componente
codice zona - stringa
delicatezza - enum. [++, +, -, --]
nome - stringa
peso - float
cRiduzione - float
distBaricentro - integer
zonePresaCilindriche set (0,n) di oggetti ZonaCilindrica
zonePresaPiane - set (0,n)
di oggetti ZonaPiana
zonePresaIrregolari set (0,n) di oggetti ZonaIrregolare
IS A
distRettaApp - integer
cAttrito - float
forzaMaxRottura - float
forzaSerrAssemblaggio - float
forzaSerrTrasporto - float
forzaScelta - Float
distanzaSuperfici - Integer
areaAfferrata - float
IS A
IS A
ZonaCilindrica
ZonaPiana
ZonaIrregolare
altezza - integer
raggio - integer
altezza - integer
larghezza - integer
areaContatto - integer
angolo - integer
singola - enum. [si, no]
ferromagnetica - enum. [si, no]
porosa - enum. [si, no]
C.A.A.
14 Gennaio 2000
TIPOLOGIA ORGANO PRESA
OrganoPresa
attuazione - oggetto di tipo Attuazione
morfologia - oggetto di tipo Morfologia
diti - oggetto di tipo diti
forzaSerraggio - integer
PART OF
PART OF
corsa - integer
regolazioneForza - integer
cambioRapido - enumerazione [si, no]
Morfologia
nome - enum.
Attuazione
nome - enum.
PART OF
[elettrico, pneumatico, idraulico,
elettropeumatico]
costo - enum. [++, +, -, --]
Diti
nome - enum. [piatti, intaglio_a_V,
[tre_dita_autocentranti,
tre_dita_indipendenti,
due_dita_parallele,
due_dita_angolari, magnete,
ventose]
costo - enum. [++, +, -, --]
ingombro - enum. [++, +, -, --]
intaglio_cilindrico, non_standard]
semplice - enum. [++, +, -, --]
esplosivo - enum. [++, +, -, --]
delicati - enum. [++, +, -, --]
posizionano - enum. [si, no]
peso - enum. [++, +, -, --]
duraturi - enum. [++, +, -, --]
peso - enum. [++, +, -, --]
pulito - enum. [++, +, -, --]
preciso - enum. [++, +, -, --]
forza - enum. [++, +, -, --]
semplice - enum. [++, +, -, --]
C.A.A.
14 Gennaio 2000
PROCESSO
Processo
accRobot - float
forzaInserimento - float
puliziaAmbiente - enum. [++, +, -, --]
sicurezzaAmbiente - enum. [++, +, -, --]
nome_componente - stringa
nome_organo_presa - stringa
14 Gennaio 2000
C.A.A.
SCHEMA ENTITA’ RELAZIONI
ZONA PRESA
PIANA
TIPOLOGIA
ORGANO PRESA
n
ZONA PRESA
CILINDRICA
1
CONTESTUALE A
POSSIEDE
n
0
0
POSSIEDE
COMPONENTE
1
1
CONTESTUALE A
1
PROCESSO
0
POSSIEDE
n
ZONA PRESA
IRREGOLARE
C.A.A.
14 Gennaio 2000
Interfaccia di Integrazione
Obbiettivo

Organizzazione e gestione della
cooperazione di moduli Software.
Modulo
Software
Modulo
Software
Interfaccia
di
Integrazione
Modulo
Software
Modulo
Software
14 Gennaio 2000
C.A.A.
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).
14 Gennaio 2000
C.A.A.
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.
14 Gennaio 2000
C.A.A.
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.
14 Gennaio 2000
C.A.A.
Architettura proposta

Sistema basato su Tecnologie Web.
Database
Interfaccia
di
Integrazione
Interfaccia
Utente
Client
Web Browser
Web Server
With Java Servlet
Object Store
Sistema Basato
sulla
Conoscenza
Jess
14 Gennaio 2000
C.A.A.
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).
14 Gennaio 2000
C.A.A.