Simulation af SM Electronics - the Mathematics home page. - Aarhus ...
Simulation af SM Electronics - the Mathematics home page. - Aarhus ...
Simulation af SM Electronics - the Mathematics home page. - Aarhus ...
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Simulation</strong> <strong>af</strong> <strong>SM</strong> <strong>Electronics</strong><br />
<strong>Simulation</strong> of <strong>SM</strong> <strong>Electronics</strong><br />
Bachelorprojekt i Matematik-Økonomi<br />
Lene O. Sønder<br />
20061258<br />
Morten Petersen<br />
20061557<br />
Vejleder: Søren Glud Johansen<br />
Institut for Matematiske Fag<br />
<strong>Aarhus</strong> Universitet<br />
Maj 2009
Indholdsfortegnelse<br />
Abstract iii<br />
Forord v<br />
Kapitel 1 Indledning 1<br />
1.1 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . 1<br />
1.2 Modellen og Antagelser . . . . . . . . . . . . . . . . . . . . . . 2<br />
Kapitel 2 Modelkonstruktion, verificering og validering 7<br />
2.1 Ankomster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7<br />
2.2 Ankomst til input conveyor . . . . . . . . . . . . . . . . . . . . 8<br />
2.3 Arbejdsstation 8 . . . . . . . . . . . . . . . . . . . . . . . . . . 9<br />
2.4 Automatiserede arbejdsstationer . . . . . . . . . . . . . . . . . 10<br />
2.5 Manuelle arbejdsstationer . . . . . . . . . . . . . . . . . . . . . 12<br />
2.6 De sidste 4 moduler . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
2.7 Run Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
2.8 Verificering og Validering . . . . . . . . . . . . . . . . . . . . . 14<br />
Kapitel 3 Analyse og konklusion 19<br />
3.1 Mulige forbedringer . . . . . . . . . . . . . . . . . . . . . . . . 19<br />
3.2 Modifikation 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20<br />
3.3 Modifikation 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
3.4 Kombinationer <strong>af</strong> modifikation 1 og 2 . . . . . . . . . . . . . . 23<br />
3.5 Konklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
Appendices 27<br />
Contest Problem 9: <strong>SM</strong> <strong>Electronics</strong> 29<br />
Output fra grundmodel 35<br />
Output fra modifikation 49<br />
Litteratur 63<br />
i
Abstract<br />
This project is written in connection with <strong>the</strong> course „Modelling, simulation<br />
and analysis“ at <strong>Aarhus</strong> University, Denmark. It takes its starting point in<br />
„Contest Problem 9“, supplied by Rockwell Automation, Inc. We have used simulation<br />
to examine a certain problem at a fictitious company, <strong>SM</strong> <strong>Electronics</strong>.<br />
The company has observed that bottlenecks occur somewhere in <strong>the</strong>ir system,<br />
and we have <strong>the</strong>refore build a model, by means of simulation, that describes<br />
<strong>the</strong> system. This is discussed in <strong>the</strong> first part of <strong>the</strong> assignment. We have <strong>the</strong>n<br />
established where <strong>the</strong> problem arised and as a conseqence of that, we have<br />
made some modifications to our model in order to try to solve <strong>the</strong> problem.<br />
By means of our simulations we have shed some light on <strong>the</strong> origin of <strong>the</strong><br />
problem and also seen which modifications that improved <strong>the</strong> system. In deciding<br />
which modifications to be used, we also took into account <strong>the</strong> cost of<br />
implementing <strong>the</strong> change and <strong>the</strong> savings obtained from <strong>the</strong> modification.<br />
iii
Forord<br />
Dette bachelorprojekt omhandler virksomheden <strong>SM</strong> <strong>Electronics</strong> som beskrevet<br />
i „Contest Problem 9“. Formålet med projektet har været at modellere<br />
en konkret virksomhed, og ud fra denne model at analysere en bestemt problemstilling<br />
vha. simulation. I det følgende er der en indgående beskrivelse <strong>af</strong><br />
den omtalte model, en diskussion <strong>af</strong> hvorfor den virker, samt en analyse <strong>af</strong><br />
problemstillingen med udgangspunktet i de resultater vi har opnået i løbet <strong>af</strong><br />
processen. Vi har set på forskellige modifikationer <strong>af</strong> modellen for at undersøge<br />
hvilke forbedringer, der er mulige at lave, og hvilke der kan forbedre systemet,<br />
samt lavet en analyse <strong>af</strong>, hvilke ændringer i grundmodellen, der således kan<br />
betale sig at gennemføre.<br />
Århus, Maj 2009<br />
v<br />
Lene Sønder & Morten Petersen
Kapitel 1<br />
Indledning<br />
1.1 Problemformulering<br />
Med udgangspunkt i „Contest Problem 9“ (se appendiks s. 35) har vi forsøgt<br />
at benytte simulation til at analysere og forbedre en vis problemstilling hos<br />
<strong>SM</strong> <strong>Electronics</strong>. Virksomheden fremstiller elektroniske elementer, som andre<br />
virksomheder videreforarbejder. I den konkrete problemstilling ser vi på en<br />
<strong>af</strong>deling som producerer tre elementer, A, B og C. Disse bliver hovedsageligt<br />
produceret separat, men ender alle i en fælles <strong>af</strong>sluttende proces. Helt konkret<br />
bliver elementerne placeret på et transportbånd, der fragter dem mellem otte<br />
arbejdsstationer, jvf. figur 1.1.<br />
Figur 1.1: Oversigt<br />
Der er tre forskellige typer arbejdsstationer. Station 8 er en på-/<strong>af</strong>læsningsstation,<br />
hvor de forskellige elementer anbringes i, hhv. fjernes fra en pallet,<br />
hvori elementerne transporteres i det videre system. Station 1, 3, 4, 5 og<br />
6 er automatiserede stationer, hvor elementerne bliver forarbejdet <strong>af</strong> maskiner,<br />
og hvor maskinerne evt. skal omstilles, hvis forrige element ikke var <strong>af</strong><br />
samme type som det nuværende. Til sidst har vi også de manuelle arbejdsstationer,<br />
hvor elementerne bliver behandlet <strong>af</strong> medarbejdere. Elementerne<br />
1
2 Kapitel 1. Indledning<br />
bliver fragtet rundt i systemet på nogle transportbånd med begrænset kapacitet,<br />
og et element betragtes som tabt for systemet, hvis der ikke er plads på<br />
transportbåndene.<br />
Problemstillingen består så i at minimere de omkostninger, som virksomheden<br />
har ved disse tabte elementer. Man kan fx forestille sig, at begrænsningerne<br />
på transportbåndene kunne være et problem, eller måske er arbejdsstationerne<br />
ikke hurtige nok. Yderligere kunne man forestille sig, at arbejdsstationerne<br />
kunne udnyttes bedre. Selve problemstillingen samt disse mulige årsager vil<br />
vi tage op og analysere i denne opgave.<br />
1.2 Modellen og Antagelser<br />
Data for <strong>SM</strong> <strong>Electronics</strong>’ fjerde linje omhandler ankomster <strong>af</strong> enhederne A, B<br />
og C, den tid det tager at forarbejde hver type på de syv forskellige arbejdsstationer,<br />
den tid det tager at omstille maskinerne, så de passer til de forskellige<br />
typer enheder og hastigheden på virksomhedens transportbånd. Desuden oplyses<br />
den lost cost der indtræffer, når et element smides ud, inden det når at<br />
komme ind på det første transportbånd til det videre system. Da der er tale<br />
om et faktisk system, som virksomheden har og arbejder med, må det forventes,<br />
at tiderne er en god repræsentation <strong>af</strong> virkeligheden. Samlet producerer<br />
de tre første linjer omkring<br />
( 60 60<br />
+<br />
2.8 1.4<br />
60<br />
+ ) stk/time · 16 timer ≈ 1500 stk<br />
2<br />
hver dag, og det er derfor muligt at samle ret gode data om, hvordan enhederne<br />
kommer, og hvad der sker med dem igennem systemet.<br />
Man kan diskutere, om en triangulær fordeling normalt vil give et godt<br />
billede <strong>af</strong>, fx hvor lang tid et stykke arbejde tager, men da virksomheden<br />
netop har h<strong>af</strong>t et konsulentfirma til at finde data, og da der er så meget data<br />
at lave analyser ud fra, må det forventes, at de oplyste tal giver et nogenlunde<br />
godt billede <strong>af</strong> virkeligheden. Mht. lost cost, som vi får oplyst, er hhv. 0.89,<br />
0.63 og 0.72, kan vi ud fra teksten ikke vurdere, om det er tal, der svarer<br />
til virkeligheden, da vi ikke har nogen andre omkostninger i forbindelse med<br />
systemet, og vi intet får at vide om, hvordan disse omkostninger er fundet. Vi<br />
må derfor blot antage, at data i opgavebeskrivelsen er en god repræsentation<br />
<strong>af</strong> virkeligheden, især fordi vi behandler et system, der allerede eksisterer, og<br />
hvor det er muligt at lave faktiske målinger.<br />
Mht. de to modifikationer er der til gengæld tale om endnu ikke <strong>af</strong>prøvede<br />
systemer, hvilket gør, at det ikke er muligt at se, hvordan de fungerer. Men<br />
da der kun er tale om små modifikationer i det faktiske system, som ikke<br />
umiddelbart vil have nogen effekt på andet end hhv. antallet <strong>af</strong> enheder i<br />
systemet, eller hvor ofte nogle enheder skal igennem setuptid, må vi også<br />
forvente, at data i disse tilfælde er gode nok.
1.2. Modellen og Antagelser 3<br />
Den del <strong>af</strong> <strong>SM</strong> <strong>Electronics</strong>, vi analyserer, er et system, hvor der kommer<br />
tre typer enheder ind, A, B og C, som er blevet forarbejdet på hver deres<br />
linje og nu kommer ind på en fælles linje. Alle tre enheder kommer fra en<br />
anden linje i konstante tidsintervaller, dog med en lille forsinkelse nogle få<br />
procent <strong>af</strong> de gange, de ankommer. På den fjerde linje placeres enhederne på<br />
et fælles transportbånd, „Input Conveyor“ (IC), i den rækkefølge de kommer<br />
ind. På (IC) er der plads til 40 enheder. Vi har antaget at en enhed fylder<br />
2 fod på (IC) (og de tre buffer conveyors fra modifikation 2), ligesom det er<br />
tilfældet på transportbåndet mellem arbejdsstationerne, som vi har valgt at<br />
kalde „Conveyor“ (C). Ligeledes har vi antaget, at alle transportbånd kører<br />
med samme hastighed som (C), dvs. 72 fod pr. min. Dette betyder i det store<br />
hele ikke noget, da vi har en opvarmningsperiode, jvf. <strong>af</strong>snit 2.7 på side 13, så<br />
vi kun måler på systemet, når det er fyldt op. Alligevel synes vi, at det giver<br />
en bedre repræsentation <strong>af</strong> virkeligheden at lave disse transportbånd i forhold<br />
til kun at lave en kø, fordi det virker mest naturligt, at der er en transporttid,<br />
fx fra der hvor enhederne samles til det område, hvor de læsses på (C).<br />
Hvis der allerede er 40 enheder på (IC), når enheden kommer hen til transportbåndet,<br />
smides den ud. Når elementerne har passeret (IC), læsses de op<br />
på en slags pallet, som enhederne nu skal fragtes i, i det videre system. Disse<br />
palletter er placeret på (C), som er forbindelsen mellem otte stationer, hvor<strong>af</strong><br />
de syv forarbejder enheden. På (C) er der 40 palletter, dvs. der også på dette<br />
transportbånd højst kan være 40 enheder.<br />
Hele den fjerde linje består <strong>af</strong> 8 stationer, 5 automatiserede arbejdsstationer,<br />
2 manuelle arbejdsstationer og én på-/<strong>af</strong>læsningsstation, hvor alle arbejdsstationerne<br />
har forskellige procestider, der er <strong>af</strong>hængige <strong>af</strong> hvilken type<br />
enhed, der skal behandles. Af-/pålæsningsstationens proces tager en konstant<br />
tid, ligegyldigt hvilken type enhed der behandles.<br />
Vi har ladet denne fjerde linje bestå <strong>af</strong> to transportbånd, (IC) og (C).<br />
Dette har vi gjort, fordi vi forstår systemet således, at der placeres en ny<br />
enhed ned i en pallet, så snart den færdiggjorte enhed er blevet fjernet, hvilket<br />
ikke var muligt, hvis systemet skulle bestå <strong>af</strong> kun et transportbånd. Havde<br />
der kun været ét bånd, skulle det efter <strong>af</strong>læsning <strong>af</strong> en færdig enhed tilbage<br />
til stationen, hvor enhederne kommer ind på linjen, og først derefter hen til<br />
pålæsningsstationen. Denne løsning ville også give problemer mht. palletten,<br />
da enhederne ikke skal anbringes i en pallet med det samme, de kommer ind<br />
på transportbåndet, og det ville derfor blive nødvendigt, at fjerne palletten<br />
fra båndet samtidig med den færdige enhed, for derefter at placere den på<br />
transportbåndet igen, når en ny enhed skal læsses på palletten. Derfor har vi<br />
valgt at lade de to transportbånd køre i hver sin ring. (IC) kører fra punktet,<br />
hvor enhederne kommer ud, til på-/<strong>af</strong>læsningsstationen og tilbage igen, mens<br />
(C) kører fra på-/<strong>af</strong>læsningsstationen videre til arbejdsstation 1, 2 osv. frem<br />
til arbejdsstation 7 og tilbage til på-/<strong>af</strong>læsningsstationen.<br />
På arbejdsstationerne har vi antaget <strong>af</strong> elementerne fjernes fra transportbåndet<br />
og placeres derpå igen, efter arbejdet er færdiggjort. Vi har valgt
4 Kapitel 1. Indledning<br />
denne løsning, fordi vi i beskrivelsen <strong>af</strong> problemet får opgivet en hastighed,<br />
som transportbåndet kører med, der gør, at det vil tage transportbåndet under<br />
to sekunder at bevæge sig de to fod en arbejdsstation fylder. Derfor ville<br />
det aldrig kunne lade sig gøre, at arbejdet på stationerne blev lavet, hvis<br />
elementerne skulle blive på båndet, og båndet skulle køre med den opgivne<br />
hastighed. Vi har derfor valgt, at enhederne forlader båndet ved alle arbejdsstationer,<br />
da alternativet ville være, at båndets hastighed skulle bestemmes<br />
<strong>af</strong> den langsomste proces, og hastigheden på de 72 fod i minuttet ville dermed<br />
være underordnet.<br />
Fordi vi har antaget, at elementerne forlader transportbåndet ved arbejdsstationerne,<br />
har vi valgt at inkludere de enheder, der er på arbejdsstationerne,<br />
og specielt i kø til disse, i de 40, der højst kan være på transportbåndet. Havde<br />
vi ikke valgt at gøre dette, skulle der fx være ubegrænset plads i køen til<br />
arbejdsstationerne. Det ville have betydet, at begrænsningen på højst 40 enheder<br />
ikke ville have gjort nogen forskel, da man ved at se lidt på arbejdstiderne<br />
på arbejdsstationerne, kan se, at det som regel vil tage længere tid for en enhed<br />
at komme igennem en arbejdsstation end at blive transporteret imellem<br />
to arbejdsstationer. Derfor har vi valgt, at der maksimalt kan være 40 på (IC)<br />
og området omkring den. Ligeledes kan der i alt være 40 på transportbåndet<br />
og arbejdsstationerne i det videre system. For at begrænse antallet <strong>af</strong> enheder<br />
i systemet, dvs. for at undgå så stor en kø før (IC), at den aldrig ville kunne<br />
<strong>af</strong>vikles, tjekkes der, når en enhed kommer frem til det første transportbånd,<br />
om der samlet er færre end 40 enheder på (IC) og i køen til pålæsningsstationen.<br />
Er der det, sendes elementet ind på transportbåndet, og det gennemløber<br />
hele systemet, mens enheden smides ud, hvis der er 40 på båndet og området<br />
omkring den.<br />
I de fem automatiserede arbejdsstationer er der en konstant procestid, der<br />
er <strong>af</strong>hængig <strong>af</strong>, hvilken type den ankomne enhed har, men der er også en<br />
setuptid, som enheden skal igennem, hvis den forrige enhed var <strong>af</strong> en anden<br />
type end den nyankomne. Når arbejdsdagen slutter skal alle enheder stoppe<br />
der, hvor de er, og næste dag fortsættes der, hvor man slap. Det betyder<br />
naturligvis også, at setuptid for den første, der ankommer en morgen, <strong>af</strong>hænger<br />
<strong>af</strong>, hvilken type den sidste, der var igennem stationen dagen før, havde. Vi har<br />
samtidigt antaget, at når systemet begynder, er alle maskiner gjort klar til en<br />
enhed <strong>af</strong> type A. Dette betyder dog ikke noget pga. opvarmningsperioden.<br />
Den arbejdsopgave at fjerne et element fra en pallet og pålæsse en ny<br />
tager samlet 25 sekunder plus en forsinkelse nogle procent <strong>af</strong> gangene. Dette<br />
har vi modelleret lidt anderledes dog uden at ændre på, hvordan modellen<br />
fungerer. Vi har ladet station 8, som er <strong>af</strong>-/pålæsningsstationen, opdele i to<br />
stationer. En station i starten, der læsser enheder på (C), og en station til sidst<br />
i modellen, der fjerner dem fra den igen. Afstanden mellem disse to stationer<br />
har vi ladet være nul, hvilket gør, at så snart en enhed er taget ud <strong>af</strong> systemet,<br />
er (C) allerede ved pålæsningsstationen, og en ny enhed bliver placeret på<br />
båndet. I stedet for at dele tiden ud på både <strong>af</strong>læsning og pålæsning, lader
1.2. Modellen og Antagelser 5<br />
vi pålæsningen tage 25 sekunder plus en forsinkelse 1% <strong>af</strong> gangene. På den<br />
måde bliver den samlede tid i systemet for hver enhed ikke ændret, og først<br />
når systemet er fyldt (og det er først når systemet er fyldt, vi begynder at<br />
måle), vil der alligevel ikke kunne pålæsses en enhed før, en færdig enhed er<br />
blevet taget <strong>af</strong> palletten. Dette gør, at det ikke har nogen betydning, at hele<br />
på-/<strong>af</strong>læsningstiden tilføjes i starten.<br />
I forbindelse med arbejdsstationerne, hvor det ankomne element fjernes fra<br />
transportbåndet, behandles og anbringes på transportbåndet igen, antager vi,<br />
at enheden fragtes på båndet de 16 fod, der er mellem to arbejdsstationer,<br />
tages <strong>af</strong> båndet, mens dette kører videre og placeres efter arbejdstiden på<br />
båndet igen. På- og <strong>af</strong>læsningstiden ved dette, antager vi, er medregnet i<br />
arbejdstiden ved den enkelte station.
Kapitel 2<br />
Modelkonstruktion,<br />
verificering og validering<br />
I dette kapitel vil vi grundigt gennemgå, hvordan modellen er bygget op,<br />
og vi vil tydeliggøre sammenhængene mellem de enkelte moduler i modellen.<br />
Formålet her er ikke at give det store overblik over modellen, da en sådan er<br />
formuleret i <strong>af</strong>snit 1.2 på side 2.<br />
2.1 Ankomster<br />
Lad os nu tage fat på modellen. I figur 2.1 på næste side ser vi, at vi har tre<br />
typer <strong>af</strong> ankomster. Der foregår dog essentielt det samme i alle tre moduler<br />
nemlig, at der er et udtryk på formen<br />
c + (DISC(x, 0, y, 1, z) · TRIA(a, b, c, w))<br />
hvor c angiver en konstant, der repræsenterer en fast ankomstrate. Vi bruger<br />
operatoren DISC til at modellere, at der en vis procentdel <strong>af</strong> gangene sker<br />
forsinkelser <strong>af</strong> typen TRIA. Eksempelvis ankommer der et element <strong>af</strong> typen<br />
A hver 168 sekund bortset fra, at det 2% <strong>af</strong> gangene bliver forsinket med<br />
en stokastisk variabel, der er triangulær fordelt med parametrene 5, 15 og<br />
60. Bemærk i øvrigt også, at vi styrer talstrømmene (her symboliseret med z<br />
og w) således, at vi er sikre på, at der kommer det samme antal ankomster i<br />
både vores grundmodel samt i vores modifikationer.<br />
Efter disse indledende create moduler kommer elementerne nu til et assign<br />
modul, hvis eneste opgave er at tildele de forskellige typer <strong>af</strong> elementer en<br />
værdi 1, 2 eller 3, <strong>af</strong>hængig <strong>af</strong> om elementet er <strong>af</strong> type A, B eller C. Hvad vi<br />
helt konkret bruger disse værdier til, kommer vi tilbage til i <strong>af</strong>snit 2.2 på den<br />
følgende side.<br />
7
8 Kapitel 2. Modelkonstruktion, verificering og validering<br />
Figur 2.1: Ankomster<br />
2.2 Ankomst til input conveyor<br />
Vi er nu nået dertil, hvor vi skal <strong>af</strong>gøre, om der plads på (IC) eller ej. Dette<br />
sørger vores decide modul for vha. følgende udtryk<br />
Entity Counter + NQ(Queue for load point.Queue) < 40 (2.1)<br />
„Entity Counter“ er en variabel, som holder øje med hvor mange elementer,<br />
der er på (IC). Dvs. næsten i hvert fald. Som det fremgår <strong>af</strong> (2.1), har vi også<br />
tilføjet antallet <strong>af</strong> elementer i vores load point kø, hvilket er specificeret i et<br />
hold modul senere i modellen. Vi vil komme ind på, hvorfor dette er vigtigt,<br />
og hvorfor det er en del <strong>af</strong> (2.1) i <strong>af</strong>snit 2.3 på næste side.<br />
Figur 2.2: Ank. til input conveyor<br />
Indtil videre vil vi antage, at dette er i orden, og vi vil derfor bevæge os<br />
videre til det næste decide modul. Det vil sige, at vi nu er i tilfældet, hvor<br />
(IC) er fyldt. Der er nu tre mulige udfald; enten er elementet <strong>af</strong> typen A,<br />
B eller C. Det er så her værdien, som elementet fik tildelt i assign modulet<br />
i starten <strong>af</strong> modellen, kommer ind i billedet. Vi er nemlig nu i stand til at
2.3. Arbejdsstation 8 9<br />
<strong>af</strong>gøre elementtypen blot vha. følgende tests<br />
if assigned value = i, i = 1, 2, 3<br />
Vi har nu fået <strong>af</strong>gjort <strong>af</strong> hvilken type, det pågældende element er, og vi kan derfor<br />
begive os videre til de tre record moduler, som blot tæller én op, hver gang<br />
et element passerer. På denne måde har vi styr på hvor mange <strong>af</strong> hver type,<br />
der bliver betragtet som tabt. Udover disse tre record moduler samt standard<br />
statistikken fra run setup, har vi yderlige defineret nogle ekstra linjer i datamodulet<br />
„Statistic“ under „Advanced processes“. Disse fremgår <strong>af</strong> figur 2.3.<br />
De første tre rækker tager blot antallet fra vores førnævnte record moduler og<br />
Figur 2.3: Statistik<br />
ganger med enhedsomkostningen for de respektive typer. På denne måde får<br />
vi skabt noget statistik, der fortæller, hvad omkostningerne har været, fordelt<br />
på de tre typer <strong>af</strong> elementer. Den fjerde række lægger blot disse tal sammen,<br />
så vi får et udtryk for den samlede omkostning.<br />
Lad os nu se på situationen, hvor (IC) er ledig, dvs. at elementet i stedet<br />
kommer til assign modulet, „Increment # of Entities in input Conveyor“,<br />
hvis eneste opgave er at tælle variablen „Entity Counter“ én op. Elementet<br />
ankommer herefter til en station, „merge station“, som modellerer ankomsten<br />
til (IC). „Merge point“, som er det efterfølgende leave modul, søger så for, at<br />
elementerne faktisk kommer op på (IC).<br />
2.3 Arbejdsstation 8<br />
Inden vi fortsætter med de næste moduler, vil vi her lige forklare, hvordan<br />
vores generelle transportbånd er bygget op. Grundlæggende er de bygget fuldstændig<br />
identisk op, så vi vil nøjes med at betragte (IC). Den er <strong>af</strong> typen<br />
„non-accumulating“, da vi betragter et transportbånd, der kører med en konstant<br />
fart uden <strong>af</strong>brydelser. Hastigheden er sat til 72 fod pr. minut, eller som<br />
der står i opgaveteksten (jvf. „Contest Problem 9: <strong>SM</strong> <strong>Electronics</strong>“ på side<br />
35), 18 fod pr. 15 sekunder. I datamodulet „Conveyor“ har vi valgt at sætte<br />
„Cell Size“ til én fod og „Max Cells Occupied“ til to fod. Ligeledes har vi i alle<br />
leave modulerne givet „# of Cells“ værdien 2. Disse værdier har vi valgt, fordi<br />
en enhed skal optage to fod på et transportbånd, hvilket vi sørger for ved at<br />
lade en enhed fylde to celler, der hver er på én fod. Denne løsning har vi valgt,<br />
frem for at lade et element fylde en celle på to fod, for at gøre simulationen<br />
mere præcis jvf. [1].
10 Kapitel 2. Modelkonstruktion, verificering og validering<br />
Figur 2.4: Workstation 8<br />
Tilbage til modulerne, jvf. figur 2.4. Vores element ankommer nu til et enter<br />
modul, som har til opgave at tage vores element <strong>af</strong> (IC). Inden vi kommer til<br />
det førnævnte hold modul, skal vores element lige igennem et assign modul,<br />
der tæller vores Entity Counter én ned igen, således at vi kan holde styr<br />
på antallet <strong>af</strong> elementer på (IC). Hold modulet holder på elementerne indtil<br />
følgende betingelse er opfyldt<br />
Entity Counter 2 < NrOfEntities<br />
hvor „Entity Counter 2“ er en variabel fuldstændig magen til Entity Counter,<br />
blot tæller denne variabel antallet <strong>af</strong> elementer på (C) og ikke (IC).<br />
„NrOfEntities“ er en variabel, der konstant er lig 40, da det giver os mulighed<br />
for at bruge Process Analyzer (PAN) til at se på effekterne <strong>af</strong> en evt.<br />
udvidelse <strong>af</strong> antallet <strong>af</strong> palletter på (C). Så det, betingelsen siger, er, at vi<br />
skal holde på vores elementer, indtil der er plads på (C). Dette venteområde<br />
betragter vi også som en del <strong>af</strong> (IC). Grunden hertil er, at vi mener, det giver<br />
det mest realistiske billede <strong>af</strong> virkeligheden, og den måde vi opfatter den på,<br />
jvf. <strong>af</strong>snit 1.2 på side 2. Sagen er, at der kan være 40 elementer på (IC), dvs.<br />
i det område der kommer før workstation 8, dvs. inkl. hold modulet. Dette er<br />
også grunden til, at vi i (2.1) medtager antallet <strong>af</strong> elementer i hold modulet.<br />
Nu er vi så kommet dertil, hvor elementet skal op på (C), og derfor skal<br />
vores enhed igennem endnu et assign modul, der har til formål at tælle førnævnte<br />
Entity Counter 2 én op. Dernæst ankommer elementet til en station,<br />
der skal markere, at enheden er klar til at komme op på (C). Selve denne<br />
manøvre sker i det næste leave modul. Her bemærkes i øvrigt, at hele load-<br />
/unload proceduren regnes med her, som det også fremgår <strong>af</strong> den forsinkelse,<br />
vi har angivet i modulet.<br />
2.4 Automatiserede arbejdsstationer<br />
Med udgangspunkt i den første arbejdsstation vil vi nu se på de automatiserede<br />
arbejdsstationer, dvs. arbejdsstationerne 1, 3, 4, 5 og 6 (se evt. 2.5 på<br />
næste side). Disse er opbygget <strong>af</strong> et enter modul, „Enter Work Station 1“,<br />
for at enheden kan forlade transportbåndet, et seize modul, „Seize Work Station<br />
1“, der belægger ressourcen, og et decide modul, „Is Entity Type <strong>the</strong><br />
same in 1?“, der <strong>af</strong>gør, om den pågældende enhed er <strong>af</strong> samme type, som den<br />
foregående. Dvs. vi har en variabel, „Variabel 1“, som har en værdi 1, 2 eller<br />
3, og decide modulet tester, om „assigned value“ ved den enhed, der kommer
2.4. Automatiserede arbejdsstationer 11<br />
igennem decide modulet, er den samme som denne værdi. Hvis svaret til decide<br />
modulet er falskt, vil enheden nu skulle igennem både en setuptid og en<br />
procestid, som begge er konstanter, der er <strong>af</strong>hængige <strong>af</strong> enhedens type og hvilken<br />
arbejdsstation, den er ved. Er svaret sandt, og enheden er <strong>af</strong> samme type<br />
som den foregående, skal enheden blot igennem procestiden. Inden ressourcen<br />
frigives skal enheden igennem et assign modul, der sætter Variabel 1 til værdien<br />
<strong>af</strong> „assigned value“, og derved holdes der styr på hvilken type enhed, der<br />
lige har været igennem arbejdsstationen. Denne værdi bruges således til at<br />
<strong>af</strong>gøre, om den næste enhed skal igennem setup eller blot kan sendes direkte<br />
ind i processen. Herefter fragtes elementet igennem et release modul, der frigiver<br />
ressourcen, et station modul, der bruges til at angive transportbåndets<br />
rute og et leave modul, „Leave Work Station 1“, hvor elementet kommer på<br />
transportbåndet igen og sendes videre til næste station. Løsningen med seizedelay-release,<br />
har vi valgt for at sikre, at det ikke er muligt at overhale en<br />
enhed, der befinder sig i setup. På denne måde kan et element ikke komme<br />
ind i decide modulet, før det foregående er færdigbehandlet, og dets type er<br />
gemt i Variabel 1.<br />
Figur 2.5: Automatiseret arbejdsstation<br />
Procestiderne og setuptiderne har vi valgt at lave i et array med hhv. 21<br />
og 15 indgange. Det betyder, at den første indgang i udtrykket Process er<br />
arbejdstiden i arbejdsstation 1 på et element <strong>af</strong> typen A. Anden indgang er<br />
arbejdstiden i arbejdsstation 1 på et element <strong>af</strong> typen B, fjerde indgang er<br />
arbejdstiden i arbejdsstation 2 på et element <strong>af</strong> typen A osv. Setuptiderne er<br />
defineret på samme måde, her er der dog bare tale om en liste med 15 indgange,<br />
fordi de to manuelle arbejdsstationer ikke skal gennem opsætning ved forskellige<br />
typer elementer. Arena sørger for at vælge de rigtige indgange, fordi vi<br />
under fx „Delay Time“ i „Process Time 1“ har skrevet Process(assigned value).<br />
Hvis elementet, der kommer ind i dette modul, er <strong>af</strong> typen A, vil den have<br />
værdien 1 som assigned value, og Arena vil derfor finde Process(1), som er den<br />
første indgang i Process. Ved hver <strong>af</strong> de efterfølgende arbejdsstationer har vi<br />
blot lagt hhv. 3, 6, 9, 12, 15 og 18 til assigned value, og derved finder Arena<br />
de tider, elementet skal forsinkes med baseret på, hvilken type det er, og hvor<br />
det er i systemet. Denne løsning har vi valgt frem for at have et expression til<br />
hver proces-/setuptid, fordi vi ved at have et expression til alle tider fik for<br />
mange siman objekter, og derfor ikke kunne køre modellen. Alternativt kunne
12 Kapitel 2. Modelkonstruktion, verificering og validering<br />
vi have reduceret modellen, så den fx ikke havde så mange arbejdsstationer,<br />
men denne løsning ville vi selvfølgelig gerne undgå.<br />
2.5 Manuelle arbejdsstationer<br />
De manuelle arbejdsstationer er en simplere udgave <strong>af</strong> de automatiserede.<br />
Her er det ikke nødvendigt med en setuptid, hvilket gør, at det ikke bliver<br />
nødvendigt at holde styr på, hvilke typer der tidligere har været igennem. Disse<br />
arbejdsstationer er derfor kun opbygget <strong>af</strong> et enter modul, der tager enhederne<br />
<strong>af</strong> transportbåndet, et process modul, der har samme effekt som seize-delayrelease-konstruktionen<br />
fra de automatiserede arbejdsstationer, og til slut en<br />
station og et leave modul, der gør, at transportbåndets rute kan blive beskrevet<br />
i datamodulet „Segment“, og at enhederne sættes tilbage på transportbåndet.<br />
Som ved de automatiserede arbejdsstationer vælges procestiderne vha. Process<br />
under „Expression“, og de rigtige indgange i denne liste findes vha. attributten<br />
assigned value plus en konstant. Eneste ændring er, at tiderne her ikke er<br />
konstante, men triangulært fordelte.<br />
2.6 De sidste 4 moduler<br />
Figur 2.6: Manuel arbejdsstation<br />
Nu er vi så nået til <strong>af</strong>slutningen <strong>af</strong> vores model. Her kommer elementet i første<br />
omgang til et enter modul, „Exit conveyor“, som igen blot tager elementet <strong>af</strong><br />
(C). Dernæst har vi en station, „Leaving unload station“, som markerer det<br />
sidste element på (C). Inden enheden sendes ud gennem vores dispose modul,<br />
skal vi lige sørge for at Entity Counter 2 bliver talt én ned, hvilket selvfølgelig<br />
sker gennem et assign modul, som her hedder „Decrement # of Entities in<br />
Conveyor“.<br />
Figur 2.7: Exit
2.7. Run Setup 13<br />
2.7 Run Setup<br />
Det sidste, vi vil kommentere i dette kapitel, er, hvordan vi har sat selve kørslerne<br />
op. Som det fremgår <strong>af</strong> Figur 2.8, har vi sat „replikationslængden“ til<br />
5000 minutter (5 dage med 16 timer pr. dag angivet i minutter plus 200 min. i<br />
opvarmningsperiode) og „Timer pr. dag“ til 16. Dette fremgår mere eller mindre<br />
<strong>af</strong> opgaveteksten (jvf. „Contest Problem 9: <strong>SM</strong> <strong>Electronics</strong>“ på side 35),<br />
idet virksomheden arbejder med 16 timers produktionsdage, 5 dage om ugen.<br />
Med hensyn til „opvarmningsperioden“ og „# replikationer“ har vi her været<br />
i gang med nogle overvejelser. Mere præcist har vi til opvarmningsperioden<br />
benyttet Output Analyzer (OA). Da produktionen bliver lukket ned hver dag<br />
uden, at de ufærdige produkter forlader systemet, var vores mål, at opvarmningsperioden<br />
skulle sørge for, at antallet <strong>af</strong> elementer i systemet skulle være<br />
på det normale niveau. Til at undersøge hvad dette normale niveau er, har<br />
Figur 2.8: Run Setup<br />
vi som sagt brugt (OA). Af grunde vi ikke forstår vælger (OA) ikke at vise,<br />
hvad der sker efter ca. 200 min. (svarende til opvarmningsperioden), hvis man<br />
blot ser på et kort tidsinterval, jvf. figur 2.9 på næste side, så for det fulde<br />
billede, se figur 2.10 på den følgende side. Det, vi her ser, er, at der går ca.<br />
150 min., fra vi starter, til niveauet for systemet er stabiliseret, og for at være<br />
på den sikre side sætter vi derfor opvarmningsperioden til 200 min. Bemærk<br />
at vi har benyttet (OA) i tilfældet, hvor NrOfEntities er 72. Dette gør selvfølgelig<br />
opvarmningsperioden unødvendigt lang i tilfældet med færre palletter<br />
på båndet, men i forbindelse med vores kørsler i (PAN) var det en fordel at<br />
systemet var fyldt u<strong>af</strong>hængigt <strong>af</strong> NrOfEntities. Mht. antallet <strong>af</strong> replikationer,<br />
så har vi her gjort os nogle overvejelser mht. vores konfidensintervaller. Vi har<br />
i den forbindelse lavet kørsler med hhv. 10, 40, 50, 70 og 100 replikationer,
14 Kapitel 2. Modelkonstruktion, verificering og validering<br />
Figur 2.9: # i systemet<br />
Figur 2.10: # i systemet, set over hele perioden<br />
og det viser sig, at når antallet kommer over 50, bliver ændringerne meget<br />
små, og vi har derfor valgt, at det ikke kan betale sig at lave flere end 50<br />
replikationer. Dette er selvfølgelig et skøn, vi har gjort os, men virksomheden<br />
kunne jo sagtens tænkes at have andre præferencer end os. Man kunne sagtens<br />
forestille sig, at de gerne ville have en meget præcis simulation, og derfor ville<br />
sætte pris på mange flere replikationer eller omvendt, at de ikke vil bruge for<br />
mange ressourcer, og derfor kunne være fint tilfredse med fx 10 replikationer.<br />
2.8 Verificering og Validering<br />
I opbygningen <strong>af</strong> vores model har vi ikke, som anbefalet i [2], startet med<br />
at lave en mindre model og udbygget den efterhånden, men i stedet forsøgt<br />
at lave hele modellen, og så senere delt den ind i mindre dele for at undersøge,<br />
om alle delprocesser virkede efter hensigten. Dette har vi gjort, da vi<br />
syntes, at det var nødvendigt med mindst én arbejdsstation <strong>af</strong> hver type og<br />
vores <strong>af</strong>/-pålæsningsstation for at lave en grundmodel, der nogenlunde kunne<br />
repræsentere virksomheden, og dermed give et overblik over opbygningen <strong>af</strong><br />
denne produktionslinje. Da fem <strong>af</strong> arbejdsstationerne er identiske, bortset fra<br />
nogle proces- og setuptider, valgte vi at lave alle fem på én gang. Ligeledes<br />
lavede vi de to manuelle arbejdsstationer samtidig, fordi vi således kunne få<br />
et overblik over den samlede model, og alligevel, fordi så mange arbejdsstationer<br />
stort set er ens, forholdsvist nemt kunne overskue modellen. Dette gav et<br />
overblik over, om elementerne blev fragtet igennem systemet som ønsket, og<br />
især om transportbåndene fungerede, som de skulle. Sidenhen har vi forenklet<br />
modellen bl.a. for at undersøge, om decide modulerne i modellen fungerede<br />
som forventet.<br />
Det første decide modul (Is Input Conveyor avaliable?) <strong>af</strong>gør, om der er<br />
så mange elementer på vores (IC), at det pågældende element, der er kommet<br />
ind i decide modulet, skal direkte ud <strong>af</strong> systemet som en lost cost eller ej.<br />
For at undersøge om dette modul gjorde som forventet, har vi fokuseret på<br />
Arenas animation, hvor vi kunne se, at elementerne sendes videre i systemet,
2.8. Verificering og Validering 15<br />
når der samlet er færre end 40 i „merge point“, (IC) og „Queue for load point“.<br />
I vores output, jvf. „Output fra grundmodel“ på side 35, fra kørslerne ses det<br />
også, at summen <strong>af</strong> antal ventende ved hhv. merge point, Queue for load point<br />
og antallet <strong>af</strong> elementer på (IC) er mindre end 40, og at den også ligger så<br />
tæt på 40, at betingelsen ser ud til at blive udnyttet fuldt ud. Ligeledes har<br />
vi kunnet nå frem til, at vores hold modul inden load point (Queue for load<br />
point) fungerer efter hensigten, da man under „Entity“ → „O<strong>the</strong>r“, kan se, at<br />
det samlede work in process for A, B og C er under, men dog forholdsvist tæt<br />
på 80. Da der aldrig er mere end 40 i (IC) og køerne omkring denne betyder<br />
dette, at der er omkring 40 i resten <strong>af</strong> systemet som ønsket.<br />
For at <strong>af</strong>gøre om decide modulet (Is entity <strong>the</strong> same type?) ved arbejdsstationerne<br />
fungerer efter hensigten, har vi set på hele systemet, hvor vi kun<br />
har sendt én type ind, og derved har kunnet se, at decide modulerne sender<br />
alle enheder videre til processen uden setuptid, på nær det første element,<br />
som, hvis det er <strong>af</strong> type B eller C, skal igennem setuptid, da vi har antaget, at<br />
maskinerne er gjort klar til type A. Derefter sendte vi kun elementer <strong>af</strong> type<br />
A og B ind i systemet på en sådan måde, at hver anden var <strong>af</strong> type A, hver<br />
anden <strong>af</strong> type B, og kunne så observere, som ønsket, at alle elementer skulle<br />
igennem en setuptid ved alle arbejdsstationer. Alt dette har vi observeret vha.<br />
Arenas simulation <strong>af</strong> kørslen.<br />
Ud over at vi selv har diskuteret modellen, hvor vi har forsøgt at se om<br />
den giver mening i forhold til virkeligheden, og om den fungerer som den skal,<br />
har vi også ladet to andre se modellen igennem, sådan at de med upåvirkede<br />
øjne kunne se efter eventuelle svage punkter eller fejlfortolkninger.<br />
Desuden har vi lavet forskellige simple udregninger for at teste, om fx antallet<br />
<strong>af</strong> lost parts udregnes rigtigt (summen <strong>af</strong> antal lost parts og „Number out“<br />
i proces 7, bør ca. være Number out i alt), og set generelt på tallene i output<br />
fra kørslerne (se „Output fra grundmodel“ på side 35) for at se, om tallene<br />
virker realistiske. Både ud fra køtider, antal elementer i kø og udnyttelse <strong>af</strong><br />
ressourcerne ses det, at flaskehalsen i systemet er arbejdsstationerne, hvilket<br />
også er det forventede, da transportbåndene kører 72 fod i minuttet, og det<br />
dermed vil tage ca. 14 sekunder at blive transporteret de 16 fod, der er mellem<br />
to arbejdsstationer. Det er derfor klart, at der vil skabes kø ved arbejdsstationerne,<br />
fordi ingen <strong>af</strong> arbejdsstationerne har en procestid på under 20 sekunder,<br />
og der udover procestiderne også ofte kommer en setuptid.<br />
Da det ikke er transportbåndene, der er flaskehals i systemet, vil det naturligvis<br />
også betyde, at man, for at få en forbedring <strong>af</strong> systemet der virkelig<br />
gør en forskel, er nødt til at forkorte tiden, enhederne er på arbejdsstationerne.<br />
Derfor er det også forventeligt, at man ved modifikation 1, hvor antallet <strong>af</strong><br />
elementer i systemet udvides, ikke ser en stor ændring i antallet <strong>af</strong> lost parts,<br />
mens man ved modifikation 2 forkorter tiden i arbejdsstationerne betydeligt,<br />
og derved får en stor forbedring.<br />
I forhold til ankomsterne <strong>af</strong> enhederne, er der opstået det problem, at de<br />
ikke var ens, når man så på modifikation 2 i forhold til grundmodellen. Dette
16 Kapitel 2. Modelkonstruktion, verificering og validering<br />
har vi dog fået løst ved at styre alle talstrømme, dvs. ved at bruge forskellige<br />
talstrømme til alle diskrete og triangulære fordelinger i de forskellige create<br />
moduler, men selvfølgelig de samme talstrømme på tværs <strong>af</strong> modifikationerne,<br />
jvf. <strong>af</strong>snit 2.1 på side 7.<br />
Da virksomhedens ønske kun er at få færre enheder smidt ud <strong>af</strong> den fjerde<br />
linje, inden de kommer ind på det første transportbånd, er det informationen,<br />
der har med denne problemstilling at gøre, der er vigtige at finde. Det betyder,<br />
at detaljegraden fx omkring arbejdsstationerne kun skal være stor nok til, at<br />
det kan give et indblik i, hvordan der kan komme flere igennem systemet, og<br />
dermed få færre elementer smidt ud.<br />
Var <strong>SM</strong> <strong>Electronics</strong> et virkeligt firma, ville det være forholdsvist simpelt<br />
at få et overblik over, om vores model svarer til virkeligheden, fordi grundmodellen<br />
beskriver et produktionssystem, der allerede eksisterer, og det ville<br />
derfor være muligt at se hvor mange enheder <strong>af</strong> hver type, der blev færdigproduceret,<br />
og hvor mange der blev kasseret. Ligeledes ville det være muligt at<br />
se, om det i virkeligheden var de samme arbejdsstationer, der gav anledning<br />
til flaskehalse, som dem i vores model og lignende. Desværre er det ikke muligt<br />
for os, da vi ganske enkelt ikke har de tal. Alligevel er det dog muligt ud fra<br />
det data, der er opgivet at se på nogle <strong>af</strong> modellens resultater. Bemærk at de<br />
følgende udregninger er baseret på overslag. Ankomsterne i modellen svarer<br />
godt til virkeligheden, da antal sekunder på en uge er 16 · 60 · 60 · 5 = 288000,<br />
hvilket betyder, at der på en uge kommer ca.<br />
288000<br />
168<br />
≈ 1714,<br />
288000<br />
84<br />
≈ 3429 og<br />
288000<br />
120<br />
≈ 2400<br />
elementer ind i systemet <strong>af</strong> hhv. type A, B og C (eller ca 343, 686 og 480 om<br />
dagen). Bemærk at disse tal er lidt over det faktiske, og de tal som Arena<br />
giver, da vi i disse udregninger ikke har taget højde for de forsinkelser, der<br />
nogle gange er i ankomsterne. Mht. flaskehalsene i systemet, er det klart, at<br />
det i virkeligheden, som i vores model, må være arbejdsstationerne, der er<br />
flaskehalsene, fordi det, som forklaret ovenfor, for alle arbejdsstationer tager<br />
mere end 14 sekunder at behandle en enhed. At det især er ved arbejdsstation<br />
4, der er kø, og dermed også denne station, der giver anledning til flaskehalse,<br />
kan også ses ud fra tallene ved at lave et vægtet gennemsnit <strong>af</strong> procestiderne<br />
ved arbejdsstationerne 1, 3, 4, 5 og 6 vægtet med, hvor mange enheder der<br />
kommer <strong>af</strong> hver type. Da fås hhv. ca. 41.7, 28.5, 41.5, 37.3 og 34.2, hvor<br />
eksempelvis det første tal er udregnet på følgende måde<br />
37 · 343 + 46 · 686 + 39 · 480<br />
343 + 686 + 480<br />
≈ 41.7<br />
Dette betyder, at den gennemsnitlige procestid i arbejdsstation 1 og 4 er væsentligt<br />
længere end ved de andre stationer. Men da så stor en del <strong>af</strong> enhederne<br />
skal igennem setup i grundmodellen, er det også nødvendigt at tage disse med<br />
i overvejelserne. Her ses det, at setuptiderne for alle tre typer er kortere ved
2.8. Verificering og Validering 17<br />
arbejdsstation 1 end ved arbejdsstation 4. Mht. arbejdsstation 3 er procestiderne<br />
så meget kortere end procestiderne i arbejdsstation 4, at det virker<br />
fornuftigt, at det vil tage en enhed længere tid at passere arbejdsstation 4 end<br />
3, på trods <strong>af</strong> setuptiderne ved arbejdsstation 3. På samme vis kunne det på<br />
data godt se ud til, at de sidste fire arbejdsstationer ikke er lige så forsinkende<br />
for systemet, som arbejdsstation 4, fordi setuptiderne i station 5 og 6 stort<br />
set alle er mindre end de tilsvarende tider fra station 4, og fordi stationerne 2<br />
og 7 ikke har setuptider, og derfor må være væsentligt hurtigere. Alt i alt er<br />
det plausibelt, at det bør være arbejdsstation 4, der samler kø, ligesom det er<br />
tilfældet i modellen. Mht. modifikationen, der gør, at enhederne bliver samlet<br />
alt efter type, virker det også troværdigt, at det stadig er arbejdsstation 4,<br />
der er flaskehalsen i systemet, fordi procestiderne i denne station var blandt<br />
dem, der tog længst tid, hvilket modifikationen ikke ændrer på. At køen også<br />
er længere ved station 4 end 1 skyldes stadig setuptiderne, for selvom antallet<br />
<strong>af</strong> enheder, der skal gennem setup, er stærkt reduceret, er der dog stadig tale<br />
om et stort antal enheder, som skal igennem setup.
Kapitel 3<br />
Analyse og konklusion<br />
3.1 Mulige forbedringer<br />
Som den oprindelige model fungerer, sendes forholdsvist mange enheder ud<br />
<strong>af</strong> den fjerde linje, inden de forarbejdes, fordi denne linje ikke kan følge med,<br />
i forhold til hvor hurtigt enhederne kommer ud fra de tidligere linjer. For at<br />
mindske antallet <strong>af</strong> enheder, der smides ud, er det derfor nødvendigt at se<br />
på ændringer, der kan <strong>af</strong>hjælpe dette problem. Da linjen består <strong>af</strong> to transportbånd,<br />
(IC) og (C), og otte arbejdsstationer, er det disse steder, vi skal<br />
forsøge at lave forbedringer. På transportbåndene er der to ting, der kan ændres<br />
på, som muligvis vil kunne hjælpe. For det første vil der blive smidt færre<br />
elementer ud <strong>af</strong> systemet, hvis et transportbånd kan indeholde flere enheder.<br />
Dvs. hvis der er plads til flere enheder på (IC) eller (C), vil der skulle smides<br />
færre enheder ud <strong>af</strong> den fjerde linje, inden de er blevet sendt igennem de<br />
otte arbejdsstationer. Ligeledes kunne en forøgelse <strong>af</strong> hastigheden, som de to<br />
transportbånd kører med, være en løsning på problemet, da det med sådan en<br />
ændring ville være hurtigere at fragte en enhed mellem arbejdsstationerne, og<br />
den samlede tid pr. enhed på den fjerde linje ville derfor kunne mindskes.<br />
Forbedringer på arbejdsstationerne skal kunne gøre det hurtigere for et<br />
element at blive behandlet på den enkelte arbejdsstation. Da vi antager, at<br />
det ikke er muligt at forkorte proces- og setuptiderne, er den eneste mulighed<br />
for at forkorte tiden i en arbejdsstation at få færrest mulige elementer igennem<br />
setuptiden. I modifikation 2 laves der en model, der netop gør dette ved at<br />
gruppere enhederne således, at der fx kommer fem elementer <strong>af</strong> samme type i<br />
træk, og det sikres derved, at de fire <strong>af</strong> dem ikke skal igennem setup.<br />
Naturligvis kunne mange andre muligheder undersøges, fx kunne en løsning<br />
også være at have forskellige maskiner til hver type ved alle arbejdsstationer,<br />
det kunne måske hjælpe at indsætte flere transportbånd igennem systemet,<br />
ændre på hvordan (IC) fungerer og længden <strong>af</strong> den eller lign., men da vi ikke<br />
kan vide, om det er fysisk muligt at lave sådanne udvidelser, og heller ikke<br />
har mulighed for at vurdere, hvad omkostningerne ved disse udvidelser ville<br />
19
20 Kapitel 3. Analyse og konklusion<br />
være, undersøger vi blot de to modifikationer, der er foreslået, og hvorom vi<br />
har fået data.<br />
Hvilken en <strong>af</strong> modifikationerne, der bedst kan betale sig, og om det er en<br />
kombination <strong>af</strong> ændringerne, der er den bedste løsning kommer naturligvis an<br />
på, om det er arbejdsstationerne eller transportbåndet, der er hovedårsagen<br />
til flaskehalsen, eller om det er en kombination. Dette vil vi analysere i det<br />
følgende. Det er dog værd at bemærke, at denne undersøgelse <strong>af</strong> forbedringer<br />
<strong>af</strong> modellen kun koncentrerer sig om minimering <strong>af</strong> „Total lost cost“ som<br />
performancemål, og tager derfor ikke nødvendigvis hensyn til at fx antallet <strong>af</strong><br />
enheder, der forlader systemet, kunne forringes.<br />
I den oprindelige model, svarende til <strong>SM</strong> <strong>Electronics</strong>, som virksomheden<br />
ser ud nu, har vi, bl.a. vha. vores record moduler i output fra Arena, antallet<br />
<strong>af</strong> enheder, der bliver smidt ud <strong>af</strong> det fjerde system om ugen, fordelt på de tre<br />
typer. Vi har omkostningen ved disse og den samlede omkostning ved disse<br />
„lost parts“ pr. uge, og det er denne samlede omkostning, vi bruger som mål<br />
for, om en ændring forbedrer systemet så meget, at det kan betale sig at<br />
investere.<br />
Som <strong>SM</strong> <strong>Electronics</strong> fungerer nu, sendes der samlet omkring 2800 elementer<br />
ud <strong>af</strong> den fjerde linje pr. uge, svarende til en omkostning på lidt mere end<br />
$2000. Det betyder at ca. 4500 færdige enheder kommer ud <strong>af</strong> systemet i<br />
løbet <strong>af</strong> en uge.<br />
3.2 Modifikation 1<br />
For at se på modifikation 1, har vi vha. (PAN) kørt vores grundmodel, hvor<br />
variablen NrOfEntities har værdierne hhv. 40, 45, 50, 55, 60, 65 og 72. Dette<br />
svarer til ændringen <strong>af</strong> modellen, hvor der er tilføjet 0, 5, 10, 15, 20, 25 eller<br />
32 palletter til transportbåndet, hvilket betyder, at det nu er muligt at have<br />
flere enheder på båndet ad gangen. I øvrigt bemærkes at 72 er en øvre grænse<br />
for antallet <strong>af</strong> elementer der kan være på (C), da transportbåndets samlede<br />
længde er<br />
16 · 8 + 2 · 8 = 144<br />
og én enhed optager 2 fods plads. De 16 er antal fod mellem hver arbejdsstation,<br />
mens de 2 er det antal fod en arbejdsstation optager.<br />
Som det ses i figur 3.1 på modstående side er Total lost cost stort set<br />
konstant ligegyldigt, hvilken værdi NrOfEntities antager. Derfor kan det klart<br />
konkluderes, at det ikke kan betale sig at tilføje flere palletter på (C), da der<br />
er forbundet en ganske stor omkostning ved dette, men ingen fortjeneste.<br />
Ved at se på køtiderne i outputtet for grundmodellen ses det, at der især er<br />
to steder, hvor der samles kø, Queue for load point og Seize Work Station 4. At<br />
der samles kø inden en arbejdsstation, kan denne modifikation naturligvis ikke<br />
ændre på. Den anden kø, er en kø til at blive læsset op på transportbåndet.<br />
Denne kø vil heller ikke blive forkortet, men nærmere forlænget ved denne
3.3. Modifikation 2 21<br />
Figur 3.1: PAN<br />
ændring, fordi flere enheder vil blive sendt videre i systemet på (IC), men det<br />
ikke vil gå hurtigere med at læsse dem på transportbåndet, da transportbåndet<br />
ikke kører hurtigere eller pålæsningstiden ikke forkortes. Alt i alt vil ændringen<br />
fra grundmodellen til denne model, hvor der er plads til flere elementer på<br />
(C), kun betyde at der vil sendes få, svarende til det antal ekstra, der kan<br />
være på båndet, videre igennem den fjerde linje, men tiden igennem systemet<br />
vil ikke blive forkortet, og derfor vil der blot være flere ufærdige enheder<br />
på transportbåndet, når arbejdsdagen slutter. Dette vil betyde, at der ville<br />
være en lille forbedring i den tabte omkostning, hvis systemet startede tomt,<br />
svarende til, at der i starten ville sendes flere enheder ind i systemet, men reelt<br />
svarer det bare til at tage nogle enheder fra i systemet, når de ellers skulle<br />
kasseres, og undlade at tælle denne tabte omkostning med. Men da systemet<br />
aldrig kører tomt, hvilket vi, som nævnt i <strong>af</strong>snit 2.7 på side 13, modellerer ved<br />
en opvarmningsperiode, der sikrer, at systemet er på sit normale niveau, når<br />
vi begynder at samle data, sker dette aldrig, og dermed vil end ikke lost cost<br />
kunne forbedres ved at have flere palletter.<br />
Denne modifikation vil altså betyde, at der kører flere halvfærdige enheder<br />
rundt i systemet. Samtidig vil den tid, det tager en enhed at komme igennem<br />
systemet, forlænges, og der vil ikke blive færdiggjort flere enheder. Da systemet<br />
aldrig kører tomt, vil denne ændring derfor ikke hjælpe til at færre enheder<br />
smides ud inden (IC), og det vil naturligvis ikke kunne betale sig at investere<br />
i noget, som ikke giver anledning til en forbedring.<br />
3.3 Modifikation 2<br />
Som tidligere nævnt har vi lavet en modifikation, som skal gøre, at vi mindsker<br />
setuptiden på vores arbejdsstationer. Dette kommer ud på, at vi har lavet tre<br />
buffer conveyors, som de forskellige typer kommer op på inden de når til (IC).<br />
Yderligere sker der det, at hver type <strong>af</strong> ankomster bliver samlet i en gruppe,<br />
inden de kommer op på (IC). Hvad dette har <strong>af</strong> betydning for den økonomiske<br />
side <strong>af</strong> modellen, skal vi komme tilbage til senere. Antallet, der skal være i
22 Kapitel 3. Analyse og konklusion<br />
hver gruppering, styrer vi ved hjælp <strong>af</strong> en variabel, „Batch size“, der som<br />
udgangspunkt antager værdien 5. Vi kan så vha. (PAN) undersøge forskellige<br />
størrelser <strong>af</strong> denne Batch size, hvilket også fremgår <strong>af</strong> figur 3.2. Når vi har<br />
Figur 3.2: PAN<br />
en Batch size på 1, svarer det selvfølgelig til tilfældet, hvor vi ikke har nogen<br />
buffer conveyors, dog med den forskel, at der er lidt transporttid på disse<br />
bånd. Som det fremgår arbejder vi også med størrelserne 2, 5, 7 og 10. Der<br />
er en naturlig grænse på 10 for hvor mange ankomster, man kan gruppere, da<br />
der, jvf. appendix „Contest Problem 9: <strong>SM</strong> <strong>Electronics</strong>“ på side 35, er plads<br />
til netop 10 ankomster på vores buffer conveyors.<br />
Lad os nu tage et kig på besparelserne ved disse grupperinger. Det første,<br />
vi kan bemærke, er, at man, ved at vælge Batch size til 5, faktisk mere<br />
end halverer „Total Lost Cost“, hvilket må siges at være noget <strong>af</strong> en forbedring.<br />
Vi ser også at ved yderligere at ændre batch size til 10, opnår vi en<br />
Total Lost Cost på 681.758. Disse tal skal selvfølgelig sættes i forhold til den<br />
investering, man skal lave for at opnå disse besparelser, men mere om det<br />
senere. Først vil vi nemlig lige prøve at give en forklaring på, hvorfor vi opnår<br />
disse store besparelser, i modsætning til den første modifikation beskrevet i<br />
<strong>af</strong>snit 3.2 på side 20. Kodeordet i den sammenhæng er setuptid. Den helt store<br />
fordel ved denne løsningsmodel er nemlig, at der kommer mange færre enheder<br />
gennem setuptid. Hvor mange enheder <strong>af</strong> samme type, der kommer efter<br />
hinanden, <strong>af</strong>hænger naturligvis <strong>af</strong>, hvor mange enheder, der kommer ind i systemet,<br />
men dette kan være op til så mange enheder som Batch size er sat til,<br />
hvilket vil betyde, at enhederne kun skal gennem setuptid 1/(Batch size) <strong>af</strong><br />
gangene. Dette, har vores kørsler vist, gør, at båndene sjældnere bliver fyldt,<br />
og dermed mindskes vores lost cost. Ydermere er det med til at underbygge<br />
vores endelige konklusion, om at virksomhedens flaskehals i virkeligheden ikke<br />
er transportbåndene, men derimod arbejdsstationerne, eller mere specifikt<br />
setuptiden på de automatiserede arbejdsstationer.<br />
Indtil nu har vi beskrevet denne løsning, som værende helt fantastisk,<br />
men i virkeligheden nytter det jo ikke noget, hvis investeringen, der sikrer<br />
den lavere lost cost, er alt for omkostningsfyldt. Derfor vil vi nu tage denne<br />
problemstilling op til overvejelse. Som bekendt er omkostningen ved at anlægge<br />
disse nye buffer conveyors $56.000, og vi har en ugentlig besparelse på
3.4. Kombinationer <strong>af</strong> modifikation 1 og 2 23<br />
2097.12 1 − 1009.757 = $1087.363 i tilfældet, hvor Batch size er 5. Spørgsmålet<br />
er nu hvor lang tid, der går, før investeringen er tjent hjem. 2 Her bruger vi<br />
selvfølgelig annuitetsformlen<br />
og isolerer n. Udregningerne ser således ud<br />
P V = A 1<br />
(1 − ) (3.1)<br />
r (1 + r) n<br />
1087.363<br />
1<br />
(1 −<br />
) = 56000<br />
0.0005686 (1.0005686) n<br />
1<br />
1 −<br />
= 0.02928<br />
(1.0005686) n<br />
1<br />
= 0.9707166788<br />
(1.0005686) n<br />
1.0005686 n = 1.0301667<br />
log 1.0301667<br />
n =<br />
log 1.0005686<br />
n = 52.2847<br />
Det vil altså sige, at det tager lidt mere end 52 uger, før investeringen er tjent<br />
hjem. Så umiddelbart ser det ud til at være en rigtig fornuftig investering,<br />
men hvorfor restringere sig til en batch size på 5? Som udgangspunkt er omkostningen<br />
ved investeringen fast, uanset de indstillinger der skal til for at<br />
bestemme Batch size. Dette betyder i realiteten, at man bør udnytte kapaciteten<br />
til fulde, dvs. sætte Batch size til 10 for at udnytte systemet bedst<br />
muligt. Ser vi nu på dette tilfælde, vil man opnå en ugentlig besparelse på<br />
2097.12 − 681.758 = $1415.362. Selvfølgelig kunne man godt argumentere for,<br />
at der ville komme andre ting i spil ved en øget Batch size. Fx kunne man<br />
forestille sig, at antallet <strong>af</strong> fejl på transportbåndet stiger med Batch size, men<br />
dette kan vi dog ikke tage hensyn til uden at lave en masse antagelser.<br />
3.4 Kombinationer <strong>af</strong> modifikation 1 og 2<br />
Ud fra den tidligere diskussion ses det, at virksomheden skal investere i modifikation<br />
2. Vi vil nu se, om det kan betale sig at lave en kombination <strong>af</strong> de<br />
to modifikationer, og vi ser derfor på, om modifikation 1 kan betale sig, givet<br />
vi har investeret i modifikation 2.<br />
Ligesom ved modifikation 1, forventede vi, at der ikke ville blive tale om<br />
nogen besparelse ved at tilføje flere palletter, fordi vi, som forklaret i <strong>af</strong>snit 3.2<br />
på side 20, ikke får et system, der er hurtigere, og ændringen derfor kun<br />
betyder, at der befinder sig flere ufærdige enheder inde i systemet.<br />
1 jvf. appendix „Output fra grundmodel“ på side 35<br />
2 For en diskussion <strong>af</strong> dette, se <strong>af</strong>snit 3.4
24 Kapitel 3. Analyse og konklusion<br />
Figur 3.3: PAN<br />
Da det i modifikation 2 var så klart, at det optimale altid ville være at lade<br />
Batch size være 10, jvf. <strong>af</strong>snit 3.3 på side 21, havde vi egentlig blot tænkt os<br />
at se på dette tilfælde. Men da det ud fra (PAN) ikke var fuldstændig oplagt<br />
at se, om ændringer i NrOfEntities ikke havde nogen effekt, har vi alligevel<br />
valgt at lave kørsler for flere forskellige værdier <strong>af</strong> Batch size. Dette har vi<br />
gjort for at få et mere generelt overblik over, hvordan Total lost cost ændres<br />
for forskelligt antal palletter på (C). Selvom der i figur 3.3 ses noget større<br />
spredning <strong>af</strong> Total lost cost er der ikke noget, der tyder på en generel tendens<br />
til at Total lost cost falder, når værdien <strong>af</strong> NrOfEntities stiger.<br />
Skulle begge investeringer gennemføres ville det, som forklaret i <strong>af</strong>snit 3.3<br />
på side 21, og som det også tydeligt fremgår <strong>af</strong> figur 3.3, klart være optimalt<br />
at lade Batch size være 10. Givet denne værdi er den største besparelse, der<br />
kan opnås $13.6 pr. uge, svarende til at investere i alle 32 mulige palletter.<br />
For at ligning 3.1 på forrige side har en løsning, skal der gælde<br />
P V · r<br />
A<br />
≤ 1
3.5. Konklusion 25<br />
Dette betyder med en årlig rente på 3%, at nutidsværdien <strong>af</strong> investeringen<br />
ikke kan blive større end<br />
13.6<br />
= $23918.4<br />
0.0005686<br />
Dette er lavere end omkostningen ved at få tre palletter mere på (C), og det<br />
er derfor tydeligt, at det ikke kan betale sig at investere i en kombination <strong>af</strong><br />
modifikation 1 og 2.<br />
Vi har valgt at vurdere investeringerne, ved at se på hvor mange år der<br />
skal gå, før nutidsværdien <strong>af</strong> vores besparelse er lige så stor som prisen på<br />
investeringen. Denne løsning tager naturligvis ikke hensyn til <strong>af</strong>skrivninger<br />
og lign., men for at undgå at skulle lave antagelser, som vi egentlig ikke har<br />
noget hold i, har vi alligevel valgt denne løsning. Denne metode kan godt<br />
bruges til at <strong>af</strong>gøre, om en enkelt investering kan betale sig, men er ikke god<br />
til sammenligning <strong>af</strong> alternativer, og da vi direkte kan <strong>af</strong>vise modifikation 1 og<br />
en kombination <strong>af</strong> 1 og 2, vha. denne metode, kommer vi ikke ud i problemer,<br />
hvor vi skal sammenligne hvilken investering, der er bedst.<br />
3.5 Konklusion<br />
Vi har i det foregående lavet en simulation <strong>af</strong> <strong>SM</strong> <strong>Electronics</strong>, hvor vi har<br />
betragtet fire scenarier; virksomhedens nuværende setup, to modifikationer<br />
samt en kombination <strong>af</strong> de to. Vha. Arena har vi lavet ændringer i, hvordan<br />
virksomheden fungerer nu, først ved at ændre på antallet <strong>af</strong> enheder, der kan<br />
være inde i systemet, og dernæst ved at lave ændringer, så enhederne grupperes<br />
efter deres type og dermed hurtigere kan blive behandlet på de forskellige<br />
arbejdsstationer. På baggrund <strong>af</strong> kørsler <strong>af</strong> de forskellige modifikationer har<br />
vi således kunnet se på den tabte omkostning, der opstår, fordi en enhed smides<br />
ud <strong>af</strong> linjen, hvis der er for mange elementer i det videre system. Det er<br />
denne omkostning, vi har forsøgt at minimere ved at se på disse ændringer.<br />
Ved at observere vores grundmodel kunne vi se, at det er i arbejdsstationerne,<br />
der opstår flaskehalse, og ikke pga. transportbåndene. Især kunne vi se,<br />
at arbejdsstation 8 og 4 giver anledning til kø, og allerede her kunne man<br />
derfor forudsige, at modifikation 1 ikke vil have nogen mærkbar effekt. På<br />
trods <strong>af</strong> dette gennemgik vi selvfølgelig modifikationen med et resultat som<br />
forventet; ingen ugentlig besparelse. Dette kunne vi klart <strong>af</strong>vise som en dårlig<br />
investering og dermed yderligere forstærke vores opfattelse <strong>af</strong>, at det ikke var<br />
transportbåndet, der var årsag til flaskehalsen.<br />
I modifikation 2 ændrede vi systemet sådan, at enhederne blev grupperet<br />
efter deres type, og dermed undgik vi at så mange enheder skulle sendes gennem<br />
setup ved de automatiserede arbejdsstationer. Dette havde som forventet<br />
stor effekt, netop fordi tiden i arbejdsstationerne blev nedsat kr<strong>af</strong>tigt. Her viste<br />
vores beregninger, at investeringen var yderst fordelagtig. Vi diskuterede<br />
også, i hvor store mængder vi skulle gruppere elementerne, inden de sendtes
26 Kapitel 3. Analyse og konklusion<br />
videre i systemet. Konklusionen var her, at man blot skulle benytte den fulde<br />
kapacitet på ti. Dette var dog set i det perspektiv, at der ikke var nogen ekstra<br />
omkostning forbundet med større Batch size, hvilket vi også satte spørgsmålstegn<br />
ved troværdigheden <strong>af</strong>. Dog endte vi med at tage opgavebeskrivelsens<br />
oplysninger for gode varer.<br />
Et sidste forsøg på at minimere de tabte omkostninger, blev gjort ved<br />
først at antage modifikation 2 gennemført, og derefter se på modifikation 1<br />
gennemført i denne nye modificerede model. Vi valgte den antagelse, da der<br />
ikke kunne være nogen som helst tvivl om, at modifikation 2 skulle være en<br />
del <strong>af</strong> den endelige ændring <strong>af</strong> systemet. Vi brugte denne gang (PAN) til vores<br />
undersøgelser. Vi havde ikke de store forventninger, og det viste sig da også,<br />
selvom det ikke var lige så tydeligt som i vurderingen <strong>af</strong> modifikation 1 alene,<br />
at der ikke var tale om en besparelse, der kunne opveje omkostningen ved<br />
investeringen. Alt i alt nåede vi frem til, at det mest rentable udfald blev<br />
opnået ved udelukkende at benytte modifikation 2 med en Batch size på ti.
Appendices<br />
27
Contest Problem 9: <strong>SM</strong><br />
<strong>Electronics</strong><br />
29
CONTEST PROBLEM 9<br />
IIE/RA Contest Problems<br />
IIE/RA CONTEST PROBLEMS<br />
B.9 Ninth Annual Contest: <strong>SM</strong> <strong>Electronics</strong><br />
<strong>SM</strong> <strong>Electronics</strong> is a small manufacturer that produces electronic parts used by a variety of<br />
o<strong>the</strong>r manufacturers. Recently, we noticed problems in a department that produces three<br />
different parts. The demand mix for <strong>the</strong>se three products has changed slowly over time.<br />
The department is almost fully automated and consists of four lines. Each of <strong>the</strong> first three<br />
lines produces a single product and <strong>the</strong>y have all been modified over time to meet <strong>the</strong><br />
current demand mix. When <strong>the</strong> almost-finished parts (Parts A, B, and C) exit <strong>the</strong>se three<br />
lines, <strong>the</strong>y all enter <strong>the</strong> fourth line where <strong>the</strong> final operations are performed for all product<br />
types. The new product mix has caused <strong>the</strong> fourth line to become a bottleneck.<br />
<strong>SM</strong> <strong>Electronics</strong> employed several consultants to collect data and recommend modifications<br />
to this line. Although we’ve received sufficient information to proceed with <strong>the</strong><br />
modifications, <strong>the</strong> actual performance <strong>af</strong>ter <strong>the</strong> modifications are implemented is in<br />
question. Two different approaches were suggested. At this time, it’s not clear which<br />
approach would provide <strong>the</strong> best results. It’s also possible that both suggested modifications<br />
may be required in order to achieve <strong>the</strong> desired performance. In light of this uncertainty,<br />
we are initiating this request for recommendations.<br />
You are asked to evaluate <strong>the</strong> current design and propose <strong>the</strong> configuration(s) that<br />
will result in approximately minimizing operating cost while still achieving <strong>the</strong> desired<br />
performance levels. With this in mind, this document describes <strong>the</strong> current system and<br />
presents <strong>the</strong> two different modifications that have been proposed, as well as including<br />
data where <strong>the</strong>y are available.<br />
Your analysis should concentrate on <strong>the</strong> fourth line, and a schematic of it is shown.<br />
We do not anticipate a need to change <strong>the</strong> first three lines, so we will give you only<br />
limited information on <strong>the</strong>m.<br />
Parts A, B, and C enter <strong>the</strong> fourth line on <strong>the</strong> left. Since <strong>the</strong> lines that produce <strong>the</strong>se<br />
parts are fully automated, <strong>the</strong>ir arrival rates are very predictable. The normal arrivals for<br />
<strong>the</strong> three parts are: Part A, every 2.8 minutes; Part B, every 1.4 minutes; and Part C,<br />
every 2.0 minutes. There are occasional jams on <strong>the</strong>se lines, which can cause slight<br />
delays in part arrivals. The collected data show that delays occur 2%, 1.75%, and 0.5% of<br />
<strong>the</strong> time on Lines A, B, and C, respectively. The data for <strong>the</strong>se delays have been analyzed<br />
and triangular distributions have been fitted to <strong>the</strong> data. The parameters for <strong>the</strong>se<br />
distributions are (5,15,60), (5,20,55), and (5,20,65) for Lines A, B, and C, respectively.<br />
Note that <strong>the</strong> time units for <strong>the</strong>se parameters are in seconds.<br />
IIE_RA_9.pmd 1<br />
5/30/2006, 12:19 PM<br />
1
2 IIE/RA CONTEST PROBLEMS<br />
Part A Line<br />
Part B Line<br />
Part C Line<br />
7 6 5 4<br />
8 1 2 3<br />
Finished Parts<br />
The arriving parts are merged (in <strong>the</strong> order in which <strong>the</strong>y arrive) onto a single input<br />
conveyor, which feeds <strong>the</strong> fourth and final system. The input conveyor from <strong>the</strong> merge<br />
point to where <strong>the</strong> parts enter <strong>the</strong> fourth system has room for 40 parts. If this input<br />
conveyor becomes full and a new part attempts to merge onto <strong>the</strong> conveyor, <strong>the</strong>n <strong>the</strong> line<br />
producing that part temporarily shuts down until space becomes available. Currently,<br />
<strong>the</strong>re are numerous shutdowns during each day. For analysis purposes, you can assume<br />
that if a part arrives and <strong>the</strong> input conveyor is full, that part is considered to be lost<br />
production. The cost for a lost part is $0.89, $0.63, and $0.72 for Parts A, B, and C,<br />
respectively.<br />
The fourth system consists of eight work cells connected by a power-and-free<br />
conveyor. The distance between each work cell is 18 feet. When a new part enters <strong>the</strong><br />
system from <strong>the</strong> input conveyor at Work Cell 8, it must wait for a special pallet that will<br />
hold <strong>the</strong> part as it travels through <strong>the</strong> system. Presently, <strong>the</strong>re are 40 pallets in <strong>the</strong> system,<br />
each requiring 2 feet of space. Thus, <strong>the</strong>re is room for eight pallets between each pair of<br />
successive work cells (16 feet of buffer space and 2 feet for <strong>the</strong> work cell). The travel<br />
time between work cells (18 feet) is 15 seconds.<br />
When both a pallet and a new part are available at Work Cell 8, <strong>the</strong> finished part is first<br />
removed from <strong>the</strong> pallet, and <strong>the</strong>n <strong>the</strong> new part is loaded. This unload/load process is fully<br />
automated and takes 25 seconds. A jam occurs approximately 1% of <strong>the</strong> time, requiring<br />
additional time. The time to respond to a jam follows a triangular distribution with<br />
parameters (5,15,75). These parameters are expressed in seconds. Once <strong>the</strong> unload/load<br />
process is complete, <strong>the</strong> pallet moves to <strong>the</strong> buffer area in front of Work Cell 1. If <strong>the</strong>re is<br />
no room in <strong>the</strong> buffer area, <strong>the</strong> pallet remains at <strong>the</strong> unload/load work cell until room<br />
becomes available. In effect, <strong>the</strong> waiting loaded pallet blocks <strong>the</strong> unload/load work cell.<br />
The new part moves through <strong>the</strong> system where an operation is performed at each of<br />
<strong>the</strong> remaining seven work cells. Work Cells 1, 3, 4, 5, and 6 are automated operations.<br />
Work Cells 2 and 7 are manual operations.<br />
When a pallet enters an automated work cell, a scanner reads <strong>the</strong> part type on that<br />
pallet. If <strong>the</strong> part type is different from <strong>the</strong> last part type at that work cell, <strong>the</strong> work cell<br />
must undergo a setup. The required setup time is dependent only on <strong>the</strong> new part type.<br />
These setup times (in seconds) are given in <strong>the</strong> table below.<br />
IIE_RA_9.pmd 2<br />
5/30/2006, 12:19 PM
IIE/RA CONTEST PROBLEMS<br />
Arriving<br />
Part Type Work Cell 1 Work Cell 3 Work Cell 4 Work Cell 5 Work Cell 6<br />
Part A 25 52 35 29 11<br />
Part B 20 21 22 14 19<br />
Part C 17 34 24 37 17<br />
For example, if a Part B arrives at Work Cell 1 and <strong>the</strong> previous part at that work cell<br />
was ei<strong>the</strong>r an A or C, <strong>the</strong>n a 20-second setup is required. If <strong>the</strong> previous part was a B,<br />
<strong>the</strong>n no setup is required.<br />
The operation or process time at <strong>the</strong> automated work cells is also part dependent.<br />
These operation times (in seconds) are given in <strong>the</strong> following table. For example, a Part B<br />
at Work Cell 4 requires a 38-second operation time.<br />
Part Type Work Cell 1 Work Cell 3 Work Cell 4 Work Cell 5 Work Cell 6<br />
Part A 37 39 41 33 31<br />
Part B 46 27 38 41 24<br />
Part C 39 23 47 35 51<br />
The operation or process times at <strong>the</strong> two manual work cells follow triangular<br />
distributions with <strong>the</strong> parameters given, in seconds. No setup is required at <strong>the</strong> manual<br />
work cells.<br />
Part Type Work Cell 2 Work Cell 7<br />
Part A 36,45,52 27,35,41<br />
Part B 21,32,39 31,39,43<br />
Part C 32,36,42 22,27,38<br />
Based on our observations, we feel that you can s<strong>af</strong>ely assume that no jams or failures<br />
occur at Work Cells 1 through 7.<br />
The factory is currently working two shifts, a 16-hour production day, five days a<br />
week. The lines are shut down at <strong>the</strong> end of each day, leaving <strong>the</strong> incomplete parts in <strong>the</strong><br />
system, and <strong>the</strong>y are restarted at <strong>the</strong> beginning of <strong>the</strong> next working day.<br />
Although casual observations by <strong>the</strong> consultants and our production engineers<br />
indicate that our lost production cost is high, we are not able to place a dollar value on<br />
that loss. Thus, <strong>the</strong> first question we would like you to address is: What is <strong>the</strong> cost of lost<br />
production for our current system? Please provide this as a weekly cost.<br />
We would <strong>the</strong>n like you to evaluate <strong>the</strong> two proposed modifications to see if <strong>the</strong>y<br />
make economic sense. The first proposed modification requires that we add pallets to <strong>the</strong><br />
existing fourth system. Since <strong>the</strong> current control logic for that system was developed<br />
specifically for 40 pallets, that logic must be modified. The fixed cost for this<br />
modification is $17,000. This cost is incurred even if only one pallet is added. In<br />
addition, <strong>the</strong>re is an incremental cost of $3,000 for each pallet added.<br />
IIE_RA_9.pmd 3<br />
5/30/2006, 12:19 PM<br />
3
4 IIE/RA CONTEST PROBLEMS<br />
The second proposed modification requires that we insert additional space for<br />
incoming parts by adding three new buffer conveyors. The amount of additional storage<br />
is limited, based on available space. The current available space would allow three buffer<br />
conveyors to be added at <strong>the</strong> incoming merge point, one conveyor for each part type.<br />
Each of <strong>the</strong>se conveyors would have space for an additional ten parts. The concept is that<br />
each of <strong>the</strong> first three lines would insert <strong>the</strong>ir parts into <strong>the</strong>ir own buffer conveyor<br />
(limited to ten parts on each conveyor). Logic would <strong>the</strong>n be developed that would allow<br />
<strong>the</strong>se parts to be released in batches to <strong>the</strong> existing buffer conveyor (limited to 40 parts).<br />
For example, you might release in batches of five. When <strong>the</strong>se batches of five (all <strong>the</strong><br />
same part) are processed by <strong>the</strong> final system, <strong>the</strong>re would be only one setup at each of <strong>the</strong><br />
automated operations at <strong>the</strong> start of <strong>the</strong> batch. We have already priced this option with a<br />
conveyor manufacturer. The cost to implement this modification is $56,000. This cost<br />
includes <strong>the</strong> equipment cost, installation cost, and <strong>the</strong> development of whatever release<br />
logic is required.<br />
<strong>SM</strong> <strong>Electronics</strong> requests that during your analysis you evaluate and answer <strong>the</strong><br />
following questions:<br />
1. What is <strong>the</strong> cost of lost production for our current system?<br />
2. What is <strong>the</strong> cost savings, if any, resulting from <strong>the</strong> implementation of <strong>the</strong> first<br />
proposed modification?<br />
� How many additional pallets should be added?<br />
3. What is <strong>the</strong> cost savings, if any, resulting from <strong>the</strong> implementation of <strong>the</strong> second<br />
proposed modification?<br />
� Include a detailed description of your proposed release logic.<br />
4. Should we implement both of <strong>the</strong> proposed modifications?<br />
Please provide all cost comparisons in dollars per week. Your report should include a<br />
recommendation for <strong>the</strong> most cost-effective system. Your analysis may reveal that nei<strong>the</strong>r<br />
of <strong>the</strong> two options should be considered.<br />
We are currently occupied by o<strong>the</strong>r activities and will not require a solution until<br />
early April. Since <strong>the</strong>re are several groups competing for this contract, we have decided<br />
that we will not provide additional information during <strong>the</strong> analysis period. However, you<br />
are encouraged to make additional reasonable, documented assumptions. We look<br />
forward to receiving your report in April and reviewing your proposed solution.<br />
IIE_RA_9.pmd 4<br />
5/30/2006, 12:19 PM
Output fra grundmodel<br />
35
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
System<br />
Average<br />
Number Out 7,517<br />
Values Across All Replications<br />
Key Performance Indicators<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 1 of 11
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Conveyor<br />
Usage<br />
Values Across All Replications<br />
Blocked Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Conveyor 0.4041<br />
0,00 0.3965 0.4086 0.00 1.0000<br />
Input Conveyor 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Utilization Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Conveyor 0.04378898<br />
0,00 0.04282192 0.04432481 0.00 0.1806<br />
Input Conveyor 0.01330404<br />
0,00 0.01305691 0.01342110 0.00 0.03750000<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 2 of 11
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Entity<br />
Time<br />
Values Across All Replications<br />
VA Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 0.9670<br />
0,01 0.8575 1.0911 0.00 3.0040<br />
Part B 1.0071<br />
0,01 0.9105 1.0529 0.00 2.8038<br />
Part C 0.9135<br />
0,01 0.8661 0.9548 0.00 2.8785<br />
NVA Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Part B 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Part C 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Wait Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 40.2441<br />
0,65 35.3891 46.2952 0.00 81.2402<br />
Part B 47.2050<br />
0,33 43.6137 48.7974 0.00 83.6583<br />
Part C 43.7199<br />
0,26 41.1690 45.6697 0.00 82.2126<br />
Transfer Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 2.2339<br />
0,03 1.9873 2.5100 0.00 6.2050<br />
Part B 2.5645<br />
0,02 2.3122 2.6805 0.00 6.6809<br />
Part C 2.3882<br />
0,01 2.2773 2.5117 0.00 6.6990<br />
O<strong>the</strong>r Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 3.0922<br />
0,05 2.7457 3.4873 0.00 5.5500<br />
Part B 2.5902<br />
0,02 2.3829 2.6869 0.00 4.5333<br />
Part C 3.1320<br />
0,02 2.9674 3.2609 0.00 5.4000<br />
Total Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 46.5372<br />
0,74 40.9796 53.3835 0.00 92.7234<br />
Part B 53.3669<br />
0,38 49.2193 55.2177 0.00 92.2647<br />
Part C<br />
O<strong>the</strong>r<br />
50.1536<br />
0,29 47.2798 52.3615 0.00 92.1767<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 3 of 11
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Entity<br />
O<strong>the</strong>r<br />
Values Across All Replications<br />
Number In Minimum Maximum<br />
Average Half Width Average Average<br />
Part A 1708.80 0,30 1707.00 1711.00<br />
Part B 3410.04 0,68 3405.00 3415.00<br />
Part C 2397.60 0,26 2396.00 2400.00<br />
3600,000<br />
3400,000<br />
3200,000<br />
3000,000<br />
2800,000<br />
2600,000<br />
2400,000<br />
2200,000<br />
2000,000<br />
1800,000<br />
1600,000<br />
Number Out Minimum Maximum<br />
Average Half Width Average Average<br />
Part A 1709.90 1,85 1697.00 1722.00<br />
Part B 3408.52 2,13 3393.00 3425.00<br />
Part C 2398.08 1,23 2389.00 2409.00<br />
WIP Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Part A<br />
Part B<br />
Part C<br />
Maximum<br />
Value<br />
Part A 16.5554<br />
0,27 14.6211 19.0088 2.0000 30.0000<br />
Part B 37.9062<br />
0,27 34.9322 39.2276 21.0000 55.0000<br />
Part C 25.0426<br />
0,14 23.6132 26.1357 10.0000 38.0000<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 4 of 11
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Process<br />
Time per Entity<br />
Values Across All Replications<br />
VA Time Per Entity Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Process 2 0.5899<br />
0,00 0.5859 0.5977 0.3506 0.8662<br />
Process 7 0.5708<br />
0,00 0.5676 0.5729 0.3673 0.7165<br />
Wait Time Per Entity Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Process 2 0.01075151<br />
0,00 0.00950411 0.01244499 0.00 1.0080<br />
Process 7 0.07579734<br />
0,00 0.06733613 0.08117324 0.00 1.2599<br />
Total Time Per Entity Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Process 2 0.6007<br />
0,00 0.5966 0.6083 0.3506 1.5228<br />
Process 7<br />
Accumulated Time<br />
0.6466<br />
0,00 0.6350 0.6529 0.3673 1.8689<br />
Accum VA Time Minimum Maximum<br />
Average Half Width Average Average<br />
Process 2 2719.11 2,00 2701.91 2731.94<br />
Process 7 2624.63 5,43 2561.67 2650.68<br />
2720,000<br />
2700,000<br />
2680,000<br />
2660,000<br />
2640,000<br />
2620,000<br />
Process 2<br />
Process 7<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 5 of 11
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Process<br />
Accumulated Time<br />
Values Across All Replications<br />
Accum Wait Time Minimum Maximum<br />
Average Half Width Average Average<br />
Process 2 49.5580 0,94 43.9470 57.4585<br />
Process 7 348.57 4,65 303.89 375.86<br />
O<strong>the</strong>r<br />
360,000<br />
320,000<br />
280,000<br />
240,000<br />
200,000<br />
160,000<br />
120,000<br />
80,000<br />
40,000<br />
Number In Minimum Maximum<br />
Average Half Width Average Average<br />
Process 2 4609.36 7,33 4524.00 4649.00<br />
Process 7 4598.02 7,34 4514.00 4639.00<br />
4610,000<br />
4608,000<br />
4606,000<br />
4604,000<br />
4602,000<br />
4600,000<br />
4598,000<br />
Number Out Minimum Maximum<br />
Average Half Width Average Average<br />
Process 2 4609.36 7,31 4525.00 4649.00<br />
Process 7 4597.86 7,35 4513.00 4640.00<br />
Process 2<br />
Process 7<br />
Process 2<br />
Process 7<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 6 of 11
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Queue<br />
Time<br />
Values Across All Replications<br />
Waiting Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Leave Work Station 1.Queue 0.00358265<br />
0,00 0.00332983 0.00386060 0.00 0.7675<br />
Leave Work Station 2.Queue 0.00421123<br />
0,00 0.00403889 0.00440867 0.00 0.9374<br />
Leave Work Station 3.Queue 0.00362525<br />
0,00 0.00319744 0.00438670 0.00 0.9950<br />
Leave Work Station 4.Queue 0.00341479<br />
0,00 0.00317966 0.00374328 0.00 0.9048<br />
Leave Work Station 5.Queue 0.00341958<br />
0,00 0.00313982 0.00382948 0.00 0.9113<br />
Leave Work Station 6.Queue 0.00406262<br />
0,00 0.00369289 0.00459082 0.00 1.1977<br />
Leave Work Station 7.Queue 0.00458415<br />
0,00 0.00446420 0.00476928 0.00 0.6469<br />
load point.Queue 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
merge point.Queue 0.00319506<br />
0,00 0.00287445 0.00348787 0.00 0.04131701<br />
Process 2.Queue 0.01075072<br />
0,00 0.00950411 0.01244928 0.00 1.0080<br />
Process 7.Queue 0.07579870<br />
0,00 0.06732121 0.08117324 0.00 1.2599<br />
Queue for load point.Queue 40.1324<br />
0,07 39.7643 40.9238 32.5036 46.6082<br />
Seize work Station 1.Queue 0.7759<br />
0,02 0.6267 0.9987 0.00 14.7529<br />
Seize Work Station 3.Queue 0.5966<br />
0,01 0.5234 0.7219 0.00 6.2905<br />
Seize Work Station 4.Queue 30.7022<br />
0,07 30.3200 31.4282 15.0443 36.9273<br />
Seize Work Station 5.Queue 0.2279<br />
0,00 0.1995 0.2500 0.00 1.9934<br />
Seize Work Station 6.Queue<br />
O<strong>the</strong>r<br />
0.1270<br />
0,00 0.1145 0.1383 0.00 1.6000<br />
Number Waiting Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Leave Work Station 1.Queue 0.00344038<br />
0,00 0.00314107 0.00372415 0.00 1.0000<br />
Leave Work Station 2.Queue 0.00404399<br />
0,00 0.00387137 0.00425412 0.00 1.0000<br />
Leave Work Station 3.Queue 0.00348178<br />
0,00 0.00306421 0.00423957 0.00 2.0000<br />
Leave Work Station 4.Queue 0.00327096<br />
0,00 0.00304188 0.00355846 0.00 2.0000<br />
Leave Work Station 5.Queue 0.00327571<br />
0,00 0.00299591 0.00369146 0.00 2.0000<br />
Leave Work Station 6.Queue 0.00389162<br />
0,00 0.00347209 0.00438040 0.00 2.0000<br />
Leave Work Station 7.Queue 0.00439120<br />
0,00 0.00425351 0.00459937 0.00 1.0000<br />
load point.Queue 0.00<br />
0,00 0.00 0.00 0.00 1.0000<br />
merge point.Queue 0.00306048<br />
0,00 0.00276666 0.00334690 0.00 2.0000<br />
Process 2.Queue 0.01032382<br />
0,00 0.00915562 0.01197465 0.00 2.0000<br />
Process 7.Queue 0.07262165<br />
0,00 0.06330999 0.07828780 0.00 2.0000<br />
Queue for load point.Queue 38.4369<br />
0,00 38.4148 38.4712 35.0000 40.0000<br />
Seize work Station 1.Queue 0.7299<br />
0,02 0.5850 0.9462 0.00 15.0000<br />
Seize Work Station 3.Queue 0.5726<br />
0,01 0.5056 0.6951 0.00 8.0000<br />
Seize Work Station 4.Queue 29.4726<br />
0,03 29.2617 29.7265 14.0000 34.0000<br />
Seize Work Station 5.Queue 0.2184<br />
0,00 0.1887 0.2415 0.00 3.0000<br />
Seize Work Station 6.Queue 0.1217<br />
0,00 0.1084 0.1337 0.00 3.0000<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 7 of 11
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Resource<br />
Usage<br />
Values Across All Replications<br />
Instantaneous Utilization Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Work Station 1 0.9348<br />
0,00 0.9235 0.9401 0.00 1.0000<br />
Work Station 2 0.5665<br />
0,00 0.5629 0.5692 0.00 1.0000<br />
Work Station 3 0.8876<br />
0,00 0.8757 0.9018 0.00 1.0000<br />
Work Station 4 1.0000<br />
0,00 1.0000 1.0000 0.00 1.0000<br />
Work Station 5 0.9343<br />
0,00 0.9274 0.9386 0.00 1.0000<br />
Work Station 6 0.7534<br />
0,00 0.7469 0.7613 0.00 1.0000<br />
Work Station 7 0.5468<br />
0,00 0.5337 0.5522 0.00 1.0000<br />
Number Busy Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Work Station 1 0.9348<br />
0,00 0.9235 0.9401 0.00 1.0000<br />
Work Station 2 0.5665<br />
0,00 0.5629 0.5692 0.00 1.0000<br />
Work Station 3 0.8876<br />
0,00 0.8757 0.9018 0.00 1.0000<br />
Work Station 4 1.0000<br />
0,00 1.0000 1.0000 0.00 1.0000<br />
Work Station 5 0.9343<br />
0,00 0.9274 0.9386 0.00 1.0000<br />
Work Station 6 0.7534<br />
0,00 0.7469 0.7613 0.00 1.0000<br />
Work Station 7 0.5468<br />
0,00 0.5337 0.5522 0.00 1.0000<br />
Number Scheduled Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Work Station 1 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 2 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 3 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 4 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 5 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 6 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 7 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 8 of 11
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Resource<br />
Usage<br />
Values Across All Replications<br />
Scheduled Utilization Minimum Maximum<br />
Average Half Width Average Average<br />
Work Station 1 0.9348 0,00 0.9235 0.9401<br />
Work Station 2 0.5665 0,00 0.5629 0.5692<br />
Work Station 3 0.8876 0,00 0.8757 0.9018<br />
Work Station 4 1.0000 0,00 1.0000 1.0000<br />
Work Station 5 0.9343 0,00 0.9274 0.9386<br />
Work Station 6 0.7534 0,00 0.7469 0.7613<br />
Work Station 7 0.5468 0,00 0.5337 0.5522<br />
1,000<br />
0,950<br />
0,900<br />
0,850<br />
0,800<br />
0,750<br />
0,700<br />
0,650<br />
0,600<br />
0,550<br />
0,500<br />
Total Number Seized Minimum Maximum<br />
Average Half Width Average Average<br />
Work Station 1 4609.20 7,34 4524.00 4649.00<br />
Work Station 2 4609.36 7,33 4524.00 4649.00<br />
Work Station 3 4609.98 7,26 4525.00 4649.00<br />
Work Station 4 4598.00 7,33 4512.00 4638.00<br />
Work Station 5 4598.00 7,35 4513.00 4639.00<br />
Work Station 6 4598.00 7,34 4513.00 4639.00<br />
Work Station 7 4598.04 7,35 4514.00 4640.00<br />
4610,000<br />
4608,000<br />
4606,000<br />
4604,000<br />
4602,000<br />
4600,000<br />
4598,000<br />
Work Station 1<br />
Work Station 2<br />
Work Station 3<br />
Work Station 4<br />
Work Station 5<br />
Work Station 6<br />
Work Station 7<br />
Work Station 1<br />
Work Station 2<br />
Work Station 3<br />
Work Station 4<br />
Work Station 5<br />
Work Station 6<br />
Work Station 7<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 9 of 11
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Station<br />
O<strong>the</strong>r<br />
Values Across All Replications<br />
Number Entities Transferring Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Enter load station.Station 1.0643<br />
0,00 1.0446 1.0737 0.00 3.0000<br />
Enter Work Station 1.Station 0.2130<br />
0,00 0.2091 0.2152 0.00 2.0000<br />
Enter Work Station 2.Station 0.3794<br />
0,00 0.3659 0.3865 0.00 3.0000<br />
Enter Work Station 3.Station 0.4002<br />
0,00 0.3934 0.4059 0.00 2.0000<br />
Enter Work Station 4.Station 0.3831<br />
0,00 0.3722 0.3885 0.00 4.0000<br />
Enter Work Station 5.Station 0.3788<br />
0,00 0.3655 0.3882 0.00 3.0000<br />
Enter Work Station 6.Station 0.3798<br />
0,00 0.3710 0.3879 0.00 3.0000<br />
Enter Work Station 7.Station 0.3872<br />
0,00 0.3799 0.3922 0.00 3.0000<br />
Exit conveyor.Station 0.2272<br />
0,00 0.2225 0.2308 0.00 2.0000<br />
Leaving load station 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving unload station 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 1 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 2 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 3 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 4 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 5 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 6 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 7 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
merge station 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 10 of 11
Category Overview<br />
13:45:22 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
User Specified<br />
Counter<br />
Values Across All Replications<br />
Count Minimum Maximum<br />
Average Half Width Average Average<br />
Record Part A lost parts 756.28 14,03 635.00 862.00<br />
Record Part B lost parts 1208.86 18,95 1114.00 1417.00<br />
Record Part C lost parts 953.46<br />
8,57 889.00 1031.00<br />
1250,000<br />
1200,000<br />
1150,000<br />
1100,000<br />
1050,000<br />
1000,000<br />
950,000<br />
900,000<br />
850,000<br />
800,000<br />
750,000<br />
Time Persistent<br />
Variable Minimum Maximum<br />
Average Half Width Average Average<br />
Record Part A lost parts<br />
Record Part B lost parts<br />
Record Part C lost parts<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
cost counter 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Entity Counter<br />
Output<br />
1.0674<br />
0,00 1.0475 1.0768 0.00 3.0000<br />
Output Minimum Maximum<br />
Average Half Width Average Average<br />
Lost Cost A 673.09 12,49 565.15 767.18<br />
Lost Cost B 761.58 11,94 701.82 892.71<br />
Lost Cost C 686.49 6,17 640.08 742.32<br />
Total Lost Cost 2121.16 2,08 2107.21 2141.86<br />
2200,000<br />
2000,000<br />
1800,000<br />
1600,000<br />
1400,000<br />
1200,000<br />
1000,000<br />
800,000<br />
600,000<br />
Lost Cost A<br />
Lost Cost B<br />
Lost Cost C<br />
Total Lost Cost<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig<br />
Page 11 of 11
Output fra modifikation<br />
49
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
System<br />
Average<br />
Number Out 7,516<br />
Values Across All Replications<br />
Key Performance Indicators<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 1 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Conveyor<br />
Usage<br />
Values Across All Replications<br />
Blocked Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Buffer A 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Buffer B 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Buffer C 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Conveyor 0.5353<br />
0,00 0.5328 0.5383 0.00 1.0000<br />
Input Conveyor 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Utilization Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Buffer A 0.00494444<br />
0,00 0.00493924 0.00495082 0.00 0.05000000<br />
Buffer B 0.00986701<br />
0,00 0.00985243 0.00988137 0.00 0.05000000<br />
Buffer C 0.00693736<br />
0,00 0.00693287 0.00694198 0.00 0.05000000<br />
Conveyor 0.06434975<br />
0,00 0.06386248 0.06478937 0.00 0.2222<br />
Input Conveyor 0.01760920<br />
0,00 0.01754629 0.01766558 0.00 0.1500<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 2 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Entity<br />
Time<br />
Values Across All Replications<br />
VA Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 1.3501<br />
0,02 1.2034 1.5541 0.00 2.9758<br />
Part B 1.2987<br />
0,01 1.2003 1.3698 0.00 2.8585<br />
Part C 1.2151<br />
0,00 1.1829 1.2500 0.00 2.7625<br />
NVA Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Part B 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Part C 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Wait Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 44.9924<br />
0,67 40.7359 50.8752 0.00 64.7568<br />
Part B 45.1621<br />
0,33 42.2437 47.3467 0.00 60.4259<br />
Part C 44.6981<br />
0,16 43.7588 45.8212 0.00 62.0937<br />
Transfer Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 3.8212<br />
0,06 3.4535 4.3417 0.2775 7.6343<br />
Part B 3.8194<br />
0,03 3.5441 4.0117 0.2775 7.9871<br />
Part C 3.7348<br />
0,01 3.6367 3.8360 0.2775 7.7887<br />
O<strong>the</strong>r Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 2.8451<br />
0,04 2.5825 3.2083 0.00 5.5500<br />
Part B 2.7068<br />
0,02 2.5201 2.8404 0.00 4.5333<br />
Part C 3.0209<br />
0,01 2.9568 3.1004 0.00 5.4000<br />
Total Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Part A 53.0088<br />
0,80 47.9752 59.9794 0.2775 76.0037<br />
Part B 52.9870<br />
0,39 49.5082 55.5439 0.2775 70.5745<br />
Part C<br />
O<strong>the</strong>r<br />
52.6689<br />
0,19 51.5419 53.9931 0.2775 72.4180<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 3 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Entity<br />
O<strong>the</strong>r<br />
Values Across All Replications<br />
Number In Minimum Maximum<br />
Average Half Width Average Average<br />
# Batches 1502.90 0,22 1501.00 1504.00<br />
Part A 1708.80 0,30 1707.00 1711.00<br />
Part B 3410.04 0,68 3405.00 3415.00<br />
Part C 2397.60 0,26 2396.00 2400.00<br />
3600,000<br />
3200,000<br />
2800,000<br />
2400,000<br />
2000,000<br />
1600,000<br />
1200,000<br />
Number Out Minimum Maximum<br />
Average Half Width Average Average<br />
# Batches 1502.90 0,22 1501.00 1504.00<br />
Part A 1711.66 1,26 1705.00 1720.00<br />
Part B 3406.32 1,32 3398.00 3416.00<br />
Part C 2398.46 0,77 2393.00 2404.00<br />
WIP Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
# Batches<br />
Part A<br />
Part B<br />
Part C<br />
Maximum<br />
Value<br />
# Batches 0.00<br />
0,00 0.00 0.00 0.00 1.0000<br />
Part A 18.8992<br />
0,29 17.0829 21.3689 7.0000 27.0000<br />
Part B 37.6496<br />
0,28 35.2405 39.4182 26.0000 48.0000<br />
Part C 26.3160<br />
0,09 25.7414 26.9623 17.0000 35.0000<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 4 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Process<br />
Time per Entity<br />
Values Across All Replications<br />
VA Time Per Entity Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Process 2 0.5927<br />
0,00 0.5872 0.6009 0.3506 0.8662<br />
Process 7 0.5701<br />
0,00 0.5670 0.5720 0.3670 0.7164<br />
Wait Time Per Entity Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Process 2 0.08760054<br />
0,00 0.07767864 0.0951 0.00 1.6388<br />
Process 7 0.2325<br />
0,00 0.2157 0.2469 0.00 2.4015<br />
Total Time Per Entity Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Process 2 0.6803<br />
0,00 0.6649 0.6959 0.3506 2.4330<br />
Process 7<br />
Accumulated Time<br />
0.8025<br />
0,00 0.7844 0.8189 0.3670 3.0287<br />
Accum VA Time Minimum Maximum<br />
Average Half Width Average Average<br />
Process 2 3615.40 4,36 3590.50 3659.87<br />
Process 7 3470.98 3,41 3443.59 3492.72<br />
3620,000<br />
3600,000<br />
3580,000<br />
3560,000<br />
3540,000<br />
3520,000<br />
3500,000<br />
3480,000<br />
3460,000<br />
Process 2<br />
Process 7<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 5 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Process<br />
Accumulated Time<br />
Values Across All Replications<br />
Accum Wait Time Minimum Maximum<br />
Average Half Width Average Average<br />
Process 2 534.33 6,08 475.00 579.64<br />
Process 7 1415.46 14,06 1311.62 1507.34<br />
O<strong>the</strong>r<br />
1600,000<br />
1400,000<br />
1200,000<br />
1000,000<br />
800,000<br />
600,000<br />
400,000<br />
Number In Minimum Maximum<br />
Average Half Width Average Average<br />
Process 2 6100.18 2,64 6075.00 6118.00<br />
Process 7 6089.26 2,60 6065.00 6109.00<br />
6102,000<br />
6100,000<br />
6098,000<br />
6096,000<br />
6094,000<br />
6092,000<br />
6090,000<br />
6088,000<br />
Number Out Minimum Maximum<br />
Average Half Width Average Average<br />
Process 2 6099.84 2,67 6074.00 6118.00<br />
Process 7 6088.70 2,58 6065.00 6106.00<br />
Process 2<br />
Process 7<br />
Process 2<br />
Process 7<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 6 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Queue<br />
Time<br />
Values Across All Replications<br />
Waiting Time Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Batch 2.Queue 3.8317<br />
0,00 3.8281 3.8365 0.00 12.6704<br />
Leave Part A Line.Queue 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leave Part B Line.Queue 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leave Part C Line.Queue 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leave Work Station 1.Queue 0.00366070<br />
0,00 0.00319727 0.00428433 0.00 0.9848<br />
Leave Work Station 2.Queue 0.00436478<br />
0,00 0.00402659 0.00483652 0.00 1.0350<br />
Leave Work Station 3.Queue 0.00383503<br />
0,00 0.00323843 0.00433585 0.00 1.1498<br />
Leave Work Station 4.Queue 0.00378261<br />
0,00 0.00335110 0.00419512 0.00 0.9180<br />
Leave Work Station 5.Queue 0.00343074<br />
0,00 0.00297389 0.00393603 0.00 1.0924<br />
Leave Work Station 6.Queue 0.00457547<br />
0,00 0.00408256 0.00506101 0.00 1.1155<br />
Leave Work Station 7.Queue 0.00338256<br />
0,00 0.00304802 0.00388276 0.00 0.8769<br />
load point.Queue 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
merge point.Queue 0.05051293<br />
0,00 0.04948186 0.05167219 0.00 0.2493<br />
Process 2.Queue 0.08760294<br />
0,00 0.07767864 0.0951 0.00 1.6388<br />
Process 7.Queue 0.2325<br />
0,00 0.2158 0.2469 0.00 2.4015<br />
Queue for load point.Queue 27.5547<br />
0,03 27.3262 27.7338 21.2845 32.8481<br />
Seize work Station 1.Queue 1.1914<br />
0,07 0.8739 1.8282 0.00 11.4875<br />
Seize Work Station 3.Queue 0.2870<br />
0,00 0.2756 0.3001 0.00 2.3795<br />
Seize Work Station 4.Queue 20.6595<br />
0,07 19.9490 21.0475 8.2181 23.9244<br />
Seize Work Station 5.Queue 0.2709<br />
0,00 0.2565 0.2882 0.00 1.9456<br />
Seize Work Station 6.Queue<br />
O<strong>the</strong>r<br />
0.4297<br />
0,00 0.4153 0.4513 0.00 2.2806<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 7 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Queue<br />
O<strong>the</strong>r<br />
Values Across All Replications<br />
Number Waiting Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Batch 2.Queue 6.0004<br />
0,00 5.9969 6.0038 0.00 13.0000<br />
Leave Part A Line.Queue 0.00<br />
0,00 0.00 0.00 0.00 1.0000<br />
Leave Part B Line.Queue 0.00<br />
0,00 0.00 0.00 0.00 1.0000<br />
Leave Part C Line.Queue 0.00<br />
0,00 0.00 0.00 0.00 1.0000<br />
Leave Work Station 1.Queue 0.00465233<br />
0,00 0.00406919 0.00544200 0.00 2.0000<br />
Leave Work Station 2.Queue 0.00554679<br />
0,00 0.00510622 0.00615649 0.00 1.0000<br />
Leave Work Station 3.Queue 0.00487165<br />
0,00 0.00410471 0.00551285 0.00 2.0000<br />
Leave Work Station 4.Queue 0.00479826<br />
0,00 0.00424054 0.00531819 0.00 2.0000<br />
Leave Work Station 5.Queue 0.00435119<br />
0,00 0.00376879 0.00499137 0.00 2.0000<br />
Leave Work Station 6.Queue 0.00580472<br />
0,00 0.00516359 0.00643908 0.00 2.0000<br />
Leave Work Station 7.Queue 0.00429077<br />
0,00 0.00386781 0.00493272 0.00 2.0000<br />
load point.Queue 0.00<br />
0,00 0.00 0.00 0.00 1.0000<br />
merge point.Queue 0.06405115<br />
0,00 0.06267703 0.06543335 0.00 9.0000<br />
Process 2.Queue 0.1113<br />
0,00 0.0990 0.1208 0.00 3.0000<br />
Process 7.Queue 0.2950<br />
0,00 0.2733 0.3144 0.00 4.0000<br />
Queue for load point.Queue 34.9565<br />
0,03 34.7173 35.1937 27.0000 40.0000<br />
Seize work Station 1.Queue 1.5020<br />
0,08 1.0997 2.3151 0.00 15.0000<br />
Seize Work Station 3.Queue 0.3647<br />
0,00 0.3512 0.3812 0.00 4.0000<br />
Seize Work Station 4.Queue 26.2464<br />
0,09 25.3887 26.6655 10.0000 30.0000<br />
Seize Work Station 5.Queue 0.3436<br />
0,00 0.3253 0.3664 0.00 3.0000<br />
Seize Work Station 6.Queue 0.5449<br />
0,00 0.5267 0.5728 0.00 4.0000<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 8 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Resource<br />
Usage<br />
Values Across All Replications<br />
Instantaneous Utilization Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Work Station 1 0.9820<br />
0,00 0.9734 0.9886 0.00 1.0000<br />
Work Station 2 0.7532<br />
0,00 0.7480 0.7624 0.00 1.0000<br />
Work Station 3 0.7578<br />
0,00 0.7514 0.7661 0.00 1.0000<br />
Work Station 4 1.0000<br />
0,00 1.0000 1.0000 0.00 1.0000<br />
Work Station 5 0.9107<br />
0,00 0.9033 0.9167 0.00 1.0000<br />
Work Station 6 0.7976<br />
0,00 0.7931 0.8015 0.00 1.0000<br />
Work Station 7 0.7231<br />
0,00 0.7175 0.7277 0.00 1.0000<br />
Number Busy Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Work Station 1 0.9820<br />
0,00 0.9734 0.9886 0.00 1.0000<br />
Work Station 2 0.7532<br />
0,00 0.7480 0.7624 0.00 1.0000<br />
Work Station 3 0.7578<br />
0,00 0.7514 0.7661 0.00 1.0000<br />
Work Station 4 1.0000<br />
0,00 1.0000 1.0000 0.00 1.0000<br />
Work Station 5 0.9107<br />
0,00 0.9033 0.9167 0.00 1.0000<br />
Work Station 6 0.7976<br />
0,00 0.7931 0.8015 0.00 1.0000<br />
Work Station 7 0.7231<br />
0,00 0.7175 0.7277 0.00 1.0000<br />
Number Scheduled Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
Work Station 1 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 2 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 3 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 4 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 5 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 6 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Work Station 7 1.0000<br />
0,00 1.0000 1.0000 1.0000 1.0000<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 9 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Resource<br />
Usage<br />
Values Across All Replications<br />
Scheduled Utilization Minimum Maximum<br />
Average Half Width Average Average<br />
Work Station 1 0.9820 0,00 0.9734 0.9886<br />
Work Station 2 0.7532 0,00 0.7480 0.7624<br />
Work Station 3 0.7578 0,00 0.7514 0.7661<br />
Work Station 4 1.0000 0,00 1.0000 1.0000<br />
Work Station 5 0.9107 0,00 0.9033 0.9167<br />
Work Station 6 0.7976 0,00 0.7931 0.8015<br />
Work Station 7 0.7231 0,00 0.7175 0.7277<br />
1,000<br />
0,960<br />
0,920<br />
0,880<br />
0,840<br />
0,800<br />
0,760<br />
0,720<br />
Total Number Seized Minimum Maximum<br />
Average Half Width Average Average<br />
Work Station 1 6100.20 2,69 6075.00 6119.00<br />
Work Station 2 6100.10 2,65 6075.00 6118.00<br />
Work Station 3 6099.80 2,68 6074.00 6118.00<br />
Work Station 4 6088.64 2,59 6065.00 6107.00<br />
Work Station 5 6088.22 2,64 6064.00 6107.00<br />
Work Station 6 6089.02 2,62 6064.00 6108.00<br />
Work Station 7 6088.88 2,59 6065.00 6107.00<br />
6102,000<br />
6100,000<br />
6098,000<br />
6096,000<br />
6094,000<br />
6092,000<br />
6090,000<br />
6088,000<br />
Work Station 1<br />
Work Station 2<br />
Work Station 3<br />
Work Station 4<br />
Work Station 5<br />
Work Station 6<br />
Work Station 7<br />
Work Station 1<br />
Work Station 2<br />
Work Station 3<br />
Work Station 4<br />
Work Station 5<br />
Work Station 6<br />
Work Station 7<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 10 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
Station<br />
O<strong>the</strong>r<br />
Values Across All Replications<br />
Number Entities Transferring Minimum Maximum<br />
Average Half Width Average Average<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
A Enters Merge Point.Station 0.0989<br />
0,00 0.0988 0.0990 0.00 1.0000<br />
B Enters Merge Point.Station 0.1973<br />
0,00 0.1970 0.1976 0.00 1.0000<br />
C Enters Merge Point.Station 0.1387<br />
0,00 0.1387 0.1388 0.00 1.0000<br />
Enter load station.Station 1.4087<br />
0,00 1.4037 1.4132 0.00 12.0000<br />
Enter Work Station 1.Station 0.2870<br />
0,00 0.2846 0.2890 0.00 3.0000<br />
Enter Work Station 2.Station 0.5835<br />
0,00 0.5766 0.5898 0.00 3.0000<br />
Enter Work Station 3.Station 0.6032<br />
0,00 0.5966 0.6113 0.00 3.0000<br />
Enter Work Station 4.Station 0.5580<br />
0,00 0.5499 0.5637 0.00 4.0000<br />
Enter Work Station 5.Station 0.5864<br />
0,00 0.5788 0.5954 0.00 3.0000<br />
Enter Work Station 6.Station 0.5707<br />
0,00 0.5610 0.5792 0.00 3.0000<br />
Enter Work Station 7.Station 0.5376<br />
0,00 0.5319 0.5428 0.00 4.0000<br />
Exit conveyor.Station 0.3715<br />
0,00 0.3648 0.3768 0.00 3.0000<br />
Leaving load station 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Part A Line 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Part B Line 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Part C Line 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving unload station 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 1 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 2 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 3 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 4 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 5 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 6 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Leaving Work Station 7 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
merge station 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 11 of 12
Category Overview<br />
13:38:13 maj 5, 2009<br />
<strong>SM</strong> <strong>Electronics</strong><br />
Replications: 50 Time Units: Minutes<br />
User Specified<br />
Counter<br />
Values Across All Replications<br />
Count Minimum Maximum<br />
Average Half Width Average Average<br />
Record Part A lost parts 378.26 23,03 177.00 520.00<br />
Record Part B lost parts 572.76 24,12 417.00 787.00<br />
Record Part C lost parts 476.98<br />
7,77 422.00 526.00<br />
600,000<br />
560,000<br />
520,000<br />
480,000<br />
440,000<br />
400,000<br />
360,000<br />
Time Persistent<br />
Variable Minimum Maximum<br />
Average Half Width Average Average<br />
Record Part A lost parts<br />
Record Part B lost parts<br />
Record Part C lost parts<br />
Minimum<br />
Value<br />
Maximum<br />
Value<br />
cost counter 0.00<br />
0,00 0.00 0.00 0.00 0.00<br />
Entity Counter<br />
Output<br />
1.4728<br />
0,00 1.4673 1.4779 0.00 12.0000<br />
Output Minimum Maximum<br />
Average Half Width Average Average<br />
Lost Cost A 336.65 20,49 157.53 462.80<br />
Lost Cost B 360.84 15,19 262.71 495.81<br />
Lost Cost C 343.43 5,59 303.84 378.72<br />
Total Lost Cost 1040.92 4,87 995.43 1067.93<br />
1100,000<br />
1000,000<br />
900,000<br />
800,000<br />
700,000<br />
600,000<br />
500,000<br />
400,000<br />
300,000<br />
Lost Cost A<br />
Lost Cost B<br />
Lost Cost C<br />
Total Lost Cost<br />
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]<br />
Page 12 of 12
Litteratur<br />
[1] W. D. Kelton, R. P. Sadowski, and D. T. Sturrock. <strong>Simulation</strong> with Arena.<br />
McGraw-Hill Book Co., New York, 2007. McGraw-Hill Series in Industrial<br />
Engineering and Management Science.<br />
[2] Averill M. Law. <strong>Simulation</strong> modeling and analysis. McGraw-Hill Book<br />
Co., New York, 2007. McGraw-Hill Series in Industrial Engineering and<br />
Management Science.<br />
[3] David G. Luenberger. Investment Science. Oxford University Press, inc.,<br />
New York, 1998.<br />
63