Teorie della progettazione: approcci

matematici, logici e metodologici per la

valutazione delle soluzioni sviluppate
Università degli Studi di Salerno

Prof. Nicola Cappetti

Dipartimento di Ingegneria Industriale

Università degli Studi di Salerno
 progetto
 In ingegneria e architettura, il complesso degli
elaborati (disegni, calcoli e relazioni) che
determinano le forme e le dimensioni di un’opera
da costruire (edificio, impianto, macchina, strada,
ecc.), ne stabiliscono i materiali, il modo di
esecuzione, le particolarità costruttive, i reciproci
Università degli Studi di Salerno

impegni tra committente e costruttore e ne stimano

il costo (in alcuni casi vi è compresa anche una
relazione sulla ricerca preliminare che ha
determinato le scelte)
Università degli Studi di Salerno
Costo progetto / vita del prodotto
 La pianificazione di un prodotto

Sviluppo Prodotto
Università degli Studi di Salerno

ingegnerizzazio
ne
progettazione

dimensionament
o
Università degli Studi di Salerno
Team di progetto
 Le fasi dello sviluppo di un nuovo
prodotto
Università degli Studi di Salerno
 Le fasi dello sviluppo di un nuovo
prodotto
Università degli Studi di Salerno
 L’influenza del tipo di prodotto sul
processo
Università degli Studi di Salerno
 La teoria dello sviluppo prodotto
Dominio del cliente,
Dominio funzionale,
Dominio fisico,
Dominio del processo
costituiscono gli ambiti di un progetto

Il Dominio del cliente è costituito dagli

Università degli Studi di Salerno

attributi (CAs) che il cliente attende da un

prodotto
Il Dominio funzionale è costituito dai
requisiti funzionali (FRs) con cui il
Il Dominio fisico è costituito dalle progettista intende soddisfare i
forme, dimensioni e caratteristiche bisogni del cliente
fisiche (parametri di progetto DPs) che
definiscono il prodotto
Il Dominio del processo è costituito da tutto
ciò che definisce il ciclo di produzione (variabili
di processo PVs) del prodotto
 Processo di Progettazione
Il processo di progettazione parte sempre da idee astratte
di tipo qualitativo e arriva ad una descrizione quantitativa
in termini di dimensionali, geometrici e tecnologici

Ciclo di evoluzione del

progetto
Caratteristiche che il Fase di
prodotto deve verifica
Università degli Studi di Salerno

possedere

Come il progettista
vuole raggiungere lo
Fase di scopo
decisione

Alessandro Naddeo – S.S.D. ING-

IND/15
 La teoria dello sviluppo prodotto
Il processo di progettazione genera una
determinata corrispondenza tra i quattro domini
(mappatura)

 Il processo di mappatura dei Requisiti

funzionali nei Parametri di Progetto è
Università degli Studi di Salerno

fondamentalmente creativo ed esprime il

senso della progettazione
 In generale la mappatura da un Dominio al
successivo è creativa o basata su esperienze
pregresse
 La fase creativa e quella esperienziale non
portano necessariamente a risultati ottimali
 Alcuni esempi di Domini in differenti
settori
Campo di CAs FRs DPs PVs
progettazione
Azienda Attributi richiesti Requisiti Variabili fisiche di Variabili di
manufatturiera dal consumatore funzionali definiti progetto processo che
per il prodotto influenzano i DPs
Materiali Comportamento Proprietà richieste Microstruttura Processo
richiesto produttivo

Software Caratteristiche del Outputs Variabili di Input Subroutines

Università degli Studi di Salerno

software ed algoritmi

Organizzazione Soddisfazione del Funzioni Uffici e strutture Persone

cliente organizzative

Sistemi Attributi richiesti FRs del sistema Macchine, Risorse (umane,

componenti e finanziarie,
subcomponenti materiali, etc.)
 Fasi del processo e domini di progetto

1. Pianificazione CAs

2. Progettazione Concettuale FRs

3. Progettazione di sistema
Università degli Studi di Salerno

4. Progettazione di dettaglio
DPs
5. Sperimentazione e miglioramento
6. Produzione
PVs
Università degli Studi di Salerno
Progetti buoni e progetti cattivi
 Progettare nuovi prodotti

 Soluzioni diverse allo stesso problema

Università degli Studi di Salerno
 Equazione della progettazione

Innovare significa trasformare i

problemi in soluzioni” (Eric Reiss)
Problemi = Esigenze
Soluzioni = Prodotti
Università degli Studi di Salerno

detta [A] è la matrice

di Progetto
{ws}{FRs} = [A]{DPs} Risolvere i
problemi in
Risolvere Ridurre la complessità modo diverso
nuovi problemi del prodotto
 Analisi e iterazioni nella progettazione
Performance
Target Delibera del progetto

Vincoli Testing e
progettuali Correlazione
numerico-
Università degli Studi di Salerno

sperimentale
modifiche
Realizzazione
Definizione prototipo
prototipo fisico
virtuale
Ottimizzazione
Analisi dei
Simulazione risultati
 Decision making
Esistono differenti metodi che permettono di
“prendere decisioni” in maniera ottimale
L’applicazione di queste tecniche dipende da:
 Tipologia di progetto e caratteristiche richieste
 Conoscenze intuitive a disposizione del
progettista (derivate da esperienza)
Università degli Studi di Salerno

 Conoscenze teoriche (leggi fisiche)

 Indagini statistiche
 Disponibilità di materiali e/o componenti
commerciali
 Costi
 Possibilità tecnologiche
 Altro….
 Ottimizzazione nel processo di
progettazione
In tutte le fasi di progettazione ci si pone il
problema dell’ottimizzazione poiché:

 Spesso è necessario trovare un equilibrio tra

esigenze opposte (es.: bilanciamento delle
tolleranze in dipendenza della precisione del
Università degli Studi di Salerno

meccanismo e del contenimento dei costi)

 Spesso si devono confrontare e ottimizzare
aspetti non quantificabili numericamente (es.:
la carrozzeria di un’autovettura viene valutata
esteticamente e strutturalmente)
 Spesso le caratteristiche richieste non hanno
la uguale importanza
 Metodi di progettazione/ottimizzazione
In tutte le fasi di progettazione, l’ingegnere puo’ far
uso di differenti metodi per “ottimizzare” il progetto:
 Ottimizzazione, tra le caratteristiche richieste, di
quelle di fondamentale importanza (Approccio
algoritmico)
 Riformulazione del problema progettuale in modo
che sia scomponibile a blocchi ottimizzabili
Università degli Studi di Salerno

individualmente (Approccio assiomatico, TRIZ)

 Utilizzo di sistemi di rappresentazione della
conoscenza che, con appositi algoritmi, possano
individuare la soluzione ottimale globale (sistemi
logici [Fuzzy, doxastica, ..], algoritmi genetici,
Reti neurali, etc.) (Approccio logico o IA)
 Utilizzo di metodi comparativi (AHP, MADM, …)

Alessandro Naddeo – S.S.D. ING-

IND/15
 OBIETTIVI DA PERSEGUIRE

Riduzione degli errori Riduzione dei tempi di

di progettazione nella messa in produzione
fase di stesura del del nuovo prodotto
progetto
Università degli Studi di Salerno

Riduzione del numero Riduzione delle spese

di prototipi fisici di prototipazione
Alessandro Naddeo – S.S.D. ING-
IND/15
 Approccio algoritmico
• Pahl and Beitz
• Progettazione sistematica• Hubka adn Eder
• Oshuga
• VDI (German Standard Institute)
• Concurrent Engineering

• Progettazione Robusta •
Università degli Studi di Salerno

Metodo Taguchi
• Metodo 6-sigma

• Design for Assembly

• Design for X • Design for Manufacturing
• Design for Maintenance
• Design for Environment

Alessandro Naddeo – S.S.D. ING-

IND/15
 Approccio logico
• Algoritmi Genetici

•
• Approcci logici Logica Doxastica (delle credenze)
• Logica Fuzzy
• Logica binaria
Università degli Studi di Salerno

• Reti Neurali

• Approcci probabilistici • Entropia informazionale

• Probabilità marginale

Alessandro Naddeo – S.S.D. ING-

IND/15
 Approccio assiomatico
• Approccio Assiomatico

Axiomatic Design by N.P. Suh

Teoria della complessità
Principi di indipendenza e
Università degli Studi di Salerno

dell’informazione

Alessandro Naddeo – S.S.D. ING-

IND/15
 Metodi comparativi in fase Concettuale

 Triz Theory

 Kansei Engineering

 Quality Function Deployment

Università degli Studi di Salerno

 AHP (Analitycal Hierarchy

Process)

Alessandro Naddeo – S.S.D. ING-

IND/15
 Il buon progettista

Un buon progettista deve:

 Saper riconoscere il metodo migliore di

ottimizzazione in funzione dello specifico
problema
Università degli Studi di Salerno

 Saper integrare ed armonizzare tali

tecniche in presenza di problemi complessi
 Pregi e difetti nell’utilizzo dei metodi

 Ottimizzazioni in tempi ridotti

 Tempi lunghi di implementazione
 Formalizzazione della conoscenza
 Incoscienza del livello di
Università degli Studi di Salerno

ottimizzazione (metodi comparativi)

 Ottimizzazione di progetto

{ws}{FRs} = [A]{DPs}
Ottimizzare un progetto significa
massimizzare il valore della Funzione
Obiettivo (F.O.)
Università degli Studi di Salerno

F.O. = S ws m(FRs)

m(FRs) è il livello di soddisfacimento dei

Requisiti Funzionali e dipende dalle scelte
fatte sui DPs.
I vari metodi differiscono per il modo di
calcolare questa misura
 Ottimizzazione di progetto
Max[m({ws}{FRs})] = Max[m([A]{DPs})]
{FRs} si ottengono dall’analisi di mercato
le importanze relative {ws} si ottengono confrontando i FRs con
tecniche comparative tipo AHP
I {DPs} vengono inizialmente scelti dal progettista sulla base delle
conoscenze tecniche, dell’esperienza con l’aiuto di sistemi di
Università degli Studi di Salerno

scomposizione funzionale
Il problema può essere riformulato tramite metodologia TRIZ in
modo da modificare [A] riducendo o eliminando le Dipendenze
(chiamate «Contraddizioni»)

m(FRs) può essere il contenuto di informazione (2° assioma), il

grado di appartenenza (logica Fuzzy), la probabilità, la
possibilità (Dempster e Shafer), la credenza (logica Doxastica),
la comparazione (AHP), la qualità percepita (Robust Design),
……
 Axiomatic Design: un po’ di storia
La teoria della progetazione assiomatica e’ stata sviluppata dal Prof.
Nam P. Suh (MIT) che nel 1990 ha pubblicato un testo che comincia
con la frase “there exists a fundamentals set of principles that
determines good design practice”.

In tale testo il Suh sostiene che e’ possibile un approccio

assiomatico alla progettazione, da affiancare a quello algoritmico

ASSIOMA: e’ una definizione che si crede essere universalmente

vera, anche nelle sue applicazioni, ma che non puo’ essere provata.
Università degli Studi di Salerno

L’axiomatic design e’ stato sviluppato ed e’ stato, negli anni, anche

supportato con lo sviluppo di un software ad hoc.
E’ un metodo di progettazione che si basa sulla costruzione di
matrici di relazione logico/funzionale tra i domini della progettazione
 Axiomatic Design

Axiom 1 Mantenere l'indipendenza dei FRs:

The Independence Axiom In un design accettabile, DPs e
FRs sono legati in modo tale che
un DP specifico può essere
regolato per soddisfare il suo
corrispondente FR senza influire
Università degli Studi di Salerno

sulle altre FRs.

Axiom 2 Ridurre al minimo il contenuto di
The Information Axiom informazione:
il progetto migliore è quello il cui
contenuto di informazione è
minimo
 Le tipologie di progetto
{FR}nx1 = [A]nxm {DP}mx1
Università degli Studi di Salerno
 ASSIOMA 1

Assioma dell’indipendenza dei FRs: i requisiti

funzionali devono essere, tra loro ,
indipendenti

Tale requisito e’ automaticamente verificato per i

progetti “disaccoppiati”
Università degli Studi di Salerno

 FR1   X 0 0   DP1 
     
 FR2    0 X 0   DP2  FRi = Aii xDPi
 FR   0 X   DP3 
 3  0
 Progetti disaccoppiabili

 FR1   X 0 0   DP1 
     
 FR2    X X 0   DP2 
 FR   X X   
 3  X  3
DP
Università degli Studi di Salerno

FR1 = A11 DP1

FR2 = A21DP1 + A22 DP2
FR3 = A31 DP1 + A32 DP2 + A33 DP3
Ogni funzione puo’ essere ottimizzata in modo
indipendente
 Progetti accoppiati

 FR1   X X X   DP1 
     
 FR2    X X X   DP2 
 FR   X X   
 3  X  3
DP
Università degli Studi di Salerno

FR1 = A11 DP1 + A12 DP2 + A13 DP3

FR2 = A21DP1 + A22 DP2 + A23 DP3
FR3 = A31 DP1 + A32 DP2 + A33 DP3
Il primo assioma non e’ mai verificato
Università degli Studi di Salerno
L’esempio di Suh
 Schema Funzionale

Rubinetto “originale”
Università degli Studi di Salerno
 Schema Assiomatico
FR1 = Controllo del flusso (quantità di acqua)
FR2 = Controllo della temperatura dell’acqua

DP1 = Rotazione della manopola acqua calda

DP2 = Rotazione della manopola acqua fredda

 FR1   X X   DP1 
    
Università degli Studi di Salerno

FR2   X X  DP2 

Problema completamente accoppiato poiche’ sia

il flusso che la temperatura dell’acqua dipendono
dalla rotazione di entrambe le manopole.

Qual e’ la soluzione??
 Applicazione del primo assioma
I Requisiti Funzionali DEVONO essere indipendent
Come fare??
Bisogna fare in modo che il flusso di acqua sia
controllato da un solo comando e che anche la
temperatura sia controllata da un solo comando; inoltre
i due comandi devono essere indipendenti tra loro.
Università degli Studi di Salerno

Soluzione: leva di controllo flusso complessivo +

leva di controllo miscelamento: troppo complicata!
Applico il 3° Corollario del Suh (Integrazione delle
parti):
UNICA LEVA con doppio comando:
1) Cilindrico verticale (movimento dx-sx) per controllo
miscelatore
2) Cilindrico orizzontale (movimento su-giu’) per controllo flusso
 Schema Funzionale
Rubinetto “finale”
Università degli Studi di Salerno
 Schema Assiomatico
FR1 = Controllo del flusso (quantità di acqua)
FR2 = Controllo della temperatura dell’acqua

DP1 = Rotazione della leva dx-sx per controllo miscela

DP2 = Rotazione della leva su-giù per controllo flusso

 FR1   X 0   DP1 
    
Università degli Studi di Salerno

FR2   0 X  DP2 

Problema completamente disaccoppiato

OTTIMO!!
 Strumenti di analisi e di sintesi: Hierarchy
I Requisiti funzionali di un prodotto/processo possono
essere in prima istanza definiti in maniera macroscopica:
Es. prodotto: rubinetto
requisito funzionale: erogazione acqua
Ogni requisito puo’ essere “esploso” in sub-requisiti
funzionali piu’ dettagliati:
Es. Requisito funzionale: erogazione acqua
Università degli Studi di Salerno

Sub requisiti: erogazione acqua calda, acqua fredda,

miscelazione
Il processo di dettagliamento puo’ generare vari step
originando una “gerarchia” di requisiti:
Requisiti di dettaglio: pressione e temperatura di
erogazione acqua, dettagli tecnici del meccanismo di
miscelazione, materiali utilizzabili….etc.etc..
 Strumenti di analisi e di sintesi: Hierarchy
I Parametri di progetto possono a loro volta essere
dettagliati fino a giungere alle specifiche progettuali di ogni
singolo componente del prodotto
Università degli Studi di Salerno
 Strumenti di analisi e di sintesi: Zigzagging
I Parametri di progetto possono seguire lo stesso
criterio di dettagliamento dei requisiti funzionali con
un’operazione detta “zigzagging”
Università degli Studi di Salerno
 Esempio di zigzagging
Prodotto: rubinetto a due manopole
Requisito funzionale: erogazione acqua
Parametro di progetto: sistema di erogazione a saracinesca
1° livello di sub-requisiti: erogazione acqua calda, fredda,
miscelamento
Parametri di progetto: saracinesca acqua calda, saracinesca
acqua fredda, convogliatore/miscelatore
2° livello di sub-requisiti: saracinesca a guarnizione assiale e
Università degli Studi di Salerno

azionamento a vite acqua calda, idem per acqua fredda, miscelatore

a convogliatore comune
Parametri di progetto: tipo di guarnizione, accoppiamento
vite/madrevite, geometria del convogliatore, per acqua calda e
fredda
…………………
………………….

Dettagliato fino alle specifiche di progetto:

Materiale della saracinesca: ghisa con determinate proprietà
meccaniche
Sistema di collegamento con filettatura ISO con caratteristiche….
 Strumenti di analisi e di sintesi: Zigzagging
L’azione di zigzagging ha un preciso significato in
ambito progettuale:
ZIG
- Concettualizzazione del problema
- Mappatura dei Requisiti Funzionali (FR) in funzione
dei Parametri di Progetto (DP) con relativa
definizione e riempimento della Design Matrix [DM]:
Università degli Studi di Salerno

FR = [DM]*DP
- Test dell’Assioma dell’indipendenza
ZAG
- Definizione del livello inferiore dei requisiti
funzionali: ogni requisito funzionale deriva
dall’analisi dei parametri di progetto del livello
superiore
- Verifica che ogni parametro di progetto generi un
Università degli Studi di Salerno
I corollari del primo assioma
Università degli Studi di Salerno
I corollari del primo assioma
 Matematica del 1° assioma

Data la funzione q  q  x  per incrementi piccoli  x

dq
si ha  q  q  x   x   q  x   q  q  x   x   q  x   x
dx
Dato il vettore FRi  si ha
Università degli Studi di Salerno

FRi  FRi  DP1 , ..., DPn 

FR1 FR1
FR1  DP1  ...  DPn
DP1 DPn
....... .........
FRn FRn
FRn  DP1  ...  DPn
DP1 DPn
 I problemi non affrontabili: matrici rettangolari

Redundant Design: Il numero dei

parametri di progetto e’ superiore al
numero dei requisiti funzionali e ci
sono interdipendenze.
Soluzione: analisi di sensibilità a
parametri fissi – definisco due valori
fissi per DP3 e DP4, risolvo il sistema
per variazioni a step di questi ultimi e
cerco il valore di ottimo
Università degli Studi di Salerno

 FR1   A11 A12 A13  Insufficient design: Il numero

  DP1 
dei parametri di progetto e’
 FR   A
 2   21 A22 A23
  DP2 
inferiore al numero dei
  requisiti funzionali e ci sono
 FR3   A31 A32 A33   interdipendenze

 FR4   A41  
DP3
Soluzione: applicazione del
A42 A43  principio di massima entropia
(Pappalardo-Naddeo, 2005)
 ASSIOMA 2
Assioma dell’informazione: il miglior progetto e’
quello con il contenuto minimo di informazione

Informazione = una misura della conoscenza

richiesta (mancante) per soddisfare un FR ad ogni
Università degli Studi di Salerno

livello gerarchico

Informazione e’ legata alla probabilità di

soddisfare un FR
 Misura del’informazione
L’assioma dell’informazione puo’ essere applicato a ogni
parametro di progetto (DP)
La misura dell’informazione e’ quella suggerita da
Shannon, derivante dalla misura della “media
dell’autoinformazione” e puo’ essere espressa in nat
(logaritmo in base e) o in bit (logaritmo in base 2)
Università degli Studi di Salerno

I = loge (1/P)
P = Probabilità di soddisfacimento di un FR

Una grande probabilità di successo implica che

l’informazione e’ molto molto piccola!!
 Misura dell’informazione
Nella definizione dei parametri di progetto e’ possibile
identificare:

Il System Range (SR) = Distribuzione di probabilità che il

valore del parametro di progetto sia tale da soddisfare il
requisito funzionale

Il Design Range (DR) = Distribuzione di probabilità che il

Università degli Studi di Salerno

valore del parametro di progetto assume in base alle scelte

del progettista (limitazioni delle macchine)

Il Common Range (CR): insieme dei valori del parametro

di progetto, comuni al system range e al common range,
rispetto cui e’ possibile stimare la probabilità che il nostro
progetto (design) soddisfi il requisito funzionale
 Misura dell’informazione
Esempio di
System range = SR
Design Range = DR
Common Range = CR

Probabilità che il nostro

progetto soddisfi un
determinato requisito
Università degli Studi di Salerno

funzionale = P = CR/SR
da cui:

Il valore dell’informazione =
I = loge (1/P) = I = loge (System Range/Common Range)

N.B.: quando il SR=CR allora I = 0 => il progetto e’ ottimo secondo il 2° Assioma

Università degli Studi di Salerno
Esempi di distribuzioni
Università degli Studi di Salerno
Problemi con FR dipendenti

Quando due requisiti funzionali sono dipendenti tra loro

puo’ accadere che uno dei due non risulti mai soddisfatto da
un parametro e quindi che il progetto sia sempre “pessimo”
secondo il 2° assioma
 Esempio di applicazione del 2° Assioma

Immaginiamo di avere una vettura i cui requisiti funzionali

siano descritti da questi 3 parametri:
Università degli Studi di Salerno

La descrizione dei parametri ci permette di definire 3

distribuzioni di probabilità, di tipo a gradino (integrabili
alla Riemann) che rappresentano i nostri System Ranges
 Esempio di applicazione del 2° Assioma
Immaginiamo di avere tre possibili set di opzioni (design
ranges) tra cui scegliere volendo rispettare la regola imposta
dal secondo Assioma del Suh:
Università degli Studi di Salerno

Per ogni parametro possiamo sovrapporre i DR con i SR e

ottenere i CR necessari per calcolare l’Informazione
 Esempio di applicazione del 2° Assioma
Calcoliamo l’informazione utilizzando la teoria di Shannon
Università degli Studi di Salerno

And the winner is…….

La vettura A (con il minor valore di informazione
espressa in nat)