Embed Size (px)
Citation preview
UNIVERSITA’ DEGLI STUDI ROMA TRE
Facoltà di Ingegneria Corso di Laurea in Ingegneria Gestionale e dell’Automazione
Metodi e Modelli per la Simulazione
Simulazioni e Analisi di euristiche di scheduling su macchine parallele per la minimizzazione del makespan Ambra Consolo Manuel Ottaviani Valerio Voci
2
Indice
1. Introduzione al problema .......................................................................................... 3
2. Definizione del problema di Scheduling su macchina parallele ........... 5
2.1Scheduling su macchine parallele ...................................................................................... 5
2.2 Formulazione PLI ................................................................................................................... 6
3. Caratteristiche del Sistema ....................................................................................... 7
4. Descrizione delle Euristiche ..................................................................................... 8
4.1 Euristica Min-Min(B) ............................................................................................................. 8
4.2 Euristica Max-Min(A) ......................................................................................................... 10
4.3 Euristica Assegnazione macchina meno carica(C) .................................................. 11
4.4 Euristica di Miglioramento: Scambi (S) ...................................................................... 13
5. Scelta degli input per le simulazioni ................................................................. 16
6. Risultati delle esecuzioni ....................................................................................... 19
6.1 Indici di prestazione ............................................................................................................. 19
6.2 Risultati esecuzioni .............................................................................................. 20
6.2.1 Offline R=0 ............................................................................................................................. 20
6.2.2 Offline R≠0 ............................................................................................................................ 23
6.2.3 Online ..................................................................................................................................... 28
6.2.4 Lotti R=0 ................................................................................................................................. 33
6.2.5 Lotti R≠0 ................................................................................................................................ 36
7. Analisi degli Output ................................................................................................... 42
7.1 Offline R=0 .............................................................................................................................. 42
7.2 Offline R≠0 .............................................................................................................................. 49
7.3 Online ........................................................................................................................................ 54
7.4 Lotti R=0………………………………………………………………………………………………………..57 7.4.1 Tempi di setup molto piccoli…………………………………………………………………….57 7.4.2 Tempi di setup molto maggiori rispetto ai tempi di processamento ………………….61
7.5 Lotti Offline R≠0 .................................................................................................................... 63
7.6 Lotti Online ............................................................................................................................. 66
8. Conclusioni .................................................................................................................... 67
3
1. Introduzione al Problema
L’obiettivo affrontato in questa tesina è stato quello di analizzare i risultati di scheduling
ottenuti da un modello da noi creato per lo studio di macchine parallele. Per poter
analizzare il problema in tutte le sue sfaccettature, si è dovuto quindi costruire un buon
modello, principalmente per poter rappresentare la realtà all’interno del sistema scelto
con sufficiente dettaglio e permettere di rappresentare tutti i dati correlati con
sufficiente aderenza alla realtà stessa e con sufficiente approssimazione.
Inoltre, l’utilizzo degli strumenti di simulazione ci ha fornito la possibilità di effettuare in
tempi ragionevoli un gran numero di analisi dando un’indicazione sull’opportunità o la
convenienza di una certa decisione o scelta algoritmica, nell’affrontare nel nostro caso
“problemi di scheduling”.
Con il termine “problemi di scheduling” si intende una vasta classe di problemi, molto
diversi tra loro per complessità e struttura. Tutt’oggi per la soluzione di problemi di
questo tipo non è possibile indicare un unico approccio risolutivo. Possiamo comunque
definire come problemi di scheduling tutti quei problemi decisionali in cui riveste
particolare importanza il fattore “tempo“ visto come risorsa da allocare in modo ottimo
a determinate attività. In generale, uno “schedule”, è un’allocazione su uno o più
intervalli di tempo delle attività per espletare un certo job.
La schedulazione su macchine parallele in particolare è importante sia dal punto di vista
teorico che pratico. Dal punto di visto teorico questo caso è una generalizzazione dello
scheduling su macchina singola, mentre dal punto di vista pratico è rilevante in quanto
l’esistenza di risorse parallele in comune si verifica nella realtà.
Per ottenere dei risultati da confrontare ed analizzare, sono stati implementate tre
euristiche per la schedulazione iniziale, a cui viene successivamente applicata una
quarta euristica di miglioramento, basata sulla ricerca locale. Per “procedimento
euristico” si intende un metodo di approccio alla soluzione dei problemi che non segue
un chiaro percorso, ma che si affida all’intuito e allo stato temporaneo delle circostanze,
al fine di favorire la scoperta di nuovi risultati scientifici. L’algoritmo euristico “ideale”
dovrebbe essere in grado di determinare sempre la soluzione ottimale di un problema.
In generale si vorrebbe però che l’algoritmo fosse almeno in grado di determinare
sempre una “buona” soluzione ammissibile, dove per “buona” qui si intende una
soluzione il cui valore è abbastanza vicino al valore della soluzione ottima.
4
Esistono essenzialmente due modi per studiare l’efficacia di un algoritmo:
Sperimentale: si seleziona un sottoinsieme “rilevante” di istanze del problema,
tali che siano rappresentative delle istanze da risolvere in una o più applicazioni
pratiche, si esegue l’algoritmo su quelle istanze misurando l’errore relativo
ottenuto e poi se ne esaminano le caratteristiche statistiche (media, massimo,
minimo e varianza). Si noti però, che per fare ciò è necessario essere in grado di
calcolare il valore ottimo della funzione obiettivo (o una sua buona
approssimazione) per le istanze di test.
Teorico: si dimostrano matematicamente relazioni che forniscono valutazioni sul
massimo errore compiuto dall’algoritmo quando questo viene applicato ad
istanze con caratteristiche date.
Le due metodologie di valutazione non sono alternative, ma complementari. Lo studio
teorico risulta in genere meno accurato nel valutare l’errore compiuto nelle istanze reali,
ma fornisce valutazioni generali valide per grandi classi di istanze ed aiuta a
comprendere meglio il comportamento dell’algoritmo (eventualmente suggerendo
come modificarlo per renderlo più efficace). D’altro canto lo studio sperimentale
permette di valutare esattamente l’errore compiuto sulle istanze e di estrapolare con
ragionevole accuratezza l’errore che ci si può attendere su istanze simili, ma non
fornisce alcuna garanzia specialmente per istanze con caratteristiche diverse (o troppo
diverse) da quelle effettivamente testate.
5
2. Definizione del problema di Scheduling su macchine parallele
2.1 Scheduling su macchine parallele
Il processo di scheduling nel nostro caso è quello di allocare n diversi job su diverse macchine (unrelated) disposte in parallelo. Le macchine possono eseguire un solo lavoro alla volta e ogni lavoro deve essere eseguito su una ed una sola macchina senza interruzione.
Dati I tempi di processamento , i=1,…, m, del lavoro j sulla macchina i sono noti.
Obiettivo Assegnare i lavori alle macchine in modo tale da minimizzare il tempo totale di completamento della macchina più carica (equivalente a minimizzare il makespan).
6
2.2 Formulazione PLI
Definizione delle variabili , i=1,…, m, tempo di completamento della macchina i = 1 se il lavoro j è assegnato alla macchina i
0 altrimenti = , } tempo di completamento di tutto il sistema Nota: il tempo di completamento della macchina più carica corrisponde al tempo di completamento del lavoro che finisce per ultimo
=
= , = ,
Funzione Obiettivo
= ,
tale che
= = ,… ,
,
7
3. Caratteristiche del sistema
Le specifiche del nostro sistema possono essere riassunte come di seguito:
Macchine parallele
Coda infinita
No preemption
La caratterizzazione delle operazioni (tempi di processamento) dipende dalla
assegnazione job-macchina
Tempi di Setup nella gestione delle macchine per job organizzati a lotti
Casistiche
- i job arrivano tutti insieme (scheduling offline)
- i job arrivano distribuiti nel tempo (release date diverse da zero), caso offline e caso online
- i job arrivano in lotti (non un solo job ma blocchi di diversi job)
Variabili e parametri
• n: numero dei job;
• m: numero delle macchine;
• : tempo di processamento del job i sulla macchina j, variabile aleatoria distribuita in
maniera uniforme;
• : release date del job i-esimo, variabile aleatoria distribuita uniformemente;
• tempo di completamento sulla macchina m;
• tempo di set-up necessario alla macchina per passare dal lotto di tipo A al lotto di
tipo B, è una variabile aleatoria distribuita uniformemente
8
4. Descrizione delle euristiche
Nel seguito verranno descritte le 3 euristiche che sono state implementate per ottenere
una soluzione di scheduling, che verrà definita come “soluzione iniziale” per l’euristica di
miglioramento.
4.1 Euristica MinMin(B):
L’euristica parte dall’idea degli algoritmi SPT (shortest processing time), in cui i job
vengono ordinati in ordine crescente per tempi di processamento (quelli più corti per
primi), ma si sviluppa prendendo in considerazione di volta in volta i tempi di
completamento, perché i tempi di processamento dei job sono diversi per macchina.
Solo nel primo passo dell’algoritmo i tempi di processamento e di completamento di un
generico job su una macchina coincidono ( = ) poiché all’inizio non è ancora
stato assegnato nessun job alle macchine. Quindi, per calcolare la soluzione di
scheduling, si parte dai tempi di processamento dei vari job sulle macchine e mano a
mano si prendono in considerazione i loro tempi di completamento che vengono
rappresentati, per semplicità, in una matrice che contiene sulle righe i vari job e sulle
colonne le macchine a disposizione. Dopo aver scelto il job più idoneo, la matrice viene
aggiornata; nello specifico viene sommato, ai valori di completamento della colonna
della macchina a cui è stato assegnato il job, il valore del suo tempo di processamento
. Per ogni job scegliamo dunque la macchina per cui il tempo di completamento
risulta essere minore, dopo di che, tra tutti i job si sceglie quello che si completa prima,
schedulandolo sulla rispettiva macchina. In questo modo, ad ogni passo riusciamo a
bilanciare il carico sulle macchine e ad assegnare ogni volta i job considerando la
minimizzazione dei tempi di completamento e quindi una sorta di “minimizzazione
graduale” della funzione obiettivo.
Nel caso Offline con release uguali e zero, non essendoci vincoli di arrivo e quindi di
precedenza, l’applicazione dell’algoritmo viene fatta indistintamente su tutti i job ancora
da schedulare; nel caso Offline con release diverse da zero invece, essendoci dei vincoli
di precedenza e allo stesso tempo potendo sfruttare la loro piena conoscenza,
l’applicazione dell’algoritmo è stata gestita nel seguente modo: ad ogni assegnazione di
job si considera il massimo valore di completamento tra tutte le macchine (maskepan
momentaneo) e si provano a fare schedulazioni temporanee con l’algoritmo MinMin, tra
tutti i job con release minori di questo valore. Nella tabella, se su alcune macchine il
tempo di completamento è minore della release della schedulazione temporanea, si
9
ipotizza di sommare i processamenti non più ai tempi di completamento ma alle
rispettive release ( , con il rischio di creare dei “tempi morti” ) in
quanto è possibile che le macchine che non sono giunte ancora a quel tempo di
completamento massimo, possano schedulare il job solo nel momento in cui arriva, da
qui l’idle-time. Tra tutte le prove di schedulazione di job, si sceglierà quello con tempo di
completamento minore. Se ci troviamo nella condizione per cui non ci sono altri job, il
completamento di tutte le macchine, se minore della release, viene aggiornato al valore
della release successiva.
Per quanto riguarda il caso Online, ad ogni iterazione viene fatta una schedulazione
temporanea con l’algoritmo MinMin su tutti i job della release “attuale” e tra questi,
vengono schedulati definitivamente i job che partono prima della release successiva.
Viene, in questo modo, creata e gestita una coda contenente i job restanti che verranno
schedulati successivamente insieme agli altri che arriveranno.
Ci aspettiamo che il caso peggiore dell’algoritmo si presenti nel caso in cui l’ultimo job
schedulato sia molto più grande degli altri tempi di processamento, in quanto determina
il . Qui di seguito presentiamo un esempio in cui l’algoritmo viene messo in crisi,
per il motivo appena descritto.
10
4.1 Euristica MaxMin: (A)
L’euristica, in questo caso, parte dall’idea degli algoritmi LPT (Longest Processing Time)
in cui i lavori vengono assegnati in ordine non crescente dei tempi di processamento
(quelli più “lunghi” per primi) e iterativamente assegnati alla macchina meno carica . Nel
nostro caso la scelta del job da processare avviene nel seguente modo : si verifica ogni
volta , per ogni job, quale è il tempo di completamento minimo tra le varie
macchine che lo possono processare e tra tutti questi tempi di completamento si
sceglierà quello che ha il valore massimo.
Quindi la nostra euristica cerca di assegnare i job più lunghi, non dal punto di vista dei
tempi di processamento, ma da quello dei tempi di completamento mano a mano che i
job vengono assegnati, questo perché non sempre i tempi minimi ( )
corrispondono alla macchina più scarica; infatti seguendo l’idea LPT di assegnare ogni
volta il job sulla macchina più scarica si cadrebbe nell’errore (soprattutto nel caso di
grossa disparità tra i tempi di processamento di uno stesso job sulle varie macchine) di
scegliere un tempo di processamento molto più grande per un job che potrebbe essere
processato in un tempo minore su una altra macchina.
La distinzione tra i casi Online, Offline con release nulle e diverse da zero avviene nello
stesso modo dell’algoritmo Min-min precedentemente descritto. Come nell’algoritmo
Min-min, anche qui tra le soluzioni temporanee calcolate per ogni rilascio viene scelta
quella minima, perché scegliere la massima renderebbe l’algoritmo ancora meno
efficiente. Se si decidesse di scegliere la soluzione massima tra quelle proposte per i
rispettivi rilasci, i tempi di completamento verrebbero incrementati dei massimi idle-
time creati dagli ultimi tempi di rilascio.
Viene mostrato di seguito un’applicazione che mostra l’efficienza dell’algoritmo, dove la
soluzione trovata coincide con la soluzione ottima. La prima tabella, come già spiegato
per l’algoritmo B, contiene i tempi di processamento , che serviranno per
l’aggiornamento delle altre tabelle (ciascuna associata a ogni iterazione per la schedula
di ogni job) con i tempi di completamento ( ), al fine di assegnare il massimo tempo di
completamento tra quelli minimi. Notiamo come l’algoritmo, seguendo l’idea dell’ LPT,
riesce ad ottenere, al termine della schedulazione, un buon bilanciamento del carico e
del numero dei job assegnati alle macchine disponibili, anche se in realtà si potrebbe
bilanciare meno per far lavorare meno le altre macchine. Vedremo però, in seguito,
come l’algoritmo, proprio per questo motivo, viene messo in serie difficoltà
dall’aumento del numero di job e quindi all’aumentare delle iterazioni dell’algoritmo
stesso.
11
4.3 Euristica Assegnazione a macchina meno carica:(C)
Questa euristica, a differenza di quelle precedentemente descritte, non schedula i job in
base ai tempi di completamento sulle varie macchine, ma determina ad ogni iterazione
la macchina meno carica dal punto di vista della funzione obiettivo e assegna a questa, il
job che può processare nel minor tempo possibile (quindi in sostanza alla macchina
meno carica assegna il job, tra tutti quelli disponibili, col tempo di processamento
minore).
Nel caso Offline con release nulle, l’euristica viene applicata a tutti i job, in quanto
disponibili subito e senza vincoli di precedenza temporale. Per quanto riguarda invece il
12
caso Offline con release diverse da zero, ogni volta il job viene scelto con la
consapevolezza di conoscere i rilasci dei job, e quindi nella scelta del minor tempo di
processamento vengono considerati anche quelli rilasciati dopo il temporaneo
makespan della macchina meno carica, aggiungendo però l’idle temporale che si viene a
creare tra questo e il rilascio del job (se ho un job i-esimo con e per j intendo la
macchina meno carica ,considero non solo del job ma anche il tempo morto ).
Per quanto riguarda l’Online invece è stato, come gli altri, gestiti attraverso una coda a
cui viene applicata l’euristica a ogni rilascio di nuovi job/lotti .
Questo algoritmo, non prendendo in considerazione i tempi di completamento ma solo i
tempi di processamento dei job sulla macchina meno carica, può risultare inefficiente
nel caso precedentemente accennato, per cui i tempi di processamento dei job sono
molto eterogenei fra loro e soprattutto quando ci sono tante risorse disponibili
(macchine) per pochi job. Infatti è possibile che la macchina meno carica si trovi a
schedulare un job in un tempo molto grande rispetto a un’altra macchina che invece
potrebbe processarlo in un tempo molto più piccolo. Nell’esempio che viene proposto si
può osservare come al 5° passo il job F venga assegnato alla macchina che impiega più
tempo per processarlo ma in quel momento la meno carica, mettendo in risalto come in
presenza di pochi job ancora da schedulare l’algoritmo perda di efficienza.
13
4.4 Euristica di Miglioramento: SCAMBI (S)
E’ stata poi implementata un’euristica di miglioramento basata sulla ricerca locale,
applicabile agli algoritmi di schedulazioni proposti.
Gli algoritmi di ricerca locale, in generale, partono da una soluzione ammissibile e
cercano iterativamente di migliorarla effettuando semplici modifiche alla soluzione
iniziale: tali procedure di modifica, dette “MOSSE”, permettono di trovare un insieme di
soluzioni, che compongono il cosiddetto “VICINATO”, e di scegliere tra queste quella
migliore dal punto di vista della funzione obiettivo, che diventerà la nuova soluzione da
migliorare. Tali algoritmi terminano quando non esistono più modifiche del tipo
prescelto in grado di migliorare la soluzione corrente. Nel nostro caso la mossa in grado
di trovare di volta in volta soluzioni migliori, e quindi in grado di minimizzare il ,
consiste nello scambio tra due job diversi assegnati a macchine differenti. Più nel
dettaglio: a ogni iterazione viene scelta la macchina critica, e cioè quella con il tempo di
completamento maggiore, e per ogni job di questa macchina viene considerata la
possibilità di scambiarlo con i job delle altre macchine. Lo scambio viene effettuato se il
tempo di completamento della macchina più carica diminuisce e allo stesso tempo se
quello dell’altra macchina non assume un valore di completamento maggiore o uguale a
quello della macchina critica (praticamente se il miglioramento della macchina critica
non viene annullato dal peggioramento dell’altra). Nel caso Offline con release diverse
da zero vengono considerati anche i vincoli di release dei due job da scambiare cosi
come presa in considerazione la presenza di possibili buchi. I vincoli di release sono
legati al fatto che i due job presi in considerazione devono avere una release minore o
uguale rispetto all’inizio che avranno nelle macchine una volta scambiati. Per i tempi
morti ci sono molto vincoli, del tipo che se c’è la presenza di un idle-time nella macchina
critica a seguito del job che si intende scambiare, siccome sappiamo che quell’idle si è
creato per la presenza di un vincolo di rilascio, ne deduciamo che il makespan generale
non potrà migliorare anche se il nuovo job ha un minor tempo di processamento su tale
macchina.
Non avendo un criterio ben preciso di miglioramento ma essendo un insieme di prove
per trovare via via una soluzione migliore, è difficile prevedere come si comporterà e in
quale caso sarà più o meno efficiente. Chiaramente ci aspettiamo che siano fatti più
scambi là dove l’euristica di partenza sia poco efficiente e quindi dia come risultato una
soluzione molto lontana dall’ottimo.
Dal punto di vista del tempo di esecuzione, presenta degli incrementi proporzionali al
numero di job da scambiare.
14
Per il miglioramento dei lotti, visto la presenza dei set-up, si è deciso di non considerare
più lo scambio tra singoli job perché il suddividere ulteriormente i lotti separati
nell’euristica di partenza avrebbe introdotto troppi set-up che non avrebbero alla fine,
secondo il nostro punto di vista, portato a ulteriori miglioramenti. Dunque abbiamo
modificato l’algoritmo considerando lo scambio di sequenze di job uguali nel tentativo,
laddove fosse efficiente nel minimizzare il , di ricompattare i lotti.
Esempio scambio per singoli job:
Iterazione 1
1) Provo C <--> E NO Miglioramento 2) Provo C <--> D NO Miglioramento 3) Provo C <--> A NO Miglioramento 4) Provo C <--> B NO Miglioramento 5) Provo F <--> E SI Miglioramento(36-13= 23)
SI Peggioramento(23-3= 20) newMakespan2= 8+23= 31 < =41 SI SCAMBIO F con E
15
Iterazione 2
1) Provo A <--> C 2) Provo A <--> E 3) Provo A <--> F 4) Provo A <--> D 5) Provo B <--> C SI Miglioramento(28-26= 2)
SI Peggioramento(38-5= 33) newMakespan1= 38+13= 51 < =36 NO SCAMBIO B con C
6) Provo B <--> E SI Miglioramento(28-21= 7)
SI Peggioramento(38-13= 25) newMakespan1= 5+38= 43 < =36 NO SCAMBIO B con E
7) Provo B <--> F SI Miglioramento(28-18= 10) NO Peggioramento(38-13= 25) SI SCAMBIO B con F
Come visto precedentemente la soluzione ottima è proprio =26 che qui abbiamo
trovato dopo 2 iterazioni dell’algoritmo scambi applicato alla soluzione di partenza. Per
questo motivo evitiamo di continuare con le iterazioni, perché da qui in poi sappiamo
che gli scambi che verranno effettuati non modificheranno il uguale 26, e così al
primo scambio ritornando lo stesso tempo massimo di completamento terminerà
l’esecuzione dell’algoritmo.
16
5. Scelta degli Input per le Simulazioni
Per analizzare le simulazioni delle euristiche proposte si è scelto di considerare due
profili (PICCOLO e GRANDE) riguardo il numero di job da schedulare e il numero di
macchine disponibili in parallelo.
A tali profili sono stati preventivamente associati dei valori (20 /80 per i job e 3/9 per le
macchine) per verificare il comportamento delle euristiche e i rispettivi miglioramenti, a
seconda dell’aumentare della numerosità delle istanze da analizzare, e quindi al
sovraccarico di job sulle macchine e all’aumentare delle risorse disponibili.
I tempi di processamento vengono generati con una distribuzione uniforme all’interno
di due intervalli predefiniti, in modo tale che in questi la probabilità di uscita dei tempi
sia uguale per tutti i job. Si è deciso di non scegliere una distribuzione gaussiana per il
fatto che se i tempi venissero generati secondo una media ,si avrebbero dei tempi quasi
uguali e di conseguenza si assisterebbe a un’ assegnazione circolare dei job che non ci
permetterebbe di osservare il comportamento delle nostre euristiche.
La scelta degli intervalli segue l’idea di rendere i tempi di processamento dei vari job
Omogenei ed Eterogenei tra loro, per cercare di osservare il sistema in diverse situazioni
che poi rispecchiano la realtà.
OMOGENEI; l’intervallo è stato scelto tra 2 e 10 per generare dei tempi molto
simili tra loro.
ETEROGENEI; l’intervallo scelto è compreso tra 2 e 50 per generare tempi
abbastanza dissimili.
Le release sono variabili aleatorie, come i tempi di processamento, scelte tramite un
distribuzione uniforme, e strettamente dipendenti dal numero di job da assegnare alle
varie macchine e dai loro tempi di processamento. Abbiamo cercato di evitare di
scegliere release troppo grandi, soprattutto rispetto ai tempi di processamento e di
creare degli intervalli che permettessero di far arrivare i job quando le macchine sono
ancora occupate, perché altrimenti tutta la schedulazione degli algoritmi proposti
dipenderebbe esclusivamente dall’arrivo degli ultimi job, ritornando al caso di release
uguale a zero. Per ovviare a questo inconveniente e cercare di ridurre l’attesa delle
macchine (buchi) sono stati scelti intervalli per le release secondo un criterio molto
arbitrario: si prende la media per difetto dei job su ogni macchina e la media sempre per
difetto dei tempi di processamento e si moltiplicano. Inoltre si è deciso di considerare
17
per i vari casi release distanti tra loro e release ravvicinate. Questo perché release
ravvicinate permettono di avere meno job vincolati dai loro arrivi, e quindi ci permette
di avere a determinati istanti di tempo più job da considerare nella schedulazione e
soprattutto più possibilità di scambi per l’euristica di miglioramento .Nel momento
invece che vengono scelte release distanti possiamo analizzare le prestazioni degli
algoritmi in una situazione più critica e più vincolata, con la consapevolezza che la
conoscenza dei rilasci ha poco interesse ,quasi come se ci trovassimo di fronte a una
situazione online. Per scegliere l’intervallo delle release ravvicinate abbiamo preso per
ogni istanza un terzo dei rispettivi intervalli per release distanti.
5.1 Studio caso dei lotti
Per lo studio dei lotti abbiamo deciso di considerare le stesse numerosità di macchine e
di job per fare un raffronto immediato sull’ influenza dei tempi di set-up e il
bilanciamento del carico sulle varie macchine ,con quello già fatto per job singoli. Il
numero di job viene ripartito in un numero di lotti dipendente da una media e una
varianza scelta a priori . Quindi, come nel nostro caso, scegliendo una media di 5 job a
lotto , ne deriva che 80 job vengono ripartiti in 16 tipologie di lotti tramite una
distribuzione gaussiana ( = , = ). La media è stata scelta in base al numero di
lotti che ci sembrava adeguato per l’analisi che dovevamo effettuare, la varianza è stata
scelta in base ad una serie di prove sperimentali: considerare sempre lo stesso numero
di job per lotto o considerare lotti con pochi job, non è stato ritenuto un dato
rappresentativo per lo studio, infatti la scelta della gaussiana è stata fatta per assegnare
ad ogni lotto un numero di job che, discostandosi dalla media ma non di troppo né
troppo spesso, avrebbe permesso uno studio più approfondito del caso.
[Esempio di 80 job distribuiti in 16 lotti con distribuzione Gaussiana = =
6,9,2,4,6,4,3,5,3,7,2,5,8,6,5,5]
Per l’analisi dei lotti sono stati scelti, in un primo momento, dei tempi di set-up non
troppo grandi, in quanto il loro incremento, e quindi, l’avvicinarsi di questi ai tempi di
processamento dei job appartenenti al lotto, avrebbero portato a processare il lotto
interamente senza suddividerlo tra le varie macchine. Abbiamo dunque considerato i
tempi di set-up come variabili aleatorie distribuite uniformemente nell’intervallo [1,6],
intervallo scelto per poter essere più influente per tempi omogenei e di poco interesse
per quelli eterogenei.
In un secondo momento abbiamo considerato i tempi di set-up due o anche tre volte
maggiori rispetto ai tempi di processamento dei job, questo per analizzare il
comportamento del sistema anche nel caso in cui le macchine, per passare da un tipo di
job all’altro, risultano avere un elevato tempo di inattività dovuto alla preparazione.
18
Per non complicare troppo le cose, si è deciso di considerare gli stessi tempi per tutte le
macchine e che, per ogni macchina, il tempo di set-up per passare da una lavorazione ad
un’altra (ad esempio da un job di tipo A ad un job di tipo B) fosse differente dal processo
inverso (cioè da B ad A). Per semplicità possiamo immaginarli rappresentati su una
matrice quadrata che ha come dimensioni quella del numero di job e sulla diagonale
tutti zeri, rappresentante i tempi nulli per il passaggio a due tipologie identiche.
Riassumiamo i profili scelti per le simulazioni: NUMERO DEI JOB (n): • Piccolo: 20 • Grande: 80 NUMERO DELLE MACCHINE (m):
• Piccolo: 3 • Grande : 9 DISTRIBIZIONE JOB SU LOTTI •Piccolo: 20 job distribuiti, con distribuzione Gaussiana ( = , = ), in 4 lotti •Grande: 80 job distribuiti, con distribuzione Gaussiana ( = , = ) in 16 lotti TEMPI DI PROCESSAMENTO • Omogenei , Distribuiti uniformemente nell‘ intervallo (2-10) • Eterogenei, Distribuiti uniformemente nell’ intervallo [2-50) RELEASE DATE • Ravvicinate dipendenti dal numero di job e numero macchina di ogni istanza • Distanti dipendenti dal numero di job e numero macchina di ogni istanza TEMPI SETUP • Distribuiti uniformemente intervallo *1-6] • Distribuiti uniformemente intervallo [20-30] e [50-100]
19
6. Risultati delle esecuzioni
In questo capitolo vengono presentate le tabelle delle simulazioni fatte sulle varie
euristiche implementate. Le tabelle sono state etichettate con dei codici relativi
all’istanza presa in considerazione, e contenenti appunto i risultati in termini numerici
delle esecuzioni che verranno da noi analizzati più in dettaglio nel prossimo capitolo. È
stato possibile ottenere dei risultati significativi grazie alla scelta degli indici di
prestazioni che permettono di cogliere determinate caratteristiche del sistema e di
studiare i vari casi che si presentano nell’applicazione delle euristiche.
6.1 Indici di prestazione
Funzione obiettivo media: Viene calcolato per tutte le euristiche proposte, e non è
altro che la media su n esecuzione del tempo di completamento ,
,che ci
permette di osservare l’efficienza degli algoritmi proposti nella minimizzazione del
makespan:
Miglioramento Euristiche percentuale: Indica il miglioramento in percentuale della
funzione obiettivo attraverso l’applicazione dell’euristica di miglioramento.
Numero Scambi: Questo indice calcola la media del numero di scambi che vengono
fatti dopo aver applicato l’euristica di miglioramento “SCAMBI”. È proporzionale
all’indice miglioramento Euristiche percentuale in quanto all’aumentare degli scambi
diminuisce il e di conseguenza migliora la funzione obiettivo. Questi due indici
relativi agli algoritmi con le rispettive funzioni obiettivo messi in relazione tra di loro
ci permettono di osservare sia il grado di miglioramento dell‘euristica Scambi ma
anche di avere una visione generale della bontà delle soluzioni di partenza e quindi
degli algoritmi.
Numero Job su Macchina più carica/meno carica: indica il numero di job assegnati
alla macchina più/meno carica, in percentuale rispetto al numero totale di job ;serve
a rilevare se il carico di lavoro è stato distribuito in modo equo oppure una macchina
lavora più delle altre.
Valore medio : Questo indice misura il bilanciamento del carico di
lavoro tra le macchine non più in termini di numero di job ma in termine di funzione
obiettivo; più precisamente misura quanto è lo scarto medio tra il e il
delle n esecuzioni. Viene calcolato come
Distanza dal minimo: dopo aver trovato su n esecuzione il valore minimo di
viene calcolata di quanto ogni esecuzione si discosta da questo valore. Questo valore
20
ci permette di osservare di quanto le soluzioni trovate tramite un’euristica si
discostano dal valore migliore ottenuto dall’euristica stessa.
Tempo di esecuzione: è il tempo totale diviso per il numero di esecuzioni (n=50) e
indica la complessità di ogni esecuzione comprendente le tre euristiche e i relativi
miglioramenti. Aumenta proporzionalmente al numero di job ripartiti tra le varie
macchine e l’inefficienza dell’algoritmo di partenza che determina il numero di
scambi applicabile ad esso
6.2 Risultati delle esecuzioni
Qui di seguito viene illustrato il codice che identifica le tabelle e distingue i vari gruppi di
istanze aventi caratteristiche e risultati differenti, come precedentemente illustrato.
Il valore in prima posizione rappresenta il numero di job ( 1=Piccolo 2=Grande).
Il valore in seconda posizione rappresenta il numero di Macchine ( 1=Piccolo
2=Grande).
Il valore in terza posizione indica se i tempi di processamento sono Omogenei (o) o
Eterogenei(e).
Il valore in quarta posizione indica se le release, quando presenti, sono fra loro
distanti(D) o ravvicinate(R).
6.2.1 Offline R=0
21
22
23
6.2.2 Offline R≠0
24
25
26
27
28
29
6.2.3 Online
30
31
32
33
34
6.2.4 Lotti Offline R=0
35
36
6.2.5 Lotti Offline R≠0:
37
38
39
40
41
42
7 Analisi degli output In questo capitolo verranno analizzati i risultati ottenuti dalle simulazioni effettuate
secondo le istanze prescelte e descritte nei capitoli precedenti. Cercheremo di verificare
che questi risultati ottenuti, confrontati fra di loro, rispecchino i risultati attesi e le
aspettative su quanto riguarda l’applicazione delle euristiche .
7.1 Offline R=0
Analisi Istanze Con tempi omogenei
Come è possibile osservare nel grafico del Makespan, l’euristica che si comporta in
modo meno efficiente è l’algoritmo A (MaxMin) che peggiora all’aumentare del numero
di job da schedulare. In realtà l’algoritmo si comporta differentemente da come
avevamo previsto, infatti: la scelta del massimo, non essendo sui tempi di
processamento ma su quelli di completamento, all’aumentare del numero di job
differenti tra loro, incrementa il completamento degli altri job su quella macchina,
andando via via ad aumentare il valore del . Come vedremo, tale euristica non ha
mostrato particolare interesse dal punto di vista della funzione obiettivo, ma nonostante
ciò è stato deciso di analizzare i suoi risultati per mettere in evidenza l’efficacia
11o 12o 21o 22o
A 39 10,8 164,16 43,4
AS 27,88 9,64 104,48 31,84
B 29,3 9,9 105,74 30,68
BS 27,46 9,38 103,72 29,34
C 29,56 12,4 105,82 31,38
CS 27,32 9,52 103,7 28,96
0
20
40
60
80
100
120
140
160
180
Cm
ax
Makespan
43
dell’euristica Scambi che negli altri due algoritmi non è possibile osservare ,in quanto
entrambe presentano un andamento molto efficiente e sembrano avvicinarsi alla
soluzione ottima.
Osserviamo che, con tempi eterogenei, nel caso offline non cambia quasi nulla a parte il
fatto che aumentano i valori del makespan e che la differenza tra l’euristica A prima e
dopo il miglioramento è maggiore per tempi di processamento eterogenei associati ai
job che permettono di ottenere dopo gli scambi, migliori minimizzazioni dei tempi di
completamento; infine assistiamo ad un peggioramento dell’euristica C come era stato
previsto nella descrizione dell’algoritmo stesso.
11e 12e 21e 22e
A 152,26 28,62 663,58 125,06
AS 105,84 26,26 377,6 72,8
B 111,36 28,96 383,68 74,92
BS 103,3 26,66 374,16 68,56
C 112,94 39,92 384,74 84,1
CS 104,06 27,38 374,4 68,46
0
100
200
300
400
500
600
700C
max
Makespan
-20
30
80
130
180
230
280
11o 12o 21o 22o 11e 12e 21e 22e
A-B
A-B
44
Quanto detto all’inizio, viene rilevato dal confronto tra l’algoritmo A e B che sono molto
simili tra loro tranne per il fatto che uno sceglie ad ogni iterazione il minimo dei minimi
tempi di completamento e l’altro i massimi. I due algoritmi tendono ad essere molto
simili nel caso 12e e 12o proprio perché l’algoritmo A(MaxMin) si trova ad avere pochi
job da assegnare a tante macchine, quindi in questo simula maggiormente l’algoritmo
B(MinMin )e si avvicina all’idea dell’algoritmo LPT (che ,soprattutto nel caso di tempi di
processamento eterogenei , trova l’efficienza nel poter schedulare prima i job lunghi e
poi disporre alla fine quelli più corti). Come vediamo il MaxMin si allontana dal MinMin
all’aumentare del numero di job e al diminuire delle macchine (si veda la somiglianza tra
il rapporto 11o/11e e 22o/22e)
L’analisi delle euristiche A-C è molto simile a quello precedente, e segue i casi in cui A è
peggiore o migliore. L’unica cosa che viene messa in risalto dal grafico è il
peggioramento di C nei casi in cui A è maggiormente efficiente, ovvero nei casi 12o e
12e, in cui ci sono molte macchine con pochi job da schedulare. Come era stato previsto
e descritto in precedenza l’algoritmo C si trova in difficoltà in questo caso perché con
pochi job da assegnare ci sarà una maggiore probabilità di avere diverse macchine
scariche e poca scelta tra i processamenti dei job che porterà ad alzare la probabilità di
scegliere per tutti i job dei tempi di processamento relativi alla macchina scarica molto
maggiori rispetto al processamento sulle altre macchine. Vediamo, infatti, nel confronto
tra B e C che quest’ultimo peggiora in proporzione alla differenza dei tempi di
processamento , proprio nei casi in cui ci sono tante macchine, 22 e 12 ,con prevalenza
per quest’ultimo.
-20
30
80
130
180
230
280
11o 12o 21o 22o 11e 12e 21e 22e
A-C
A-C
45
Come detto precedentemente, il miglioramento portato dall’euristica Scambi(S) dipende
molto dal numero di job da scambiare cosi come dall’efficienza dell’algoritmo che dà la
soluzione di partenza. Infatti, come possiamo osservare dai seguenti grafici, il più alto
valore percentuale di miglioramento è associato all’algoritmo meno efficiente, ovvero
MaxMin, soprattutto nei casi in cui i tempi di processamento sono eterogenei. Basta
tornare indietro e osservare come nel caso 22o la soluzioni migliorata non si avvicini
come nel caso 22e alle altre due soluzioni migliorate.
I miglioramenti di B e C invece cambiano molto poco tra tempi omogenei ed eterogenei
visto l’andamento simile del , come se la percentuale di miglioramento non sia
proporzionale alla distanza e alla grandezza dei tempi di processamento.
0
5
10
15
20
11o 12o 21o 22o 11e 12e 21e 22e
C-B
C-B
0,00
20,00
40,00
60,00
80,00
100,00
11
e
11
o
12
e
12
o
21
e
21
o
22
e
22
o
Miglioramento Percentuale Euristica A
Miglioramento Percentuale Euristica A
46
Nell’algoritmo C assistiamo a un maggior miglioramento nei casi in cui l’algoritmo si
rileva peggiore e cioè nei casi in cui ci sono tante macchine e i tempi sono eterogenei
(ricordiamo 12o 12e e 22e) .
La distanza dal minimo ha un andamento altalenante dipendente dal numero di
macchine. Più macchine sono a disposizione e più le soluzioni trovate sono molto vicine
al valor medio del tempo di completamento, mentre tendono ad all’allontanarsi
all’aumentare dei job e all’aumentare dell’eterogeneità dei tempi di processamento,
0
20
40
60
80
100
11e 11o 12e 12o 21e 21o 22e 22o
Miglioramento Percentuale Euristica B
Miglioramento Percentuale Euristica B
0
20
40
60
80
100
11e 11o 12e 12o 21e 21o 22e 22o
Miglioramento Percentuale Euristica C
Miglioramento Percentuale Euristica C
0
50
100
150
11o 12o 21o 22o 11e 12e 21e 22e
Distanza media dal minimo Cmax
A
B
C
47
Per quanto riguarda il bilanciamento del carico di lavoro, in termini di tempo di
completamento tra le varie macchine, dai seguenti grafici possiamo affermare che
quella che bilancia meglio, è l’euristica peggiore MaxMin. L’unico particolare
peggioramento dopo gli scambi , lo osserviamo proprio nel caso in cui A migliorato (AS)
non si avvicina alle soluzioni BS e CS, caso 22o, come se per raggiungere ancora un
tempo di completamento minore sia necessario uno spostamento di un job da una
macchina a un’altra, cosa che non permette l’euristica scambi.
Molto efficiente è il bilanciamento portato dagli scambi per quanto riguarda il caso 21o
e 21e; infatti tra la macchina più carica e quella meno carica come differenza non c’è
neanche il tempo di processamento di un job. Era anche prevedibile visto che la quantità
di job permette una maggior possibilità di scambi , ma allo stesso tempo la piccola
0
20
40
60
80
100
11o 12o 21o 22o 11e 12e 21e 22e
Distanza media dal minimo Cmax
AS
BS
CS
2 4 6 8 10
11o
12o
21o
22o
Cmax-Cmin
CS
C
BS
B
AS
A
2 12 22 32 42
11e
12e
21e
22e
Cmax-Cmin
CS
C
BS
B
AS
A
48
quantità di macchine facilita il bilanciamento del tempo di completamento tra la
macchina più carica e quella meno. Di solito l’euristiche B e C vanno di pari passo nel
bilanciamento iniziale , l’unico piccolo distacco lo assistiamo da parte di C in 12o e 12e
ma è naturale dato il grande numero di macchine in confronto all’esiguo numero di job
da assegnare a queste.
Osservando infine il grafico del numero di job assegnati alla macchina più carica,
possiamo affermare che il numero di job viene distribuito equamente .( 35%dei job per
3 macchine e 10/15% per 9 macchine)
0
5
10
15
20
25
30
35
40
11o 11e 12o 12e 21o 21e 22o 22e
Numero Job Su Macchina Critica in %
A
AS
B
BS
C
CS
49
7.2 Offline R≠0
Abbiamo deciso di mostrare solo queste due euristiche dato che l’algoritmo A MaxMin,
per quanto spiegato prima, è per noi privo di senso nel caso di release diverse da zero .
L’uguaglianza degli andamenti per release distanti e vicine, mostra che le euristiche non
sono influenzate dall’arrivo dei job ma che comunque si assiste ad un incremento del
. Questo è dovuto al fatto che la presenza di più job vincolati da tempi di rilascio
distanti rende meno influente, dal punto di vista della minimizzazione del , la
conoscenza che si ha nel caso offline, e aumenta la probabilità di avere tempi morti
mentre, per release ravvicinate, sfruttando la conoscenza, ci si avvicina ai risultati del
caso offline release uguale a zero.
11oR 12oR 21oR 22oR
B 30,68 10,48 107,16 31,32
BS 29,2 10,06 105,48 30,52
C 30,94 12,74 107,44 32,26
CS 29,26 11,36 105,78 31,12
0
20
40
60
80
100
120
Tito
lo a
sse
Makespan medio
11oD 12oD 21oD 22oD
B 33,66 11,46 116,38 35,44
BS 32,5 11,34 114,8 34,92
C 33,68 13,18 116,74 37,44
CS 32,5 12,58 114,32 36,22
0
20
40
60
80
100
120
Tito
lo a
sse
Makespan medio
50
I miglioramenti illustrati nel grafico precedente, mostrano come ancora una volta
l’euristica C si comporti in maniera peggiore rispetto a quella B e come, il miglioramento
sia maggiore in percentuale per release ravvicinate. Osserviamo come per l’euristica B al
contrario, nei casi in cui ci sono pochi job, il miglioramento sia maggiore per release
distanti.
0,00%
2,00%
4,00%
6,00%
8,00%
10,00%
Miglioramenti %
Miglioramento Percentuale Euristica B
Miglioramento Percentuale Euristica C
0
2
4
6
8
10
12
11oR 12oR 21oR 22oR 11oD 12oD 21oD 22oD
Tito
lo a
sse
Distanza dal minimo
B
C
51
Per Tempi eterogenei:
Osservando i grafici del makespan per tempi eterogenei possiamo affermare che anche
in questo caso l’algoritmo B è il migliore dal punto di vista della funzione obiettivo.
Parlando dell’euristica C come al solito assistiamo a un peggioramento nei casi in cui ci
sono molte macchine, ma quello che notiamo di nuovo è un inaspettato distacco
dall’euristica B nel caso in cui i rilasci sono distanti tra loro, anche per gli altri due casi 11
e 21. Analizzando il fatto che nell’algoritmo si considerano a ogni iterazione i tempi di
processamento della macchina meno carica e per i job con rilascio maggiore del
makespan l’aggiunta dell’idle-time, probabilmente nel momento in cui ci sono rilasci
distanti tra loro aumenta l’incidenza degli idle-time che si aggiungono ai tempi di
processamento e riduce, quindi, proprio quell’efficienza dell’ algoritmo C che era per
tanti job per il caso offline.
11eR 12eR 21eR 22eR
B 113,28 31,4 387,4 85,24
BS 107,92 30,68 379,78 82,14
C 117,42 44,52 390,78 95,32
CS 110,72 39 383,16 89,46
0
50
100
150
200
250
300
350
400
450
Cm
ax
Makespan
11eD 12eD 21eD 22eD
B 130,4 42,6 442,82 132,54
BS 126,56 42,2 433,56 132
C 139,8 56,26 460,7 148,52
CS 133,18 54,14 449,22 144,32
0
50
100
150
200
250
300
350
400
450
500
Cm
ax
Makespan
52
I miglioramenti sono chiaramente di minor entità per il fatto che non sempre due job,
anche se vanno a migliorare il , possono essere scambiati proprio perché vincolati
da un loro rilascio noto a priori. Quindi alla fine quello che determina un miglior risultato
dello scambio è un peggioramento delle euristiche e i vincoli legati ai rilasci dei singoli
job; basta osservare il distacco che ha in percentuale l’euristica C in 12eR , nel quale
sappiamo peggiorare e avere delle release ravvicinate(ovviamente la percentuale
dipende anche quantitativamente dal completamento dell’istanza presa in
considerazione e non dal numero di scambi come possiamo osservare nel caso 21eD). Di
solito il miglioramento di B è sempre minore, forse per la sua efficienza , tranne nel caso
21eR. Vediamo che ciò dipende dal fatto che in quest’istanza il numero di scambi per C
invece che aumentare per release ravvicinate diminuisce, probabilmente per ragioni di
efficienza nel calcolare la soluzione di partenza.
0,00%
2,00%
4,00%
6,00%
8,00%
10,00%
Miglioramenti %
Miglioramento Percentuale Euristica B
Miglioramento Percentuale Euristica C
11eD 11eR 12eD 12eR 21eD 21eR 22eD 22eR
0,78
1,56
0,16 0,44
4,344,74
0,16
2,32
1,281,76
0,44
1,34
5,74
4,16
0,84
3,28
Numero medio Scambi
B->BS C->CS
53
A differenza dei tempi omogenei assistiamo a un incremento netto delle distanza del
valore medio dal minimo trovato, legato alla probabilità di poter avere tempi con valori
piccoli e ma allo stesso tempo con valori grandi .Inoltre l’euristica C si distacca
maggiormente per tutte le istanze dovuto al suo peggioramento per tempi eterogenei.
Dal confronto dei grafici della differenza del completamento tra la macchina critica e
quella meno carica, assistiamo comunque ad un miglior risultato generale per rilasci
ravvicinati che, come detto molte volte, permettono sia una maggior quantità di job su
cui applicare l’algoritmo sia meno vincoli per migliorare la soluzione trovata.
0
10
20
30
40
50
60
70
11eD 12eD 21eD 22eD 11eR 12eR 21eR 22eR
B
C
0 10 20 30 40 50
11eD
12eD
21eD
22eD
Cmax-Cmin
CS
C
BS
B
0 10 20 30 40 50
11eR
12eR
21eR
22eR
Cmax-Cmin
CS
C
BS
B
54
7.3 Online
Per Tempi Omogenei:
Anche per quanto riguarda l’online l’euristica peggiore è A(MaxMin) che come
analizzato precedentemente migliora e si avvicina alle altre euristiche quando il
raffronto iterativo è tra pochi job avvicinandosi alla logica del B(MinMin). In questi
grafici infatti osserviamo l’avvicinarsi alle altre due euristiche per release distanti nei casi
11oD e 22oD(che sappiamo avere un rapporto risorse/macchine molto simile), proprio
perché meno job sono in coda , minore è l’incremento sui tempi di completamento
portato da MaxMin.
Facendo un confronto tra il comportamento delle euristiche per rilasci ravvicinati e
distanti non notiamo grandi differenze a parte un lievemente maggiore nelle
soluzioni trovate dall’euristiche B e C per rilasci distanti, dovuto chiaramente alla minore
numerosità di job in coda rispetto ai rilasci ravvicinati e la conseguente perdita di
efficienza nell’applicazione delle euristiche e alla maggiore incidenza dei l’ idle-time.
11oR 12oR 21oR 22oR
A 38,44 10,58 165,48 44,06
AS 37,62 10,36 163,2 43,16
B 29,84 10,34 106,92 31,16
BS 29,1 9,92 106,92 30,5
C 30,54 12,92 107,5 32,02
CS 28,76 10,46 105,82 29,96
020406080
100120140160180
Makespan Medio
11oD 12oD 21oD 22oD
A 37,46 11,52 166,72 41,06
AS 36,88 11,44 165,7 40,58
B 33,48 11,6 112,48 35,48
BS 33,28 11,6 110,76 35,14
C 35,26 14,64 114,04 38,02
CS 33,88 12,94 112,48 35,86
0
20
40
60
80
100
120
140
160
180
Makespan Medio
55
In generale ,come è possibile notare dai grafici, i miglioramenti sono bassi , quasi tutti
sotto il 10% tranne per il caso 21, e l’euristica scambi ha più influenza in percentuale,
proporzionalmente al , nel caso in cui i rilasci sono ravvicinati. Evidentemente nel
caso 21 con release vicine quello che è più efficiente è l’algoritmo di partenza essendo
applicabile a più job in coda.
Per tempi eterogenei:
0,00%
5,00%
10,00%
15,00%
20,00%
11
oD
11
oR
12
oD
12
oR
21
oD
21
oR
22
oD
22
oR
Miglioramento Percentuale Euristica C
Miglioramento Percentuale Euristica C
0,00%
1,00%
2,00%
3,00%
4,00%
11
oD
11
oR
12
oD
12
oR
21
oD
21
oR
22
oD
22
oR
Miglioramento Percentuale Euristica B
Miglioramento Percentuale …
21eR 22eR
A 655,8 124,16
AS 653,14 123,34
B 385,21 81,14
BS 390,92 81,06
C 394,12 102,66
CS 384,6 88,5
0
100
200
300
400
500
600
700
Makespan Medio
21eD 22eD
A 656,72 130,86
AS 650,4 130,86
B 410,22 131,28
BS 406,4 131,26
C 430,18 157,22
CS 419,62 151,7
0
100
200
300
400
500
600
700
Makespan Medio
56
Per le release distanti notiamo che confrontando i casi con lo stesso numero di
macchine ma con diversa numerosità di job da 20 a 4 volte di più, 80,troviamo un
circa 4 volte più grande . Infatti per release distanti è come ripetere ogni volta il caso
offline con release uguale a zero. Per release ravvicinate invece all’avanzare della
numerosità della coda ci avviciniamo al caso offline con release diverse da zero perché la
coda ci dà più informazione.
Il caso che ne dimostra l’inefficacia, è proprio l’euristica MaxMin che non ha un
miglioramento come nella casistica offline, ma il suo miglioramento è limitato
esattamente come in tutte le altre euristiche. Interessante questo caso perché oltre a
mostrare i miglioramenti minimi denota un peggioramento di questa euristica nel caso
21eR
Come avevamo previsto lo scambio nel caso online non è una garanzia di efficienza nel
migliorare la soluzione, e questo perché lo scambio non avviene alla fine su tutti i job,
non avendo come nel caso offline piena conoscenza di questi e delle loro release , ma
avviene sui job schedulati in coda a ogni rilascio di nuovi job. Quindi il miglioramento
parziale non assicura il miglioramento finale, e di conseguenza la scelta di applicare o
meno gli scambi in modalità online deve essere fatta prima con la consapevolezza che
non abbiamo la certezza che migliori la soluzione, anche perché la piccola percentuale
positiva può essere nient’altro che il risultato medio dei casi positivi e negativi.
Sicuramente sappiamo che i miglioramenti sono più influenti per release Ravvicinate, in
quanto ogni iterazione ha una maggior quantità di job rilasciati e presenti in coda, che
permette più scambi “momentanei”.
-1,50%
-1,00%
-0,50%
0,00%
0,50%
1,00%
1,50%
2,00%
Miglioramento Percentuale Euristica B
Miglioramento Percentuale Euristica B
57
Il confronto tra questi due grafici ,confermando la tesi appena descritta, mostra come ci
sia una disparità tra il numero di scambi e il miglioramento per l’euristica C , che a ogni
release schedula e scambia i job in coda.
7.4 Lotti R=0
7.4.1 Tempi di setup molto piccoli
Prima di passare all’analisi, ricordiamo che il numero di job totale è stato ripartito in un
numero di lotti secondo una media ed una varianza prefissata. Questo ha portato, nel
caso di numerosità di job bassa, ad avere pochi lotti da permettere un’analisi con
risultati interessanti.
0,00%
5,00%
10,00%
15,00%
21eD 21eR 22eD 22eR
Miglioramento Percentuale Euristica C
Miglioramento Percentuale Euristica C
0
50
100
150
200
250
11
eD
11
eR
12
eD
12
eR
21
eD
21
eR
22
eD
22
eR
Numero Scambi C
Numero Scambi C
58
Sicuramente confrontando i risultati del makespan per lotti, rispetto a quelli per job
singoli, notiamo dei valori un po’ più alti proprio per la presenza dei tempi di set-up nel
passaggio da un lotto di un tipo a quello di un altro. L’incidenza è sicuramente maggiore
dal punto di vista percentuale per tempi omogenei in quanto i set-up si avvicinano
molto ai tempi di processamento e per le istanza con numerosità di job alto. Infatti
proprio alla quantità maggiore di job, come appena detto, corrisponde un numero di
lotti superiore e quindi maggiore possibilità di dover calcolare i tempi di set-up .
11o 12o 21o 22o
A 53,02 15,76 251,58 74,72
AS 38,22 12,24 147,26 43,76
B 36,36 12,7 128,04 41,18
BS 34,72 11,5 123,72 38,34
C 38,6 16,94 129,4 44,48
CS 35,32 11,62 124,98 38,1
0
50
100
150
200
250
300C
max
Makespan medio
11e 12e 21e 22e
A 147,66 39,2 692,5 158,14
AS 125,94 36,56 445,68 100,88
B 119,68 35,72 410 93,1
BS 114,74 32,64 396,28 84,76
C 126,2 57,18 414,2 109,14
CS 115,78 34,2 397,82 82,84
0
100
200
300
400
500
600
700
800
Cm
ax
Makespan medio
0,00
10,00
20,00
30,00
40,00
50,00
60,00
70,00
11e 11o 12e 12o 21e 21o 22e 22o
Miglioramenti %
Miglioramento Percentuale Euristica A
Miglioramento Percentuale Euristica B
Miglioramento Percentuale Euristica C
59
I miglioramenti, come spiegato nell’euritica scambi, nella gestione dei lotti prende in
considerazioni sequenze di job uguali e cerca di scambiarli con altre sequenze in altre
macchine, con lo scopo di ricompattare i lotti e risparmiare sui tempi di set-up o
processare sequenze di job in un’altra macchine in un tempo minore. I risultati
dimostrano che tale criterio è abbastanza efficiente. Il miglioramento di A nel caso
21e/o, minore di quello calcolato nel caso offline per job singoli, mette in evidenza una
minor efficia nel considerare blocchi invece di job singoli.
Il fatto che i tempi di Set-up hanno maggiore influenza nel caso omogeneo rispetto al
caso eterogeno influenza in percentuale sia il sia il numero di scambi: si può
vedere dal grafico del numero degli scambi, come i casi Omogenei presentino un
numero di scambi sempre maggiori rispetto al caso eterogeneo.
Questi due grafici sui carichi mostrano come nei lotti la questione si complica per il
bilanciamento quando ci sono tante macchine. Per i lotti chiaramente non c’è un
bilanciamento cosi omogeneo e, molto spesso, proprio il miglioramento tende a
peggiorare il carico di lavoro sulle macchine, che magari tendono, in termini di
minimizzazione del tempo di completamento, a scegliere di schedulare quei pochi lotti
in macchine per cui il processamento è molto minore rispetto ad altre macchine. E
infatti proprio per pochi lotti e tante macchine 12o /12e c’è un grosso peggioramento
che potrebbe dipendere dal non sfruttare tutte le macchine.
0
20
40
60
80
100
120
11e 11o 12e 12o 21e 21o 22e 22o
Numero Scambi
AS
BS
CS
60
Proponiamo qui di seguito il grafico del numero di job assegnati alla macchina più carica.
Osserviamo che , rispetto a quello per job singoli , per i lotti la distribuzione è meno
omogenea soprattutto nel caso 12e.
0 2 4 6 8 10 12
11o
12o
21o
22o
Cmax-Cmin
CS
C
BS
B
AS
A
0 10 20 30 40 50
11e
12e
21e
22e
Cmax-Cmin
CS
C
BS
B
AS
A
0
5
10
15
20
25
30
35
40
11e 12e 21e 22e 11o 12o 21o 22o
Numero Job su macchina critica in %
A
AS
B
BS
C
CS
61
7.4.2 Tempi di setup molto maggiori rispetto ai tempi di processamento
omogenei ed eterogenei dei job
Tempi eterogenei e omogenei casi con numerosità di job grande con set-up 20-30
Per studiare come potesse cambiare lo scheduling dei lotti in relazione ai dei tempi di
lavorazione abbastanza grandi, è stato scelto di analizzare il caso con il profilo di
numero di lotti grande(21 e 22) con tempi di set-up 2/3 volte l’intervallo dei tempi di
processamento omogenei ma simili ai tempi di lavorazione nel caso di tempi eterogenei.
Dal risultato emerge come sia decisivo per l’incremento dei tempi di completamento.
Vediamo attraverso A come ,anche se il metodo non permetta di fare scambi su singoli
job nel caso dei lotti , il tentativo di ricompattare dei lotti o spostate intere porzioni di
esse su un'altra macchina sia comunque molto efficiente dal punto di vista migliorativo.
62
Come ci aspettavamo la differenza di carico, in termini di Cmax, è molto più grande dato
il fatto che con tempi set-up più alti è conveniente processare l’intero lotto su una sola
macchina piuttosto che suddividere la lavorazione in più macchine e quindi aumentare
il numero di set-up tra le varie lavorazioni. La differenza diciamo che è quindi legata al
tempo di processamento e al numero dei job di cui è composto il lotto.
Il dislivello del carico numerico dei job sulla macchina più carica ,come possiamo
osservare, non è cosi evidente come nel caso del tempo di completamento, ma questo è
probabilmente dovuto alla scelta della distribuzione gaussiana che ha permesso di
distribuire secondo una media ben equilibrata il numero di job per ogni lotto.
Tempi eterogenei, casi con numerosità di job grande e con set-up 50-100
Qui di seguito invece è stato estremizzato il caso scegliendo per in tempi di set-up un
intervallo di tempo fino a 2 volte l’intervallo di tempo per tempi eterogenei di
processamento.
63
7.5 Lotti Offline R≠0
In questo caso l’analisi si è concentrata solamente sulle euristiche B e C e sui loro
rispettivi miglioramenti. Come spiegato in precedenza infatti l’euristica A perde
significato per release diverse da zero. Abbiamo inoltre deciso di porre la nostra
attenzione solamente nelle istanze che presentano 80 job. Questo perché, come detto
in precedenza, la presenza di pochi lotti determina anche la presenza di poche release e
quindi a casi con risultati non particolarmente interessanti .
21oR 22oR
B 134,14 50,36
BS 127,6 47,08
C 139,2 57,48
CS 130,64 54,28
0
20
40
60
80
100
120
140
160
Cm
ax
Makespan
21oD 22oD
B 157,62 58,96
BS 149,1 56,42
C 162,16 67,04
CS 150,54 62,52
0
20
40
60
80
100
120
140
160
180
Cm
ax
Makespan
64
Anche qui andamento simile con risultati maggiori rispetto all’offline release zero per la
presenza di tempi morti. Essi condizionano come sappiamo anche i miglioramenti
diminuendo la possibilità e quindi il numero di scambi.
Osservando i grafici sembra strano come per release distanti, nonostante sappiamo che
la soluzione di partenza sia peggiore rispetto a quella per release ravvicinate, in realtà ci
siano cosi tanti scambi data appunto la quantità di vincoli per i lotti. In realtà, se
analizziamo il miglioramento scambi gestito per lotti e cioè il tentativo di ricompattare i
lotti divisi con l’euristica di partenza per minimizzare il , ci accorgiamo che i vincoli
portati dai rilasci in questo caso sono meno incidenti negli scambi rispetto a prima, dato
che ogni lotto ha un'unica release e, questo, può far diminuire gli idle time creati da lotti
scompattati.
21oD 21oR 22oD 22oR
4,76% 4,24% 3,88%
5,84%6,60%
5,62% 6,06%5,00%
MIiglioramento %
Miglioramento B Miglioramento C
0
2
4
6
8
10
12
14
16
21oD 21oR 22oD 22oR
Numero Scambi
BS
CS
65
Dai grafici sembra non peggiorare di molto l’algoritmo C come accadeva per job singoli,
e in generale i grafici del makespan sia per tempi omogenei che per quelli eterogenei,
sembrano non mostrare una diversità degli andamenti delle due euristiche in base alla
distanza dei tempi di rilascio dei job. Questo probabilmente è dovuto al fatto che
parlando di lotti ci sono meno release che spesso non incidono sul processamento dei
lotti, e quindi un’ euristica, che tende il più delle volte a processare tutti i job di un lotto
(perchè contenente job uguali) , dà come soluzione la stessa incrementata dalla
differenza dell’idle-time creato dai rispettivi rilasci.
21eR 22eR
B 446,38 117,8
BS 436,12 113,12
C 452,44 130,12
CS 437,58 121,84
050
100150200250300350400450500
Tito
lo a
sse
Makespan medio
21eD 22eD
B 471,78 147,88
BS 450,08 144,96
C 479,32 168,32
CS 459,92 160,32
0
100
200
300
400
500
600
Tito
lo a
sse
Makespan medio
21eD 21eR 22eD 22eR
4,00%
2,02%1,66%
3,54%3,68%3,20%
4,32%
5,72%
Miglioramenti %
Miglioramenti Euristica B Miglioramenti Euristica C
66
Proprio questo squilibrio del carico tra le macchine mostra secondo noi quanto in realtà
l’idea di scambiare no job singoli ma sequenze di job uguali per tempi eterogenei ,dove i
set-up non contano poi cosi tanto sia poco efficiente ,e quel poco vada a discapito del
bilanciamento tra le varie macchine anche se per i lotti è quasi normale.
7.6 Lotti Online:
Per quanto riguarda il caso Lotti Online si è deciso di non fare un’analisi approfondita
come per i casi precedenti. Questo perché le euristiche presentate tendono alla lunga ad
arrivare a comportamenti simili a quelli già illustrati per la casistica online. Questo
soprattutto in caso di release date ravvicinate poiché il numero di job in coda tende ad
aumentare. Nel caso invece di Release date distanti la possibilità di scambi scende
vertiginosamente. Questo succede poiché il tempo set-up insieme alla presenza delle
release date rappresenta un ulteriore vincolo alla presenza di scambi. Per queste
osservazioni si è quindi deciso di non analizzare in maniera approfondita questa
casistica.
0
1
2
3
4
5
6
21eD 21eR 22eD 22eR
Numero Scambi
BS
CS
0 100 200
21eD
22eD
Cmax-Cmin
CS
C
BS
B
0 20 40 60 80
21eR
22eR
Cmax-Cmin
CS
C
BS
B
67
8 Conclusioni
8.1 Analisi Riassuntiva
Il lavoro di questa tesina è stato quello di analizzare i risultati di scheduling ottenuti da
un modello da noi creato per la studio di macchine parallele. Sono state implementate
tre euristiche: MinMin(B), MaxMin(A) e Assegnamento Macchina Meno Carica(C),
secondo la funzione obiettivo di minimizzare il tempo di completamento della macchina
più carica. Queste euristiche sono state simulate su più classi di istanza per mostrarne il
comportamento in risposta a differenti caratteristiche del sistema, importanti per il
nostro studio e che sappiamo potersi riproporre nella realtà.
Sono state quindi generate 64 istanze secondo una precisa analisi degli input
,riguardante parametri come il numero di macchine e di job/lotti ,e variabili aleatorie
come i tempi di processamento, di rilascio e ,nel caso dei lotti, di set-up tra due
lavorazioni; per ogni istanza inoltre sono stati effettuati 50 “run” in modo tale da avere
una quantità di dati tale da permetterci di fare un’analisi statistica per ogni tipologia di
istanza. Abbiamo quindi predefinito degli indici di prestazione, fondamentali per il
raccoglimento e la registrazione dei dati, come il makespan medio, il numero di scambi,
il miglioramento % ,la distanza dal minimo ecc… A partire dalle soluzione trovate da
queste tre euristiche abbiamo implementato una nuova euristica basata sulla ricerca
locale,” Scambi(S)”, in grado di migliorare la soluzione di partenza facendo degli scambi
tra job(o porzioni di job dello stesso lotto) di diverse macchine. Infine dopo aver raccolto
tutti i dati è stata fatta l’analisi dei risultati ottenuti per le diverse casistiche (offline e
online) dalle quali abbiamo ottenuto le seguenti principali osservazioni:
- Osservando l’analisi da noi effettuata e le seguenti tabelle riassuntive , non si può non
notare che (B)MinMin è l’euristica che ottiene i risultati migliori nella quasi totalità delle
nostre istanze
OFFLINE R=0
ISTANZA BEST EURISTIC
11e B
12e A
21e B
22e B
11o B
12o B
21o B
22o B
68
OFFLINE R ≠ 0 TEMPI PROCESSAMENTO OMOGENEI1
ISTANZA BEST EURISTIC
11oR B
12oR B
21oR B
22oR B
11oD B
12oD B
21oD B
22oD B
OFFLINE R ≠ 0 TEMPI PROCESSAMENTO ETEROGENEI2
ISTANZA BEST EURISTIC
11eR B
12eR B
21eR B
22eR B
11eD B
12eD B
21eD C
22eD B
ONLINE TEMPI OMOGENEI
ISTANZA BEST EURISTIC
11oR B
12oR B
21oR B
22oR B
11oD B
12oD B
21oD B
22oD B
1 Vengono considerate solamente le euristiche B e C
2 vedi nota 1
69
ONLINE TEMPI ETEROGENEI3
ISTANZA BEST EURISTIC
21eR B
22eR B
21eD B
22eD B
LOTTI R = 0;
ISTANZA BEST EURISTIC
11e B
12e B
21e B
22e B
11o B
12o B
21o B
22o B
LOTTI R ≠ 04
ISTANZA BEST EURISTIC
21eR B
22eR B
21eD B
22eD B
21oR B
22oR B
21oD B
22oD B
-C’è altresì da sottolineare come l’euristica C (Assegnamento Macchina Meno Carica)
non sia meno efficiente dell’euristica B per funzione obiettivo. Infatti come abbiamo
visto nell’analisi fatta nei capitoli precedenti, le distanze fra i risultati delle due
euristiche in molte delle nostre istanze discostano di pochi punti percentuali,
aumentando maggiormente nel caso in cui sono presenti pochi job da assegnare; infatti
in quest’ultimo caso si ha una maggiore probabilità di avere diverse macchine scariche e
poca scelta tra i processamenti dei job, alzando dunque la probabilità di scegliere per
3 vedere 7.3 per l’analisi
4 Considerate solo l’euristiche B e C e solo i casi con 80 Job per aver risultati interessanti da analizzare
70
tali job dei tempi di processamento relativi alla macchina scarica molto maggiori rispetto
al processamento sulle altre macchine.
-L’euristica A (MaxMin) in generale non ha mostrato dei buoni risultati soprattutto nei
casi in cui la numerosità dei job era di gran lunga maggiore rispetto alla disponibilità
delle macchine. Ha mostrato un comportamento molto simile all’algoritmo B nei casi in
cui si è trovato a schedulare pochi job su tante macchine (12), avvicinandosi cosi
all’idea dell’algoritmo LPT per il quale era stato concepito (che ,soprattutto nel caso di
tempi di processamento eterogenei , trova l’efficienza nel poter schedulare prima i job
lunghi e poi disporre alla fine quelli più corti).Ha comunque permesso di mostrare la
bontà dell’euristica S (Scambi) con dei miglioramenti che in alcuni casi hanno sfiorato il
30% ed un numero di scambi superiori a 150.
-Molto interessante è stata la simulazione degli scambi nelle classi di istanze “online”
poiché fare scambi online non è una garanzia di efficienza nel migliorare la soluzione,
proprio perché lo scambio non avviene alla fine su tutti i job, e di conseguenza
otteniamo dei miglioramenti parziali che non assicurano il miglioramento finale.
-Di impatto è stato vedere come la lavorazione dei lotti,e quindi decidere se lavorare
tutto il lotto o suddividerlo su più macchine perche in grado di abbassare il tempo di
completamento, sia dipendente dalla grandezza dei tempi di set-up delle macchine.
Un ulteriore considerazione che possiamo fare è quella sui tempi di esecuzione di ogni
istanza. Ricordando che abbiamo calcolato i tempi di esecuzione come tempo totale
diviso per il numero di esecuzioni (n=50) e che dipende dal numero di scambi effettuati
e quindi dall’efficienza della soluzione di partenza, i tempi di esecuzione da noi calcolati
risultano molti bassi. Eccezion fatta per la casistica on-line dove, vista la situazione già
spiegata in precedenza, ci siamo trovati di fronte ad un gran numero di scambi (anche
più di 150 per l’euristica C) che ha fatto aumentare notevolmente il tempo di esecuzione
rispetto alle altre casistiche ma restando in tempi comunque ottimi. Oltre a questo c’è
da osservare che le casistiche 21 e 22 sono sempre le peggiori in termini di tempi di
esecuzione. Questo è proprio quello che ci aspettavamo visto il gran numero di job e
quindi la maggior possibilità di scambi da effettuare.
8.2 Possibili Miglioramenti Futuri
Per migliorare il nostro lavoro, secondo i nostro punto di vista, è fondamentale porre
l’attenzione soprattutto su possibili nuove euristiche di miglioramento delle soluzioni
ottenute con le tre euristiche da noi implementate. Questo perché è importante
71
apportare dei miglioramenti alle soluzioni di euristiche che sappiamo in generale
comportarsi bene in dei casi e meno bene in altri.
Un’euristica interessante da implementare potrebbe essere sicuramente una in grado di
spostare un singolo job da una macchina a un’altra senza dover coinvolgere un altro job
sperando che si possa colmare un deficit di carico tra le macchine oppure andare ad
occupare dei tempi morti presenti nelle macchine (come nel caso di job schedulati
offline con release diverse da zero). Sarebbe inoltre molto interessante confrontare poi i
risultati di questa nuova euristica di miglioramento con quella da noi implementata
anche se, per quanto riguarda il bilanciamento del carico in termini di completamento,
abbiamo visto come per i job singolo non ci sia una grande disparità tra le macchina più
carica e quella meno. Quindi potendo prevedere il comportamento non ci aspettiamo
una eguale capacità migliorativa
