Metodi e Modelli per la Simulazione

Transcript

1 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 Definizione del problema di Scheduling su macchina parallele Scheduling su macchine parallele Formulazione PLI Caratteristiche del Sistema Descrizione delle Euristiche Euristica Min-Min(B) Euristica Max-Min(A) Euristica Assegnazione macchina meno carica(c) Euristica di Miglioramento: Scambi (S) Scelta degli input per le simulazioni Risultati delle esecuzioni Indici di prestazione Risultati esecuzioni Offline R= Offline R Online Lotti R= Lotti R Analisi degli Output Offline R= Offline R Online Lotti R= Tempi di setup molto piccoli Tempi di setup molto maggiori rispetto ai tempi di processamento Lotti Offline R Lotti Online Conclusioni

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. 3

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. 4

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). 5

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 = =,,, 6

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 7

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 8

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. 9

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 idletime 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. 10

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 11

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. 12

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. 13

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 14

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. 15

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 16

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. 17

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 ( =, Grande: 80 job distribuiti, con distribuzione Gaussiana ( =, = ), in 4 lotti = ) 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] 18

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 19

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) Offline R=0 20

21 21

22 22

23 6.2.2 Offline R 0 23

24 24

25 25

26 26

27 27

28 28

29 6.2.3 Online 29

30 30

31 31

32 32

33 33

34 6.2.4 Lotti Offline R=0 34

35 35

36 6.2.5 Lotti Offline R 0: 36

37 37

38 38

39 39

40 40

41 41

42 Cmax 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 Makespan o 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 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 42

43 Cmax 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. 700 Makespan e 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 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. 280 A-B A-B o 12o 21o 22o 11e 12e 21e 22e 43

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) 280 A-C A-C o 12o 21o 22o 11e 12e 21e 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. 44

45 11e 11o 12e 12o 21e 21o 22e 22o 20 C-B C-B 0 11o 12o 21o 22o 11e 12e 21e 22e 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. Miglioramento Percentuale Euristica A 100,00 80,00 60,00 40,00 20,00 0,00 Miglioramento Percentuale Euristica A 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. 45

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) Miglioramento Percentuale Euristica B 0 11e 11o 12e 12o 21e 21o 22e 22o Miglioramento Percentuale Euristica B Miglioramento Percentuale Euristica C 0 11e 11o 12e 12o 21e 21o 22e 22o Miglioramento Percentuale Euristica C 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, Distanza media dal minimo Cmax o 12o 21o 22o 11e 12e 21e 22e A B C 46

47 Distanza media dal minimo Cmax AS BS CS 0 11o 12o 21o 22o 11e 12e 21e 22e Cmax-Cmin Cmax-Cmin 22o 21o 12o 11o CS C BS B AS A 22e 21e 12e 11e CS C BS B AS A 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 47

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) Numero Job Su Macchina Critica in % o 11e 12o 12e 21o 21e 22o 22e A AS B BS C CS 48

49 Titolo asse Titolo asse 7.2 Offline R Makespan medio 120 Makespan medio oR 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, oD 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 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. 49

50 Titolo asse Miglioramenti % 10,00% 8,00% 6,00% 4,00% 2,00% Miglioramento Percentuale Euristica B Miglioramento Percentuale Euristica C 0,00% 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 Distanza dal minimo 11oR 12oR 21oR 22oR 11oD 12oD 21oD 22oD B C 50

51 Cmax Cmax Per Tempi eterogenei: Makespan eR 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, ,16 89,46 Makespan eD 12eD 21eD 22eD B 130,4 42,6 442,82 132,54 BS 126,56 42,2 433, C 139,8 56,26 460,7 148,52 CS 133,18 54,14 449,22 144,32 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. 51

52 Miglioramenti % 10,00% 8,00% 6,00% 4,00% 2,00% Miglioramento Percentuale Euristica B Miglioramento Percentuale Euristica C 0,00% 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. Numero medio Scambi B->BS C->CS 5,74 1,28 0,78 1,56 1,76 0,16 0,44 0,44 1,34 4,34 4,74 4,16 0,84 0,16 2,32 3,28 11eD 11eR 12eD 12eR 21eD 21eR 22eD 22eR 52

53 eD 12eD 21eD 22eD 11eR 12eR 21eR 22eR B C 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. 22eD Cmax-Cmin 21eD 12eD 11eD CS C BS B 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. 22eR Cmax-Cmin 21eR 12eR 11eR CS C BS B

54 7.3 Online Per Tempi Omogenei: Makespan Medio 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, 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 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. 54

55 11oD 11oR 12oD 12oR 21oD 21oR 22oD 22oR 11oD 11oR 12oD 12oR 21oD 21oR 22oD 22oR 20,00% 15,00% 10,00% 5,00% 0,00% Miglioramento Percentuale Euristica C Migliorame nto Percentual e Euristica C 4,00% 3,00% 2,00% 1,00% 0,00% Miglioramento Percentuale Euristica B Migliora mento Percentu ale 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: Makespan Medio eR 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 Makespan Medio eD 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 55

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 2,00% 1,50% 1,00% Miglioramento Percentuale Euristica B 0,50% 0,00% -0,50% -1,00% -1,50% Miglioramento Percentuale Euristica B 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. 56

57 11eD 11eR 12eD 12eR 21eD 21eR 22eD 22eR 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. Miglioramento Percentuale Euristica C 15,00% 10,00% 5,00% 0,00% 21eD 21eR 22eD 22eR Miglioramento Percentuale Euristica C Numero Scambi C Numero Scambi C 7.4 Lotti R= 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. 57

58 Cmax Cmax Makespan medio Makespan medio o 12o 21o 22o e 12e 21e 22e A 53,02 15,76 251,58 74,72 A 147,66 39,2 692,5 158,14 AS 38,22 12,24 147,26 43,76 AS 125,94 36,56 445,68 100,88 B 36,36 12,7 128,04 41,18 B 119,68 35, ,1 BS 34,72 11,5 123,72 38,34 BS 114,74 32,64 396,28 84,76 C 38,6 16,94 129,4 44,48 C 126,2 57,18 414,2 109,14 CS 35,32 11,62 124,98 38,1 CS 115,78 34,2 397,82 82,84 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. Miglioramenti % 70,00 60,00 50,00 40,00 30,00 20,00 10,00 0,00 11e 11o 12e 12o 21e 21o 22e 22o Miglioramento Percentuale Euristica A Miglioramento Percentuale Euristica B Miglioramento Percentuale Euristica C 58

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. Numero Scambi AS BS CS 0 11e 11o 12e 12o 21e 21o 22e 22o 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. 59

60 22o 21o 12o 11o Cmax-Cmin CS C BS B AS A 22e 21e 12e 11e Cmax-Cmin CS C BS B AS A 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 Numero Job su macchina critica in % 11e 12e 21e 22e 11o 12o 21o 22o A AS B BS C CS 60

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 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. 61

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 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. 62

63 Cmax Cmax 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 Makespan 21oR 22oR Makespan 21oD 22oD B 134,14 50,36 B 157,62 58,96 BS 127,6 47,08 BS 149,1 56,42 C 139,2 57,48 C 162,16 67,04 CS 130,64 54,28 CS 150,54 62,52 63

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. MIiglioramento % Miglioramento B Miglioramento C 4,76% 6,60% 5,62% 6,06% 4,24% 3,88% 5,84% 5,00% 21oD 21oR 22oD 22oR 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. Numero Scambi oD 21oR 22oD 22oR BS CS 64

65 Titolo asse Titolo asse Makespan medio Makespan medio eR 22eR eD 22eD B 446,38 117,8 B 471,78 147,88 BS 436,12 113,12 BS 450,08 144,96 C 452,44 130,12 C 479,32 168,32 CS 437,58 121,84 CS 459,92 160,32 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. Miglioramenti % Miglioramenti Euristica B Miglioramenti Euristica C 5,72% 4,00% 3,68% 3,20% 4,32% 3,54% 2,02% 1,66% 21eD 21eR 22eD 22eR 65

66 Numero Scambi eD 21eR 22eD 22eR BS CS Cmax-Cmin Cmax-Cmin 22 ed CS 22eR CS 21 ed C BS B 21eR C BS B 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. 66