Appunti Optimization and innovation of production processes (parte 2)

Due assiomi definiscono la struttura dell’Axiomatic Design:

Assioma 1: The Indipendence Axiom richiede che le FRs siano soddisfatte in maniera

indipendente. Per un progetto dalle migliori caratteristiche i DPs e gli FRs sono legati da

relazioni tali che possiamo cambiare il valore di ogni DPs, in modo da aggiustare quello del FR

collegato, senza però influire sugli altri FRs.

Assioma 2: The Information Axiom. Per un migliore progetto dobbiamo cercare di

massimizzare la probabilità che i nostri FRs siano soddisfatti, in pratica cercare di

minimizzare il contenuto di informazione del nostro progetto. Il contenuto di informazione è

l’errore che si commette non soddisfando le specifiche.

L’assioma 1 a6erma che durante il processo di progettazione, come passiamo dagli FRs del

dominio funzionale ai DPs del dominio fisico, le relazioni devono essere tali che una

variazione nel valore di un DP deve riscontrarsi solo in una variazione del FR collegato. In

pratica i valori degli FRs devono essere indipendenti fra di loro. L’assioma 2 a6erma invece

che, fra tutti quei progetti che soddisfano l’assioma di indipendenza, il migliore è quello che il

minor contenuto di informazione e con la maggiore probabilità di soddisfare le specifiche.

Design matrix: scelto un set di PDs in grado di soddisfare le FRs, si ha una matrice definita

dalla seguente equazione:

Assioma indipendenza richiede che le FRs del sistema siano soddisfatte in maniera

indipendente (non implica indipendenza delle parti fisiche).

Accoppiamento funzionale:

- Caso uncoupled: FRs indipendenti

- Caso decoupled: FRs indipendenti solo se…

- Caso coupled: FRs dipendenti

Assioma informazione a6erma che il miglior progetto è quello con la maggiore probabilità di

soddisfare le specifiche

Il contenuto di informazione misura la probabilità che le FRs soddisfino la specifica.

Il progetto uncoupled

Il più semplice dei casi è quando la matrice di design assume una forma triangolare, cioè si

ha che:

In caso di un progetto a 3 FRs la nostra matrice di design avrà quindi la forma:

Per l’Axiomatic Design questo è il caso migliore, infatti ogni DP influenza un solo FR, si

possono così ottimizzare i valori dei DPs per soddisfare le richieste espresse dalle FRs in

qualsiasi ordine, un tipo del genere di progetto si dice path-independent. Il progettista deve

sempre cercare di arrivare ad una situazione del genere, anche se questo compito è spesso

di6icile e talvolta impossibile. Questo tipo di progetto garantisce la più alta a6idabilità e

funzionalità, e dato che ogni FR è influenzato solo da un DP, permette l’identificazione della

fonte di qualsiasi problema facilmente, permettendo una più rapida risposta in caso di

situazioni inaspettate ed una più veloce riparazione o manutenzione del sistema.

Il progetto decoupled

La seconda categoria nelle quali possiamo suddividere i vari tipi di progetti è quella dei

progetti decoupled. Sono progetti non più ideali ma comunque considerati accettabili, ed in

generale sono i progetti che si riescono ad ottenere più frequentemente. Diversamente dai

progetti uncoupled, qui si hanno interazioni di alcuni DPs con più di una FR, ciò porta a non

avere più una matrice di progetto diagonale. In generale la matrice di progetto ha la forma

mostrata sotto:

I progetti uncoupled possono avere una matrice che è al massimo triangolare superiore o

triangolare inferiore. In questo caso si può assumere che l’indipendenza delle FRs è verificata

solo se si sceglie un particolare ordine per aggiustare il valore dei DPs, soddisfacendo così

l’assioma 1. Questa è l di6erenza tra i progetti decoupled e quelli uncoupled, che potevano

avere un ordine dei PDs qualsiasi. In questo caso si può veder che DP1 influenza tutti gli FRs,

mentre solo DP3 riesce ad influenzare solo il corrispondente FR.

È però necessario chiedersi se questo sia il giusto ordine da seguire per l’ottimizzazione del

prodotto nel caso specifico. A questo proposito si deve per prima cosa trovare il valore

corretto di DP1 che ci consente di appagare le richieste di FR1, questo valore rimarrà ora

costante. Si passa ora a cercare il valore ottimale di DP2 con l’intento di soddisfare FR2,

facendo questo anche il valore di FR3 viene cambiato ma non quello di FR1. Alla fine, si può

ottimizzare il valore di DP3 fino a che non si ottiene il valore di FR3 da cercato.

Questa è la procedura nel caso che tutti gli elementi della matrice di design siano costanti,

cioè nel caso in cui si abbia un sistema lineare ì. Sfortunatamente nella pratica comune, molti

elementi non sono costanti ma funzioni di alcuni DPs, normalmente il progettista deve

ottimizzare un progetto che è non lineare. In questi casi si deve allora valutare la matrice di

progetto per specifici valori dei DPs, stando attenti al fatto che per certi valori dei DP il nostro

progetto può cambiare e passare da decoupled ad uncoupled o anche coupled. Obiettivo del

prossimo capitolo sarà anche di stabilire quanto un progetto decoupled è migliore di altri

dello stesso tipo.

Il progetto coupled

Il terzo caso è quando il progetto non è né uncoupled né decoupled, si ha allora che neanche

variando i DPs in un certo ordine si riesce a rispettare il primo assioma. Un progetto di questo

tipo si dice coupled e la sua matrice di design è generalmente una matrice piena o comunque

con qualche elemento esterno alla parte triangolare.

Diversamente dagli altri casi, qui non esiste un modo dirette per arrivare ad una soluzione

ottimale, bisogna invece ricorrere a delle iterazioni, si vengono cioè a creare dei loops nel

calcolo. Il progetto coupled, a causa del suo violare il primo assioma, viene considerato come

il peggiore. Purtroppo, talvolta, per ragioni che vanno dal costo, agli ingombri, alla a6idabilità,

non è possibile disaccoppiare un progetto e quindi si è costretti a scegliere il migliore dei

progetti coupled.

Come possiamo immaginare la prima e più banale conseguenza del primo assioma è che le

migliori matrici di progetto devono per forza essere quadrate; infatti, solo in questo modo

possiamo sperare di associare ad un FR solo un altro DP. Questo ragionamento ovviamente

vale anche per i progetti decoupled e coupled, in quanto un diverso numero fra FRs e DPs

porta in tutti i casi ad un aumento del coupling della matrice.

Decomposition e zigzagging

Si passi ora a studiare come si sviluppa un progetto con l’Axiomatic Design. Una delle

caratteristiche che rende molto usato questo metodo è la sua rappresentazione di un

progetto in obiettivi generalmente ordinati. Si parte dagli obiettivi principali del progetto che

sono le FRs di livello più alto e si scompongono in sotto obiettivi, lo stesso viene fatto per i

DPs. Di solito i DPs e le FRs di massimo livello vengono chiamate top FRs e top DPs per

indicare la loro importanza; infatti, è in queste che si trova la specifica del progetto, i livelli più

bassi, quelli terminali, si chiamano invece leaves (foglie) per rendere più chiaro che la

struttura del progetto è ad albero.

La scomposizione degli alberi, se ne hanno infatti uno per le FRs ed uno per i DPs, vanno fatte

di livello in livello, partendo dal top fino alle leaves, seguendo una regola. Questa dice che

prima di decomporre un livello di FRs in un livello sottostante dobbiamo trovare i DPs che

soddisfino tale livello, solo quando si avranno chiari quali DPs sono da usare si può passare a

scrivere le altre FRs. Questo perché le FRs di livello più basso dipendono sempre dalle scelte

progettuali che sono state fatte a livello superiore. Si tratta in pratica di non scomporre i due

alberi separatamente ma di passare continuamente da uno all’altro. dato lo sigzag tra i due

domini, ovviamente l’albero delle FRs appartiene al dominio funzionale e quello dei DPs al

dominio fisico, che si deve fare questa regola prende il nome di zigzagging. Passaggio tra

domini non è monodirezionale ma si e6ettua con lo zigzagging.

In pratica il primo step è definire le FRs di primo livello, da specifica del progetto; quindi, le

DPs che le soddisfano e da qui passare a definire le FRs di secondo livello. Da qui il ciclo

ricomincia ma per il livello sottostante, cioè ora si deve cercare le DPs di secondo livello e

continuare fino a che non si abbiano solo foglie. Un DP o un FR è una foglia quando non è più

possibile scomporlo ulteriormente.

Questo processo consente al progettista di concentrarsi di volta in volta solo su un numero

ristretto di FRs, quello di un solo livello, con il compito di cercare i componenti (DPs) che le

soddisfino. Altrimenti potrebbe accadere che il progettista inesperto si trovi a fronteggiare

una moltitudine di FRs appartenenti a più livelli, rendendo la soluzione del problema molto

più complessa, con notevole ritardo nello sviluppo del progetto.

Naturalmente durante tutta la scomposizione dobbiamo tenere conto dei vincoli di input che

non devono essere mai violati dalle nostre scelte progettuali. Inoltre, alcune soluzioni

possono introdurre altri vincoli, in questo caso chiamati di sistema, che devono essere

rispettati nella scomposizione successiva alla introduzione di detto vincolo e non in tutta la

scomposizione. Per capire la di6erenza si può fare un esempio: dovendo progettare una

pompa si ha come vincolo di input che questa deve lavorare almeno per 30 minuti senza

bisogno di alimentazione, la soluzione proposta è quella di realizzare una pompa con motore

alternativo a benzina. Questa scelta progettuale induce il vincolo di sistema che la pompa

non deve inquinare più dei limiti di legge, cosa non prevista all’inizio della progettazione

perché ancora non si era valutato le possibili soluzioni progettuali.

La procedura di progetto

Come si può evincere dalla teoria dell’AD, il processo di generazione di un progetto deve

essere fortemente organizzato, si propone quindi un ordine per le operazioni da svolgere.

1. Si devono riconoscere i customer needs, cioè le esigenze dei clienti, tramite analisi di

mercato.

2. I Costumer Needs appena trovati devono ora essere espressi in termini di Functional

Requirements, che definiscono il range entro il quale si può dichiarare una soluzione

accettabile. Inoltre si deve valutare i contraints del sistema, cioè i vincoli (legislativi,

tecnici, di sicurezza, costo, etc.) che il nostro prodotto o servizio dovrà rispettare. Nella

definizione delle FRs e dei vincoli di input devono essere coinvolti tutti i reparti

dell’azienda, perché a seconda di quali sono gli FRs scelti, si avranno prodotti

risultanti diversi. Si