La Simulazione ad Eventi Discreti

Transcript

Università degli Studi di Genova
FACOLTÀ DI INGEGNERIA
Corso di Laurea in Ingegneria Informatica
Analisi di un modello di Supply Chain
attraverso un Simulatore ad Eventi Discreti
( Analysis of a Supply Chain model by means of a Discrete Event Simulator )
Relatori:
Chiar.mo Prof. Davide Giglio
Chiar.mo Prof. Riccardo Minciardi
Laureando:
Simone Campora
Anno Accademico 2006/2007
Dipartimento di Informatica, Sistemistica e Telematica
Sommario
CAP. I : La Simulazione ad Eventi Discreti ...................................
pag. 1
1.0 Introduzione ..................................................................................... pag. 1
1.1 Definizioni matematiche .................................................................. pag. 6
1.2 La Simulazione ................................................................................. pag. 8
1.3 Aree di Applicabilità ....................................................................... pag. 12
1.4 Simulazione Object Oriented .......................................................... pag. 13
CAP. II : Le Supply Chain ....................................................................... pag. 14
2.1 Obiettivi e Fasi ................................................................................. pag. 16
2.2 Vista di Processo .............................................................................. pag. 18
2.3 Le Componenti ................................................................................ pag. 20
2.4 Tassonomie ...................................................................................... pag. 23
CAP. III : Definizione del modello ...................................................... pag. 25
3.1 Il Modello ......................................................................................... pag. 26
3.2 Dati in Ingresso e Uscita al sistema.................................................. pag. 28
3.3 Le equazioni di stato ........................................................................ pag. 29
3.4 Analisi delle Variabili Controllabili ................................................. pag. 34
3.5 Politiche di gestione degli Inventories ............................................. pag. 36
3.6 Indici di prestazione ......................................................................... pag. 39
CAP. IV : L’applicazione Software
................................................. pag. 45
4.0 Introduzione ( Il Linguaggio Java ) ................................................. pag. 45
4.1 Le Strutture Dati .............................................................................. pag. 50
4.2 L’algoritmo di simulazione ............................................................. pag. 65
4.3 L’interfaccia Grafica e le funzionalità ............................................. pag. 67
CAP. V : Analisi dei Risultati ................................................................ pag. 70
5.1 Effetti della precisione finita ............................................................ pag. 72
5.2 Scelta della politica di gestione Migliore ......................................... pag. 74
CAP. VI : Conclusioni, limitazioni e possibili sviluppi ............ pag. 82
6.0 Limitazioni ....................................................................................... pag. 82
6.1 Considerazioni Finali ....................................................................... pag. 83
Bibliografia ...................................................................................................... pag. 84
Ringraziamenti
Rivolgo un particolare ringraziamento ai Prof. Davide Giglio e Prof. Riccardo Minciardi
per avermi guidato in questi mesi con la loro indiscutibile competenza e disponibilità.
Grazie per avermi confermato ancora una volta che vostra "È l'arte suprema
dell'insegnante, risvegliare la gioia della creatività e della conoscenza" (Albert Einstein).
Ringrazio la mia famiglia e la mia fidanzata per avermi sostenuto in questi anni e per la
loro continua fiducia nelle mie capacità e aspirazioni. Grazie per tutto quello che
riuscite a fare ogni giorno per me.
Ringrazio tutti i miei amici per ogni momento di svago e di studio, grazie di tutto.
Simulazione ad Eventi Discreti
CAPITOLO I: La Simulazione ad Eventi Discreti
1.0
Introduzione
Fig. 1.1
L’approccio di simulazione risulta efficace in ogni applicazione di cui non sia
possibile definire un modello matematico di semplice utilizzo, o come alternativa
quando i risultati sono ottenibili tramite operazioni non lineari, facilmente ricavabili
tramite procedure algoritmiche iterative. La simulazione può essere utilizzata con
profitto, anche in situazione dove si voglia avere a disposizione uno strumento di
validazione per un modello matematico.
La simulazione ha come potente vantaggio, la flessibilità assoluta nel trattare
sistemi dinamici senza aver bisogno di particolari restrizioni e semplificazioni, che si
rendono necessarie invece utilizzando i metodi analitici. In questo studio, la simulazione
1
ha reso possibile la scomposizione del problema di natura complessa in sotto sistemi più
facilmente identificati, concettualizzati ed infine modellati. Ad esempio, nell’utilizzare
eventi discreti in ingresso e in uscita al sistema se questi sono distribuiti come dati
deterministici, l’unico approccio possibile risulta essere quello simulativo.
La simulazione presenta anche altri punti di forza. Un esperimento simulato
infatti non rappresenta solamente una rappresentazione alternativa al modello
matematico, essa infatti elabora una stima (sufficientemente precisa per nostri calcoli)
dell’evoluzione delle variabili di stato. La simulazione è utile ogni volta in cui vogliamo
ottenere come risultato un “trace” delle variabili di stato. E’ altresì vantaggiosa se si
presenta il
bisogno di calcolare particolari indici prestazionali che richiedono
operazioni puntuali (come conteggi) , o di tipo integrale (costi medi, utilizzazioni
medie). Avere a disposizione uno storico grafico con l’andamento delle variabili di stato
mi conferisce tutte le informazioni necessarie per questi calcoli. Più in generale
analizzando questi ed altri aspetti di dettaglio, è possibile sottolineare vantaggi e
svantaggi per la Simulazione, alcuni dei quali già ipotizzati nel 1970 da Schmidt1 e
Taylor2.
Vantaggi:
•
Una volta che il modello è costruito può essere utilizzato ripetutamente
in modo tale da rendere possibile l’analisi di differenti politiche
proposte.
•
I metodi di simulazione possono essere usati come aiuto nell’analisi di
sistemi proposti anche se i dati in ingresso si presentano lacunosi e
generalmente incompleti.
•
E’ comune il caso in cui i dati del sistema da simulare sono molto
meno costosi rispetto all’implementazione reale del sistema in analisi.
•
I metodi di simulazione sono comunemente più facili da applicare
rispetto ai metodi analitici. Inoltre i potenziali utenti di un programma
1
J. William Schmidt: professore di “Industrial Engineering” e “Operations Research” presso il Virginia
Polytechnic Institute and State University.
2
R. E. Taylor: professore afferente al dipartimento di “Industrial Engineering and Operations Research”
presso il Virginia Polytechnic Institute and State University
2
di simulazione sono largamente più numerosi di quelli di un metodo
analitico.
•
Nel caso in cui i metodi analitici richiedano normalmente molte
assunzioni semplificative per rendere il sistema trattabile (es. lineare), i
metodi simulativi non hanno questi problemi. Con i metodi del primo
tipo l’analista usualmente può compiere solo un limitato numero di
misure di performance sul sistema. Con la simulazione invece i dati
generati possono essere riutilizzati per stimare qualsivoglia indice di
prestazione.
•
Per quanto concerne alcuni casi specifici, la simulazione rappresenta
l’unico insostituibile modo di procedere verso la soluzione di un dato
problema.
•
La simulazione possiede intrinsecamente l'abilità di poter espandere e
comprimere l'avanzamento temporale degli eventi in modo tale da
creare degli scenari simulativi di maggior dettaglio o con maggior
anticipo rispetto gli eventi reali simulati.
•
La capacità di controllare direttamente le sorgenti del sistema.
•
Precisare gli errori di misura e fornirne un intervallo di confidenza
esatto.
•
Il modellatore può avere il controllo diretto sulla granularità dei
dettagli.
Sempre Schmidt e Taylor considerarono gli svantaggi (in minor numero) nell’utilizzo di
metodi simulativi. Svantaggi:
•
I modelli di simulazione per complessi sistemi di calcolo possono
essere costosi in quantità di tempo, codifica e validazione.
•
Si richiedono numerose prove di simulazione prima di arrivare a
risultati stabili ed utilizzabili per stime di parametri di interesse, e
questo in certe situazioni può comportare costi a livello di tempo e
capacità di calcolo.
3
Lo sviluppo di un buon progetto di simulazione, si articola in fasi ben distinte, che
per alcuni aspetti ricalcano fasi progettuali di uso comune in altri ambiti
ingegneristici:
•
Formulazione del problema: ogni studio dovrebbe iniziare con la
definizione del problema da risolvere con l’approccio simulativo. E’
consigliabile sviluppare sufficientemente l’analisi del problema, onde
definire in maniera chiara ed esaustiva, il maggior numero degli aspetti
del problema in questione. Questo diminuirà la probabilità di
riconsiderare parti della simulazione in itinere a causa di errori la cui
gravità è crescente con il ritardo con cui questi errori vengono rilevati,
riducendo perciò i rallentamenti nella codifica.
•
Messa a punto degli obbiettivi di progetto: una volta appurato che la
simulazione rappresenta il metodo risolutivo ottimale per il problema,
occorre sviluppare uno studio su cosa si vuole ottenere dalla
simulazione, con quali mezzi, in quali limiti temporali e più in generale
con quali costi.
•
Costruzione del modello: è la fase di sviluppo che richiede il maggior
sforzo di creatività. Questa fase decide il grado di complessità della
simulazione; come le semplificazioni della realtà da simulare o il grado
di confidenza che si vuole raggiungere con le elaborazioni. La
costruzione del modello deve soddisfare requisiti di essenzialità ed
estrarre i concetti chiave del problema.
•
Raccolta dei dati: è uno studio che andrebbe portato avanti
parallelamente al precedente, in quanto è di sinergica importanza
analizzare i tipi di dati a cui si può accedere per decidere come il tipo
di modello deve essere strutturato.
•
Codifica: prevede la messa in opera del modello tramite (come in
questo caso) la stesura di una procedura algoritmica in un linguaggio di
programmazione specifico per l’applicazione software.
•
Verifica e validazione: una volta sviluppato il simulatore, l’evoluzione
4
naturale è quella della verifica del risultato. Si appura che i risultati
ottenuti siano conformi con le aspettative e che i valori in ingresso e le
strutture del modello siano correttamente rappresentate nel codice. La
validazione inoltre determina se il dato modello rappresenta una
adeguata approssimazione del fenomeno reale.
In forma maggiormente dettagliata, il procedimento per la formulazione e realizzazione
di un simulatore, si può schematizzare come segue.
Fig. 1.2
5
1.1 Definizioni matematiche
In questo studio, si prenderà in analisi un tipo di sistema dinamico ad eventi
discreti. Anzitutto è utile introdurre brevemente che cosa si intenda per sistema
dinamico, per evento, e in che forme si possono presentare.
Un sistema è definibile come un gruppo di oggetti che sono in relazione grazie
ad interazioni regolari o dipendenze per il raggiungimento di un obiettivo di qualche
genere. Un sistema dinamico, è definito da un insieme di attributi (variabili) che
evolvono in relazione con il mondo esterno.
“Un sistema dinamico è un sistema che evolve nel tempo, indicando con
questo termine che sia l'ingresso che l'uscita si sviluppano nel tempo. In
generale l'uscita all'istante t di un sistema dinamico non dipende solo
dall'ingresso del sistema allo stesso istante, ma da una grandezza, detta stato,
che rappresenta la storia passata degli ingressi del sistema.” 3
Con riferimento al caso di tempo continuo, un sistema può essere descritte da equazioni
di stato del tipo:
Dove
sono rispettivamente: il vettore delle variabili di stato, il
vettore delle condizioni iniziali, il vettore degli ingressi e il vettore delle uscite
Di un sistema è di interesse valutare l’evoluzione di particolari variabili,
necessarie e sufficienti per identificarlo univocamente, le variabili di stato. Lo stato di
un sistema, è definito infatti da un insieme di variabili necessarie a descriverlo in un
3
Wikipedia: http://it.wikipedia.org/wiki/Sistema_dinamico_(teoria_dei_sistemi)
6
dato istante (temporale nella fattispecie). Queste variabili di stato, possono appartenere
al dominio continuo (si parla di sistemi dinamici a variabili continue o più
semplicemente sistemi dinamici continui vedi Fig. 1.4), oppure al dominio discreto
(sistemi dinamici discreti, nati come tali o ottenibili dalla discretizzazione di variabili
per loro natura continue vedi Fig. 1.3). Esse variano in concomitanza di accadimenti
istantanei denominati eventi.
“Un sistema ad eventi discreti è un sistema dinamico i cui stati possono
assumere valori logici o simbolici, piuttosto che numerici, e il cui
comportamento è caratterizzato dall'occorrenza di eventi istantanei che si
verificano con cadenza irregolare non necessariamente noto a priori. Il
comportamento di tali sistemi è descritto, appunto, in termini di stati e di
eventi.” 4
L’evento infatti è definibile come un’istantanea occorrenza che fa cambiare lo
stato del sistema. Un sistema dinamico ad eventi discreti, può essere analizzato per via
analitica oppure numerica. La seconda è quella che si intraprende con la simulazione.
Fig. 1.3
4
Fig. 1.4
Wikipedia: http://it.wikipedia.org/wiki/Sistema_ad_eventi_discreti
7
1.2 La Simulazione
Fig. 1.5
In una simulazione ad eventi discreti, come il nome suggerisce, le variabili
assumono soltanto valori a precisione non infinita, le variazioni di tali variabili sono
istantanee e condizionate al verificarsi di ben precisi eventi in ingresso al sistema.
Questi, in dipendenza della classe a cui appartengono, decidono sull’evoluzione del
sistema insieme alle equazioni di stato. Il modello che analizzeremo in seguito riguarda
un particolare sistema di simulazione ad eventi discreti, in quanto prevede alcune
variabili continue nella dinamica ad eventi discreti (per quanto riguarda il livello di
Inventory), per cui classificheremo il sistema come “sistema ibrido”.
Ipotesi di base per quanto riguarda questo modello di simulazione sono le seguenti:
•
Sistema monocliente: per tutta la sua dinamica, il sistema processa una sola
tipologia di cliente, in quanto l’attenzione del modello non si concentrerà
tanto sulle variazioni relative alle al susseguirsi di tipologie diverse di clienti
processati, quanto invece ai tempi di inter-arrivo e alle quantità di
informazione trasportata dai suddetti clienti5.
•
Regime work-conserving: ossia, le risorse del sistema (i macchinari, o i nodi
produttivi) sono sempre utilizzate se un quantità ε di materiale da processare
è almeno presente nel sistema (come vedremo più avanti questo coincide alla
5
Si intende un evento di tipo “arrivo di N quantità di materiale”
8
situazione in cui vi sia almeno una singola giacenza nel magazzino in
ingresso ad ogni nodo produttivo).
I dati in ingresso, si suddividono in due tipologie ben distinte:
Dati relativi ai trasferimenti dei Clienti: sia per quanto riguarda il processo degli
arrivi nel sistema, delle partenze, e dei trasferimenti interni nel sistema, si
ipotizzano essere tutti deterministici, e prestabiliti al tempo di pre-simulazione.
Dati relativi ai livelli di produttività dei macchinari: si ipotizzano determinati
tramite un particolare processo stocastico, che previa la scelta di un particolare
valore medio (deterministico dovuto alla scelta del ritmo di produzione), genera
l’occorrenza di una variabile aleatoria gaussiana distribuita attorno a quel valor
medio (e in particolare a varianza unitaria ) troncato da due valori, nel caso
specifico +5 -5. Questo fatto vincolante per la definizione successiva del
modello, quantifica la possibilità di discrepanze nell’effettivo livello di
produzione rispetto a quello pianificato e deterministico.
Fig. 1.6
9
Esistono delle variabili essenziali nel sistema che coincidono con le uniche
variabili indispensabili alla corretta esecuzione e terminazione della simulazione.
Insieme a queste variabili, ve ne possono coesistere in numero teoricamente infinito di
altre variabili, denominate non essenziali, che costituiscono tutto il bagaglio informativo
che arricchisce il calcolo prestazionali. Queste forniscono informazioni non di primaria
importanza per la struttura algoritmica del simulatore, ma di fondamentale importanza
nel momento in cui l'utilizzatore finale debba ricondursi alla sintesi di un risultato.
Ad ogni istante di occorrenza di un evento, devo poter descrivere con un
certo meccanismo, quello che si deve fare e le modifiche da apportare al sistema, in
modo da far avanzare correttamente la simulazione e garantire la cronologicità degli
eventi. Gli eventi appartengono a diverse categorie e quando il sistema riceve i dati in
ingresso, non fa altro che collocare le informazioni relative agli eventi in due liste ben
distinte, la lista degli eventi attivi LEA(t) e lista dei tempi degli eventi attivi LTEA(t).
La prima ( Scheduled Event List ) contiene tutti gli eventi attivi (che ancora
devono verificarsi ma già schedulati) e porta l’informazione sulla tipologia del prossimo
evento e dei successivi. La lista degli eventi attivi è costruita in moto tale da contenere
gli eventi ordinati in base a tempi di occorrenza non decrescenti.
La seconda (Scheduled Time Event List ) invece contiene l’informazione sui
tempi residui al prossimo evento, ossia quantifica quanto tempo manca prima che si
verifichi il prossimo evento. Queste due sono le strutture teoriche tramite le quali
avviene la gestione degli eventi.
Come deve essere progettato un algoritmo di simulazione?
In Primis è necessario identificare quali siano le variabili di stato essenziali e
secondarie, queste ultime verranno scelte in base agli indicatori prestazionali richiesti
dal problema e in base alla loro tipologia di calcolo (on-line, off-line, di conteggio o
prevedendo operatori simili all’integrale del tempo continuo).
Secondariamente si devono identificare le tipologie degli eventi che devono essere
indipendenti e che in generale possono suddividersi in due categorie:
10
Interni: ossia quelli che riguardano eventi verificatisi all’interno del sistema come
possono essere, i trasferimenti di materiale tra due magazzini di stoccaggio.
Esterni: ossia quelli che mettono in relazione il sistema con l’ambiente esterno e che
possono essere esemplificati come l’arrivo di clienti dall’esterno o la partenza di clienti
verso l’esterno.
Una volta avute a disposizione tutte le categorie di eventi, si provvede alla
selezione e decisione delle tipologie di transizioni ottenibili dal verificarsi dei vari
eventi. In conclusione del processo di progettazione, si deve considerare l’integrazione
di tutte questi aspetti, e selezionare consecutivamente gli eventi della lista degli eventi
attivi, in base al principio di minor tempo di attesa prima del verificarsi di tale evento.
In via definitiva l’algoritmo di simulazione consta in un insieme di istruzioni
(facilmente codificabili, in quanto il modello simulativo rappresenta allo stesso tempo
un ottimo modello concettuale, in grado di fornire una relazione puntuale con le
procedure software), che devono essere ripetute iterativamente fino al termine della
simulazione. Queste sono:
1. Rimozione del primo elemento nella LEA;
2. Aggiornamento del tempo di simulazione;
3. Aggiornamento dello stato del sistema;
4. Ordinamento nella LEA di eventuali eventi inseriti, per ordine cronologico;
Una volta conclusa la progettazione concettuale dell'algoritmo, si procede
alla traduzione del modello, costruendo le strutture software necessarie, e le
metodologie ottimali per memorizzare i dati. Le specifiche di codifica non
necessariamente dovranno ricopiare quelle definite in fase di progettazione concettuale,
ma verosimilmente ricopieranno le medesime funzionalità ( es: la LEA(t) in questo
simulatore viene implementata nella stessa struttura dati contenente la LTEA(t) ).
11
1.3 Aree di applicabilità
Esempi noti sono elencabili dai simulatori di volo, ai sistemi di gestione logistica
per grandi quantità di elementi, e Business-games. Tuttavia esistono infinite aree
potenziali per la simulazione ad eventi discreti. Una di queste che recentemente ha
intrapreso uno studio orientato in questa direzione è la simulazione di processi
produttivi, specialmente quando si tratta di organizzare materiale ad alto contenuto
d’investimento. Ad esempio, se una compagnia decide di mettere in opera una nuova
linea produttiva, la suddetta linea può essere facilmente simulata in modo tale ad
valutare la sua praticabilità ed efficienza. Ulteriori esempi possono essere:
•
La simulazione di operazioni in un aeroporto di grandi dimensioni da
parte di una compagnia che desideri testare i cambiamenti nelle
gestioni riguardanti la misura della capacità di manutenzione, le risorse
di attracco per i mezzi e la loro quantità.
•
La simulazione di un flusso di traffico presso un incrocio regolato da
semafori temporizzati in modo tale da determinare le sequenze
temporali ottimali.
•
La simulazione di battaglie militari su larga scala in modo tale da
valutare il potenziale offensivo e difensivo.
•
La simulazione globale dell’operato di una azienda commerciale in
modo tale da analizzare i cambiamenti generali nelle politiche di
gestione.
•
La simulazione di un sistema di comunicazione telefonico per
determinare la capacità richiesta ai singoli componenti per provvedere
al fabbisogno del servizio al costo minore sostenibile.
•
La simulazione dell’operato di una linea produttiva in modo tale da
determinare l’ammontare dei livelli di magazzino durante il processo
produttivo in modo tale da dimensionare correttamente lo spazio
fisicamente richiesto.
12
1.4 Simulazione Object Oriented
Il sistema preso in analisi (questo risulterà più chiaro in seguito nel trattare la
codifica del simulatore) utilizza tecniche “Orientate agli Oggetti”. Queste sono state
sviluppate fino dagli inizi del 1960’. Soltanto recentemente le tecniche orientate agli
oggetti si sono sviluppate notevolmente tramite l’uso di linguaggi di programmazione
creati nativamente per supportare questa caratteristica.
La differenza principale che intercorre tra la programmazione tradizionale e lo
sviluppo di tecniche orientate agli oggetti è il modo in cui i dati sono memorizzati e
manipolati attraverso il codice programma. Nel software tradizionale, i dati e il codice
relativo al programma da simulare sono facenti parte di un unico flusso di elaborazione,
rendendo la sicurezza dei dati e la loro integrità difficile da appurare (talvolta è
addirittura possibile che una procedura causi effetti apparentemente funzionanti ma
scorretti, se i dati sono modificati). Tuttavia, nel software di simulazione orientato agli
oggetti, ogni dato e procedura in relazione ad una data entità (oggetto) è incapsulata
nell’oggetto stesso che controlla la sua interazione con l’integrità dei dati e i permessi
d’accesso ad altri oggetti.
Un simulatore progettato e codificato tramite un approccio orientato agli oggetti,
acquisisce tutte le caratteristiche e i vantaggi che la programmazione orientata agli
oggetti comporta. Infatti si rende più facile l'estendibilità e la possibilità di modificare il
software interagendo a livello concettuale e non puramente procedurale.
In generale è corretto asserire che utilizzando una programmazione del
simulatore orientata agli oggetti, sia lo sviluppatore che l’utente finale acquisisce una
immediata manualità con il programma, riducendo al minimo lo sforzo di
comprensione, grazie ad una più agile concettualizzazione dei fenomeni da simulare.
13
Supply Chain
CAPITOLO II: Le Supply Chain
2.0
Introduzione
Fig. 2.1
Durante l’epoca delle produzioni di massa, l’automazione a ritmi forzati portò
l’automobile a divenire oggetto alla portata dell’individuo comune. Attualmente, la
tendenza dell’automazione è quella di concentrare i propri sforzi innovativi ai rapporti
tra imprese ed ai rapporti tra azienda e cliente, usando come tramite la rete Internet.
Oggi infatti è possibile ricevere agilmente ordini da parte di un cliente in qualsiasi parte
del globo esso si trovi e soddisfare le sue richieste automaticamente, con il minimo
intervento umano. Bisogna far fronte però a fattori limitanti come ad esempio la
mancanza di infrastrutture all’interno delle realtà nazionali. Il tema centrale in tutti gli
sviluppi industriali durante
il secolo passato è stato l’automazione. Il primo
esemplificativo approccio fu quello dell’automatizzazione in catena di montaggio per la
produzione dei motori per automobile, ad opera di Henry Ford nei primi anni del 1900.
Oggi ci sono notevoli sistemi di supporto alle decisioni e mezzi di comunicazione, che
14
Supply Chain
arricchiscono di servizi essenziali il mercato dell’automazione, e non solo quello, ma
anche dei processi di vendita così come per le relazioni con i fornitori. Il motivo di
questi
sforzi
ad
automatizzare
i
processi
di
supply
chain1,
inizia
dall’approvvigionamento delle materie prime e finisce con le consegne ai clienti finali,
con l’obiettivo di servire con la massima efficienza ed efficacia il cliente.
Fig. 2.2
Una supply chain consta di un insieme di stadi che sono coinvolti direttamente o
indirettamente nel perseguimento di una richiesta da parte di un cliente. Più in generale
una supply chain include non solo la componente manifatturiera e la componente dei
fornitori, ma considera gli aspetti di trasporto e logistica, stoccaggio, punti di rivendita.
Una supply chain è dinamica e coinvolge un costante afflusso di informazioni, prodotti
e investimenti tra i diversi livelli. Ogni livello della supply chain sviluppa differenti
processi ed interagisce con altrettante diverse parti.
1
Si manterrà per tutto l’elaborato la dizione inglese per uniformità di notazione, nonostante sia termine
interscambiabile la traduzione italiana “catena di approvvigionamento ”
15
Supply Chain
2.1 Obiettivi e Fasi
Fig. 2.3
L’obiettivo di ogni supply chain (una volta soddisfatta la domanda del cliente) è
quello di massimizzare il valore aggiunto globale di tutto il processo. Il valore che
genera è quantificabile comunemente con il valore aggiunto che il prodotto apporta al
cliente, in rapporto agli sforzi che la supply chain deve sostenere nel soddisfacimento
della domanda. Per molte supply chains commerciali, il valore sarà strettamente legato
con la sua redditività, ossia la differenza tra il profitto generato dal cliente e il costo
totale della supply chain. Si definisce infatti il successo di una supply chain in termini
della sua redditività, tenendo sempre conto che l’unico flusso di cassa positivo è
rappresentato dal soddisfacimento della domanda del cliente.
Un sistema di gestione per supply chain di successo, richiede un certo numero di
decisioni relative al flusso di informazioni, al prodotto e ai costi. Queste decisioni si
possono far ricadere in tre categorie (o fasi) ben distinte per arco temporale interessato e
tipologia di decisione intrapresa:
1. Supply Chain strategy or design: In questa fase l’azienda decide come
strutturare la supply chain. Decide come dovrebbe essere configurata e quali processi
devono essere intrapresi per ogni livello. Le decisioni prese durante questa fase sono
riferite alle decisioni strategiche dell’azienda, che comprendono le localizzazioni degli
impianti, le capacità produttive ottimali, come e quali strutture di stoccaggio utilizzare,
che prodotti immagazzinare nelle diverse locazioni, le modalità di trasporto da utilizzare
tra le diverse spedizioni e non ultimo il tipo di sistema informativo da utilizzare.
16
Supply Chain
2. Supply Chain Planning: come risultato della fase di pianificazione, le aziende
definiscono un insieme di politiche operative per controllare le operazioni a breve
termine. E’ importante notare che per le decisioni intraprese entro questi termini, la
configurazione adottata in fase di pianificazione strategica rimane sempre invariata.
Questa configurazione infatti stabilisce dei limiti entro i quali la pianificazione deve
rientrare. Le aziende generalmente iniziano questa fase di pianificazione con delle
previsioni per l’anno successivo (o di un lasso di tempo con il quale effettuare paragoni)
riguardo la domanda nei diversi mercati in cui intendano immettere i propri prodotti.
La pianificazione include le decisioni che riguardano i mercati da rifornire, e da
quale locazione far giungere i prodotti, la pianificazione della gestione dei magazzini,
le decisioni “make-or-buy”, le politiche di riempimento da seguire per i magazzini, le
azioni da intraprendere in caso di livello di magazzino fortemente bassi, le tempistiche e
le modalità delle iniziative di marketing. Non per ultima importanza, in questa fase sono
proprie le considerazioni a riguardo il grado di incertezza della domanda, e sui rapporti
di scambio e competizione sull’arco temporale considerato.
3.Supply Chain Operation: in questa parte l’orizzonte temporale considerato è
settimanale se non giornaliero, e le decisioni interessate riguardano in buona parte
esclusivamente quelle relative ai singoli ordini dei clienti. Al livello Operativo
l’obiettivo principale è quello di implementare le politiche di gestione nel miglior modo
possibile. In questa fase le ditte distribuiscono gli ordini ai magazzini o al reparto
produttivo, impostano i percorsi di distribuzione delle flotte di camion.
17
Supply Chain
2.2 Vista di Processo
La supply chain non è altro che una sequenza di processi e flussi che prendono
luogo tra i diversi stadi della supply chain, e che si combinano fino a completare la
domanda del cliente. E’ importante quindi ai fini di ottenere una completa visibilità di
tutte le interdipendenze, analizzare le viste di processo, che possono essere
schematizzate come segue:
1. Cycle view: si riferisce alla suddivisione dei processi della supply chain in
una serie di cicli che interfacciano i vari stadi della supply chain.
2. Push/pull view: in questa suddivisione invece i processi sono divisi in due
categorie dipendenti dalla condizione che essi provengano in risposta alla richiesta
specifica di un cliente (pull) o in anticipazione di un ordine (push).
Cycle view:
Fig 2.4
18
Supply Chain
Ogni processo di supply chain viene suddiviso nei seguenti processi ciclici:
- Ciclo degli ordini del cliente: è posizionato tra il cliente e l’ultimo rivenditore, ed
include tutti i processi direttamente coinvolti nella ricezione e completamento
dell’ordine. E’ un processo che ha inizio quando il cliente entra in contatto con il
rivenditore e termina quando la richiesta è correttamente formulata.
- Ciclo di rifornimento: si trova tra il rivenditore ed il distributore e concerne i processi
coinvolti nel rifornimento del magazzino del rivenditore. E’ un processo che ha inizio
quando il rivenditore richiede al distributore che gli sia riempito il magazzino per
ottemperare alle future richieste con l’obiettivo di ridurre al minimo i costi di
rifornimento (scegliere la giusta misura tra frequenza di rifornimento e quantità
rifornita).
- Ciclo di produzione: si colloca tra il distributore ed il produttore. I processi coinvolti
in questo ciclo sono ad esempio il processo degli ordini dal distributore, rivenditore o
cliente, lo scheduling della produzione, il processo di produzione in se e di acquisto e di
ricezione dei materiali da parte dei distributori, rivenditori e clienti.
- Ciclo di approvvigionamento: riguarda l’ultima fase e la prima a monte della
produzione. E’ una tra le più delicate in quanto il produttore e il fornitore devono
accordarsi sulla pianificazione temporale in modo tale da non ritrovarsi mai in
condizioni di magazzini ai componenti vuoti (in carenza di materie prime).
Push/Pull:
I processi di Push sono quei processi che vengono iniziati come anticipazioni degli
ordini del cliente. Mentre al tempo d’esecuzione di un processo di Pull, la domanda è
nota con certezza, qui non la si conosce e l’incaricato di questo processo dovrà prendere
le decisioni necessarie sulla base di pure previsioni e stime. I processi di Pull invece
possono essere definiti come reattivi in quanto reagiscono semplicemente alla domanda
del cliente. Entrambe le due categorie di processi sono essenziali, in quanto non è
pensabile per certe categorie di prodotti iniziare la produzione solo una volta ricevuto
un ordine preciso, in quanto i tempi di produzione risulterebbero inaccettabili. Avere in
visione il rapporto tra i processi di Pull e quelli di Push all’interno di una supply chain è
di fondamentale importanza nella misura in cui si considerino decisioni strategiche nella
fase di design della supply chain.
19
Supply Chain
2.3 Le Componenti
L’incaricato di costruire il modello della supply chain deve conoscere nella
migliore misura possibile le sue componenti essenziali, in quanto non aver obiettivi
specifici da raggiungere significa doversi confrontare con una difficoltosa
pianificazione delle misure di performance. Non avere misure di performance adeguate
o confrontabili si traduce nell’impossibilità di determinare l’andamento corretto della
supply chain e quindi non riuscire ad intervenire in tempo per rimediare alle
inefficienze. E’ quindi chiaro il bisogno di delineare quali possono essere queste
componenti chiave, che da una realtà aziendale ad un’altra possono ovviamente variare
sensibilmente.
1. Elementi guida (Supply chain drivers)
L’individuazione degli obiettivi è il primo passo per la modellazione di una supply
chain. In dipendenza di questi, sarà più semplice scegliere il modello più adatto, o avere
un’idea su quali sono i parametri più importanti da voler monitorare ed ottimizzare nella
supply chain. Questi possono essere molteplici e raggruppabili in quattro sezioni:
a) Attività legate al soddisfacimento del cliente: anche se difficile da
quantificare, l’obiettivo ultimo resta sempre il soddisfacimento del cliente, che
rappresenta in ogni forma l’ultimo anello della supply chain. Per trovare una
buona stima del grado di soddisfacimento del cliente, è possibile ricorrere
all’analisi di due aspetti importanti. Il primo è rappresentato dalla “Reperibilità
del prodotto”, in quanto molte volte coloro che gestiscono la supply chain
falliscono nel raggiungimento dei bisogni del cliente se questi riguardano ritmi
produttivi e necessità da adempire in tempo reale. Per questo motivo un buon
modello dovrebbe contenere misure della performance di servizio come la
percentuale degli ordini portati a compimento senza ritardi, o la percentuale di
accuratezza degli ordini (se sono giunti nelle giuste quantità, completi di
documentazione, e con le caratteristiche richieste dal cliente). Il secondo aspetto
da considerare è senz’altro il “Tempo di Risposta” che misura il grado di
20
Supply Chain
flessibilità di una supply chain. Indicatori possono esserne la differenza tra i
giorni previsti per la consegna e quelli realmente impiegati per l’evasione
dell’ordine; Il tempo globale di attraversamento del processo da parte di un
singolo oggetto, ossia di quanto tempo passa da quando l’ordine è richiesto a
quando il cliente può usufruire del prodotto; il tempo di ciclo del denaro, ossia
quanto tempo passa, dopo che l’azienda investe i soldi nella produzione, prima
che possa avere il primo flusso positivo di cassa; la percentuale di tempo in cui
le macchine sono ferme a causa di manutenzione o ripari.
b) Valore Monetario: E’ generalmente definito come il rapporto tra il profitto ed il
costo totale sostenuto. Una supply chain può incrementare il suo valore
monetario o aumentando i ricavi sulle vendite, allargando il suo potenziale di
mercato, o la produttività, riducendo al contempo i consumi come i difetti nella
catena produttiva. Il Valore monetario si può analizzare scomposto in base al
principio di provenienza del valore: questo può derivare dal grado di
Utilizzazione delle risorse, e rilevato tramite la stime di parametri come il
rapporto annuale tra il valore del venduto e la media dell’investimento di
magazzino; dal ROI (Return on Investment) che è un indice finanziario molto
usato nelle analisi di Conto Economico.
c) Transazione dell’ Informazione: L’informazione garantisce la connessione tra
le varie fasi della supply chain e rende possibile la coordinazione tra i vari
partners, in modo tale da aumentare la visibilità di magazzino. Molto spesso
l’abilità messa in gioco dai partners per una supply chain risiede proprio nel
gestire quantità di dati in tempo reale. Questo tipo di comunicazione prevede
l’utilizzo di piattaforme tecnologiche e di sistemi informativi adeguati, come
EDI (electronic data inter-change), ERP (enterprise resource planning), WMS
(warehouse management systems).
2. Limiti della Supply Chain
Riguardano le limitazioni che un’azienda può incontrare nella scelta delle
decisioni. In particolare si possono avere limiti in Capacità siano essi di tipo
21
Supply Chain
finanziario, di produzione o tecnici, sono responsabili della determinazione del risultato
finale in termini di livelli di magazzino, di produzione, forza lavoro, capitali da
investire, tecnologie informatiche da adottare. Siccome lo scopo ultimo di una supply
chain rimane sempre il soddisfacimento della domanda, il limite forse più importante
per ogni decisione rimane sempre la conformità di servizio erogato. Questo si
esemplifica con il rispetto delle consegne temporali, imporre dei limiti di ritardo che in
generale possono dipendere da diversi fattori sia produttivi (il ciclo di produzione di un
dato prodotto) che logistici (limiti di trasporto, ore di guida degli autisti degli autotreni).
3. Variabili Decisionali
In ultima analisi le performances di una supply chain dipendono anche da alcune
variabili decisionali, in quanto esse stesse sono parametri importanti nella politica
decisionale adottata e nelle scelte che si sono analizzate in precedenza. Tra queste
variabili seguono:
a. Posizione Geografica: determina la scelta del posizionamento degli impianti,
magazzini e centri distribuzione.
b. Allocazione: Questa determina quali magazzini e quali centri di distribuzione
dovranno servire quali clienti.
c. Struttura di Rete: questo tipo di variabili decisionali coinvolgono problemi quali
decentralizzazione o centralizzazione della rete distributiva e determinano quale
combinazione di fornitori, impianti e magazzini di stoccaggio debbano essere usati o
ignorati.
d. Numero dei livelli: determina il numero degli stadi inclusi nella supply chain; questa
variabile considera la possibilità di modificare il livello di integrazione orizzontale o
della combinazione/separazione di livelli distinti.
e. Volume: questa variabile considera la quantificazione ottimale delle materie da
comprare, dei livelli di produzione e di trasporto per ogni nodo della rete di
approvvigionamento.
f. Livello di Inventory: determina il valore ottimale degli SKU (stock-keeping unit) ossia
materiali finiti a magazzino, delle materie prime e prodotti semilavorati che devono
essere mantenuti come scorta di garanzia per ogni livello della supply chain.
22
Supply Chain
2.4 Tassonomie2
Con riferimento alla modellizzazione di supply chains e come strumento per chi
si dedica alla progettazione e alla ricerca di modelli matematici, è possibile stilare una
breve catalogazione dei modelli a disposizione. E’ possibile infatti suddividere i modelli
matematici di supply chain in modelli:
•
Deterministici;
•
Stocastici;
•
Ibridi (con elementi di entrambi, es: Inventory Management Systems );
•
IT-driven ( basati su principi fondamentali di particolari tecnologie IT );
Fig 2.5
1. Modelli Deterministici
Assumono che tutti i parametri del modello siano noti e fissati con certezza
lungo l’asse temporale. Mentre i modelli stocastici prendono in considerazione un certo
grado di incertezza, qui non vi sono alcune variabili aleatorie. I modelli deterministici
possono essere suddivisi ancora in due sottoinsiemi, quelli ad obiettivo singolo ed
obiettivo multiplo. Queste categorie, che non dettaglieremo ulteriormente sono state
sviluppate per far fronte all’ingente richiesta di modelli che armonizzassero obiettivi
conflittuali di differenti partner all’interno della stessa supply chain.
2
Tassonomia: (dal greco ταξινοµία (taxinomia) dalle parole taxis = ordine e nomos = regole)
Classificazione gerarchica di concetti.
23
Supply Chain
2. Modelli Stocastici
Comprendono quella classe di modelli i cui parametri non sono noti a priori, ma
sono risultato di occorrenze di opportune variabili aleatorie (distribuite con una qualche
distribuzione di probabilità). Questi modelli sono suddivisi in due categorie: una
incentrata sulla teoria di ricerca del controllo ottimo, e la seconda sui modelli basati su
programmazione dinamica.
3. Modelli Ibridi
Alcune supply chain (come quella modellizzata nel caso preso in esame in
questo elaborato) sono basate su modelli che pongono particolare attenzione alla teoria
di Inventory e sulla Simulazione. Essi contengono sia elementi deterministici che
elementi stocastici e conseguentemente vengono denominati ibridi.
4. Modelli IT-Driven
Lo sviluppo delle tecnologie IT già dal 2001 era una delle forze trainanti per
l’innovazione delle supply chians, motivo di stravolgimenti di processo e reengineering dei business. I modelli basati su tecnologia IT aiutano ad integrare, e
coordinare le varie fasi della supply chain, fornendo strumenti software che migliorino
la visibilità attraverso la catena di approvvigionamento. Questi modelli includono i
WMS, i TMS (Transportation Management Systems), gli ITT (Integrated Transportation
Tracking), I CPFR (Collaborative Planning and Forecasting Replenishment), MRP
(Material Requirement Planning), DRP (Distribution Resource Planning), ERP, e GIS
(Geographical
Information
Systems).
In
particolare
i
GIS
semplificano
la
visualizzazione dei dati in quanto rendono possibile la visualizzazione dei dati analitici
(livelli di magazzino, tipologie di prodotti) nel loro contesto geografico, il che facilita
non poco il compito di coordinazione per Supply Chain fortemente decentralizzate o
distribuite. Combinato con un database management system (DBMS), i GIS
rappresentano una valida piattaforma ricca di funzionalità per aumentare il grado di
collaborazione tra i diversi partners della supply chain.
24
Definizione del Modello
CAPITOLO III: Definizione del Modello
3.0 Introduzione
Fig 3.1
Nei precedenti capitoli si è cercato di proporre una panoramica generale sulle
diverse
tipologie
de
modelli
e
tecnologie
che
vengono
affiancate
alla
concettualizzazione di supply chain. In dettaglio questo studio prenderà in esame un
modello che può essere collocato a cavallo tra due suddivisioni di categoria: i modelli
Ibridi ed IT-driven. Infatti, per quanto riguarda il primo, il modello presenta parametri
sia in forma deterministica che stocastica. Secondariamente questo modello è stato
implementato utilizzando una piattaforma software con interfaccia user-friendly (Java
SE 1.5), il che giustifica l’appartenenza al secondo sottoinsieme. Questo modello vuole
analizzare le problematiche legate alla presenza di una rete complessa di produzione
caratterizzata dalla presenza di una molteplicità di siti produttivi. La presenza di diversi
fornitori di materiali, e di centri produttivi distribuiti da fornire, solleva problemi di
coordinamento non banali e che in questa sede verranno analizzati tramite l’approccio
di simulazione. Verrà infatti in seguito sviluppato un software di simulazione ad eventi
discreti che ne valuterà le prestazioni.
25
3.1 Il Modello
Il sistema è composto dall’interconnessione di quattro singoli nodi indipendenti.
Il flusso di dati nel sistema attraversa questi sottosistemi, che livello per livello
effettuano delle lavorazioni sui materiali e li rilasciano all’ambiente esterno (come da
Fig 3.2).
Fig. 3.2
Ogni singolo impianto riceve una data quantità di prodotti da processare e
possiede al suo interno un magazzino per i prodotti grezzi e uno per i prodotti lavorati.
Il flusso di produzione per un singolo impianto si può quindi schematizzare nel seguente
modo:
Fig 3.3
26
Il flusso di prodotti in ingresso ( in figura rappresentati dalla funzione z(t) ) e il
flusso di prodotti in uscita dal singolo nodo y(t) sono dati forniti dal problema e
modificabili a seconda del tipo di politica di gestione adottata. Sono definiti i tempi di
inter-evento distribuiti deterministicamente lungo l’asse temporale. Ogni oggetto
processato dal nodo i-esimo subisce una lavorazione il cui rate è espresso da funzioni
costanti a tratti (per intervalli di tempo prestabiliti i macchinari lavorano a ritmo
costante).
Il modello prevede la presenza di quattro entità fondamentali:
•
due Nodi di primo livello: raccolgono i dati in ingresso ed effettuano una prima
elaborazione degli oggetti e li immagazzinano in attesa della richiesta da parte
delle strutture di secondo livello.
•
due Nodi di secondo livello: estraggono i dati processati nel primo livello della
catena di produzione e li processano una seconda ed ultima volta prima di
renderli disponibili per soddisfare la domanda proveniente dall’esterno.
Le funzioni p01(t) , p02(t) contengono l’informazione sugli eventi in ingresso
del tipo “arrivo di M quantità di oggetti nell’Inventory dei prodotti grezzi”. Le funzioni
p30(t), p40(t) rappresentano invece gli eventi in uscita dai nodi 3 e 4 del tipo”nuova
richiesta di M oggetti da parte di un generico cliente”. Le funzioni p14(t) e p23(t)
rappresentano infine gli eventi “richiesta da parte di 4 o di 3 di oggetti lavorati nel
primo livello della catena di produzione”. Analizzando cosa contiene un singolo nodo, e
le dinamiche ad esso associate, è possibile capire l’andamento e la migrazione dei
prodotti lavorati all’interno del sistema creato dall’interconnessione dei quattro. Le
uniche dinamiche di interesse sono quelle legate ai livello di Inventory, in quanto sono
noti deterministicamente i flussi di dati in ingresso e in uscita del sistema, ed è altresì
noto a priori che i tempi di set-up delle macchine e di trasporto da un nodo produttivo
ad un altro siano nulli (in ipotesi di lavoro).
27
3.2 Dati in Ingresso e in Uscita al Sistema
I dati in ingresso e in uscita al sistema sono modellate come funzioni impulsive
di variabile reale temporale discreta e asincrona. Un elemento “arrivo o partenza di N
oggetti nel sistema” è modellabile tramite un Impulso, in particolare si definisce:
(1)
L’impulso i-esimo della funzione Pxy(t) di quantità N (superiormente limitata in
ipotesi). Con questo impulso è possibile modellare un evento istantaneo per un nuovo
arrivo nel sistema in analisi. L’insieme dei tutti gli impulsi relativi ad un singolo nodo
costruisce la funzione Pxy(t).
Questa funzione fornisce informazioni sugli eventi “arrivo di N oggetti nel
sistema” oppure in relazione ad eventi “richiesta di N oggetti al sistema”, gli arrivi
infatti sono modellati senza tenere conto di eventuali tempi di trasporto e
posizionamento nell’inventory, per queste semplificazioni il grafico della Pxy(t) può
essere rappresentato da un grafico del tipo:
Fig 3.4
Dove:
Superiormente limitato dalla quantità T, il tempo di fine simulazione.
28
3.3 Le Equazioni di Stato
L’evoluzione dei livelli di inventory per ogni nodo è definibile istante per istante
utilizzando due equazioni di stato proprie di quel nodo. Le due equazioni di stato
forniscono informazione riguardo il numero di oggetti nell’inventory, e sono processi
che assumono valori continui a tratti. Le variazioni infinitesime dello stato infatti sono il
risultato del verificarsi degli eventi di instradamento all’interno del sistema
interconnesso e del livello delle funzioni di capacità produttiva. Sono presenti delle
condizioni iniziali sui livelli di inventory che danno informazione riguardo il numero di
oggetti già presenti nei magazzini al tempo di inizio simulazione, di fondamentale
importanza per garantire l’unicità della soluzione dell’equazione di stato (equazione
differenziale). In generale si vuole ottenere un modello facilmente inseribile in una
realtà applica, per cui la quantificazione delle giacenze da cui iniziare l’attività di
simulazione è senz’altro richiesta. Il numero di oggetti nel primo inventory e il numero
degli oggetti nel secondo inventory rappresentano le uniche due variabili di stato
essenziali per la simulazione del sistema in questione. Ad esempio, con riferimento al
primo impianto, le due equazioni di stato sono:
(2)
(3)
In forma ricorsiva è possibile definire lo stato del sistema all’istante i+1 in questo
modo:
Con
e x(0) istante iniziale del livello di magazzino.
29
La (2) definisce l’equazione di stato del primo inventory mentre la (3) fa
riferimento alla costruzione del secondo inventory, in uscita a Nodo 1. La funzione k(t)
rappresenta la funzione definita costante a tratti che stabilisce il numero di oggetti
processati per ogni istante di tempo dal sistema i-esimo (ossia la produttività),
ipotizzando K il valore di upper-bound della capacità produttiva.
La capacità produttiva è definita da variazioni asincrone di quantità costanti
discretizzate e continue nel tempo. Può assumere valori compresi tra K e 0 (che
coincide con lo stato di inattività del sottosistema i-esimo, ossia quando non processo
alcun oggetto).
Le funzioni k(t) hanno una rappresentazione analitica del tipo:
Fig 3.5
Sull’asse delle ascisse è rappresentato il tempo, mentre sulle ordinate si trova il
numero di oggetti che la macchina può smaltire nell’unità di tempo. Si può notare che il
passaggio da un livello di capacità produttiva ad un altro non provoca alcun ritardo o
interruzione della produzione. Ipotizziamo infatti che non ci siano tempi di set-up o
ulteriori tempi residui per altre operazioni e quindi per passare da un regime di
produzione di M oggetti processati per unità di tempo ad un altro di N oggetti processati
per unità di tempo, non è richiesta alcuna perdita di tempo. Combinando
opportunamente le due funzioni k(t) e Pxy(t) e previa integrazione nel dominio del
tempo e aggiunta delle condizioni iniziali, si ottiene la funzione x(t) numero di oggetti
in inventory, considerati gli arrivi del sistema e il processo di produzione.
30
Quello che ne risulta è il grafico seguente:
Fig 3.6
L’andamento è il risultato del susseguirsi di un generico insieme di ingressi. Si
può notare che quando l’inventory raggiunge il valore nullo, per convenzione si è
assunto mantenere tale valore fino al prossimo evento “nuovo arrivo”. Questo ha
significato fisico di uno shortage1, ossia quando non ci sono sufficienti oggetti
nell’inventory d’ingresso e il macchinario del processo passa istantaneamente in uno
stato di idle (inattività). Questa condizione è sconsigliabile, in quanto consiste in una
perdita di produttività (i macchinari non hanno più le risorse necessarie e quindi la
produzione si blocca), per cui rappresenta un costo aggiuntivo nell’economia
dell’impianto. D’altra parte avere un inventory eccessivamente “alta” pone il problema
inverso: troppi oggetti nell’inventory aumentano costi di immagazzinamento (serve più
spazio), con la possibilità di far risiedere nel magazzino i prodotti per molto tempo
senza averli venduti.
In molte applicazioni questo non è accettabile e consiste comunque in una
perdita di produttività. Analizzando queste situazioni si vedrà più avanti come
modificare le politiche di gestione in funzione dell’interconnessione dei nodi e dei
livelli degli inventory (è necessario attuare politiche che evitino per lo meno il caso
sicuramente sconsigliabile di shortage ).
Analogamente è possibile sviluppare un’analisi per la (2), riutilizzando le
1
Shortage: Carenza
31
considerazioni precedenti sulle funzioni p(t) e k(t) e combinandole opportunamente, si
ottiene un grafico della x’(t) del tipo:
Fig 3.7
L’andamento è orizzontalmente speculare rispetto alla x(t) e le considerazioni
sono simili. I tratti di andamento lineare rappresentano infatti le quantità di oggetti che
vengono depositate nell’inventory dei prodotti finiti mentre i tratti di discontinuità
verticali rappresentano il verificarsi istantaneo di un evento di tipo “prelievo oggetto
dall’inventory”. Se il prelievo richiesto supera la quantità disponibile nell’inventory,
allora lo stato si ferma al valore 0 (tenendo traccia nelle variabili di stato non essenziali
della quantità di richiesta insoddisfatta). I tratti di grafico costante sono dovuti alle
situazioni di shortage del nodo. Infatti non avendo risorse a sufficienza per continuare la
produzione, istantaneamente la macchina associata al nodo di produzione viene fermata.
Se consideriamo quindi tutti e quattro i nodi e le loro interconnessioni, otteniamo più
nel dettaglio:
Primo Nodo:
Secondo Nodo:
32
Terzo Nodo:
Quarto Nodo:
In conclusione, il sistema formato dall’interconnessione dei quattro nodi, è
completamente descritto dalle otto equazioni di stato (due per ogni sistema) che
corrispondono a otto variabili essenziali per la simulazione,e dalle otto condizioni
iniziali.
33
3.4 Analisi delle Variabili Controllabili
L’analisi delle variabili controllabili quantifica l’informazione del numero di
linee di controllo che l’utente può utilizzare nel gestire l’evoluzione del simulatore. Esse
rappresentano il numero di possibilità che hanno i dati che compongono un elemento
informativo, di variare liberamente e fornisce una misura di come il sistema possa
interagire modificando i dati e quindi sulle sue potenzialità.
Se consideriamo il sistema in questione composto dall’interconnessione dei
quattro Nodi produttivi, possiamo analizzare questi gradi di libertà partendo dall’analisi
delle variabili manipolate dei dati in ingresso. Per quanto concerne le funzioni p(t)
responsabili dei trasferimenti di materiale, ogni elemento è definito da due numeri reali,
uno rappresentante la quantità di materiale trasferito e uno rappresentante la posizione
temporale in cui avverrà il trasferimento istantaneo. Per ogni linea di trasferimento ci
sono due variabili sui quali poter agire per ogni elemento, e considerando tutte le otto
linee di trasferimento ( 13, 14, 01, 02, 23, 24, 30, 40). I vincoli
presentati dal modello matematico si limitano ad evitare la contemporaneità degli
eventi.
A queste variabili bisogna poi aggiungere quelle relative ai livelli di produttività
delle singole macchine. Ogni funzione k(t) si è visto essere definita dal livello di
capacità produttiva mantenuto costante entro un intervallo di tempo. Ogni funzione è
definita tramite una funzione costante a tratti, di cui ogni tratto è definito da tre
variabili, il valore di inizio, il valore finale e il valore d’ampiezza. Per ogni tratto
costante elementare ci sono quindi 3 variabili liberamente assegnabili, perciò i vincoli
del modello ai livelli di produttività sono più complessi per quanto riguarda le funzioni
di trasferimento oggetti, in quanto queste funzioni hanno le particolarità di:
34
•
Essere superiormente limitate dalla quantità di massima capacità produttiva;
•
Avere il valore d’inizio tratto costante ≤ del valore di fine tratto costante per
ovvi motivi di logica rappresentativa;
•
Avere ogni valore finale di un tratto costante elementare coincidente con uno ed
un solo tratto iniziale del successivo tratto costante elementare;
Il simulatore sviluppato non consente tuttavia il trattamento di un numero così ampio di
controlli, infatti tramite le politiche di gestione è possibile unicamente modificare la
posizione temporale e quantità dei trasferimenti degli oggetti, mentre le capacità
produttive sono prefissate e variabili secondo un processo stocastico a densità di
probabilità troncata e media prefissata e deterministica. Con queste limitazioni i gradi di
libertà diminuiscono fortemente in quanto contengono solo il contributo delle funzioni
p(t).
35
3.5 Politiche di gestione degli Inventories
La simulazione di questo modello ha come scopo principale quello di valutare
delle performances in base ad un certo numero di politiche di gestione. La complessità
di gestione di un centro produttivo multi-site come questo introduce diverse
problematiche come quelle relative alla gestione degli shortage o alla ricerca del
corretto approvvigionamento. Si è reso quindi necessario la valutazione ed
implementazione di politiche di gestione per gli Inventories di materie grezze e per gli
Inventories di prodotti finiti. Queste politiche sono valutabili separatamente ai
magazzini in ingresso e ai magazzini in uscita alle macchine, ma combinabili
opportunamente si ottengono tutte le possibili politiche di gestione della supply chain.
Si analizzeranno ora le singole politiche non combinate.
Inventories in Ingresso ai Nodi
•
Politica CP (“Critical Purchase”): questa politica consente di gestire
inventory in ingresso anche con giacenze nulle. Questo tipo di gestione è
preferibile o quando i costi di acquisto di materiali sono una componente
sensibile o di alto costo, per cui conviene acquistare puntualmente alle
scadenza prestabilite senza aggiungere nuovi acquisti per ricolmare il
magazzino vuoto.
•
Politica MP (“Maximize Production”): questa politica privilegia una
gestione ottimale degli inventories, in quanto prevede di anticipare i
successivi acquisti di materiale nel caso in cui un inventory in ingresso al
nodo produttivo risulti svuotato completamente. Questa politica
garantisce prestazioni migliori in ogni situazione in cui si vogliano
mantenere utilizzate per il maggior tempo possibile le macchine e
diminuire la probabilità di non poter soddisfare le domande dei clienti.
36
Inventories in Uscita ai Nodi
•
Politica FS (“Fast Selling”): questa politica prevede la vendita dei
prodotti in magazzino senza particolare cura del relativo livello in
giacenza. Se un cliente ordina una certa quantità e nel magazzino ne è
presente una quantità inferiore, utilizzando questa politica la supply
chain si evade comunque l’ordine, ma ovviamente della massima
quantità vendibile, senza curarsi del restante quantitativo della domanda
insoddisfatta. Questa politica è preferibile in ogni situazione in cui ci sia
particolare attenzione sul velocizzare il flusso delle vendite, infatti il
tempo che intercorre tra la richiesta del materiale e l’evasione dell’ordine
è sempre nullo, e non è possibile avere quantitativi di materiale in attesa
di vendita a causa del completamento della quantità del lotto.
•
Politica FSD (“Fast Selling Delayed”): questa politica è simile alla
precedente ma con la differenza che il quantitativo di domanda
insoddisfatta viene fatta ritardare alla consegna successivamente
programmata. Questo particolare risulta positivo se consideriamo il
livello di magazzino di vendite che risulta mediamente più basso in
quanto non contiene più il quantitativo di domanda insoddisfatta, che ora
seppur con un certo ritardo risulta evasa.
•
Politica DOC (“Delayed Orders Chartered”): questa politica prevedere
l’evasione delle domande fino ad esaurimento scorte in magazzino come
le precedenti, ma con la modifica sostanziale che prevede la creazione di
nuovi ordini aggiuntivi della quantità di domanda insoddisfatta non
appena il livello di magazzino sia sufficientemente alto da consentirlo.
•
Politica OCO (“Only Complete Orders”): questa politica di gestione
prevedere l’evasione degli ordini esclusivamente se completi. Se quindi
il livello delle giacenze in magazzino non lo permette, l’ordine viene
ritardato non appena il livello di magazzino consenta di soddisfare la
domanda secondo i parametri quantitativi. Ogni domanda viene presto o
37
tardi evacuata ma con la possibilità di ritardi anche significativi.
Generalmente questa politica di gestione non è preferibile in molte
applicazioni, in quanto comporta una maggior probabilità di ottenere
risultati di performances globalmente insoddisfacenti.
La combinazione di queste politiche di gestione singolari, compone le otto politiche di
Gestione di Inventory implementabili nel simulatore, che contengono gli aspetti positivi
e negativi delle singole politiche di gestione a livello di magazzino in ingresso o in
uscita al nodo. Esse sono:
1. CP+FS
Critical Purchase
with
Fast Selling
2. CP+FSD
Critical Purchase
with
Fast Selling Delayed
3. CP+DOC
Critical Purchase
with
Delayed Orders Chartered
4. CP+OCO
Critical Purchase
with
Only Complete Orders
5. MP+FS
Maximize Production
with
Fast Selling
6. MP+FSD
Maximize Production
with
7. MP+DOC
Maximize Production
with
8. MP+OCO
Maximize Production
with
38
3.6 Indici Prestazionali
Per quanto concerne la misurazione delle performance, il modello prevedere il
calcolo di due categorie distinte di Indici: Strutturali ed Economici.
Indici Strutturali:
Rappresentano quegli indici che vengono calcolati e che variano in relazione a
cambiamenti della struttura di simulazione. In questo caso, il sistema prevede sempre di
mantenere inalterata la struttura dei quattro Impianti interconnessi nello stesso modo,
ma con la possibilità di variare le politiche di gestione degli inventory. Le politiche di
gestione degli inventory previste si suddividono a loro volta per le politiche di gestione
degli inventory in ingresso e in uscita.
Per quanto riguarda le politiche di gestione degli inventory in ingresso:
1.
Politica “Critical Purchase”: in questo caso se il livello dell’inventory
in ingresso è nullo, la macchina non ha a disposizione alcun oggetto da
processare e di conseguenza produce un costo di inattività. Questo
costo si ripercuote sia nel livello di inventory in uscita (in quanto
risulta non più strettamente crescente ma rimane costante) e più
direttamente il costo influisce sull’indice del costo di produzione e
dell’utilizzazione della macchina (che vedremo più avanti).
2.
Politica “Maximize Production”: prevede che nel caso di inventory
nullo, si anticipi il successivo acquisto presente nella lista degli eventi
attivi di tipo “nuovo acquisto allo stesso nodo”, il che comporta da un
lato l’annullamento dei temi di inattività della macchina al centro
produttivo, e d’altra parte si traduce nell’aggiunta di un costo di
“anticipo domanda” che è misurabile in questo modo:
Costo di acquisto anticipato:
39
dove,
è un coefficiente opportuno di peso dell’indice;
è l’istante temporale in cui sarebbe dovuto avvenire l’acquisto;
è l’istante temporale in cui viene richiesto l’anticipo;
Per quanto riguarda le politiche di gestione degli inventory di uscita al centro
produttivo i-esimo, si differenziano nei casi in cui la quantità di magazzino sia
insufficiente per soddisfare la domanda. In questo casi è possibile valutare il costo di in
soddisfacimento della domanda come segue:
Costo di non Soddisfacimento della domanda:
dove,
sono coefficienti opportuni di peso per l’indice prestazionale;
rappresenta la quantità di domanda j-esima richiesta dal cliente al sistema;
è la quantità effettivamente consegnata (la massima disponibile);
è l’istante temporale entro cui viene soddisfatta in ritardo la domanda j-esima;
è l’istante temporale in cui viene richiesta la domanda j-esima;
La scelta dei coefficienti di peso viene opportunamente scelta in base alla politica di
gestione, infatti si ottiene:
40
1.
Politica “Fast Selling”: in questo caso se la domanda eccede la
giacenza del magazzino, l’algoritmo di aggiornamento del magazzino
procede consegnando tutto il contenuto del magazzino e ignorando la
domanda insoddisfatta (non prevede né ritardi né ulteriori consegne
per coprire la quantità richiesta). Questo tipo di scelta influisce
negativamente in quanto una certa quantità di materiale si sarebbe
potuto vendere ed invece è andata persa. Questa perdita è
quantificabile attraverso l’indice di non soddisfacimento della
domanda utilizzando come coefficienti:
≠0
=0
2.
Politica “Fast Selling Delayed”: La situazione di applicabilità è
identica alla precedente, ma con la differenza che la quantità di
domanda insoddisfatta non viene più ignorata, ma bensì aggiunta al
successivo ordine e quindi ritardata di una certa quantità di tempo. E’
per questo che si creerà un costo quantificabile utilizzando i
coefficienti:
≠0
≠0
3.
Politica “Delayed Orders Chartered”: Se la domanda non è possibile
soddisfarla a pieno e prima di un successivo evento “nuova domanda
dall’esterno
allo
stesso
centro
produttivo”
l’inventory
è
sufficientemente alto da superare la quantità di domanda ritardata,
allora si crea un nuovo evento “domanda dall’esterno al nodo i-esimo”
della quantità in questione e temporalmente prima possibile. Questo
creerà un costo aggiuntivo per la creazione di un nuovo ordine,
quantificabile con:
41
≠0
≠0
4.
Politica “Only Complete Orders”: invece di spezzare gli ordini
creando ritardi solo su una parte della quantità, si può decidere di
ritardare in blocco tutto l’ordine, questo può accadere ad esempio se
non è possibile trasportare il materiale in due momenti distinti ma si è
obbligati a trasportare tutto il materiale in blocco. In conseguenza avrò
un costo di ritardo sulla consegna in questo caso più aggravato che in
precedenza:
=0
≠0
Indici Economici:
Per quanto riguarda la seconda categoria di indici, riguarda quelli in diretta relazione
con l’economia dell’Impianto e all’acquisto di materiali.
Ritroviamo ad esempio:
1.
Costo di Inventory: tiene conto del livello di inventory ed associa un
costo di una certa proporzione per il livello di inventory da sostenere,
nel caso che si stia valutando un inventory d’Ingresso con possibilità
di idle-time, si considera a diverso peso il livello di inventory
“mancato” ossia l’area negativa del grafico di livello.
Costo di Inventory:
42
dove,
,
coefficienti opportuni di peso per l’indice;
AreaPositiva quantità di giacenza in magazzino effettiva;
AreaNegativa quantità di magazzino virtualmente utilizzabile dal
macchinario per la lavorazione se il livello di giacenza non fosse zero;
2.
Costo di Produzione: quantifica il costo relativo all’usura del
macchinario. In questo costo ricadono costi di manutenzione, di
utilizzo e di consumo (es: l’energia elettrica).
Costo di Produzione:
dove,
a,b: coefficiente opportuno che quantifica il peso dell’indice,
identificabile anche come “numero di pezzi processati per unità di
tempo”.
tratti della funzione di produttività diversi da 0, con
relativa ampiezza;
quantità temporale in cui il macchinario risulta inutilizzato;
3.
Costo d’acquisto: porta informazioni su quanto costano tutti i materiali
che concorrono alla formazione del prodotto (materiali diretti).
Costo di Acquisto:
43
dove,
rappresenta l’area dell’impulso j-esimo;
CF: costi fissi
CV: costi variabili
4.
Utilizzazione della macchina: rappresenta un coefficiente limitato tra 0
e 1 che porta informazioni sulla percentuale di utilizzo della macchina.
Essa è sempre a 1 tranne che nei casi in cui ci sia la possibilità di idletime.
Utilizzazione macchina:
dove,
tempo in cui la macchina risulta attiva durante la simulazione;
è il tempo totale di simulazione;
44
L’applicazione Software
CAPITOLO IV: L’applicazione Software
4.0 Introduzione ( Il Linguaggio Java )
Fig 4.1
Il passo successivo nello sviluppo del Simulatore riguarda la progettazione
software. Ogni progetto software si articola in diverse fasi, tra le quali si rende
necessaria la scelta del linguaggio di programmazione dell’ambiente di sviluppo. La
scelta di questo studio è ricaduta sul Java Development Kit 1.6.0 SE, e le motivazioni a
valle di questa scelta si devono ricercare anzitutto nelle peculiarità che rendono questo
linguaggio un’alternativa valida in molti ambiti applicativi.
Orientamento agli Oggetti
La prima caratteristica irrinunciabile è l'orientamento agli oggetti. Questo
metodo di programmazione si basa sul fondamento teorico che produrre software risulti
più facilmente concettualizzabile e facilmente mantenibile se le procedure algoritmiche
45
ricalcano la rappresentazione di entità tangibili o astratte in cui il problema è
scomponibile (oggetti definiti da classi). Un simulatore progettato con un approccio ad
oggetti è facilmente concettualizzabile perché richiede meno sforzo da parte del
programmatore per trovare la corrispondenza di significato-significante tra il codice e la
realtà. Inoltre è scomponibile in moduli software facilmente gestibili e le cui modifiche
non interessano l’intero pacchetto software ma solo una piccola parte (le
implementazioni dei metodi che costituiscono le interfacce degli oggetti). Gli oggetti
infatti comunicano tra loro tramite lo scambio di messaggi regolate da interfacce
predefinite.
In Java le classi rappresentano le definizioni di ogni entità che può essere
utilizzata all’interno di una applicazione. La stessa applicazione principale è anch’essa
una classe, ma privilegiata per la presenza del metodo main che stabilisce un “punto di
partenza” a livello di istruzione. A loro volta le classi possono essere raggruppate
secondo funzionalità, scopo di visibilità dell’applicazione o qualsivoglia criterio. Questi
raggruppamenti si chiamano package e non sono altro che librerie comuni ad altri
linguaggi di programmazione, ma non solo. Il meccanismo infatti è provvisto di una
struttura gerarchica per l’assegnamento di nomi alle classi in modo da evitare eventuali
collisioni in caso in cui il programmatore usi lo stesso nome per differenti definizioni di
classe. Considerando la gestione di grandi progetti software, questi facilmente
richiedono l’integrazione di librerie sviluppate da terzi, è facile imbattersi in classi
“omonime” ma con implementazioni diverse. Oltre a questo, sono molti i benefici
nell’uso di questo meccanismo:
•
le classi possono essere mascherate all’interno dei package implementando
l’incapsulamento anche a livello di file;
•
le classi di un package possono condividere dati e metodi con classi di altri
package;
•
i package forniscono un meccanismo efficace per distribuire oggetti;
46
Indipendenza dalla piattaforma
L’indipendenza dal calcolatore è una peculiarità del linguaggio Java che risiede
nella sua natura di linguaggio semi-compilato. Un calcolatore elettronico infatti non è
altro che una macchina capace di eseguire automaticamente delle operazioni, e queste
operazioni possono essere ad esempio le istruzioni contenute in un programma Java. Il
formato sorgente per le applicazioni scritte in questo linguaggio non è altro che un
semplice file testuale ad estensione .java che viene costruito dal programmatore usando
sintassi ed istruzioni ad alto livello che possiedono caratteristiche naturali orientate agli
oggetti. Un file sorgente di questo genere può essere portato in esecuzione tramite due
passi fondamentali: la compilazione e l’interpretazione. Nonostante possa sembrare
antitetico, il file .java, una volta compilato viene tradotto in un file semi-compilato
.class denominato Bytecode. Questo formato garantisce la completa portabilità
dell’applicazione e viene eseguito agilmente da un interprete (Java Virtual Machine) che
è strettamente legato alla piattaforma del sistema operativo (come Microsoft Windows,
Mac OS, UNIX like). Si adopera come interfaccia tra il linguaggio macchina e può
essere eseguito su ogni calcolatore in possesso di una Java Virtual Machine (JVM).
Fig 4.2
47
JDBC (Java DataBase Connectivity)
E’ un middleware per database che consente l'accesso alle basi di dati da qualsiasi
programma scritto con il linguaggio di programmazione Java, indipendentemente dal
tipo di Database Management System utilizzato. È costituita da una API ( Application
Program Interface ), raggruppata nel package java.sql, che serve:
•
ai client per connettersi ad un database;
•
a fornire metodi per interrogare e modificare i dati;
È orientata ai database relazionali ed è Object Oriented. La piattaforma Java 2
Standard Edition contiene le API JDBC, insieme all'implementazione di un bridge
JDBC-ODBC, che permette di connettersi a database relazionali che supportino ODBC.
Questo driver è in codice nativo e non in Java. JDBC è uno strato di astrazione software
tra un'applicazione Java ed un database. La sua struttura a due livelli, permette di
accedere a database engine differenti, a patto che questi supportino l'ANSI SQL 2. I due
fondamentali componenti di JDBC sono:
•
Un'implementazione del vendor del RDBMS (in questo caso verrà utilizzato il
server MySql Copyright of MySQL AB, in versione 5.0.41-community-nt)
conforme alle specifiche java.sql.
•
L’applicativo che implementi il client (in questo caso tramite connessione
TCP/IP)
Il vendor deve fornire l'implementazione di una serie di interfacce definite dal
package
java.sql,
ovvero
Driver,
Connection,
Statement,
PreparedStatement,
CallableStatement, ResultSet, DatabaseMetaData, ResultSetMetaData. Verranno infatti
fornite alcune classi, che implementano i metodi delle interfacce appena citate.
Attualmente tutti i più importanti database engine, supportano driver JDBC.
Lo sviluppatore ha un compito piuttosto semplice: implementare del codice che sfrutta
l'implementazione del vendor, seguendo pochi semplici passi.
Un'applicazione JDBC deve:
48
•
Caricare un driver
•
Aprire una connessione con il database
•
Creare un oggetto Statement per interrogare il database
•
Interagire con il database
•
Gestire i risultati ottenuti
Il simulatore utilizza questa funzionalità per accedere ai dati della simulazione (sia i
parametri che le liste degli eventi discreti) da Database remoto. In questo modo si può
garantire la più completa genericità non solo dalla piattaforma di esecuzione, ma anche
dalla tipologia di dati memorizzati, che vengono acquisiti tramite un’interrogazione al
DBMS. Un DBMS è progettato per sistemi multi-utente, e a tale scopo, i DBMS si
appoggiano a kernel che supportano nativamente il multitasking e il collegamento in
rete. Grazie a questo accorgimento dunque, più istanze del simulatore, collocate su
calcolatori anche se fisicamente distanti, possono usufruire degli stessi dati, ed
eventualmente modificarli, rispettando i criteri della concorrenza tra applicazioni, in
quanto lo spazio di memoria condivisa si limita ai dati gestiti dal DBMS.
Fig 4.3
49
4.1 Le Strutture Dati
Per arrivare alla definizione delle strutture dati occorre seguire una procedura
sistematica in modo tale da non tralasciare alcun dettaglio da implementare. La branca
dell’ingegneria che si occupa dei processi produttivi e delle metodologie di sviluppo
finalizzate alla realizzazione di sistemi software è l’Ingegneria del Software. Questa ha
come proprio oggetto di studio l'uso e lo sviluppo delle metodologie e tecnologie
informatiche di supporto al processo di sviluppo del software. Infatti sulla base di alcuni
parametri è possibile suddividere il processo di produzione del software secondo stadi
progressivi:
•
Definizione Requisiti: riguarda il processo di scelta dei punti cardinali del
problema. Spesso la raccolta di ciò che si vuole ottenere dal progetto software
può non essere semplice in quanto la raccolta dei requisiti riguarda
l’estrapolazione dal linguaggio naturale dei punti chiave del software, e quindi
di cosa l’utente finale si aspetta di ottenere.
•
Modellazione: dai requisiti, in una fase non nettamente definibile ma collocabile
tra la definizione dei requisiti e l’ analisi di progettazione, è possibile discernere
una prima modellazione del sistema. Essa deve tenere conto dei risultati
riguardo la presentazione delle prospettive esterne (il sistema nell’ambiente),
comportamentali e strutturali (l’architettura dei dati).
•
Progettazione: rappresenta una fase distinta dalla programmazione o codifica,
che corrisponde alla traduzione in un particolare linguaggio di programmazione
(es. Java) scelto in base alle caratteristiche offerte in fase di progettazione. Le
distinzioni fra le attività fin qui menzionate non sono sempre chiare come
vorrebbero le teorie classiche dell'ingegneria del software. La progettazione, in
particolare, può descrivere il funzionamento interno di un sistema a diversi
livelli di dettaglio, ciascuno dei quali si colloca in una posizione intermedia fra
analisi e codifica. Normalmente si intende con progettazione dell'architettura la
50
progettazione in cui si definisce solo la struttura complessiva del sistema in
termini dei principali moduli di cui esso è composto e delle relazioni
macroscopiche fra di essi. A questo livello di progettazione appartengono
formule come client-server, three-tier, o più in generale decisioni sull'uso di
particolari architetture hardware, sistemi operativi, DBMS, protocolli di rete.
Una livello intermedio di dettaglio definisce ancora la scomposizione del sistema in
moduli, ma questa volta con riferimento più o meno esplicito alle modalità di
scomposizione offerte dal particolare linguaggio di programmazione con cui avverrà lo
sviluppo; per esempio, in una progettazione condotta con tecnologie orientato agli
oggetti come in questo caso, il progetto potrebbe descrivere il sistema in termini delle
principali classi e delle loro interrelazioni.
Il progetto di dettaglio, infine, rappresenta una descrizione del sistema molto
vicina alla codifica, ovvero che la vincola in maniera sostanziale (per esempio,
descrivendo non solo le classi in astratto ma anche i loro attributi e metodi, con relativi
tipi. A causa della natura "astratta" del software, e a seconda degli strumenti che si
utilizzano nel processo, il confine fra progettazione e codifica può essere anche
praticamente impossibile da identificare. Per esempio, alcuni strumenti CASE sono in
grado di generare codice a partire da diagrammi UML che descrivano graficamente la
struttura di un sistema software. In questo caso non sono stati utilizzati perché è stato
ritenuto sostenibile il carico di codice da produrre rispetto alle tempistiche assegnate, in
generale questi strumenti vengono utilizzato nello sviluppo di software “altamente
modulari” ossia il cui contenuto e' sensibilmente suddiviso tra team di sviluppatori. In
questi casi si preferisce spendere del tempo nell’organizzazione dell’ how-to, invece che
rischiare di incontrare errori risolvibili solo in una fase precedente (modellazione o più
sfortunatamente in raccolta requisiti).
Descrizione del Package it.unige.dist.automazione_industriale.impianto
In questo package sono racchiuse le definizioni per le classi necessarie al
funzionamento del motore di simulazione. Sono comprese sia le classi utili alla
51
rappresentazione dei dati da manipolare, e sia quelle che ne definiscono le metodologie
di elaborazione. Qui sotto si riporta il l’UML Package Diagram:
Fig 4.4
In particolare il package contiene le classi:
•
PData: l’oggetto in questione serve per rappresentare l’informazione minima
che descrive l’elemento fondamentale delle funzioni di tipo Pxy(t) , ossia
l’impulso di area finita (posizione temporale ed ampiezza);
52
Fig. 4.5
•
Fig 4.6
PDataComparator: implementa l’interfaccia java.util.Comparator<PData> che è
utilizzata nella funzione di ordinamento. Data una lista di elementi PData, questa
classe determina le regole secondo le quali effettuare l’ordinamento desiderato.
Fig. 4.7
•
KData: l’oggetto che rappresenta l’informazione elementare per rappresentare le
funzioni k(t) (ampiezza gradino, posizione temporale per l’inizio e la fine della
sua durata);
Fig. 4.8
53
•
PPlotter:
questa
classe
serve
per
memorizzare
effettivamente
tutta
l’informazione contenuta nelle funzioni Pxy(t). Contiene al suo interno una lista
di elementi PData, e quindi è nient’altro che la memorizzazione in struttura dati
di una funzione di tipo impulsivo.
Fig 4.9
•
KPlotter: analogamente per memorizzare le funzioni k(t) si è deciso di adottare
un approccio analogo: un oggetto di tipo KPlotter contiene le funzioni d’accesso
e i dati per la memorizzazione di una funzione costante a tratti (contiene una
lista di PData).
Fig 4.10
•
GraficoP: estende un JPanel e costituisce l’oggetto responsabile della creazione
del disegno del grafico per gli oggetti di tipo p(t). Contiene inoltre un
ActionListener, che ha il compito di ascoltare gli eventi prodotti dal mouse per
mostrare i dati contenuti nelle sorgenti d’informazione.
54
Fig 4.11
•
GraficoK: anche per quanto riguarda la visualizzazione dei grafici di tipo k(t), si
estende un JPanel effettuando anche in questo caso l’override del metodo
paintComponent(Graphics) responsabile del disegno all’interno del JPanel.
•
Impianto1Liv, Impianto2Liv: rappresentano le due classi fondamentali per il
funzionamento del simulatore. Modellano il funzionamento dei nodi di
produzione della supplì chain, e contengono tutte le strutture dati per:
-
memorizzazione livelli di inventory;
-
memorizzazione dati in ingresso, di routing tra i nodi, domande esterne;
-
salvare i dati temporanei (calcolo degli integrali) in modo tale da
alleggerire l’onere degli algoritmi di calcolo prestazionale;
-
salvare l’informazione a riguardo del tipo di politica di gestione
utilizzata nella gestione degli inventory;
All’interno delle classi di Impianto sono state costruite due classi private interne
X e Xprimo che estendendo JPanel completano tutti i metodi per il disegno e
calcolo delle Aree sottese dai grafici di Inventory x(t) e x’(t).
Le due classi si differenziano però in termini di gestione degli Inventory.
Per semplicità di rappresentazione infatti, gli Impianti di secondo livello
(Nodo3, Nodo4) non implementano le politiche di anticipo acquisti per quanto
riguarda l’approvvigionamento degli Inventory di materie grezze. Questo per
55
semplicità di classificazione delle politiche di gestione, diversamente l’algoritmo
avrebbe dovuto prevedere cicli di ricorsione e feedback per modificare gli
ingressi al primo livello anche dagli impianti del secondo livello.
Fig 4.12
•
IndiciDiPrestazione:
questa
classe
contiene
le
strutture
dati
per
la
memorizzazione e manipolazione dei coefficienti che pesano i diversi indici
prestazionali calcolabili nella simulazione. Inoltre fornisce all’interfaccia grafica
un JPanel esteso contenete l’interfaccia utente utilizzabile per variare questi
indici all’inizio della simulazione (e non a simulazione già avvenuta).
56
Fig 4.13
57
Fig 4.14
58
Fig 4.15
59
Descrizione del Package it.unige.dist.automazione_industriale.interfaccia
Questo modulo contiene le definizioni delle classi che compongono l’interfaccia
grafica ed i metodi finali con il quale il motore di simulazione deve entrare in funzioni.
In particolare si definiscono i layout, la disposizione dei visualizzatori di grafici, la
posizione dei pulsanti e le funzionalità a disposizione dell’utente utilizzatore.
•
PannelloPolitiche: Estende JPanel e fornisce all’utente il modulo per la scelta
mutuamente esclusiva di una tra le otto possibili politiche di gestione di
inventory.
Fig 4.16
•
SplashScreen: Questa classe è utilizzata dal programma per costruire il pannello
visualizzato in apertura del programma. Uno splash screen è l'immagine che
viene visualizzata quando un’applicazione è in fase di caricamento può essere
generalmente tradotto con “schermata di caricamento”. Gli splash screen sono
usati da applicazioni grandi e che consumano risorse in fase d’esecuzione tanto
da giustificare un significativo ritardo nella fase di boot. Questi forniscono
all'utente un feedback che un lungo processo è in corso, e scompaiono quando la
finestra principale del programma viene visualizzata. Gli splash screen sono
usati per dare una buona impressione grafica di un'applicazione che siccome
impiega un certo lasso di tempo per caricarsi, non sempre è gradita all’ utente. In
questo caso lo splash screen è giustificato sia dal fatto che le applicazioni Java
presentano generalmente un avvio più macchinoso (dovuto alla parziale
60
interpretazione del codice oggetto), sia dalla possibilità di avviare il programma
acquisendo direttamente i dati dal DBMS. Questo può presentare tempi di
accesso ai dati variabili e lassi di tempo più lunghi dovuti al meccanismo di
connessione tramite JDBC.
Fig 4.17
•
SplashScreenMain: questo oggetti è responsabile del caricamento dello splash
screen. Mette in pausa il processo caricante l’oggetto di tipo SplashScreen e
lancia in esecuzione il thread contenente l’applicativo principale (oggetto di tipo
Desktop). Contiene inoltre la funzione privilegiata public static void main(String
args[]), e perciò rappresenta il primo oggetto chiamato in esecuzione dalla JVM.
Fig 4.18
•
ExcelCreator: questo oggetto contiene un unico metodo che viene chiamato per
costruire la struttura del file ad estensione .xls contenente la tabella formattata ad
Microsoft© Excel© dei risultati di simulazione.
Fig 4.19
•
BasePanel: Questo JPanel esteso costituisce il cuore dell’interfaccia del motore
simulativi. Contiene gli oggetti di tipo Impianto1Liv e Impianto2Liv e fornisce
tutti i metodi per la costruzione, inizializzazione ed accesso allo schema.
61
Fig 4.20
•
Desktop: è un oggetto contenitore per la struttura modulare MainFrame. Questo
consente l’esecuzione contemporanea di diverse istanze del simulatore, che
possono essere differenziate le une dalle altre per dati di ingresso (siano essi
livelli di produzione che eventi attivi).
Fig 4.21
•
MainFrame: questa classe che estende le funzionalità di visualizzazione del
JFrame, contiene un oggetto di tipo basePanel e integra la sua istanza con i
pannelli che contribuiscono a fornire le funzionalità più dirette al simulatore. Tra
esse si ricorda la barra laterale rightFrame contenente i visualizzatori dei dati e il
62
pulsante di avvio di simulazione; l’oggetto di tipo JMenuBar contenente le
funzionalità basilari per ogni Simulatore (schema di modello, pannello politiche
di gestione, pannello di modifica dei coefficienti).
Fig 4.22
63
Descrizione del Package it.unige.dist.automazione_industriale.database
Questo package contiene solamente due definizioni di classi, ma che per loro
natura completamente indipendenti dai due precedenti. La sua creazione è stata dettata
dall’esigenza di isolare dai moduli software del motore di simulazione e dell’interfaccia,
le funzionalità necessarie per l’identificazione e connessione dell’applicazione al
DBMS. Infatti questo package contiene:
•
DbUser: Questa classe incapsula le informazioni riguardante l’utente che
intende collegarsi ad un dato database. Conglomera infatti i dati relativi a
username, password di accesso al server, nonché indirizzo IP, numero della porta
a cui si devono essere inviati i pacchetti di informazione, ed il nome del database
a cui si intende accedere. E’ presupposto ipotetico che questi dati siano integri e
funzionanti.
Fig 4.23
•
Connect: Una volta acquisiti i dati relativi all’utente e al database a cui accedere,
l’oggetto Connect si preoccupa di stabilire una connessione TCP/IP stabile con il
database server. Nel qual caso l’integrità dei dati sopraccitata non fosse
soddisfatta, l’oggetto Connect lancerà l’opportuna eccezione, e darà avviso allo
sviluppatore del tipo di eccezione raccolta.
Fig 4.24
64
4.2 L’algoritmo di simulazione
Il simulatore è stato progettato in modo tale da rimanere il più fedele possibile
all’algoritmo analizzato nel capitolo primo. Come simulatore ad eventi discreti, il suo
stato cambia in funzione del verificarsi di un dato evento. Questi eventi possono essere
di 12 tipologie fondamentali:
•
Arrivo di N oggetti sul nodo 1;
•
Arrivo di N oggetti sul nodo 2;
•
Trasferimento di N oggetti dal nodo 1 al nodo 3;
•
•
•
•
Prelievo di N oggetti dal nodo 3;
•
Prelievo d N oggetti dal nodo 4;
•
Variazione del livello di produttività al Nodo 1;
•
•
•
La lista degli eventi attivi potrà contenere eventi di 12 tipologie differenti e in
base al loro verificarsi, il sistema aggiornerà di conseguenza le 8 equazioni di stato. Il
sistema prevede anzitutto un controllo sull’integrità dei file sorgenti (all’interno degli
oggetti KPlotter, PPlotter gli errori in apertura dei file o nell’oggetto Connection se si
utilizza il database server), e una volta acquisiti i dati deterministici in ingresso,
l’algoritmo procede alla costruzione dei diversi nodi, affidando ad ogni oggetto di tipo
Impianto1Liv o Impianto2Liv una propria copia delle funzioni di trasferimento oggetti
(si è preferito fornire ogni oggetto Impianto della propria copia di dati, nonostante
questo comporti la duplicazione di dati e complicazioni negli aggiornamenti, per
favorire invece l’indipendenza degli oggetti dai collegamenti e rendere più flessibile la
scelta delle politiche di gestione). Le liste degli eventi attivi (LEA(t)) e dei tempi degli
65
eventi attivi(LTEA(t)) sono memorizzate nelle strutture PPlotter e KPlotter, divise per
struttura di memorizzazione (KData o PData), ma riconosciuti con eterogeneità
all’interno dell’algoritmo e quindi considerati come facenti parte di un’unica lista.
Vengono quindi inizializzati gli oggetti GraficoK e GraficoP per ogni impianto, e
calcolati i grafici X e XPrimo relativi agli Inventory in ingresso e in uscita ad ogni
Nodo produttivo. L’algoritmo fondamentale per il funzionamento e conferma delle
modifiche nei parametri di simulazione è quello avviato dal processo di “iniziazione
Simulazione” azionato dall’attivarsi dell’ActionListener collegato al JButton fineSim
contenuto nell’oggetto di tipo MainFrame.
Al Verificarsi di un’azione di questo tipo, l’algoritmo procede anzitutto ad
impostare il valore scelto come tempo di fine simulazione (ipotesi: il tempo di
simulazione deve mantenere l’integrità dei dati e quindi avere definito per tutta la durata
della simulazione le funzioni k(t) e p(t)), e quindi alla selezione delle politiche di
gestione, in dipendenza delle quali verranno chiamate opportune funzioni che
specializzano l’evoluzione dei magazzini. Sia per quanto riguarda il calcolo degli indici
prestazionali, sia dei calcoli integrali, vengono incrementalmente aggiornate le variabili
ad essi associati durante il procedere dell’algoritmo. Se le ipotesi di modello vengono
rispettate, l’algoritmo si conclude con successo ed i risultati presentati nelle schermate
di output del sistema sono consistenti. Un tipo di studio che nell’ultimo capitolo
poteremo a termine riguarda l’analisi dei risultati, che per quanto riguarda questo
applicativo software, si sofferma principalmente su di una scelta mirata di una delle otto
politiche di gestione degli Inventory. In base alla valutazione degli indici prestazionali,
si conviene alla ricerca della politica migliore (anche se non ottima) selezionabile tra le
scelte a disposizione. Questo tipo di scelta è utile in tutte le applicazioni in cui sono
richieste delle scelte forzate ed i gradi di libertà sul sistema sono vincolati da un numero
finito di scelte possibile ( ne sono presentate otto, ma il numero è flessibilmente
modificabile ), quindi utilizzabile in tutti gli ambiti le cui decisioni hanno ripercussione
sul breve periodo e in cui la fase di progettazione non consente il re-engineering dei
processi in modo tale da inseguire criteri di ricerca ottima delle performances del
sistema. Come nota, si segnala che tutti i calcoli portati avanti nella simulazione sono
calcolati usando cifre decimali rappresentate in virgola mobile a doppia precisione.
66
4.3 L’interfaccia Grafica e le funzionalità
L’interfaccia grafica è stata sviluppata tenendo conto dei fondamenti principali
dell’usabilità e chiarezza nel presentare i risultati. Nonostante rappresenti una piccola
parte della porzione di codice del software, l’interfaccia grafica concentra oltre l’80%
del tempo in fase di progettazione in quanto l’usabilità e la scelta di una data
configurazione di elementi è un processo tutt’altro che standardizzabile ed
arbitrariamente risolvibile. L’interfaccia grafica ha il compito principale di presentare i
dati utili dell’utente nel modo più velocemente riconoscibile ed utilizzabile, ogni utente
deve trarre vantaggio dall’applicazione con il minor sforzo possibile, in modo tale da
poter concentrare i propri sforzi sull’interpretazione dei risultati contenuti anziché sulla
decifrazione del contenitore. Il concetto di interfaccia è collegato direttamente alla
filosofia Object Oriented, in cui i dati disponibili ad un utente debbano essere filtrati
attraverso metodi di qualsiasi natura essi siano, in modo tale da facilitare la
comunicazione tra oggetti, o come in questo caso tra oggetto e persona. L’interfaccia
grafica che è stata sviluppata in questo contesto, possiede una struttura che è
schematizzabile come segue:
Fig 4.25
67
La struttura esterna è formata dall’oggetto Desktop che non è altro che contenitore ed
distanziatore di oggetti estesi da JFrame. Sia Desktop che MainFrame possiedono due
JMenuBar con diverse funzionalità:
Fig 4.26
•
Desktop.Nuovo: Istanzia un nuovo oggetto di tipo MainFrame;
•
Desktop.Sorgenti: Apre la schermata di scelta dei sorgenti ( testo/DBMS );
•
Desktop.Chiudi: Forza l’uscita dall’applicazione;
•
Desktop.Help: contiene informazioni collaterali sul programma (es. versione);
Fig 4.27
•
MainFrame.Modello di Simulazione: visualizza lo schema di modello del
sistema su cui si basa il simulatore;
•
MainFrame.Modifica Coefficienti Indici: visualizza la schermata di modifica
e aggiornamento dei coefficienti per il calcolo delle prestazioni. In questo
modo è possibile modificare ad hoc i pesi attribuibili ad ogni singolo indice;
68
•
MainFrame.Risultati: una volta conclusa un esperimento simulativo, questo
mostra una finestra contenente i risultati relativi all’ultima simulazione
effettuata;
•
MainFrame.Politiche di Inventory: visualizza la schermata con la quale è
possibile selezionare la politica di Inventory utilizzabile per il successivo
esperimento simulativo;
E’ stata scelta questa struttura in modo tale da facilitare la coesistenza di diverse
istanze di simulazione e nel contempo avere la possibilità di condividere un ambiente di
lavoro tra le diverse simulazioni, che in un ipotetico sviluppo potrebbe così più
facilmente integrarsi con altri esperimenti di simulazione.
Entrando più nello specifico, un altro significativo problema riguarda senz’altro
la disposizione degli elementi all’interno del frame principale: MainFrame. La struttura
è stata progettata in modo tale da suddividere l’area di lavoro in due zone: A sinistra il
pannello per la visualizzazione dei grafici in output, mentre a destra si trova il menu di
visualizzazione dei calcoli svolti. In questo modo
è possibile avere in una stessa
schermata di lavoro, tutti i grafici relativi ad un nodo produttivo e tutte le informazioni
relative alle prestazione misurate da quel preciso andamento. I diversi nodi produttivi
inoltre sono facilmente navigabili attraverso l’uso di un JTabbedPan selezionando uno
tra gli otto diversi Inventory visualizzabili. In conclusione la struttura risulta del tipo:
Fig 4.28
69
Analisi dei Risultati
CAPITOLO V: L’Analisi dei Risultati
5.0 Introduzione
Fig 5.1
L’analisi dei risultati riveste un ruolo chiave nella progettazione di ogni sistema.
I risultati per loro natura sono il punto di arrivo ultimo tramite il quale è possibile
intraprendere decisioni ed ottenere quindi l’informazione attesa dall’elaborazione. Il
simulatore sviluppato in questo ambito presenta risultati di almeno tre tipologie:
•
Grafici per il tracciamento dell’evoluzione dei livelli di Inventory nel tempo:
l’informazione dei livelli di magazzino
•
Risultati dei calcoli presentati all’interno del programma;
•
Memorizzazione degli stessi risultati in documenti formattati in documenti
Excel;
70
Nella disposizione dei risultati i grafici hanno un ruolo importante, in quanto
l’informazione riguardo alle variazioni degli immagazzinamenti si prestano bene ad una
rappresentazione bidimensionale. A questo scopo è utile citare lo studio del dott.
Jacques Bertin nella “Sémiologie Graphique” del 1967. Intraprese il primo studio
approfondito sulle relazioni tra i dati e le loro rappresentazioni grafiche. Identificò tre
tipologie base per la simbologia grafica (come punti linee ed aree) e sette variabili di
visualizzazione (posizione planare, dimensione, valore in scala di grigio, texture, colore,
orientazione e forma).
La tabella riportata di sotto riporta la sintesi di questo studio, che mette in relazione
la semiotica1 dell’informazione con la tipologia di informazione da manipolare , sia essa
Nominale, Ordinale e Quantitativa.
L’informazione nel nostro caso è di tipo quantitativo, per cui la scelta di
utilizzare dei grafici è senza dubbio ottimale, in quanto un grafico viene interpretato dal
fruitore tramite la posizione dei punti nello spazio, ricadendo nell’ultimo caso ad
efficienza massima.
Fig 5.2
1
In alternativa semiologia, deriva dal termine greco σηµεῖον semeion, che significa "segno"; è la
disciplina che studia i segni e i fenomeni di significazione e di comunicazione.
71
E’ importante anche soffermarsi ad analizzare anche la tipologia di informazione
con particolare interesse ad alcune sue caratteristiche, come la stima dei parametri in
ingresso, la stima dei parametri in uscita e gli effetti della precisione finita dei calcoli in
virgola mobile a doppia precisione. Un risultato di tipo non analitico, come quello
ottenuto dalla simulazione, è ritenuto valido soltanto se ottempera a determinate
condizioni ad intervalli di confidenza e precisione. E’ bene quindi conoscere a fondo gli
effetti che queste precisioni finite hanno durante l’algoritmo di elaborazione per
comprendere quanto possano ritenersi affidabili i risultati ed avere una misura
dell’affidabilità dell’algoritmo.
72
5.1 Effetti della precisione finita
Tutte le procedure algoritmiche si basano su rappresentazioni numeriche di tipo
double. In Java la rappresentazione virgola mobile doppia precisione, consente la
rappresentazione di numeri tra +/- 1.7 x 10e308 con 15 cifre significative. I tipi in
virgola mobile (float, double) rappresentano i numeri con una precisione finita e
introducono approssimazioni, mantenendo d’altra parte una maggior ampiezza nello
spazio di rappresentazione dei numeri. In generale, questo tipo di numeri si comporta in
modo molto simile ai numeri reali. Tuttavia ciò porta spesso i programmatori a non
considerare l'importanza di un'adeguata analisi numerica sui risultati ottenuti. Ci sono
molte incongruenze tra il comportamento dei numeri in virgola mobile impiegati
nell'informatica e quello dei numeri reali, anche in casi molto semplici (ad esempio la
frazione 0,1 che non può essere rappresentata da nessun sistema binario in virgola
mobile). Le cause principali di errore nel calcolo in virgola mobile sono:
•
arrotondamento
numeri non rappresentabili (0,1);
arrotondamento di operazioni aritmetiche (2/3=0,666667);
•
assorbimento (1×1015 + 1 = 1×1015);
•
cancellazione (es.: sottrazione di due numeri molto vicini);
•
overflow (con segnalazione di risultato infinito);
•
underflow (dà come risultato 0, un numero subnormale o il più piccolo
numero rappresentabile);
•
operazioni impossibili (es.: radice quadrata di un numero negativo diverso da
zero, danno come risultato Nan);
•
errori di arrotondamento;
Gli algoritmi utilizzati nel software eseguono ciclicamente unicamente somme e
moltiplicazioni con i numeri double, e in generale, a parte la complessità del calcolo,
quello che preme osservare è che il risultato è funzione dell'ordine con cui vengono
eseguite le somme e moltiplicazioni: in particolare, i primi coefficienti sono quelli che
danno un peso maggiore all'errore finale, quindi errori minori si hanno se i primi
73
coefficienti da sommare sono più piccoli. Di questo aspetto bisogna tenerne conto
benché non siano stati previsti all’interno del codice, alcun accorgimento per ovviare a
queste imprecisioni.
74
5.2 Criteri di Scelta e Politica di Gestione Migliore
Una volta conclusa la simulazione, l’utente ha a disposizione i risultati da
analizzare per trarre le conclusioni relative allo scenario simulato. Si possono trarre
conclusioni sia riguardo aree strettamente specifiche come la ricerca del minimo costo
d’acquisto, della massima utilizzazione media, oppure tramite criteri di scelta che
tengano conto della globalità degli indici calcolabili. Questi criteri di scelta sono
ottenibili per esempio analizzando le diverse politiche di gestione e scegliendo quella
che maggiormente si avvicina al realizzare le richieste della supply chain.
A titolo di esempio ora si analizzeranno un esperimento simulativo realizzato e
verificando politica per politica gli effettivi vantaggi e svantaggi dall’utilizzo delle
stesse.
Dati in Ingresso:
75
Simulazione d’Esempio:
Risultati:
Politica -->
Nodo 1
Util%
C. Acq.
C. di Prod.
C. Inv, IN
C. Inv. OUT
C. Ant. Acq.
C. Ins.Dom.
Nodo 2
Util%
C. Acq.
C. di Prod.
C. Inv, IN
C. Inv. OUT
C. Ant. Acq.
C. Ins.Dom.
Nodo 3
Util%
C. Acq.
C. di Prod.
C. Inv, IN
C. Inv. OUT
C. Ant. Acq.
C. Ins.Dom.
Nodo 4
Util%
C. Acq.
C. di Prod.
C. Inv, IN
C. Inv. OUT
C. Ant. Acq.
C. Ins.Dom.
Media
Util%
C. Acq.
C. di Prod.
C. Inv, IN
C. Inv. OUT
C. Ant. Acq.
C. Ins.Dom.
C. Acq. Tot
C. Inv. Tot.
CP+FS
CP+FSD
CP+DOC
CP+OCO
MP+FS
MP+FSD
MP+DOC
MP+OCO
97,92
419,49
306,82
26660,44
22635,82
0
19,55
97,92
419,49
306,82
26660,44
14007,14
0
52,93
97,92
419,49
306,82
26660,44
29545,67
0
121,9
97,92
419,49
306,82
26660,44
53179,96
0
101,98
100
419,49
299,97
12130,12
25511,9
337,78
19,55
100
419,49
299,97
12130,12
12181,51
337,78
45,71
100
419,49
299,97
12130,12
29558,17
337,78
88,81
100
419,49
299,97
12130,12
55358,76
337,78
101,98
93,14
379,14
304,88
19931,52
13105,26
0
11,72
93,14
379,14
304,88
19931,52
14206,32
0
35,2
93,14
379,14
304,88
19931,52
16930,41
0
156,24
93,14
379,14
304,88
19931,52
19934,26
0
32,43
100
379,14
278,17
17922,42
16207,62
253,87
7,32
100
379,14
278,17
17922,42
13074,47
253,87
36,74
100
379,14
278,17
17922,42
17027,84
253,87
83,53
100
379,14
278,17
17922,42
19848,73
253,87
42,21
69,17
298,94
414,69
14445,59
23612,62
0
0
74,82
319,63
391,79
11559,99
26742,56
0
134,81
69,36
298,77
413,9
15932,59
26742,56
0
0
80,05
386,35
370,62
21966,53
23670,56
0
0
69,17
298,94
414,69
14445,59
23612,62
0
0
77,49
330,47
380,99
12216,63
26742,56
0
134,81
69,34
298,77
414,01
16401,83
26742,56
0
0
78,84
346,42
375,53
14617,7
23670,56
0
0
56,97
21,32
56,98
709,99
2212,98
0
5,88
66,92
24,23
52,51
743,51
1522,36
0
9,4
39,11
12,86
65,02
1324,78
1164,52
0
65,05
43,06
16,49
63,24
882,09
1365,03
0
4,33
70,57
25,71
50,86
883,32
2212,98
0
5,88
73,58
26,52
49,51
831,07
1522,36
0
9,4
57,85
19,19
56,58
1181,53
1164,52
0
65,05
67,12
22,82
52,42
1441,56
1365,03
0
4,33
79,3
279,7225
270,8425
15436,89
15391,67
0
9,2875
279,7225
30828,56
83,2
285,6225
264
14723,87
14119,6
0
58,085
285,6225
28843,46
74,8825
277,565
272,655
15962,33
18595,79
0
85,7975
277,565
34558,12
78,5425
300,3675
261,39
17360,15
24537,45
0
34,685
300,3675
41897,6
84,935
280,82
260,9225
11345,36
16886,28
147,9125
8,1875
428,7325
28231,64
87,7675
288,905
252,16
10775,06
13380,23
147,9125
56,665
436,8175
24155,29
81,7975
279,1475
262,1825
11908,98
18623,27
147,9125
59,3475
427,06
30532,25
86,49
291,9675
251,5225
11527,95
25060,77
147,9125
37,13
439,88
36588,72
76
La tabella riporta nella prima parte i risultati ottenuti singolarmente ad ogni nodo
produttivo, per analizzare in dettaglio l’andamento delle prestazioni e poter analizzare
quali tra questi sono artefici dell’abbassamento o innalzamento delle performances. In
fondo, nella seconda parte della tabella sono riportati invece i risultati della media
aritmetica sui quattro nodi. Segnate in grigio scuro vi sono rappresentate le caselle che
hanno fatto registrare i primi due risultati positivi tra le diverse politiche.
E’ possibile ad esempio formulare uno studio atto a confermare l’evidente
supremazia delle politiche di gestione tramite gli indici prestazionali che, come si è
analizzato nel capitolo III, le caratterizzano al meglio. Di seguito si riportano i grafici
relativi agli indici prestazionali, suddivisi per politica di gestione.
77
78
In dettaglio, si commenteranno i grafici visti fino ad ora in base alla politica
CP+FS
Critical Purchase
with
Fast Selling
La prima politica riporta due indici favorevoli riguardo sia l’insoddisfacimento
della domanda che il costo d’acquisto anticipato. Analizzando invece anche il costo
degli acquisti, che si mantiene ad un livello mediamente basso, si può confermare che
questo tipo di politica sia veramente orientata a mantenere bassi i costi degli acquisti e
l’insoddisfacimento della domanda è conseguenza della gestione Fast Selling, che
seppur prevede insoddisfacimenti, per questa scelta di dati in ingresso rimangono di
poca influenza.
79
CP+FSD
Critical Purchase
with
La seconda politica invece riporta due indici favorevoli, riguardo gli acquisti
anticipati e il livello di Inventory in uscita a costo minimo. Questi due risultati
favorevoli confermano le cui caratteristiche per quanto riguarda entrambe le due
gestioni di Inventory, mentre è da notare il costo di non soddisfacimento della domanda,
che risulta sensibilmente alto, è dovuto in parte alla scelta dei coefficienti (si è scelto di
penalizzare maggiormente i ritardi nelle consegne piuttosto che le consegne incomplete)
e in parte al grado di ritardo maturato da alcune consegne (poche consegne con grandi
quantità di materiale).
CP+DOC
Critical Purchase
with
La terza politica di gestione registra risultati di minima spesa di acquisti in
assoluto rispetto a tutte le altre politiche, in accordo con la Critical Purchase scelta per
gli inventory in ingresso, mentre se osserviamo i livelli delle giacenze in magazzino,
vediamo essere molto alti, in quanto per molto tempo il magazzino è rimasto occupato
da risorse nello stato di vendita ma in attesa del completamento del lotto.
CP+OCO
Critical Purchase
with
La quarta politica esaspera il livello delle giacenze in magazzino che
mediamente è il peggiore degli altri casi. Questo dovuto al fatto che le vendite sono
eccessivamente ritardate e molte addirittura rimangono inevase a termine della
simulazione.
MP+FS
Maximize Production
with
Fast Selling
La quinta politica riesce ad utilizzare i macchinari in modo tale da produrre con
maggior profitto, e questo si può evincere notando il rapporto tra il costo di produzione
limitato e i costi di inventory di ingresso bassi. Questo significa che con poco materiale
80
il macchinario è riuscito a produrre in continuazione (nel costo di produzione non
gravano più i costi di inutilizzazione della macchina). Inoltre i livelli di utilizzazione dei
macchinari sono tra i più alti.
MP+FSD
Maximize Production
with
Anche qui il livello di utilizzazione medio dei macchinari è oggettivamente il
migliore e si ripetono le considerazioni fatte in precedenza, se non fosse per il fatto che
il ritardare pezzi di consegna produce un alto costo di insoddisfacimento della domanda,
sempre per la motivazione che il costo di ritardo è stato considerato parametro di
importanza nell’analisi prestazionale.
MP+DOC
Maximize Production
with
Stesse motivazioni del precedente ma è da sottolineare il livello di costo di
inventory in uscita molto alto, dovuto al costo di giacenza nulla di questo caso.
MP+OCO
Maximize Production
with
L’ultima politica di gestione presenta sempre alte utilizzazioni dei macchinari e
costi di inventory in uscita alti, ma limitati rispetto al caso precedente, in quanto gli
ordini spezzati dalla politica Delayed Orders Chartered, spezzano lotti di consegne
molto squilibrati (si crea un nuovo evento “vendita” per quantità minimali di materiale).
81
Conclusioni, limitazioni e possibili sviluppi
CAPITOLO VI:
6.0 Limitazioni
Il modello qui sviluppato ed implementato riesce a fornire risultati precisi ma
nella ristrettezza di limitazioni riguardo la struttura del sistema e dei dati. Per quanto
concerne il primo punto, il modello è sviluppato per quattro centri produttivi distribuiti,
ma se si volessero studiare le variazioni dovute all’inserimento di ulteriori centri
produttivi, bisognerebbe modificare il codice del programma sensibilmente. Nonostante
le interfacce software sono state mantenute il più possibile generalizzate, l’inserimento
di altri nodi produttivi richiederebbe un intervento significativo con particolare riguardo
alla disposizione dell’interfaccia utente.
Per quanto riguarda il secondo punto, i dati rappresentati tramite grafici pongono
limitazioni legate alla rappresentatività degli oggetti Graphics utilizzando le funzioni
void paintComponent( Graphics ) dei moduli software JPanel di Java. Queste infatti nel
modello sviluppato, disegnano utilizzando punti approssimati ad interi1 (causa
dell’uniformità alle librerie di disegno ricercata in fase di codifica). Questo potrebbe
rappresentare un problema specialmente per piccole variazioni dovute ad esempio ad
eventi troppo ravvicinati, oppure a livelli di inventory che per breve tempo si trovano al
livello nullo. Questi problemi non sono stati affrontati in sede di codifica in quanto non
sono significativi per la maggior parte delle applicazioni ( è improbabile che un’azienda
effettui due acquisti in quasi contemporaneità) e si riferiscono a problemi la cui
granularità di dettaglio esula dal compito primario dello studio.
1
Tipo primitivo integer (int)
82
6.1 Conclusioni
In conclusione questo simulatore può essere utilizzato con profitto in tutte le
applicazioni che richiedano decisioni di breve periodo e parametri prestazionali
considerabili non complessi. Anzitutto perché non utilizzando algoritmi di
ottimizzazione, questo simulatore si vuole prefiggere l’unico scopo di poter scegliere
all’interno di una gamma di possibilità, quella migliore. Non è detto ed in generale non
è corretto considerarla, la scelta ottima possibile.
Per quanto riguarda la complessità degli indici prestazionali da considerare,
come si evince dai risultati ottenuti, se la richiesta del problema comprenda il
raggiungimento di un numero elevato di obiettivi, è plausibile non trovare una scelta
migliore tra le otto politiche di gestione presentate. Ogni politica di gestione infatti
consente di ottenere buoni risultati solo su un ristretto numero di indici prestazionali
(due o tre). Questa forzatura a casistiche semplificate, decade nel momento in cui si
integri un modulo software che renda la gestione dei magazzini indipendente da una
politica particolare, ma adotti soluzioni puntuali e orientate alla ricerca del minimo
costo.
L’applicazione sviluppata fornisce uno strumento utile alla semplificazione dei
processi decisionali. Infatti, nella più totale indipendenza dall’architettura software e
hardware, questo simulatore rappresenta una soluzione flessibile e di facile utilizzo. Le
interfacce utente sono progettate in modo tale da mantenere semplice l’usabilità e
conseguentemente da non richiedere sforzi di apprendimento superflui al funzionamento
del modello di supply chain. Qualsiasi utente che conosca il sistema di
approvvigionamento dei materiali può facilmente elaborare i dati della simulazione, sia
per visualizzare in tempo reale gli scenari possibili (tramite i grafici di Inventory), che
per inserire questi risultati come parametri in altri processi decisionali. Grazie
all’esportazione dei risultati in formato Microsoft© Excel©, il simulatore rende
disponibili i risultati in modo tale da semplificare il lavoro di successive elaborazioni.
83
Bibliografia
CAP I:
• D. Giglio, Dispense del corso di Automazione Industriale 1.
•
R. Minciardi, Dispense del corso di Automazione Industriale 1.
•
S. Sacone, Dispense del corso di Automazione Industriale 1.
•
J. Banks, J.S. Carson, Discrete-Event System Simulation, Prentice Hall, (1984).
•
P. Ball , Introduction to Discrete Event Simulation, University of Strathclyde,
(1996)
•
W. L. Winston and S. Christian Albright, Practical Management Science,
Brooks/Cole, Pacific Grove, CA, 2. edition, (2001).
CAP II:
• N. Viswanadham, The past, present, and future of Supply-Chain Automation,
IEEE (2002) [49-56].
•
H. Min, G. Zhou, Supply-chain modelling: past, present and future, Computer &
Industrial Engineering 43, (2002) [232-249].
•
S. Chopra, P. Meindl, Supply Chain Management: Strategy, Planning, and
Operation, (2001).
•
R. Narasimhan, A. Das, Manifacturing Agility and Supply Chain Management
practices, Production and Inventory Management Journal – First Quarter, (1999)
[4-10].
•
C.J. Vidal, M. Goetschalckx, Strategic production-distribution models: A
critical review with emphasis on global supply chain models, European Journal
of Operational Research (1998) [1-18].
•
C.T. Ng, Leon Y.O. Li, K. Chakhlevitch, Coordinated replenishments with
alternative supply sources in two-level supply chains, Int. J. Production
Economics 73 (2001), [228-240].
•
D.J. Thomas, P. M. Griffin, Coordinated supply chain management, European
Journal of Operational Research 94 (1996), [1-15]
CAP III:
• D. Giglio, R. Minciardi, S. Sacone, S. Siri, A Hybrid model for optimal control
of single nodes in Supply Chains, (2005).
I
CAP IV
• G. Frantzeskou, S. MacDonell, E. Stamatatos, S. Gritzalis, Examining the
significance of high-level programming features in source code author
classification, The Journal of Systems and Software (2007) [1-14].
•
J. Kaczmarek, M. Kucharski, Size and effort estimation for applications written
in Java, Information and Software Technology 46 (2004) [589–601].
•
M. Verwijmeren, Software component architecture
management, Computers in Industry 53 (2004), [165–178].
•
http://www.wikipedia.com
•
http://www.mokabyte.it/2002/02/jbase_1.htm
•
http://www.mokabyte.it/1997/06/jdbc.htm
in
supply
chain
CAP V
•
J. Nielsen, Hypertext and Hypermedia, Academic Press, (1990).
•
A.V. Oppenheim, R. V. Shafer, Discrete Time Signal processing, Prentice Hall
International, (1995).
I

La Simulazione ad Eventi Discreti

Transcript

Documenti analoghi

TERZA A Allegato n 2 Simulazioni terza prova

simulazione III prova - Liceo artistico "A. Modigliani"

IMUN : Italian Model United Nations

UN SISTEMA E I SUOI ANTIVIRUS

Simulazioni terza prova 5Cl - Liceo Statale G. Carducci – Viareggio

Allegato - simulazioni di terza prova

Scarica il regolamento del simulatore

cv_format_it europeo

CONFERENZA CIES 2007 SULLA SUPPLY CHAIN La Supply

introduzione al corso