Modelare şi simulare

UTILIZAREA PROGRAMULUI DE SIMULARE ARENA

1. Obiectivele lucrării
Inițierea în utilizarea programului ARENA pentru modelarea sistemelor de producție și
simularea proceselor ce se desfășoară în cadrul acestora.
Construirea în cadrul programului a modelului unui sistem de producție, simularea
funcționării acestuia și efectuarea unor studii privind parametrii de desfășurare ai procesului
de producție.

2. Elementele modelului din cadrul programelor de simulare

In toate programele de simulare întîlnim o serie de elemente cu ajutorul cărora se

realizează modelarea în orice program specializat de simulare pe care le vom prezenta în cele
ce urmează.

2.1.Entitățile. In majoritatea simulărilor vom întîlni o serie de entități, aceste fiind

elementele care se deplasează în sistem, își schimbă starea, afectează și sunt afectate de alte
entități, modifică starea sistemului și indicii de performanță ai acestuia. Entitățile sunt obiecte
dinamice care sunt create la sosire, au priorități diferite, se așează la coadă, sunt servite de
servere și sunt eliberate în afara sistemului. De remarcat că pot exista, în același timp în
sistem, loturi de diferite tipuri de entități fiecare cu un anumit traseu și cu o anumită prioritate.
Este posibil să avem o clasă de entități care nu vor părăsi niciodată sistemul dar care vor ajuta
la circulația altor entități în sistem.

2.2.Atributele atașate fiecărei entități le individualizează. Un atribut (etichetă) este o

caracteristică a tuturor entităților dar valoarea specifica a acesteia poate diferi de la o entitate
la alta. Din punct de vedere al programului de calcul, fiecare atribut este echivalent unei
variabile locale, legate de o anumită entitate. Exemple de atribute: timpul de sosire; timpul de
ieșire; prioritatea, cod de culoare, nume etc. Cel mai important lucru pe care trebuie să-l
reținem este vă valoarea atributelor este atașată entității modelate. Același atribut, în general,
poate avea valori diferite pentru entități diferite, așa cum diferite piese au timpi de sosire,
trasee, priorități și coduri de culoare diferite.

2.3. Variabilele (globale) sunt informații care reflectă anumite caracteristici ale
sistemului modelat, cu privire la numărul și distribuția entităților în sistem.
Fiecare variabilă este unică și nu este alocată unei anumite entități dar este modificată de
acestea. Există 2 tipuri de variabile:
- variabile interne (numărul de entități de la coadă, numărul resurselor ocupate, timpul
simulării, etc.), și
- variabile definite de utilizator (numărul de entități din sistem, etc.)
Variabilele sunt accesibile tuturor entităților și multe dintre acestea pot fi schimbate de
orice entitate. De exemplu, putem crea o variabilă denumită “Numărul de entități în sistem” a
cărei valoare este egală cu numărul total de entități din sistem inclusiv acelea care sunt în
firele de așteptare sau ocupă serverele din sistem. Cînd este creată o entitate este adăugată o
unitate la variabila “Numărul de entități în sistem” iar cînd o entitate părăsește sistemul aceată
variabilă este decrementată cu o unitate.
 Utilizarea programului de simulare ARENA

2.4. Resursele. Entitățile din sistem sunt în competiție pentru a fi servite de către
resurse (personal, echipamente, spațiu de depozitare ). O entitate folosește (eng. seize) o
resursă disponibilă și o eliberează (eng.release) la terminarea serviciului. Este important să
considerăm că o resursă este atribuită unei entități și nu invers. O resursă poate reprezenta un
grup de servere, fiecare dintre acestea fiind considerată o unitate (eng. unit) a respectivei
resurse. Numărul de unități al unei resurse poate fi modificat pe parcursul simulării pentru a
reprezenta faptul că acestea se pot defecta. Pentru a modela defectarea și repararea resurselor
se crează un mecanism separat care acționează după legi prestabilite, definite de utilizator.

2.5. Firele de așteptare (Cozile). Cînd o entitate nu se poate mișca pentru a folosi o
unitate a unei resurse care este ocupată cu o altă entitate este necesar să fie plasată într-un loc
de așteptare al unei cozi (eng. queue). Firele de așteptare au un nume și o anumită capacitate
(eng. buffer) finită sau infinită.Trebuie să se definească și algoritmul de tratare a unei entități
sosite cînd depozitul este plin.

2.6. Variabile statistice. Pentru măsurarea performanțelor de ieșire, trebuie să se

memoreze ,în timpul simulării, o serie de variabile, denumite variabile statistice sau
acumulatori statistici. La începutul simulării acestea se inițializează cu zero. Cei mai uzuali
acumulatori statistici utilizați sunt:
ƒ Numărul de elemente produse pînă la un moment dat;
ƒ Timpul total petrecut la coadă pînă la un moment dat;
ƒ Numărul de elemente care au trecut pe la coadă pînă la un moment dat;
ƒ Timpul maxim perecut la coadă observat pînă la un moment dat;
ƒ Timpul total de servire pînă la un moment dat;
ƒ Timpul maxim de servire pînă la un moment dat;
ƒ Numărul mediu de piese care așteaptă la coadă=aria de sub curba lungimii firului de
așteptare,Q(t), împărțită la timpul de rulare;
ƒ Timpul mediu de utilizare al serverului= aria de sub curba ocupării serverului,B(t),
împărțită la timpul de rulare;
Cînd se produce un eveniment în sistem trebuie să se actualizeze variabilele statistice
corespunzătoare

2.7. Evenimente. Un eveniment este orice acțiune care se petrece la un moment al

timpului de simulare care poate schimba atributele, variabilele sau acumulatorii statistici De
exemplu: evenimentul sosire : o nouă piesă intră în sistem; evenimentul plecare: o piesă care a
fost prelucrată de un server și părăsește sistemul; evenimentul stop: Simularea este oprită la
t=15 min.
Fiecare program de simulare are un mecanism denumit calendar al evenimentelor. Cînd
o secvență de simulare este executată, o înregistrare a informațiilor pentru evenimentele
viitoare este plasată în calendarul de evenimente. Inregistrarea evenimentelor din calendarul
de evenimente conține informații despre entităților afectate ,despre timpul și condiția de
desfășurare a evenimentului și despre tipul de eveniment care se va desfășura. Planificarea
evenimentelor în calendarul de evenimente se face astfel încît un nou eveniment este sortat, în
ordine crescătoare, în funcție de timpul de desfășurare. Cînd trebuie să se execută următorul
eveniment, prima înregistrarea din calendarul de evenimente este preluată și informațiile din
această înregistrare sunt folosite pentru desfășurarea logicii de execuție. In modelarea cu
evenimente discrete, variabilele care descriu sistemul nu se modifică între evenimente
succesive.
Modelare şi simulare

2.8. Ceasul de simulare. Valoarea curentă a timpului în simulare este înregistrat într-o
variabilă denumită ceas de simulare. Față de timpul real, ceasul de simulare nu ia toate
valorile și timpul nu este continuu. De la timpul curent al unui eveniment se trece direct la
timpul următorului eveniment planificat în calendarul de evenimente, ceasul de simulare
interacționînd strîns cu calendarul de evenimente. De obicei, valorile ceasului sunt stocate în
variabila internă ‘TNOW’ a programului de simulare.

2.9. Startarea și oprirea simulării sunt elemente care trebuie să se definească în ceea ce
privește condițiile de start pentru atribute, variabile și acumulatori statistici. De asemenea,
trebuie precizat, de la începutul simulării, timpul de rulare sau condițiile de oprire

3. Legi de sosire a entităților și de servire de către resurse, utilizate în

lucrare

Distribuția triunghiulară este folositoare ca o primă aproximare sau ca un model

neprelucrat în lipsa informațiilor. Obișnuim să folosim această distribuție atunci când
variabila întâmplătoare descrisă se așteaptă să fie unică într-un interval definit. Deci,
distribuția triunghiulară este definită prin trei valori: minimă, medie și maximă. Această
funcție constă din două segmente liniare unul crescând de la o valoare minimă la parametrul
“m” și altul scăzând de la “m” la valoarea maximă dată. Această distribuție este cel mai
adesea folosită când încercarea de a reprezenta un proces pentru care informațiile nu sunt ușor
de obținut dar pentru care limitele (maximul și minimul) și valoarea cea mai probabilă “m”
pot fi stabilite prin diferite procedee.
Distribuția exponențială este folosită pentru aproximarea timpilor dintre evenimentele
independente (timpii dintre sosiri, timpii de durată pentru anumite operații, când descriem
timpii de fiabilitate pentru anumite componente ale sistemului). Multe fenomene sunt
exponențial distribuite: durata conversațiilor telefonice, durata de așteptare a unor piese
pentru prelucrat, timpii dintre sarcinile subordonate unui program computerizat, etc..
Evenimentele pentru care timpii dintre sosiri pot fi reprezentați exponențial sunt absolut
întâmplători. Singurul parametru de care avem nevoie pentru a descrie distribuția
exponențială este media (variația este egală cu pătratul mediei).
Distribuția Weibull este o distribuție în funcție de mai mulți parametri ce pot lua forme
variate. Este larg folosită în modelele complexe pentru a reprezenta duratele de fiabilitate la
mecanismele pentru care uzajul afectează foarte mult din funcționarea lor cum ar fi rulmenții,
mecanismele electronice, arcurile, etc.. Distribuția Weibull este câteodată folosită la timpii de
îndeplinire ai unor sarcini. Această familie de distribuții ce variază de 0÷∞ și depinde de
parametrul fix α>0 și parametrul măsurat β>0 prin definiție.
Este o curbă cunoscută “în clopot” și descrie fenomene ce au variații simetrice în jurul
unei medii.
Distribuția normală este importantă în simulare ca aplicație a teoremei limitei centrale.
Această teoremă are multe aplicații în determinarea naturii distribuției probabile rezultate prin
combinarea câtorva subprocese întâmplătoare. Teorema stabilește că o combinație lineară a
unui număr finit de variabile aleatoare independente, cu distribuții normale, are o distribuție
tot normală. În practică acest rezultat este folosit la însumarea timpilor de lucru ai mai multor
subprocese într-unul singur, subprocesele fiind firesc independente între ele.
Altă variantă a acestei teoreme ne ajută să analizăm concluziile simulării. Această
variantă stabilește că distribuția unei probe obișnuite tinde către normă, exceptând acele
cazuri în care distribuția descrie materialul din care este alcătuită proba.
 Utilizarea programului de simulare ARENA

3. Descrierea sistemului de producţie modelat

Sistem modelat descrie operațiile de prelucrare a unor repere asamblate, inspecția calității
acestora urmată de recondiționarea unora sau dezmembrarea pentru recuperarea unor
componente sau reciclarea celor care sunt necorespunzătoare calitativ, după cum se arată în
figura1.1.

Unitățile care sunt procesate (entitățile) sunt denumite Produs A până la D. Toate
produsele sunt colectate și sortate într-o unitate separată care nu este prezentată în acest
model. Produsul A sosește în sistem după o lege de sosire descrisă printr-o distribuție
exponențială cu o medie de 18 minute (timpul va fi exprimat peste tot în minute), EXP(18).
Aceste produse sunt transferate după sosire în zonele de pregătire pentru inspecție. Pentru
Produsul A, procesul de pregătire pentru inspecție este descris de o distribuție triunghiulară
definită de TRIA (5, 7, 10). Produsul este apoi transferat în zona de inspecție.

Produsele B, C și D urmează un proces similar cu cel al produsului A - dar cu legi diferite

de sosire și de pregătire pentru inspecție (Prep), după cum se arată în figura 1.1. După
procesele de pregătire, aceste produse A,B,C,D sunt trimise în zona de inspecție.

Figura 1.1: Structura sistemului de producţie.

În zona de inspecție se efectuează verificări funcționale ale produselor pentru a

verifica dacă acestea sunt conforme cu specificațiile. Timpul total de procesare pentru această
operație depinde de tipul produsului: TRIA (1,2,3) pentru Produsul A, TRIA (2,3,4) pentru
Produsul B, WEIB (2.5, 5.3) pentru Produsul C, TRIA(6 ,7,8) pentru Produsul D.

După inspecție, 30% din Produse sunt trimise pentru ambalare și expediere, 55% sunt
trimise pentru dezmembrare și reciclare ulterioară, iar restul de 15% sunt respinse și trimise
direct pentru reciclare.
Modelare şi simulare

În zona de ambalare și expediere, timpii de procesare în această zonă sunt descriși de legi
triunghiulare de procesare, respectv: TRIA (3,4,5), TRIA (6,7,10), WEIB (8,9,10,5) și TRIA
(2,8,15) pentru produsele A, B, C și D. La sosirea în această zonă, produsele trebuie să aștepte
ca un număr corespunzător din același produs să fie disponibil pentru a fi ambalate. Produsele
sunt livrate în loturi de câte 4 și sunt livrate de două ori pe zi.

În zona de dezmembrare, toate produsele sunt separate în componente individuale, (40%)

dintre acestea sunt recuperate fiind în stare bună pentru refolosire, iar restul sunt trimise la
reciclare. Procesul de dezmembrare se face după o lege de servire de tip TRIA (15, 25, 45) și
este aceeași indiferent de tipul de produs (A,B,C,D).

Vrem să colectăm statisticile, din fiecare zonă, cu privire la utilizarea resurselor, numărul de
entități aflate în firul de așteptare (queue), timpul de staționare în firul de așteptare și durata
ciclului (sau timpul total în sistem) pentru produsele livrate, componentele recuperate și
piesele reciclate. Vom realiza simularea pentru 4 schimburi consecutive de 8 ore, sau 1.920 de
minute.

4. Pregătirea pentru construcția modelului

Trebuie remarcat că utilizarea mediului de simulare Arena pentru a construi un model este
doar o componentă a unui proiect de simulare. De reținut este că, în lumea reală, nu va exista
o problemă bine definită pentru datele de intrare. În lumea reală, deseori, aceste informații nu
există în companie și ar trebui colectate în mod minuțios. De fapt, colectarea, validarea și
verificarea datelor de intrare poate necesita până la 70% din timpul și efortul total al
proiectului de simulare.

Accentul în această lucrare se referă la abordarea dezvoltării și modelarea unui sistem tipic.
În această etapă, după înțelegerea problemei și stabilirea obiectivele trebuie să se definească
sistemul modelat, să se colecteze și să se analizeze datele necesare pentru a specifica
parametri de intrare. Pentru a face acest lucru, este posibil să trebuiască să subîmpărțim
sistemul în stații sau submodele și să decidem care modulele Arena ar putea fi necesare.

În acest model, vom folosi module în principal din panoul Basic Process și vom introduce
altele noi de la alte panouri, din partea stângă a mediului Arena, pe măsură ce îmbunătățim
modelul.
În acestă lucrare vom introduce noi concepte de modelare care vor necesita utilizarea
panourilor Advance process și Advanced Transfer.
Vom împărți sistemul modelat în secțiuni identificabile, convenabile pentru o modelare
eficientă. Prin urmare, aspectele principale ale modelului nostru vor fi:

• Crearea (Create) și sosirea produselor în sistem;

• Trimiterea produselor spre zona de pregătire pentru inspecție;
• Trimiterea produselor spre zona procesului de inspecție;
• Decizia (Decide) pentru fiecare produs unde merge după inspecție;
• Trimiterea unei părți din produse pentru zona de ambalare și expediție;
• Trimiterea unei alte părți din produse către zona de dezmembrare;
• Expedierea (Dispose) produselor rămasă la reciclare;
• Expedierea (Dispose) pieselor ambalate către beneficiar;
 Utilizarea programului de simulare ARENA

• Dezmembrarea (Split) produselor în componente;

• Expedierea (Dispose) componentele recuperate după dezmembrare;
• Expedierea (Dispose) componentelor nerecuperabile la reciclare.

Pentru a realiza cele de mai sus, vom utiliza următoarele module ale mediului Arena:

• Create (4)
• Assign (4)
• Process (7)
• Decide (2)
• Record (3)
• Separate (1)
• Dispose (3)

Fiecare modul Create va reprezenta sosirea fiecărui tip de produs. Fiecare modul de
alocare Assign va fi, de asemenea, utilizat pentru definirea atributelor fiecărui tip de produs.
Patru modulele de proces Process vor reprezenta procesul de pregătire pentru inspecție, Prep,
pentru fiecare tip de produs, unul pentru procesul de inspecție, unul pentru procesul de
ambalare și expediție și ultimul pentru procesul de dezmembrare. Un modul Decide va fi
utilizat după procesul de inspecție pentru a împărți produsele pentru ambalare, dezmembrare
și reciclare. Celălalt modul Decide va fi utilizat pentru a separa componentele recuperate de
cele care vor fi reciclate după dezmembrare. Înainte ca fiecare flux de produse să fie eliminat
din sistem (Dispose), vom folosi un modul de înregistrare pentru a colecta statistici ale
timpului petrecut în sistem. În cele din urmă, cele trei module Dispose vor fi utilizate pentru a
expedia produsele, componentele recuperate și componentele reciclate.

Rețineți că legile de sosire și timpul de precesare sunt individualizate pentru fiecare tip de
produs, după cum se arată în figura 1.1. Vom folosi două atribute denumite timp de inspecție
și timp de ambalare pentru a aloca diferitele durate petrecute la procesele de inspecție și
ambalare pentru diferitele tipuri de produse. Timpul pentru procesul de dezmembrare este
constant pentru toate produsele. Vom numi resursele Prep A până la D, Inspector,
AmbTehnician și DezTehnician, respectiv pentru procesele de pregătire, inspecție, ambalare și
dezmembrare.

4.1. Construcția modelului

Deschideți mediul Arena și deschideți o nouă fereastră pentru model. Plasați modulele
necesare, așa cum au fost menționate mai sus, în fereastra modelului.

Fereastra modelului ar trebui să pară oarecum asemănătoare figurii 1.2. Pe măsură ce

glisați și fixați modulele, Arena ar trebui să le conecteze automat, dacă aveți opțiunea de
conectare automată. Pentru a dezactiva și a activa această funcție, selectați meniul Object, din
partea de sus, și faceți clic pe auto-conectare.

De asemenea, cu dublu clic pe orice modul din schemă se va afișa macheta de dialog a
modulului în care parametrii săi pot fi actualizați. Rețineți că Arena afișează simultan date
similare pentru modulul selectat în vizualizarea foaie de calcul, care arată parametrii tuturor
modulelor de același tip în cadrul modelului curent.
Modelare şi simulare

Figura 1.2: Modulele plasate în fereastra Model

Să începem prin actualizarea modulelor Create. Faceți dublu clic pe modulul Creare 1
pentru a afișa macheta de dialog. Setați numele său pentru a crea Produs A și Entitatea
Produsul A. În zona de timp dintre sosiri, setați tipul la Random (Expo) cu o valoare medie de
18 și selectați minutele pentru unități. Să presupunem acum că produsele sosesc individual,
așa că s-a setat entitățile pe sosire la 1. Lăsați Max Arrivals la setarea implicită, Infinite, și
zero pentru First Creation. După toate acestea, macheta ar trebui să arate ca figura 1.3a.

Fig. 1.3a. Macheta de diolog pentru Create Produs A

În mod similar, modulele de creare pentru produsele B, C și D sunt prezentate în figura

1.3b de mai jos.
 Utilizarea programului de simulare ARENA

Figura 1.3b: Machetele de dialog pentru crearea Produselor B, C și D.

De reținut că scopul principal al modulului Create este de a oferi un punct de pornire

pentru entitățile dintr-un model de simulare. Cazurile de mai sus sunt, prin urmare, punctele
de plecare pentru toate produsele care intră în sistemul modelat. În modulele de creare, am
specificat tipurile de entități care sunt produse de la A la D. Nu este singura informație de care
avem nevoie cu privire la fiecare produs. De asemenea, s-ar putea să știm la ce oră s-au
produs produsele în sistemul nostru, cât timp va fi petrecesatr produsul în zona inspecției etc.
Modelare şi simulare

Informațiile specifice fiecărui produs sunt cunoscute sub denumirea de atribute și sunt
atribuite entităților prin modulul de atribuire care vom discuta în continuare.

Vrem să știm timpul de sosire pentru fiecare produs. De asemenea, dorim să știm cât timp
consumă produsul în timpul proceselor de inspecție și ambalare. Pentru acestea, definim
următoarele atribute, Timp sosire, Timp inspectie și Timp ambalare. Să deschidem acum
fiecare dintre modulele de atribuire și să introduceți informațiile necesare. Faceți dublu clic pe
modulul Assign 1 și introduceți informațiile așa cum se arată în figura 1.4.

Figura 1.4: Atribuirea atributelor produsului A

 Utilizarea programului de simulare ARENA

Figura 1.5: Atribuirea atributelor produselor B,C,D.

Atribuirile noi sunt adăugate făcând clic pe butonul "Add" care afișează dialogul de alocări,
după cum se arată mai sus. Acest modul este utilizat pentru atribuirea de noi valori
variabilelor, atributelor entității, tipurilor de entități, imaginilor entităților sau altor variabile
de sistem. Atribuirile multiple se pot realiza cu un singur modul de atribuire. Urmând pașii de
mai sus, atribuiți atributele corespunzătoare produselor B, C și D, după cum se arată în figura
1.5.
TNOW este o variabilă rezervată Arena care reprezintă timpul de simulare curent.
Următorul pas este editarea modulele de proces Process Modules pentru a actualiza
parametri. Vom începe cu cele patru procese de pregătire pentru inspecție. Faceți dublu clic
pe modul Process 1 pentru a deschide fereastra de dialog. Dialogul completat este prezentat în
figura 1.6.

Figura 1.6: Machetă configurare proces pregătire inspecție Produs A, Prep A

Modelare şi simulare

Am denumit un procesul Pregătire Produs A. De asemenea, am folosit un proces standard,

după cum puteți vedea. S-a selectat combinația de acțiuni Seize-Delay-Release. Acest lucru se
datorează faptului că produsele vor ocupa în mod normal resursa Prep A, vor întârzia resursa
pe durata procesului de pregătire pentru inspecție și apoi vor elibera resursa înainte de a trece
la pasul următor în logica procesului. Timpul de pregătiri pentru produsul A a fost impus în
enunțul problemei ca fiind o distribuție triunghiulară cu parametrii 5, 7 și 10. Unitatea de timp
este minutul și alocarea de timp este valoarea adăugată. Lăsați opțiunea de statistică a
rapoartelor bifată astfel încât Arena să furnizeze rapoarte despre acest modul de procesare.

Resursele noi sunt adăugate făcând clic pe butonul "Add" care afișează dialogul Resources,
după cum se arată mai sus. Acest modul este principala metodă de procesare în simularea. Ar
putea să conțină un submodel prin selectarea opțiunii de submodel în caseta tip combo și să
efectueze diferite acțiuni de ocupare, întârziere și eliberare a resurselor atunci când este
selectată opțiunea standard.

Într-o procedură similară celei de mai sus, actualizați modulele de proces pentru produsele
B,C,D. Modulele completate sunt prezentate mai jos.

Figura 1.7: Procesul de pregatire pentru Produs B, Prep B.

 Utilizarea programului de simulare ARENA

Figura 1.8: Procesul de pregatire pentru Produs C, Prep C.

Figura 1.9 Procesul de pregatire pentru Produs D, Prep D.

Modelare şi simulare

Procesul de inspecție este foarte similar cu procesele Prep, cu excepția faptului că

utilizează o expresie pentru legea de servire în locul tipului de distribuție triunghiular pe care
l-am utilizat până acum. Acesta este motivul pentru care s-a definit atributul Timp de
inspecție în modulul de atribuire. Când se alege tipul de întârziere pentru a fi o expresie,
puteți defini orice expresie (sume sau diferențe, produse sau expresii de variabile și atribute),
iar Arena va evalua această valoare și va folosi valoarea rezultată ca fiind timpul procesului
pentru entitatea considerată. În cazul de față, se folosiște o valoare care a fost pre-alocată
timpului de inspecție al entității (produsului).
Modulul completat este prezentat în figura 1.10.

Figura 1.10. Procesul de inspecție

Deciziile sau alegerile din Arena sunt modelate folosind modulul Decide. Definiția
problemei prevede că, în urma inspecției, 30% din produse sunt trimise pentru ambalare, 55%
pentru dezmembrare și 15% pentru reciclare. Modulul de decizie include opțiuni pentru luarea
deciziilor pe baza mai multor condiții sau bazate pe una sau mai multe probabilități. Deoarece
avem valori date pentru procente, vom folosi opțiunile bazate pe probabilități.

Faceți dublu clic pe modulul Decide 1 pentru afișarea machetrei de dialog. Deoarece avem
trei rezultate posibile, vom selecta opțiunea N-way by chance din caseta tip combo. Butonul
Add afișează un alt dialog pe care îl specificați valoarea probabilității. Vom specifica două
valori de 30% și 55%. Arena va rezolva automat diferența și va trimite restul de 15% la un alt
punct de ieșire. Observați că Arena oferă un număr de puncte de ieșire din Modulul de decizie
care este egal cu numărul de condiții pe care le specificați. Modulul completat este prezentat
în figura 1.11.

Figura 1.11: Macheta de dialog a modului de decizie Rezultat inspectie.

 Utilizarea programului de simulare ARENA

Următorul pas în logica noastră de proces este actualizarea modulului Process 6. Acest
lucru este foarte similar cu modulul procesului de inspecție prezentat mai sus, cu excepția
faptului că folosim timpul atributului de ambalare în loc de timpul de inspecție. Numele
modulului se modifică de asemenea la procesul de ambalare și la resursa către AmbTehnician.
Macheta completă este prezentată mai jos.

Figura 1.12: Dialogul procesului de ambalare-expediție

Repetați pașii de mai sus pentru a finaliza modulul Process 7. Macheta de configurare este
prezentată în figura 1.13 de mai jos.

Figura 1.13: Macheta Procesului de dezmembrare.

Modelare şi simulare

La sfârșitul procesului de dezmembrare, produsele vor fi transformate în componente. Din

definiția problemei, realizăm că numărul componentelor din fiecare produs variază și procesul
de dezmembrare se realizează după o lege de servire reprezentată de o distribuție triunghiulară
a parametrilor 6, 9 și 12. Aceasta presupune că există un număr aleatoriu de componente în
fiecare produs. Vom modela acest lucru utilizând un modul Separate Module din panoul Basic
Process
Faceți dublu clic pe modulul separat 1 pentru a deschide caseta de dialog. Introduceți
Componente la "Nume" și lăsați câmpul "Type" la valoarea implicită (adică Duplicate
original). De asemenea, lăsați câmpul "Procent Cost to Duplicate" la valoarea sa implicită.
Ultimul lucru este să introduceți valoarea TRIA (6,9,12) în câmpul " Number to Duplicate".
Macheta completată arată ca în figura 1.14. Ar trebui să-ți dai seama de asta scopul utilizării
acestui modul separat este de a multiplica numărul de componente care părăsesc procesul de
dezmembrare. De aceea veți observa că ambele ieșiri ale modulului au fost puse împreună.

Figura 1.14: Macheta Componente

Există o altă decizie care trebuie luată după procesul de dezmembrare, în care 40% din
componente sunt recuperate pentru reutilizare, iar restul de 60% sunt trimise la reciclare. Vom
folosi un alt modul de decizie Decide și îl vom completa așa cum se arată în figura 1.15. Acest
modul are mai putine valori pentru a le specifica, deoarece sunt doar 2 căi.

Figura 1.15: Modulul de decizie Componente recuperate

După ce ați definit toate operațiile, pentru a termina, trebuie să actualizăm modulele
Record și Dispose.
 Utilizarea programului de simulare ARENA

Figura 1.16 prezintă macheta modului Record 1 completat pentru înregistrarea timpilor
ciclului produselor care au fost ambalate. Pentru a determina timpul ciclului care este
momentul de la momentul în care produsele sosesc în sistemul nostru până la ieșirea din
sistem, folosim tipul Interval de timp din modulul de înregistrare. Acesta este motivul
principal pentru care am definit atributul Time sosire imediat după crearea produselor. În
acest modul, am selectat atributul Time sosire ca referință pentru calculul duratei ciclului
(intervalul de timp). Arena face acest atribut disponibil în lista derulantă sub numele de atribut
Attribute Name în dialogul de înregistrare. Timpii de ciclu observat pentru entități vor fi
înregistrați într-o înregistrare denumită "Inregistrare Ambalare".

Completați modulele de înregistrare Record rămase, în același mod ca mai sus, dar cu
numele Inregistrare Componente recuperate și Inregistrare componente reciclate. Rețineți că
Arena utilizează automat numele de modul furnizat ca nume de înregistrare.

Figura 1.16: Dialogul de înregistrare a produselor finalizate

Setul final de module pe care trebuie să le completăm sunt modulele Dispose. Acest modul
este destinat ca punct de sfârșit pentru entitățile dintr-un model de simulare. Statisticile
privind entitățile pot fi înregistrate înainte ca entitatea să fie eliberată din sistem. Arena
înregistrează statisticile entității numai când bifați caseta pentru Înregistrarea statistică a
entităților în caseta de dialog. Figura 1.17 prezintă macheta de dialog pentru produsele
ambalate și trimise la expediție.
Modulele rămase sunt actualizate în același mod cu numele trimise la reprelucrare pentru
componentele recuperate și trimise la reciclare pentru componentele respinse.
Modelare şi simulare

Figura 1.17: Macheta de eliberare din sistem pentru produsele ambalate.

Modelul poate fi rulat acum, dar înainte de a face acest lucru, există câteva lucruri pe care
trebuie să le specificăm cu privire la modul în care ar trebui să funcționeze modelul. Unul
dintre acestea este să precizăm mediului Arena când să oprească simularea. Fără aceasta,
simularea se va desfășura perpetuu. Acest parametru și alți parametri necesari pentru
comportamentul al simulării și alte informații despre raportul generat pot fi stabilite prin
selectarea opțiunii "setup" din meniul "Run" din Arena. Vom analiza doar două dintre cele
cinci file din dialogul de configurare al rulării. Figura 1.18 arată dialogul de configurare
pentru macheta Project Parameters selectată.

Figura 1.18: Parametri proiectului în dialogul Run Setup

 Utilizarea programului de simulare ARENA

Această machetă vă permite să specificați informații despre proiect, cum ar fi titlul, numele
analistului și descrierea proiectului. De asemenea, vă permite să specificați pentru ce aspecte
ale modelului dvs. doriți să colectați statistici. Am selectat resurse, cozi și procese pentru
statistici. Prin urmare, nu vor exista statistici generate pe toate celelalte componente ale
modelului în raport care va fi generat după executare.

Figura 1.19: Parametri de replicare din dialogul Run Setup

Cealaltă machetă pe care o vom configura în dialogul de configurare al rulării este

"Replication parameters". Acest lucru este afișat în figura 1.19, unde specificăm intervalul de
rulare pentru simulare. Pe baza descrierii noastre de sistem, am setat timpul de replicare la 32
de ore (patru schimburi consecutive de 8 ore). Am schimbat, de asemenea, unitățile de timp
de bază la minute și lăsăm câmpurile rămase la setarea implicită.
După toate acestea, modelul dvs. complet ar trebui să pară oarecum asemănător figura 1.20.
Modelare şi simulare

Figura 1.20: Modelul complet

4.2. Rularea modelului

Arena nu poate rula un model cu erori; prin urmare, următoarea sarcină înainte de a rula
modelul este de a verifica erorile din model. Acest lucru se poate face făcând clic pe
butonul de verificare din bara de instrumente Run, sau utilizând tasta F4 de pe tastatură. Dacă
modelul nu are o eroare, Arena afișează caseta de mesaje din figura 1.23. Altfel, veți primi o
mesaj de eroare cu butoane de căutare și editare care vă vor ajuta să localizați și să remediați
eroarea.
În cazul în care există nu sunt erori în modelul dvs., puteți rula simularea făcând clic pe Go
butonul din bara de instrumente standard sau doar apăsând tasta F5 de pe tastatură sau
selectând comanda Go din meniul Run.

Figura 1.23: Mesaj Arena pentru verificarea cu succes a modelului

*Dacă executați exemplul utilizând versiunea academică Arena, puteți să primiți un

avertisment care va putea apărea după un timp declarând că ați "depășit 150 de entități"
permise pentru versiunea academică / demo a Arena. Acest lucru se datorează faptului că
modelul generează prea multe entități, depășind limitele pentru versiunea demo. Motivul
pentru această eroare ar putea fi datorat entităților care așteaptă în urma procesării
resurselor sau generării mai multor entități.
 Utilizarea programului de simulare ARENA

Puteți rezolva acest lucru în acest stadiu- prin schimbarea timpului dintre sosiri sau
reducerea timpului de procesare.

4.2.1 Vizualizarea rezultatelor

Observați faptul că Arena oferă la vizualizarea raportului, numele proiectului, numărul de

replicări simulate și unitățile de timp pentru toate valorile de timp din raport. Această unitate
de timp este preluată din câmpul " Base Time Unit " din macheta " Replication Parameters" din
caseta de dialog "Run Setup".

Figura 1.25 prezintă datele sintetice din firele de așteptare afișate în raportul de simulare.
Raportul afișează toate cozile din model și timpul petrecut de produsele care așteaptă în
fiecare coadă și numărul de entități care așteaptă. Dacă vă uitați la valorile medii pentru
timpul de așteptare în coadă și numărul de entități, veți observa că procesul de dezmembrare
are un timp de așteptare și o lungime a firului de așteptare mult mai lungă decât celelalte
procese. Aceasta este, evident, o sursă de îngrijorare; fie procesul nu are suficientă capacitate
pentru a-și gestiona activitatea, fie există o mare variabilitate în acest proces.

Figura 1.25: Raport de simulare care afișează date sumare ale firelor de așteptare

Rețineți din nou că obținerea unui rezultat din modelul dvs. de simulare nu este sfârșitul
procesului de simulare. În mod ideal, următorul pas, presupunând că modelul dvs. a fost
verificat cu succes, va fi validarea modelului prin compararea rezultatelor cu măsuri similare
din sistemul actual.
Modelare şi simulare

5. Îmbunătățirea modelului

Rețineți că obținerea unor rezultate cu modelul de simulare nu este sfârșitul procesului de

simulare. În mod ideal, următorul pas, presupunând că modelul dvs. a fost verificat cu succes,
va fi validarea modelului prin compararea rezultatelor cu date similare din sistemul real.
Chiar dacă sistemul există, este posibil să nu fie posibilă captarea tuturor complexităților
acestuia în modelul de simulare, prin urmare, există o anumită variație între model și datele
reale ale sistemului. Un scop idealist în validare este să se asigure că simularea este suficient
de bună pentru a putea fi utilizată pentru a lua decizii cu privire la sistem. Evident, dificultatea
validării crește odată cu complexitatea sistemului modelat. Astfel, la modelul prezentat inițial,
este destul de ușor de validat prin simpla verificare încrucișată cu informațiile date în
descrierea problemei.

Să presupunem, așadar, că în cadrul acestui proces de validare ați arătat rezultatele de mai
sus managerului sau clientului dvs. cu toate ipotezele de a rula modelul 24 de ore pe zi și
numai o singură resursă la fiecare proces fără pauze în decursul celor 24 de ore. Primul
răspuns al managerului dvs. este că presupunerile dvs. au fost greșite și face câteva sugestii
pentru îmbunătățirea modelului.

Următorul pas va fi așadar să ne îmbunătățim modelul prin efectuarea modificărilor

necesare pe baza noilor informații primite. Acesta este subiectul pentru următoarea secțiune
privind îmbunătățirea modelului.

Managerul dvs. înțelege că sistemul de fapt operează două schimburi pe zi și propune

să aibă trei (3) tehnicieni pentru procesul de dezmembrare în timpul primului schimb și
patru (4) pentru al doilea schimb pentru a vedea impactul asupra firului de așteptare
pentru acest proces.

Managerul a menționat, de asemenea, că există o problemă de neconcordanță la

procesul de inspecție. Un echipament de inspecție, cerut de inspector, se defectează
periodic. Datele istorice privind aceste defecțiuni au demonstrat că timpul mediu de
bună funcționare- MTBF (timpul între 2 defectări) poate fi modelat de o distribuiție
exponențială cu o medie de 180 de minute. Timpul de reparare (MTR) poate fi modelat
cu o distribuție exponențială cu o medie de 10 minute.

În următoarele secțiuni, vom include modificările de mai sus în modelul nou, denumit lab04,
prin introducerea unor noi concepte Arena.

5.1 Disponibilitatea resurselor

Necesitatea de a modela defectarea și disponibilitatea resurselor necesită o înțelegere a

conceptelor privind Resource States și Schedules din mediul Arena. Vom explica conceptul
de States în această secțiune și Schedules în secțiunea următoare.

Arena definește automat starea resurselor, Resource States, și anume, liber, ocupat, inactiv
și defect (Idle, Busy, Inactive and Failed). Astfel, pe parcursul perioadei de simulare, o resursă
nu poate fi decât într-una din aceste stări (States) . Arena ține evidența timpului în care fiecare
resursă din sistem se afla în fiecare dintre aceste stări pentru a întocmi și raporta statisticile
necesare. Se spune că o resursă este în starea Idle dacă nici una dintre unitățile sale nu a fost
ocupată de nicio entitate. Aceasta înseamnă că resursa este total liberă, fără a face nimic. Pe
 Utilizarea programului de simulare ARENA

de altă parte, de îndată ce o entitate ocupă resursa, starea sa este schimbată în Busy, pentru că
nu mai este liberă. Atunci când resursa nu este disponibilă pentru a fi utilizată, de exemplu o
pauză, Arena va stabili starea sa la Inactive. Acesta este cazul când capacitatea unei resurse
este redusă la zero (0). În cele din urmă, starea resursei ar fi schimbată în Failed atunci când
nu este disponibilă din cauza unei defecțiuni.

Atunci când apare un defect, Arena va face ca întreaga resursă să nu fie disponibilă și nici o
capacitate definită să nu poată fi ocupată de nicio entitate.

a. Planificarea resurselor - Resource schedules

Presupunerea noastră inițială că sistemul funcționează 24 de ore pe zi nu era, în mod

evident, corectă. Vom începe să implementăm noile modificări schimbând caseta “Hours per
Day” din dialogul “Run Setup” la 16 ore (Arena vă va solicita ca unele caracteristici legate de
calendar să aibă 24 de ore pe zi). Ignorați acest lucru) pentru a corespunde celor două
schimburi de 8 ore într-o zi. De asemenea, vom schimba “Replication Length” la 10 și “Time
Units” la zile (Days).

Pentru a planifica o resursă înseamnă a defini disponibilitatea acesteia. În Arena, puteți

începe să definiți disponibilitatea unei resurse fie în modulul Resource sau Schedule. (din bara
de instrumente Basic Process).

Dacă ați construit modelul de la lucrarea anterioară, deschideți-l acum și faceți clic pe
modulul Resource din panoul Basic Process. Acest lucru ar trebui să afișeze toate resursele
din model în vizualizarea foii de calcul, în partea inferioară a ferestrei model.

Vom programa resursa procesului de dezmembrare să aibă o capacitate de 3 pentru primele

8 ore și o capacitate de 4 pentru ultimele 8 ore. Înainte de aceasta, modificați coloana "Type"
pentru DisTehnician la "Based on Schedule", introduceți Planificare dezmembrare pentru
"Schedule Name" și selectați Ignore pentru coloana "Schedule Rule". Imaginea foii de calcul
tabelar ar trebui să fie ca în figura 1.26 de mai jos. De reținut că, atunci când regula de
programare este Ignore, capacitatea resursei este scăzută la timpul setat, dar se va finaliza
activitatea cu entitatea curentă. Rețineți, de asemenea, că acestea nu sunt singurele coloane
din această vizualizare.

Figura 1.26: Resursa DisTehnician bazată pe planificare

Acum trebuie să definim detaliile planificării. Acest lucru se poate face utilizând foaie de
calcul a editorului de planificare sau utilizând o opțiune de dialog. Vom utiliza a doua
opțiune.

Selectați modulul Schedule din panoul Basic Process pentru a vizualiza foaia de calcul
tabelar Schedule în partea de jos a ecranului. Faceți dublu clic pe vizualizarea foaie de calcul
pentru a deschide o nouă programare numită Schemă 1 în mod prestabilit. Dați clic în câmpul
Modelare şi simulare

"Name" și selectați Planificare dezmembrare din lista derulantă. Veți avea imaginea
prezentată în figura 1.27.

Figura 1.27: Vizualizarea tabelului modulului Schedule

Faceți clic din nou pe câmpul Durations pentru respectivul rând și pentru a afișa macheta
de planificare. Figura 1.28 prezintă macheta completată pentru o capacitate de 3 pentru
primele 8 ore și 4 pentru ultimele 8 ore.

Figura 1.28: Editorul de planificare pentru postul de dezmembrare

b. Defectarea resurselor- Resource failures

Defectarea resurselor este definită în același mod în care am definit planificarea resurselor.
Vizualizarea completă a modulului de date pentru resurse este prezentată în figura 1.29. (clic
pe modulul Resource)

Figura 1.29: Vizualizare completă a foii de calcul a resurselor

 Utilizarea programului de simulare ARENA

Vrem să definim defectarea resursei Inspector astfel încât să faceți clic pe câmpul
corespunzător pentru acea resursă din coloana "Failure" pentru a afișa vizualizarea tabelului
de defecări. Acesta afișează imaginea din figura 1.30. Introduceți Defect Inspector în câmpul
“Failure Name” și selectați Wait la " Failure Rule". Alegem Wait, deoarece când apare
defecțiunea, resursa va finaliza lucrările asupra entității (sau a produsului) curent înainte de a
fi scos din funcțiune pentru reparații.

Figura 1.30: Vizualizare foaie de calcul pentru defectarea resurselor

Parametrii defecțiunii sunt specificați în modulul de date privind defecțiunile Failure Data
Module. Acest modul se găsește în Advanced Process Panel. Faceți clic pe câmpul "Name" și
selectați Defect Inspector. Schimbați câmpul "Type" la Time și precizați la "Up Time" și
"Down Time" expresiile EXPO(180) și EXPO(5). Setați ambele unități de timp în minute.
Vederea finală ar trebui să arate ca figura 1.31.

Figura 1.31: Foaie de calcul pentru modulele de defectare

c. Rezultatele modelului îmbunătățit

Dacă ați construit modelul după indicațiile date, atunci faceți click pe butonul "Yes" din
dialog pentru a deschide raportul. Dacă tipul de raport implicit nu a fost modificat, atunci
Arena va afișa raportul “Category Overview” (Prezentare generală a categoriilor).
Pentru a schimba tipul raportului, reveniți la model, faceți click pe meniul "Run" și
selectați Setup. Faceți click pe macheta Reports și apoi trageți în jos câmpul “Default Report”
(Raport implicit). Al doilea din listă (Category Overview) și ultimul (SIMAN Summary
Report (.out file)) sunt cele pe care le considerăm aici. Raportul sumar este, în mod normal,
împărțit în diferite categorii (de exemplu, totaluri, variabile cu schimbare discretă, contoare și
ieșiri), fiecare furnizând un tip specific de statistică.

„Tally Variables" afișează sumele înregistrate în modelul dvs. Statisticile Tally includ
entitățile procesate, timpii și costurile.

VATime - (Entity Value-Added Time attribute ). Atributul de timp al entități ca valoare

adăugată. Se stochează timpul total acumulat de entitate în procesare (servire) și întârzierile
desemnate ca valoare adăugată. Când se înregistrează statisticile entității (de obicei, la
Modelare şi simulare

eliberare), acest atribut este utilizat pentru a determina timpul total acumulat de această
entitate în procesare.

NVATime- (Entity Non-Value-Added Time attribute). Atribut de timp al entității fără

valoare adăugată. Aceasta stochează timpul total acumulat în procese și întârzierile desemnate
ca fără valoare adăugată (Non-Value-Added). Atunci când statisticile entității sunt înregistrate
(în mod obișnuit pe dispuse), acest atribut este utilizat pentru a determina timpul total de
adăugare de valoare acumulat de această entitate.

“Discrete-Change Variables” includ orice statistică din model care este ponderată în timp
(Time-weighted statistics). Statisticile ponderate în funcție de timp "ponderează" valoarea
variabilei cu timpul total în care a rămas la acea valoare.) În această categorie sunt incluse
numărul de resurse ocupate, numărul programat și utilizarea acestora, precum și statisticile cu
numărul de entități din firele de așteptare (Resource Number Busy, Number Scheduled and
Utilisation as well as Number in Queue statistics) . Acestea sunt denumite, de asemenea,
statistici persistente în timp (Time Persistent Statistics).

Secțiunea “Outputs” (Ieșiri) afișează statistici pentru valoarea finală a unei variabile date de
model. Sunt incluse în această categorie costurile resurselor, costurile totale ale procesului și
numărul de variabile aflate în proces.

Secțiunea “Counters” (Contoare) afișează statistici pentru orice contoare identificate în

modelul construit. Numărul de entități care intră și ies din sistem este inclus în această
categorie. Rețineți că pot exista mai multe sau mai puține categorii de statistici în funcție de
tipurile definite în modelul dvs.

Coloana "Half Width", afișată în raport, este intervalul de 95% interval de încredere în
jurul valorii mediei. Acesta este inclus pentru a vă ajuta să determinați gradul de încredere în
rezultate pentru replicările considerate. Această coloană poate fi fie o valoare (număr real),
despre care se spune că este "insuficientă" sau "corelată" (“Insufficient” or “Correlated”)

"Insuficient" înseamnă că nu există date suficiente pentru a calcula cu exactitate gradul de

încredere. Acest lucru se datorează necesității distribuiției eșantioanelor în mod normal
(distribuție normală). Această ipoteză poate fi încălcată dacă există un număr mic (mai puțin
de 320) de eșantioane înregistrate în categorie. Rularea simulării pentru o perioadă mai lungă
de timp ar trebui să corecteze acest lucru.

"Corelat" înseamnă, de asemenea, că datele colectate pentru variabila nu sunt distribuite

independent. Formula folosită pentru calcul necesită, de asemenea, distribuirea independentă
a eșantioanelor. Datele care sunt corelate (valoarea unei observații influențează puternic
valoarea următoarei observații) are ca rezultat calculul unui interval de încredere nevalabil.
Rularea simulării pentru o perioadă mai lungă de timp ar trebui să corecteze și această
problemă.

Dacă avem o valoare în categoria Half Width, această valoare poate fi interpretată prin a
spune că "în 95% din replicări, media raportată este în intervalul mediei eșantionului ±
jumătate din împrăștiere". Valoarea împrăștierii poate fi redusă prin simularea pentru o
perioadă mai lungă de timp.

Raportul “Category Overview” are informații mai detaliate decât " Summary Report".
Aceasta afișează un rezumat al indicatorilor-cheie de performanță și este organizat în
 Utilizarea programului de simulare ARENA

următoarele secțiuni: Key Performance Indicators, Activity Area, Conveyor, Entity, Process,
Queue, Resource, Transporters, Station, Tank, ș.a. Statisticile raportate reprezintă un rezumat
al valorilor pentru toate replicările.

Informațiile afișate în acest raport variază în funcție de numărul de replicări executate și de

tipul de statistică pe care se decide să fie colectată. Se poate observa în structura arborelui
raport că Arena pune la dispoziție statistici numai pentru Entități, Cozi și Resurse. (Entities,
Queues și Resources). Acest lucru se datorează faptului că acestea sunt singurele obiecte pe
care le-am specificat pentru colectarea statisticilor, așa cum se arată în dialogul de configurare
a execuției (Run>Setup>Project Parameters). Observați, de asemenea, că Arena afișează toate
categoriile de rapoarte din panoul de raport din bara de proiect.

Pentru a vizualiza orice element din raport, trebuie doar să faceți clic pe elementul din
Reports Panel sau să selectați elementul din structura arborelui rapoartelor. De exemplu,
pentru a vedea statisticile despre Procese din model, se face clic pe elementul " Processes "
din structura arborescentă.

5.2 Enunțul problemei

Comparați timpului mediu de așteptare, număr de entități și numărul mediu de

entități în firele de așteptare pentru modelul inițial și modelul curent.

Impactul acestor schimbări este destul de evident. În general, toate diferențele pot fi
atribuite creșterii în lungime de rulare de la 32 de ore (în modelul inițial) la 160 ore (adică 16
ore x 10 zile în modelul curent). Cu toate acestea, deosebirile în ceea ce privește rezultatele
proceselor de dezmembrare și inspecție vor fi înțelese ca fiind determinate de creșterea
capacității la dezmembrare și de modelarea defectărilor la proces de inspecție.

Ne dăm seama că timpul de așteptare în coada de așteptare la procesul de dezmembrare s-a

redus după ce capacitatea a crescut în modelul curent. Acest lucru are sens, deoarece acum
mai multe produse pot fi dezmembrate decât în modelul anterior. Pe de altă parte, timpul de
așteptare în coada de așteptare la procesul de inspecție a crescut în noul model. Acest lucru
poate fi, de asemenea, bine explicat prin faptul că resursa inspectorului nu a fost întotdeauna
disponibilă din cauza unei defectări periodice (pauze).

4. Enunțul problemei
• Să se efectueze o simulare pe durata a 900 minute și să se comenteze valorile
parametrilor elementelor componente ale sistemului (opțiunea Reports);
•

Bibliografie

[1] Dekker, R., Flieschman, M., Inderfurth, K., and Van Wassenhove, L. (2004), Reverse Logistics
for closed-loop supply chains, Springer Verlag.

[2] Kelton,D., Sadowski,R., Zupick,N., (2009), Simulation with Arena, 5th Edition, Ed. McGraw-
Hill Education.