Simulation af SM Electronics - the Mathematics home page. - Aarhus ...

Simulation af SM Electronics
Simulation of SM Electronics
Bachelorprojekt i Matematik-Økonomi
Lene O. Sønder
20061258
Morten Petersen
20061557
Vejleder: Søren Glud Johansen
Institut for Matematiske Fag
Aarhus Universitet
Maj 2009

Indholdsfortegnelse
Abstract iii
Forord v
Kapitel 1 Indledning 1
1.1 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Modellen og Antagelser . . . . . . . . . . . . . . . . . . . . . . 2
Kapitel 2 Modelkonstruktion, verificering og validering 7
2.1 Ankomster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Ankomst til input conveyor . . . . . . . . . . . . . . . . . . . . 8
2.3 Arbejdsstation 8 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Automatiserede arbejdsstationer . . . . . . . . . . . . . . . . . 10
2.5 Manuelle arbejdsstationer . . . . . . . . . . . . . . . . . . . . . 12
2.6 De sidste 4 moduler . . . . . . . . . . . . . . . . . . . . . . . . 12
2.7 Run Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.8 Verificering og Validering . . . . . . . . . . . . . . . . . . . . . 14
Kapitel 3 Analyse og konklusion 19
3.1 Mulige forbedringer . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Modifikation 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Modifikation 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Kombinationer af modifikation 1 og 2 . . . . . . . . . . . . . . 23
3.5 Konklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Appendices 27
Contest Problem 9: SM Electronics 29
Output fra grundmodel 35
Output fra modifikation 49
Litteratur 63
i

Abstract
This project is written in connection with the course „Modelling, simulation
and analysis“ at Aarhus University, Denmark. It takes its starting point in
„Contest Problem 9“, supplied by Rockwell Automation, Inc. We have used simulation
to examine a certain problem at a fictitious company, SM Electronics.
The company has observed that bottlenecks occur somewhere in their system,
and we have therefore build a model, by means of simulation, that describes
the system. This is discussed in the first part of the assignment. We have then
established where the problem arised and as a conseqence of that, we have
made some modifications to our model in order to try to solve the problem.
By means of our simulations we have shed some light on the origin of the
problem and also seen which modifications that improved the system. In deciding
which modifications to be used, we also took into account the cost of
implementing the change and the savings obtained from the modification.
iii

Forord
Dette bachelorprojekt omhandler virksomheden SM Electronics som beskrevet
i „Contest Problem 9“. Formålet med projektet har været at modellere
en konkret virksomhed, og ud fra denne model at analysere en bestemt problemstilling
vha. simulation. I det følgende er der en indgående beskrivelse af
den omtalte model, en diskussion af hvorfor den virker, samt en analyse af
problemstillingen med udgangspunktet i de resultater vi har opnået i løbet af
processen. Vi har set på forskellige modifikationer af modellen for at undersøge
hvilke forbedringer, der er mulige at lave, og hvilke der kan forbedre systemet,
samt lavet en analyse af, hvilke ændringer i grundmodellen, der således kan
betale sig at gennemføre.
Århus, Maj 2009
v
Lene Sønder & Morten Petersen

Kapitel 1
Indledning
1.1 Problemformulering
Med udgangspunkt i „Contest Problem 9“ (se appendiks s. 35) har vi forsøgt
at benytte simulation til at analysere og forbedre en vis problemstilling hos
SM Electronics. Virksomheden fremstiller elektroniske elementer, som andre
virksomheder videreforarbejder. I den konkrete problemstilling ser vi på en
afdeling som producerer tre elementer, A, B og C. Disse bliver hovedsageligt
produceret separat, men ender alle i en fælles afsluttende proces. Helt konkret
bliver elementerne placeret på et transportbånd, der fragter dem mellem otte
arbejdsstationer, jvf. figur 1.1.
Figur 1.1: Oversigt
Der er tre forskellige typer arbejdsstationer. Station 8 er en på-/aflæsningsstation,
hvor de forskellige elementer anbringes i, hhv. fjernes fra en pallet,
hvori elementerne transporteres i det videre system. Station 1, 3, 4, 5 og
6 er automatiserede stationer, hvor elementerne bliver forarbejdet af maskiner,
og hvor maskinerne evt. skal omstilles, hvis forrige element ikke var af
samme type som det nuværende. Til sidst har vi også de manuelle arbejdsstationer,
hvor elementerne bliver behandlet af medarbejdere. Elementerne
1

2 Kapitel 1. Indledning
bliver fragtet rundt i systemet på nogle transportbånd med begrænset kapacitet,
og et element betragtes som tabt for systemet, hvis der ikke er plads på
transportbåndene.
Problemstillingen består så i at minimere de omkostninger, som virksomheden
har ved disse tabte elementer. Man kan fx forestille sig, at begrænsningerne
på transportbåndene kunne være et problem, eller måske er arbejdsstationerne
ikke hurtige nok. Yderligere kunne man forestille sig, at arbejdsstationerne
kunne udnyttes bedre. Selve problemstillingen samt disse mulige årsager vil
vi tage op og analysere i denne opgave.
1.2 Modellen og Antagelser
Data for SM Electronics’ fjerde linje omhandler ankomster af enhederne A, B
og C, den tid det tager at forarbejde hver type på de syv forskellige arbejdsstationer,
den tid det tager at omstille maskinerne, så de passer til de forskellige
typer enheder og hastigheden på virksomhedens transportbånd. Desuden oplyses
den lost cost der indtræffer, når et element smides ud, inden det når at
komme ind på det første transportbånd til det videre system. Da der er tale
om et faktisk system, som virksomheden har og arbejder med, må det forventes,
at tiderne er en god repræsentation af virkeligheden. Samlet producerer
de tre første linjer omkring
( 60 60
+
2.8 1.4
60
+ ) stk/time · 16 timer ≈ 1500 stk
2
hver dag, og det er derfor muligt at samle ret gode data om, hvordan enhederne
kommer, og hvad der sker med dem igennem systemet.
Man kan diskutere, om en triangulær fordeling normalt vil give et godt
billede af, fx hvor lang tid et stykke arbejde tager, men da virksomheden
netop har haft et konsulentfirma til at finde data, og da der er så meget data
at lave analyser ud fra, må det forventes, at de oplyste tal giver et nogenlunde
godt billede af virkeligheden. Mht. lost cost, som vi får oplyst, er hhv. 0.89,
0.63 og 0.72, kan vi ud fra teksten ikke vurdere, om det er tal, der svarer
til virkeligheden, da vi ikke har nogen andre omkostninger i forbindelse med
systemet, og vi intet får at vide om, hvordan disse omkostninger er fundet. Vi
må derfor blot antage, at data i opgavebeskrivelsen er en god repræsentation
af virkeligheden, især fordi vi behandler et system, der allerede eksisterer, og
hvor det er muligt at lave faktiske målinger.
Mht. de to modifikationer er der til gengæld tale om endnu ikke afprøvede
systemer, hvilket gør, at det ikke er muligt at se, hvordan de fungerer. Men
da der kun er tale om små modifikationer i det faktiske system, som ikke
umiddelbart vil have nogen effekt på andet end hhv. antallet af enheder i
systemet, eller hvor ofte nogle enheder skal igennem setuptid, må vi også
forvente, at data i disse tilfælde er gode nok.

1.2. Modellen og Antagelser 3
Den del af SM Electronics, vi analyserer, er et system, hvor der kommer
tre typer enheder ind, A, B og C, som er blevet forarbejdet på hver deres
linje og nu kommer ind på en fælles linje. Alle tre enheder kommer fra en
anden linje i konstante tidsintervaller, dog med en lille forsinkelse nogle få
procent af de gange, de ankommer. På den fjerde linje placeres enhederne på
et fælles transportbånd, „Input Conveyor“ (IC), i den rækkefølge de kommer
ind. På (IC) er der plads til 40 enheder. Vi har antaget at en enhed fylder
2 fod på (IC) (og de tre buffer conveyors fra modifikation 2), ligesom det er
tilfældet på transportbåndet mellem arbejdsstationerne, som vi har valgt at
kalde „Conveyor“ (C). Ligeledes har vi antaget, at alle transportbånd kører
med samme hastighed som (C), dvs. 72 fod pr. min. Dette betyder i det store
hele ikke noget, da vi har en opvarmningsperiode, jvf. afsnit 2.7 på side 13, så
vi kun måler på systemet, når det er fyldt op. Alligevel synes vi, at det giver
en bedre repræsentation af virkeligheden at lave disse transportbånd i forhold
til kun at lave en kø, fordi det virker mest naturligt, at der er en transporttid,
fx fra der hvor enhederne samles til det område, hvor de læsses på (C).
Hvis der allerede er 40 enheder på (IC), når enheden kommer hen til transportbåndet,
smides den ud. Når elementerne har passeret (IC), læsses de op
på en slags pallet, som enhederne nu skal fragtes i, i det videre system. Disse
palletter er placeret på (C), som er forbindelsen mellem otte stationer, hvoraf
de syv forarbejder enheden. På (C) er der 40 palletter, dvs. der også på dette
transportbånd højst kan være 40 enheder.
Hele den fjerde linje består af 8 stationer, 5 automatiserede arbejdsstationer,
2 manuelle arbejdsstationer og én på-/aflæsningsstation, hvor alle arbejdsstationerne
har forskellige procestider, der er afhængige af hvilken type
enhed, der skal behandles. Af-/pålæsningsstationens proces tager en konstant
tid, ligegyldigt hvilken type enhed der behandles.
Vi har ladet denne fjerde linje bestå af to transportbånd, (IC) og (C).
Dette har vi gjort, fordi vi forstår systemet således, at der placeres en ny
enhed ned i en pallet, så snart den færdiggjorte enhed er blevet fjernet, hvilket
ikke var muligt, hvis systemet skulle bestå af kun et transportbånd. Havde
der kun været ét bånd, skulle det efter aflæsning af en færdig enhed tilbage
til stationen, hvor enhederne kommer ind på linjen, og først derefter hen til
pålæsningsstationen. Denne løsning ville også give problemer mht. palletten,
da enhederne ikke skal anbringes i en pallet med det samme, de kommer ind
på transportbåndet, og det ville derfor blive nødvendigt, at fjerne palletten
fra båndet samtidig med den færdige enhed, for derefter at placere den på
transportbåndet igen, når en ny enhed skal læsses på palletten. Derfor har vi
valgt at lade de to transportbånd køre i hver sin ring. (IC) kører fra punktet,
hvor enhederne kommer ud, til på-/aflæsningsstationen og tilbage igen, mens
(C) kører fra på-/aflæsningsstationen videre til arbejdsstation 1, 2 osv. frem
til arbejdsstation 7 og tilbage til på-/aflæsningsstationen.
På arbejdsstationerne har vi antaget af elementerne fjernes fra transportbåndet
og placeres derpå igen, efter arbejdet er færdiggjort. Vi har valgt

4 Kapitel 1. Indledning
denne løsning, fordi vi i beskrivelsen af problemet får opgivet en hastighed,
som transportbåndet kører med, der gør, at det vil tage transportbåndet under
to sekunder at bevæge sig de to fod en arbejdsstation fylder. Derfor ville
det aldrig kunne lade sig gøre, at arbejdet på stationerne blev lavet, hvis
elementerne skulle blive på båndet, og båndet skulle køre med den opgivne
hastighed. Vi har derfor valgt, at enhederne forlader båndet ved alle arbejdsstationer,
da alternativet ville være, at båndets hastighed skulle bestemmes
af den langsomste proces, og hastigheden på de 72 fod i minuttet ville dermed
være underordnet.
Fordi vi har antaget, at elementerne forlader transportbåndet ved arbejdsstationerne,
har vi valgt at inkludere de enheder, der er på arbejdsstationerne,
og specielt i kø til disse, i de 40, der højst kan være på transportbåndet. Havde
vi ikke valgt at gøre dette, skulle der fx være ubegrænset plads i køen til
arbejdsstationerne. Det ville have betydet, at begrænsningen på højst 40 enheder
ikke ville have gjort nogen forskel, da man ved at se lidt på arbejdstiderne
på arbejdsstationerne, kan se, at det som regel vil tage længere tid for en enhed
at komme igennem en arbejdsstation end at blive transporteret imellem
to arbejdsstationer. Derfor har vi valgt, at der maksimalt kan være 40 på (IC)
og området omkring den. Ligeledes kan der i alt være 40 på transportbåndet
og arbejdsstationerne i det videre system. For at begrænse antallet af enheder
i systemet, dvs. for at undgå så stor en kø før (IC), at den aldrig ville kunne
afvikles, tjekkes der, når en enhed kommer frem til det første transportbånd,
om der samlet er færre end 40 enheder på (IC) og i køen til pålæsningsstationen.
Er der det, sendes elementet ind på transportbåndet, og det gennemløber
hele systemet, mens enheden smides ud, hvis der er 40 på båndet og området
omkring den.
I de fem automatiserede arbejdsstationer er der en konstant procestid, der
er afhængig af, hvilken type den ankomne enhed har, men der er også en
setuptid, som enheden skal igennem, hvis den forrige enhed var af en anden
type end den nyankomne. Når arbejdsdagen slutter skal alle enheder stoppe
der, hvor de er, og næste dag fortsættes der, hvor man slap. Det betyder
naturligvis også, at setuptid for den første, der ankommer en morgen, afhænger
af, hvilken type den sidste, der var igennem stationen dagen før, havde. Vi har
samtidigt antaget, at når systemet begynder, er alle maskiner gjort klar til en
enhed af type A. Dette betyder dog ikke noget pga. opvarmningsperioden.
Den arbejdsopgave at fjerne et element fra en pallet og pålæsse en ny
tager samlet 25 sekunder plus en forsinkelse nogle procent af gangene. Dette
har vi modelleret lidt anderledes dog uden at ændre på, hvordan modellen
fungerer. Vi har ladet station 8, som er af-/pålæsningsstationen, opdele i to
stationer. En station i starten, der læsser enheder på (C), og en station til sidst
i modellen, der fjerner dem fra den igen. Afstanden mellem disse to stationer
har vi ladet være nul, hvilket gør, at så snart en enhed er taget ud af systemet,
er (C) allerede ved pålæsningsstationen, og en ny enhed bliver placeret på
båndet. I stedet for at dele tiden ud på både aflæsning og pålæsning, lader

1.2. Modellen og Antagelser 5
vi pålæsningen tage 25 sekunder plus en forsinkelse 1% af gangene. På den
måde bliver den samlede tid i systemet for hver enhed ikke ændret, og først
når systemet er fyldt (og det er først når systemet er fyldt, vi begynder at
måle), vil der alligevel ikke kunne pålæsses en enhed før, en færdig enhed er
blevet taget af palletten. Dette gør, at det ikke har nogen betydning, at hele
på-/aflæsningstiden tilføjes i starten.
I forbindelse med arbejdsstationerne, hvor det ankomne element fjernes fra
transportbåndet, behandles og anbringes på transportbåndet igen, antager vi,
at enheden fragtes på båndet de 16 fod, der er mellem to arbejdsstationer,
tages af båndet, mens dette kører videre og placeres efter arbejdstiden på
båndet igen. På- og aflæsningstiden ved dette, antager vi, er medregnet i
arbejdstiden ved den enkelte station.

Kapitel 2
Modelkonstruktion,
verificering og validering
I dette kapitel vil vi grundigt gennemgå, hvordan modellen er bygget op,
og vi vil tydeliggøre sammenhængene mellem de enkelte moduler i modellen.
Formålet her er ikke at give det store overblik over modellen, da en sådan er
formuleret i afsnit 1.2 på side 2.
2.1 Ankomster
Lad os nu tage fat på modellen. I figur 2.1 på næste side ser vi, at vi har tre
typer af ankomster. Der foregår dog essentielt det samme i alle tre moduler
nemlig, at der er et udtryk på formen
c + (DISC(x, 0, y, 1, z) · TRIA(a, b, c, w))
hvor c angiver en konstant, der repræsenterer en fast ankomstrate. Vi bruger
operatoren DISC til at modellere, at der en vis procentdel af gangene sker
forsinkelser af typen TRIA. Eksempelvis ankommer der et element af typen
A hver 168 sekund bortset fra, at det 2% af gangene bliver forsinket med
en stokastisk variabel, der er triangulær fordelt med parametrene 5, 15 og
60. Bemærk i øvrigt også, at vi styrer talstrømmene (her symboliseret med z
og w) således, at vi er sikre på, at der kommer det samme antal ankomster i
både vores grundmodel samt i vores modifikationer.
Efter disse indledende create moduler kommer elementerne nu til et assign
modul, hvis eneste opgave er at tildele de forskellige typer af elementer en
værdi 1, 2 eller 3, afhængig af om elementet er af type A, B eller C. Hvad vi
helt konkret bruger disse værdier til, kommer vi tilbage til i afsnit 2.2 på den
følgende side.
7

8 Kapitel 2. Modelkonstruktion, verificering og validering
Figur 2.1: Ankomster
2.2 Ankomst til input conveyor
Vi er nu nået dertil, hvor vi skal afgøre, om der plads på (IC) eller ej. Dette
sørger vores decide modul for vha. følgende udtryk
Entity Counter + NQ(Queue for load point.Queue) < 40 (2.1)
„Entity Counter“ er en variabel, som holder øje med hvor mange elementer,
der er på (IC). Dvs. næsten i hvert fald. Som det fremgår af (2.1), har vi også
tilføjet antallet af elementer i vores load point kø, hvilket er specificeret i et
hold modul senere i modellen. Vi vil komme ind på, hvorfor dette er vigtigt,
og hvorfor det er en del af (2.1) i afsnit 2.3 på næste side.
Figur 2.2: Ank. til input conveyor
Indtil videre vil vi antage, at dette er i orden, og vi vil derfor bevæge os
videre til det næste decide modul. Det vil sige, at vi nu er i tilfældet, hvor
(IC) er fyldt. Der er nu tre mulige udfald; enten er elementet af typen A,
B eller C. Det er så her værdien, som elementet fik tildelt i assign modulet
i starten af modellen, kommer ind i billedet. Vi er nemlig nu i stand til at

2.3. Arbejdsstation 8 9
afgøre elementtypen blot vha. følgende tests
if assigned value = i, i = 1, 2, 3
Vi har nu fået afgjort af hvilken type, det pågældende element er, og vi kan derfor
begive os videre til de tre record moduler, som blot tæller én op, hver gang
et element passerer. På denne måde har vi styr på hvor mange af hver type,
der bliver betragtet som tabt. Udover disse tre record moduler samt standard
statistikken fra run setup, har vi yderlige defineret nogle ekstra linjer i datamodulet
„Statistic“ under „Advanced processes“. Disse fremgår af figur 2.3.
De første tre rækker tager blot antallet fra vores førnævnte record moduler og
Figur 2.3: Statistik
ganger med enhedsomkostningen for de respektive typer. På denne måde får
vi skabt noget statistik, der fortæller, hvad omkostningerne har været, fordelt
på de tre typer af elementer. Den fjerde række lægger blot disse tal sammen,
så vi får et udtryk for den samlede omkostning.
Lad os nu se på situationen, hvor (IC) er ledig, dvs. at elementet i stedet
kommer til assign modulet, „Increment # of Entities in input Conveyor“,
hvis eneste opgave er at tælle variablen „Entity Counter“ én op. Elementet
ankommer herefter til en station, „merge station“, som modellerer ankomsten
til (IC). „Merge point“, som er det efterfølgende leave modul, søger så for, at
elementerne faktisk kommer op på (IC).
2.3 Arbejdsstation 8
Inden vi fortsætter med de næste moduler, vil vi her lige forklare, hvordan
vores generelle transportbånd er bygget op. Grundlæggende er de bygget fuldstændig
identisk op, så vi vil nøjes med at betragte (IC). Den er af typen
„non-accumulating“, da vi betragter et transportbånd, der kører med en konstant
fart uden afbrydelser. Hastigheden er sat til 72 fod pr. minut, eller som
der står i opgaveteksten (jvf. „Contest Problem 9: SM Electronics“ på side
35), 18 fod pr. 15 sekunder. I datamodulet „Conveyor“ har vi valgt at sætte
„Cell Size“ til én fod og „Max Cells Occupied“ til to fod. Ligeledes har vi i alle
leave modulerne givet „# of Cells“ værdien 2. Disse værdier har vi valgt, fordi
en enhed skal optage to fod på et transportbånd, hvilket vi sørger for ved at
lade en enhed fylde to celler, der hver er på én fod. Denne løsning har vi valgt,
frem for at lade et element fylde en celle på to fod, for at gøre simulationen
mere præcis jvf. [1].

10 Kapitel 2. Modelkonstruktion, verificering og validering
Figur 2.4: Workstation 8
Tilbage til modulerne, jvf. figur 2.4. Vores element ankommer nu til et enter
modul, som har til opgave at tage vores element af (IC). Inden vi kommer til
det førnævnte hold modul, skal vores element lige igennem et assign modul,
der tæller vores Entity Counter én ned igen, således at vi kan holde styr
på antallet af elementer på (IC). Hold modulet holder på elementerne indtil
følgende betingelse er opfyldt
Entity Counter 2 < NrOfEntities
hvor „Entity Counter 2“ er en variabel fuldstændig magen til Entity Counter,
blot tæller denne variabel antallet af elementer på (C) og ikke (IC).
„NrOfEntities“ er en variabel, der konstant er lig 40, da det giver os mulighed
for at bruge Process Analyzer (PAN) til at se på effekterne af en evt.
udvidelse af antallet af palletter på (C). Så det, betingelsen siger, er, at vi
skal holde på vores elementer, indtil der er plads på (C). Dette venteområde
betragter vi også som en del af (IC). Grunden hertil er, at vi mener, det giver
det mest realistiske billede af virkeligheden, og den måde vi opfatter den på,
jvf. afsnit 1.2 på side 2. Sagen er, at der kan være 40 elementer på (IC), dvs.
i det område der kommer før workstation 8, dvs. inkl. hold modulet. Dette er
også grunden til, at vi i (2.1) medtager antallet af elementer i hold modulet.
Nu er vi så kommet dertil, hvor elementet skal op på (C), og derfor skal
vores enhed igennem endnu et assign modul, der har til formål at tælle førnævnte
Entity Counter 2 én op. Dernæst ankommer elementet til en station,
der skal markere, at enheden er klar til at komme op på (C). Selve denne
manøvre sker i det næste leave modul. Her bemærkes i øvrigt, at hele load-
/unload proceduren regnes med her, som det også fremgår af den forsinkelse,
vi har angivet i modulet.
2.4 Automatiserede arbejdsstationer
Med udgangspunkt i den første arbejdsstation vil vi nu se på de automatiserede
arbejdsstationer, dvs. arbejdsstationerne 1, 3, 4, 5 og 6 (se evt. 2.5 på
næste side). Disse er opbygget af et enter modul, „Enter Work Station 1“,
for at enheden kan forlade transportbåndet, et seize modul, „Seize Work Station
1“, der belægger ressourcen, og et decide modul, „Is Entity Type the
same in 1?“, der afgør, om den pågældende enhed er af samme type, som den
foregående. Dvs. vi har en variabel, „Variabel 1“, som har en værdi 1, 2 eller
3, og decide modulet tester, om „assigned value“ ved den enhed, der kommer

2.4. Automatiserede arbejdsstationer 11
igennem decide modulet, er den samme som denne værdi. Hvis svaret til decide
modulet er falskt, vil enheden nu skulle igennem både en setuptid og en
procestid, som begge er konstanter, der er afhængige af enhedens type og hvilken
arbejdsstation, den er ved. Er svaret sandt, og enheden er af samme type
som den foregående, skal enheden blot igennem procestiden. Inden ressourcen
frigives skal enheden igennem et assign modul, der sætter Variabel 1 til værdien
af „assigned value“, og derved holdes der styr på hvilken type enhed, der
lige har været igennem arbejdsstationen. Denne værdi bruges således til at
afgøre, om den næste enhed skal igennem setup eller blot kan sendes direkte
ind i processen. Herefter fragtes elementet igennem et release modul, der frigiver
ressourcen, et station modul, der bruges til at angive transportbåndets
rute og et leave modul, „Leave Work Station 1“, hvor elementet kommer på
transportbåndet igen og sendes videre til næste station. Løsningen med seizedelay-release,
har vi valgt for at sikre, at det ikke er muligt at overhale en
enhed, der befinder sig i setup. På denne måde kan et element ikke komme
ind i decide modulet, før det foregående er færdigbehandlet, og dets type er
gemt i Variabel 1.
Figur 2.5: Automatiseret arbejdsstation
Procestiderne og setuptiderne har vi valgt at lave i et array med hhv. 21
og 15 indgange. Det betyder, at den første indgang i udtrykket Process er
arbejdstiden i arbejdsstation 1 på et element af typen A. Anden indgang er
arbejdstiden i arbejdsstation 1 på et element af typen B, fjerde indgang er
arbejdstiden i arbejdsstation 2 på et element af typen A osv. Setuptiderne er
defineret på samme måde, her er der dog bare tale om en liste med 15 indgange,
fordi de to manuelle arbejdsstationer ikke skal gennem opsætning ved forskellige
typer elementer. Arena sørger for at vælge de rigtige indgange, fordi vi
under fx „Delay Time“ i „Process Time 1“ har skrevet Process(assigned value).
Hvis elementet, der kommer ind i dette modul, er af typen A, vil den have
værdien 1 som assigned value, og Arena vil derfor finde Process(1), som er den
første indgang i Process. Ved hver af de efterfølgende arbejdsstationer har vi
blot lagt hhv. 3, 6, 9, 12, 15 og 18 til assigned value, og derved finder Arena
de tider, elementet skal forsinkes med baseret på, hvilken type det er, og hvor
det er i systemet. Denne løsning har vi valgt frem for at have et expression til
hver proces-/setuptid, fordi vi ved at have et expression til alle tider fik for
mange siman objekter, og derfor ikke kunne køre modellen. Alternativt kunne

12 Kapitel 2. Modelkonstruktion, verificering og validering
vi have reduceret modellen, så den fx ikke havde så mange arbejdsstationer,
men denne løsning ville vi selvfølgelig gerne undgå.
2.5 Manuelle arbejdsstationer
De manuelle arbejdsstationer er en simplere udgave af de automatiserede.
Her er det ikke nødvendigt med en setuptid, hvilket gør, at det ikke bliver
nødvendigt at holde styr på, hvilke typer der tidligere har været igennem. Disse
arbejdsstationer er derfor kun opbygget af et enter modul, der tager enhederne
af transportbåndet, et process modul, der har samme effekt som seize-delayrelease-konstruktionen
fra de automatiserede arbejdsstationer, og til slut en
station og et leave modul, der gør, at transportbåndets rute kan blive beskrevet
i datamodulet „Segment“, og at enhederne sættes tilbage på transportbåndet.
Som ved de automatiserede arbejdsstationer vælges procestiderne vha. Process
under „Expression“, og de rigtige indgange i denne liste findes vha. attributten
assigned value plus en konstant. Eneste ændring er, at tiderne her ikke er
konstante, men triangulært fordelte.
2.6 De sidste 4 moduler
Figur 2.6: Manuel arbejdsstation
Nu er vi så nået til afslutningen af vores model. Her kommer elementet i første
omgang til et enter modul, „Exit conveyor“, som igen blot tager elementet af
(C). Dernæst har vi en station, „Leaving unload station“, som markerer det
sidste element på (C). Inden enheden sendes ud gennem vores dispose modul,
skal vi lige sørge for at Entity Counter 2 bliver talt én ned, hvilket selvfølgelig
sker gennem et assign modul, som her hedder „Decrement # of Entities in
Conveyor“.
Figur 2.7: Exit

2.7. Run Setup 13
2.7 Run Setup
Det sidste, vi vil kommentere i dette kapitel, er, hvordan vi har sat selve kørslerne
op. Som det fremgår af Figur 2.8, har vi sat „replikationslængden“ til
5000 minutter (5 dage med 16 timer pr. dag angivet i minutter plus 200 min. i
opvarmningsperiode) og „Timer pr. dag“ til 16. Dette fremgår mere eller mindre
af opgaveteksten (jvf. „Contest Problem 9: SM Electronics“ på side 35),
idet virksomheden arbejder med 16 timers produktionsdage, 5 dage om ugen.
Med hensyn til „opvarmningsperioden“ og „# replikationer“ har vi her været
i gang med nogle overvejelser. Mere præcist har vi til opvarmningsperioden
benyttet Output Analyzer (OA). Da produktionen bliver lukket ned hver dag
uden, at de ufærdige produkter forlader systemet, var vores mål, at opvarmningsperioden
skulle sørge for, at antallet af elementer i systemet skulle være
på det normale niveau. Til at undersøge hvad dette normale niveau er, har
Figur 2.8: Run Setup
vi som sagt brugt (OA). Af grunde vi ikke forstår vælger (OA) ikke at vise,
hvad der sker efter ca. 200 min. (svarende til opvarmningsperioden), hvis man
blot ser på et kort tidsinterval, jvf. figur 2.9 på næste side, så for det fulde
billede, se figur 2.10 på den følgende side. Det, vi her ser, er, at der går ca.
150 min., fra vi starter, til niveauet for systemet er stabiliseret, og for at være
på den sikre side sætter vi derfor opvarmningsperioden til 200 min. Bemærk
at vi har benyttet (OA) i tilfældet, hvor NrOfEntities er 72. Dette gør selvfølgelig
opvarmningsperioden unødvendigt lang i tilfældet med færre palletter
på båndet, men i forbindelse med vores kørsler i (PAN) var det en fordel at
systemet var fyldt uafhængigt af NrOfEntities. Mht. antallet af replikationer,
så har vi her gjort os nogle overvejelser mht. vores konfidensintervaller. Vi har
i den forbindelse lavet kørsler med hhv. 10, 40, 50, 70 og 100 replikationer,

14 Kapitel 2. Modelkonstruktion, verificering og validering
Figur 2.9: # i systemet
Figur 2.10: # i systemet, set over hele perioden
og det viser sig, at når antallet kommer over 50, bliver ændringerne meget
små, og vi har derfor valgt, at det ikke kan betale sig at lave flere end 50
replikationer. Dette er selvfølgelig et skøn, vi har gjort os, men virksomheden
kunne jo sagtens tænkes at have andre præferencer end os. Man kunne sagtens
forestille sig, at de gerne ville have en meget præcis simulation, og derfor ville
sætte pris på mange flere replikationer eller omvendt, at de ikke vil bruge for
mange ressourcer, og derfor kunne være fint tilfredse med fx 10 replikationer.
2.8 Verificering og Validering
I opbygningen af vores model har vi ikke, som anbefalet i [2], startet med
at lave en mindre model og udbygget den efterhånden, men i stedet forsøgt
at lave hele modellen, og så senere delt den ind i mindre dele for at undersøge,
om alle delprocesser virkede efter hensigten. Dette har vi gjort, da vi
syntes, at det var nødvendigt med mindst én arbejdsstation af hver type og
vores af/-pålæsningsstation for at lave en grundmodel, der nogenlunde kunne
repræsentere virksomheden, og dermed give et overblik over opbygningen af
denne produktionslinje. Da fem af arbejdsstationerne er identiske, bortset fra
nogle proces- og setuptider, valgte vi at lave alle fem på én gang. Ligeledes
lavede vi de to manuelle arbejdsstationer samtidig, fordi vi således kunne få
et overblik over den samlede model, og alligevel, fordi så mange arbejdsstationer
stort set er ens, forholdsvist nemt kunne overskue modellen. Dette gav et
overblik over, om elementerne blev fragtet igennem systemet som ønsket, og
især om transportbåndene fungerede, som de skulle. Sidenhen har vi forenklet
modellen bl.a. for at undersøge, om decide modulerne i modellen fungerede
som forventet.
Det første decide modul (Is Input Conveyor avaliable?) afgør, om der er
så mange elementer på vores (IC), at det pågældende element, der er kommet
ind i decide modulet, skal direkte ud af systemet som en lost cost eller ej.
For at undersøge om dette modul gjorde som forventet, har vi fokuseret på
Arenas animation, hvor vi kunne se, at elementerne sendes videre i systemet,

2.8. Verificering og Validering 15
når der samlet er færre end 40 i „merge point“, (IC) og „Queue for load point“.
I vores output, jvf. „Output fra grundmodel“ på side 35, fra kørslerne ses det
også, at summen af antal ventende ved hhv. merge point, Queue for load point
og antallet af elementer på (IC) er mindre end 40, og at den også ligger så
tæt på 40, at betingelsen ser ud til at blive udnyttet fuldt ud. Ligeledes har
vi kunnet nå frem til, at vores hold modul inden load point (Queue for load
point) fungerer efter hensigten, da man under „Entity“ → „Other“, kan se, at
det samlede work in process for A, B og C er under, men dog forholdsvist tæt
på 80. Da der aldrig er mere end 40 i (IC) og køerne omkring denne betyder
dette, at der er omkring 40 i resten af systemet som ønsket.
For at afgøre om decide modulet (Is entity the same type?) ved arbejdsstationerne
fungerer efter hensigten, har vi set på hele systemet, hvor vi kun
har sendt én type ind, og derved har kunnet se, at decide modulerne sender
alle enheder videre til processen uden setuptid, på nær det første element,
som, hvis det er af type B eller C, skal igennem setuptid, da vi har antaget, at
maskinerne er gjort klar til type A. Derefter sendte vi kun elementer af type
A og B ind i systemet på en sådan måde, at hver anden var af type A, hver
anden af type B, og kunne så observere, som ønsket, at alle elementer skulle
igennem en setuptid ved alle arbejdsstationer. Alt dette har vi observeret vha.
Arenas simulation af kørslen.
Ud over at vi selv har diskuteret modellen, hvor vi har forsøgt at se om
den giver mening i forhold til virkeligheden, og om den fungerer som den skal,
har vi også ladet to andre se modellen igennem, sådan at de med upåvirkede
øjne kunne se efter eventuelle svage punkter eller fejlfortolkninger.
Desuden har vi lavet forskellige simple udregninger for at teste, om fx antallet
af lost parts udregnes rigtigt (summen af antal lost parts og „Number out“
i proces 7, bør ca. være Number out i alt), og set generelt på tallene i output
fra kørslerne (se „Output fra grundmodel“ på side 35) for at se, om tallene
virker realistiske. Både ud fra køtider, antal elementer i kø og udnyttelse af
ressourcerne ses det, at flaskehalsen i systemet er arbejdsstationerne, hvilket
også er det forventede, da transportbåndene kører 72 fod i minuttet, og det
dermed vil tage ca. 14 sekunder at blive transporteret de 16 fod, der er mellem
to arbejdsstationer. Det er derfor klart, at der vil skabes kø ved arbejdsstationerne,
fordi ingen af arbejdsstationerne har en procestid på under 20 sekunder,
og der udover procestiderne også ofte kommer en setuptid.
Da det ikke er transportbåndene, der er flaskehals i systemet, vil det naturligvis
også betyde, at man, for at få en forbedring af systemet der virkelig
gør en forskel, er nødt til at forkorte tiden, enhederne er på arbejdsstationerne.
Derfor er det også forventeligt, at man ved modifikation 1, hvor antallet af
elementer i systemet udvides, ikke ser en stor ændring i antallet af lost parts,
mens man ved modifikation 2 forkorter tiden i arbejdsstationerne betydeligt,
og derved får en stor forbedring.
I forhold til ankomsterne af enhederne, er der opstået det problem, at de
ikke var ens, når man så på modifikation 2 i forhold til grundmodellen. Dette

16 Kapitel 2. Modelkonstruktion, verificering og validering
har vi dog fået løst ved at styre alle talstrømme, dvs. ved at bruge forskellige
talstrømme til alle diskrete og triangulære fordelinger i de forskellige create
moduler, men selvfølgelig de samme talstrømme på tværs af modifikationerne,
jvf. afsnit 2.1 på side 7.
Da virksomhedens ønske kun er at få færre enheder smidt ud af den fjerde
linje, inden de kommer ind på det første transportbånd, er det informationen,
der har med denne problemstilling at gøre, der er vigtige at finde. Det betyder,
at detaljegraden fx omkring arbejdsstationerne kun skal være stor nok til, at
det kan give et indblik i, hvordan der kan komme flere igennem systemet, og
dermed få færre elementer smidt ud.
Var SM Electronics et virkeligt firma, ville det være forholdsvist simpelt
at få et overblik over, om vores model svarer til virkeligheden, fordi grundmodellen
beskriver et produktionssystem, der allerede eksisterer, og det ville
derfor være muligt at se hvor mange enheder af hver type, der blev færdigproduceret,
og hvor mange der blev kasseret. Ligeledes ville det være muligt at
se, om det i virkeligheden var de samme arbejdsstationer, der gav anledning
til flaskehalse, som dem i vores model og lignende. Desværre er det ikke muligt
for os, da vi ganske enkelt ikke har de tal. Alligevel er det dog muligt ud fra
det data, der er opgivet at se på nogle af modellens resultater. Bemærk at de
følgende udregninger er baseret på overslag. Ankomsterne i modellen svarer
godt til virkeligheden, da antal sekunder på en uge er 16 · 60 · 60 · 5 = 288000,
hvilket betyder, at der på en uge kommer ca.
288000
168
≈ 1714,
288000
84
≈ 3429 og
288000
120
≈ 2400
elementer ind i systemet af hhv. type A, B og C (eller ca 343, 686 og 480 om
dagen). Bemærk at disse tal er lidt over det faktiske, og de tal som Arena
giver, da vi i disse udregninger ikke har taget højde for de forsinkelser, der
nogle gange er i ankomsterne. Mht. flaskehalsene i systemet, er det klart, at
det i virkeligheden, som i vores model, må være arbejdsstationerne, der er
flaskehalsene, fordi det, som forklaret ovenfor, for alle arbejdsstationer tager
mere end 14 sekunder at behandle en enhed. At det især er ved arbejdsstation
4, der er kø, og dermed også denne station, der giver anledning til flaskehalse,
kan også ses ud fra tallene ved at lave et vægtet gennemsnit af procestiderne
ved arbejdsstationerne 1, 3, 4, 5 og 6 vægtet med, hvor mange enheder der
kommer af hver type. Da fås hhv. ca. 41.7, 28.5, 41.5, 37.3 og 34.2, hvor
eksempelvis det første tal er udregnet på følgende måde
37 · 343 + 46 · 686 + 39 · 480
343 + 686 + 480
≈ 41.7
Dette betyder, at den gennemsnitlige procestid i arbejdsstation 1 og 4 er væsentligt
længere end ved de andre stationer. Men da så stor en del af enhederne
skal igennem setup i grundmodellen, er det også nødvendigt at tage disse med
i overvejelserne. Her ses det, at setuptiderne for alle tre typer er kortere ved

2.8. Verificering og Validering 17
arbejdsstation 1 end ved arbejdsstation 4. Mht. arbejdsstation 3 er procestiderne
så meget kortere end procestiderne i arbejdsstation 4, at det virker
fornuftigt, at det vil tage en enhed længere tid at passere arbejdsstation 4 end
3, på trods af setuptiderne ved arbejdsstation 3. På samme vis kunne det på
data godt se ud til, at de sidste fire arbejdsstationer ikke er lige så forsinkende
for systemet, som arbejdsstation 4, fordi setuptiderne i station 5 og 6 stort
set alle er mindre end de tilsvarende tider fra station 4, og fordi stationerne 2
og 7 ikke har setuptider, og derfor må være væsentligt hurtigere. Alt i alt er
det plausibelt, at det bør være arbejdsstation 4, der samler kø, ligesom det er
tilfældet i modellen. Mht. modifikationen, der gør, at enhederne bliver samlet
alt efter type, virker det også troværdigt, at det stadig er arbejdsstation 4,
der er flaskehalsen i systemet, fordi procestiderne i denne station var blandt
dem, der tog længst tid, hvilket modifikationen ikke ændrer på. At køen også
er længere ved station 4 end 1 skyldes stadig setuptiderne, for selvom antallet
af enheder, der skal gennem setup, er stærkt reduceret, er der dog stadig tale
om et stort antal enheder, som skal igennem setup.

Kapitel 3
Analyse og konklusion
3.1 Mulige forbedringer
Som den oprindelige model fungerer, sendes forholdsvist mange enheder ud
af den fjerde linje, inden de forarbejdes, fordi denne linje ikke kan følge med,
i forhold til hvor hurtigt enhederne kommer ud fra de tidligere linjer. For at
mindske antallet af enheder, der smides ud, er det derfor nødvendigt at se
på ændringer, der kan afhjælpe dette problem. Da linjen består af to transportbånd,
(IC) og (C), og otte arbejdsstationer, er det disse steder, vi skal
forsøge at lave forbedringer. På transportbåndene er der to ting, der kan ændres
på, som muligvis vil kunne hjælpe. For det første vil der blive smidt færre
elementer ud af systemet, hvis et transportbånd kan indeholde flere enheder.
Dvs. hvis der er plads til flere enheder på (IC) eller (C), vil der skulle smides
færre enheder ud af den fjerde linje, inden de er blevet sendt igennem de
otte arbejdsstationer. Ligeledes kunne en forøgelse af hastigheden, som de to
transportbånd kører med, være en løsning på problemet, da det med sådan en
ændring ville være hurtigere at fragte en enhed mellem arbejdsstationerne, og
den samlede tid pr. enhed på den fjerde linje ville derfor kunne mindskes.
Forbedringer på arbejdsstationerne skal kunne gøre det hurtigere for et
element at blive behandlet på den enkelte arbejdsstation. Da vi antager, at
det ikke er muligt at forkorte proces- og setuptiderne, er den eneste mulighed
for at forkorte tiden i en arbejdsstation at få færrest mulige elementer igennem
setuptiden. I modifikation 2 laves der en model, der netop gør dette ved at
gruppere enhederne således, at der fx kommer fem elementer af samme type i
træk, og det sikres derved, at de fire af dem ikke skal igennem setup.
Naturligvis kunne mange andre muligheder undersøges, fx kunne en løsning
også være at have forskellige maskiner til hver type ved alle arbejdsstationer,
det kunne måske hjælpe at indsætte flere transportbånd igennem systemet,
ændre på hvordan (IC) fungerer og længden af den eller lign., men da vi ikke
kan vide, om det er fysisk muligt at lave sådanne udvidelser, og heller ikke
har mulighed for at vurdere, hvad omkostningerne ved disse udvidelser ville
19

20 Kapitel 3. Analyse og konklusion
være, undersøger vi blot de to modifikationer, der er foreslået, og hvorom vi
har fået data.
Hvilken en af modifikationerne, der bedst kan betale sig, og om det er en
kombination af ændringerne, der er den bedste løsning kommer naturligvis an
på, om det er arbejdsstationerne eller transportbåndet, der er hovedårsagen
til flaskehalsen, eller om det er en kombination. Dette vil vi analysere i det
følgende. Det er dog værd at bemærke, at denne undersøgelse af forbedringer
af modellen kun koncentrerer sig om minimering af „Total lost cost“ som
performancemål, og tager derfor ikke nødvendigvis hensyn til at fx antallet af
enheder, der forlader systemet, kunne forringes.
I den oprindelige model, svarende til SM Electronics, som virksomheden
ser ud nu, har vi, bl.a. vha. vores record moduler i output fra Arena, antallet
af enheder, der bliver smidt ud af det fjerde system om ugen, fordelt på de tre
typer. Vi har omkostningen ved disse og den samlede omkostning ved disse
„lost parts“ pr. uge, og det er denne samlede omkostning, vi bruger som mål
for, om en ændring forbedrer systemet så meget, at det kan betale sig at
investere.
Som SM Electronics fungerer nu, sendes der samlet omkring 2800 elementer
ud af den fjerde linje pr. uge, svarende til en omkostning på lidt mere end
$2000. Det betyder at ca. 4500 færdige enheder kommer ud af systemet i
løbet af en uge.
3.2 Modifikation 1
For at se på modifikation 1, har vi vha. (PAN) kørt vores grundmodel, hvor
variablen NrOfEntities har værdierne hhv. 40, 45, 50, 55, 60, 65 og 72. Dette
svarer til ændringen af modellen, hvor der er tilføjet 0, 5, 10, 15, 20, 25 eller
32 palletter til transportbåndet, hvilket betyder, at det nu er muligt at have
flere enheder på båndet ad gangen. I øvrigt bemærkes at 72 er en øvre grænse
for antallet af elementer der kan være på (C), da transportbåndets samlede
længde er
16 · 8 + 2 · 8 = 144
og én enhed optager 2 fods plads. De 16 er antal fod mellem hver arbejdsstation,
mens de 2 er det antal fod en arbejdsstation optager.
Som det ses i figur 3.1 på modstående side er Total lost cost stort set
konstant ligegyldigt, hvilken værdi NrOfEntities antager. Derfor kan det klart
konkluderes, at det ikke kan betale sig at tilføje flere palletter på (C), da der
er forbundet en ganske stor omkostning ved dette, men ingen fortjeneste.
Ved at se på køtiderne i outputtet for grundmodellen ses det, at der især er
to steder, hvor der samles kø, Queue for load point og Seize Work Station 4. At
der samles kø inden en arbejdsstation, kan denne modifikation naturligvis ikke
ændre på. Den anden kø, er en kø til at blive læsset op på transportbåndet.
Denne kø vil heller ikke blive forkortet, men nærmere forlænget ved denne

3.3. Modifikation 2 21
Figur 3.1: PAN
ændring, fordi flere enheder vil blive sendt videre i systemet på (IC), men det
ikke vil gå hurtigere med at læsse dem på transportbåndet, da transportbåndet
ikke kører hurtigere eller pålæsningstiden ikke forkortes. Alt i alt vil ændringen
fra grundmodellen til denne model, hvor der er plads til flere elementer på
(C), kun betyde at der vil sendes få, svarende til det antal ekstra, der kan
være på båndet, videre igennem den fjerde linje, men tiden igennem systemet
vil ikke blive forkortet, og derfor vil der blot være flere ufærdige enheder
på transportbåndet, når arbejdsdagen slutter. Dette vil betyde, at der ville
være en lille forbedring i den tabte omkostning, hvis systemet startede tomt,
svarende til, at der i starten ville sendes flere enheder ind i systemet, men reelt
svarer det bare til at tage nogle enheder fra i systemet, når de ellers skulle
kasseres, og undlade at tælle denne tabte omkostning med. Men da systemet
aldrig kører tomt, hvilket vi, som nævnt i afsnit 2.7 på side 13, modellerer ved
en opvarmningsperiode, der sikrer, at systemet er på sit normale niveau, når
vi begynder at samle data, sker dette aldrig, og dermed vil end ikke lost cost
kunne forbedres ved at have flere palletter.
Denne modifikation vil altså betyde, at der kører flere halvfærdige enheder
rundt i systemet. Samtidig vil den tid, det tager en enhed at komme igennem
systemet, forlænges, og der vil ikke blive færdiggjort flere enheder. Da systemet
aldrig kører tomt, vil denne ændring derfor ikke hjælpe til at færre enheder
smides ud inden (IC), og det vil naturligvis ikke kunne betale sig at investere
i noget, som ikke giver anledning til en forbedring.
3.3 Modifikation 2
Som tidligere nævnt har vi lavet en modifikation, som skal gøre, at vi mindsker
setuptiden på vores arbejdsstationer. Dette kommer ud på, at vi har lavet tre
buffer conveyors, som de forskellige typer kommer op på inden de når til (IC).
Yderligere sker der det, at hver type af ankomster bliver samlet i en gruppe,
inden de kommer op på (IC). Hvad dette har af betydning for den økonomiske
side af modellen, skal vi komme tilbage til senere. Antallet, der skal være i

22 Kapitel 3. Analyse og konklusion
hver gruppering, styrer vi ved hjælp af en variabel, „Batch size“, der som
udgangspunkt antager værdien 5. Vi kan så vha. (PAN) undersøge forskellige
størrelser af denne Batch size, hvilket også fremgår af figur 3.2. Når vi har
Figur 3.2: PAN
en Batch size på 1, svarer det selvfølgelig til tilfældet, hvor vi ikke har nogen
buffer conveyors, dog med den forskel, at der er lidt transporttid på disse
bånd. Som det fremgår arbejder vi også med størrelserne 2, 5, 7 og 10. Der
er en naturlig grænse på 10 for hvor mange ankomster, man kan gruppere, da
der, jvf. appendix „Contest Problem 9: SM Electronics“ på side 35, er plads
til netop 10 ankomster på vores buffer conveyors.
Lad os nu tage et kig på besparelserne ved disse grupperinger. Det første,
vi kan bemærke, er, at man, ved at vælge Batch size til 5, faktisk mere
end halverer „Total Lost Cost“, hvilket må siges at være noget af en forbedring.
Vi ser også at ved yderligere at ændre batch size til 10, opnår vi en
Total Lost Cost på 681.758. Disse tal skal selvfølgelig sættes i forhold til den
investering, man skal lave for at opnå disse besparelser, men mere om det
senere. Først vil vi nemlig lige prøve at give en forklaring på, hvorfor vi opnår
disse store besparelser, i modsætning til den første modifikation beskrevet i
afsnit 3.2 på side 20. Kodeordet i den sammenhæng er setuptid. Den helt store
fordel ved denne løsningsmodel er nemlig, at der kommer mange færre enheder
gennem setuptid. Hvor mange enheder af samme type, der kommer efter
hinanden, afhænger naturligvis af, hvor mange enheder, der kommer ind i systemet,
men dette kan være op til så mange enheder som Batch size er sat til,
hvilket vil betyde, at enhederne kun skal gennem setuptid 1/(Batch size) af
gangene. Dette, har vores kørsler vist, gør, at båndene sjældnere bliver fyldt,
og dermed mindskes vores lost cost. Ydermere er det med til at underbygge
vores endelige konklusion, om at virksomhedens flaskehals i virkeligheden ikke
er transportbåndene, men derimod arbejdsstationerne, eller mere specifikt
setuptiden på de automatiserede arbejdsstationer.
Indtil nu har vi beskrevet denne løsning, som værende helt fantastisk,
men i virkeligheden nytter det jo ikke noget, hvis investeringen, der sikrer
den lavere lost cost, er alt for omkostningsfyldt. Derfor vil vi nu tage denne
problemstilling op til overvejelse. Som bekendt er omkostningen ved at anlægge
disse nye buffer conveyors $56.000, og vi har en ugentlig besparelse på

3.4. Kombinationer af modifikation 1 og 2 23
2097.12 1 − 1009.757 = $1087.363 i tilfældet, hvor Batch size er 5. Spørgsmålet
er nu hvor lang tid, der går, før investeringen er tjent hjem. 2 Her bruger vi
selvfølgelig annuitetsformlen
og isolerer n. Udregningerne ser således ud
P V = A 1
(1 − ) (3.1)
r (1 + r) n
1087.363
1
(1 −
) = 56000
0.0005686 (1.0005686) n
1
1 −
= 0.02928
(1.0005686) n
1
= 0.9707166788
(1.0005686) n
1.0005686 n = 1.0301667
log 1.0301667
n =
log 1.0005686
n = 52.2847
Det vil altså sige, at det tager lidt mere end 52 uger, før investeringen er tjent
hjem. Så umiddelbart ser det ud til at være en rigtig fornuftig investering,
men hvorfor restringere sig til en batch size på 5? Som udgangspunkt er omkostningen
ved investeringen fast, uanset de indstillinger der skal til for at
bestemme Batch size. Dette betyder i realiteten, at man bør udnytte kapaciteten
til fulde, dvs. sætte Batch size til 10 for at udnytte systemet bedst
muligt. Ser vi nu på dette tilfælde, vil man opnå en ugentlig besparelse på
2097.12 − 681.758 = $1415.362. Selvfølgelig kunne man godt argumentere for,
at der ville komme andre ting i spil ved en øget Batch size. Fx kunne man
forestille sig, at antallet af fejl på transportbåndet stiger med Batch size, men
dette kan vi dog ikke tage hensyn til uden at lave en masse antagelser.
3.4 Kombinationer af modifikation 1 og 2
Ud fra den tidligere diskussion ses det, at virksomheden skal investere i modifikation
2. Vi vil nu se, om det kan betale sig at lave en kombination af de
to modifikationer, og vi ser derfor på, om modifikation 1 kan betale sig, givet
vi har investeret i modifikation 2.
Ligesom ved modifikation 1, forventede vi, at der ikke ville blive tale om
nogen besparelse ved at tilføje flere palletter, fordi vi, som forklaret i afsnit 3.2
på side 20, ikke får et system, der er hurtigere, og ændringen derfor kun
betyder, at der befinder sig flere ufærdige enheder inde i systemet.
1 jvf. appendix „Output fra grundmodel“ på side 35
2 For en diskussion af dette, se afsnit 3.4

24 Kapitel 3. Analyse og konklusion
Figur 3.3: PAN
Da det i modifikation 2 var så klart, at det optimale altid ville være at lade
Batch size være 10, jvf. afsnit 3.3 på side 21, havde vi egentlig blot tænkt os
at se på dette tilfælde. Men da det ud fra (PAN) ikke var fuldstændig oplagt
at se, om ændringer i NrOfEntities ikke havde nogen effekt, har vi alligevel
valgt at lave kørsler for flere forskellige værdier af Batch size. Dette har vi
gjort for at få et mere generelt overblik over, hvordan Total lost cost ændres
for forskelligt antal palletter på (C). Selvom der i figur 3.3 ses noget større
spredning af Total lost cost er der ikke noget, der tyder på en generel tendens
til at Total lost cost falder, når værdien af NrOfEntities stiger.
Skulle begge investeringer gennemføres ville det, som forklaret i afsnit 3.3
på side 21, og som det også tydeligt fremgår af figur 3.3, klart være optimalt
at lade Batch size være 10. Givet denne værdi er den største besparelse, der
kan opnås $13.6 pr. uge, svarende til at investere i alle 32 mulige palletter.
For at ligning 3.1 på forrige side har en løsning, skal der gælde
P V · r
A
≤ 1

3.5. Konklusion 25
Dette betyder med en årlig rente på 3%, at nutidsværdien af investeringen
ikke kan blive større end
13.6
= $23918.4
0.0005686
Dette er lavere end omkostningen ved at få tre palletter mere på (C), og det
er derfor tydeligt, at det ikke kan betale sig at investere i en kombination af
modifikation 1 og 2.
Vi har valgt at vurdere investeringerne, ved at se på hvor mange år der
skal gå, før nutidsværdien af vores besparelse er lige så stor som prisen på
investeringen. Denne løsning tager naturligvis ikke hensyn til afskrivninger
og lign., men for at undgå at skulle lave antagelser, som vi egentlig ikke har
noget hold i, har vi alligevel valgt denne løsning. Denne metode kan godt
bruges til at afgøre, om en enkelt investering kan betale sig, men er ikke god
til sammenligning af alternativer, og da vi direkte kan afvise modifikation 1 og
en kombination af 1 og 2, vha. denne metode, kommer vi ikke ud i problemer,
hvor vi skal sammenligne hvilken investering, der er bedst.
3.5 Konklusion
Vi har i det foregående lavet en simulation af SM Electronics, hvor vi har
betragtet fire scenarier; virksomhedens nuværende setup, to modifikationer
samt en kombination af de to. Vha. Arena har vi lavet ændringer i, hvordan
virksomheden fungerer nu, først ved at ændre på antallet af enheder, der kan
være inde i systemet, og dernæst ved at lave ændringer, så enhederne grupperes
efter deres type og dermed hurtigere kan blive behandlet på de forskellige
arbejdsstationer. På baggrund af kørsler af de forskellige modifikationer har
vi således kunnet se på den tabte omkostning, der opstår, fordi en enhed smides
ud af linjen, hvis der er for mange elementer i det videre system. Det er
denne omkostning, vi har forsøgt at minimere ved at se på disse ændringer.
Ved at observere vores grundmodel kunne vi se, at det er i arbejdsstationerne,
der opstår flaskehalse, og ikke pga. transportbåndene. Især kunne vi se,
at arbejdsstation 8 og 4 giver anledning til kø, og allerede her kunne man
derfor forudsige, at modifikation 1 ikke vil have nogen mærkbar effekt. På
trods af dette gennemgik vi selvfølgelig modifikationen med et resultat som
forventet; ingen ugentlig besparelse. Dette kunne vi klart afvise som en dårlig
investering og dermed yderligere forstærke vores opfattelse af, at det ikke var
transportbåndet, der var årsag til flaskehalsen.
I modifikation 2 ændrede vi systemet sådan, at enhederne blev grupperet
efter deres type, og dermed undgik vi at så mange enheder skulle sendes gennem
setup ved de automatiserede arbejdsstationer. Dette havde som forventet
stor effekt, netop fordi tiden i arbejdsstationerne blev nedsat kraftigt. Her viste
vores beregninger, at investeringen var yderst fordelagtig. Vi diskuterede
også, i hvor store mængder vi skulle gruppere elementerne, inden de sendtes

26 Kapitel 3. Analyse og konklusion
videre i systemet. Konklusionen var her, at man blot skulle benytte den fulde
kapacitet på ti. Dette var dog set i det perspektiv, at der ikke var nogen ekstra
omkostning forbundet med større Batch size, hvilket vi også satte spørgsmålstegn
ved troværdigheden af. Dog endte vi med at tage opgavebeskrivelsens
oplysninger for gode varer.
Et sidste forsøg på at minimere de tabte omkostninger, blev gjort ved
først at antage modifikation 2 gennemført, og derefter se på modifikation 1
gennemført i denne nye modificerede model. Vi valgte den antagelse, da der
ikke kunne være nogen som helst tvivl om, at modifikation 2 skulle være en
del af den endelige ændring af systemet. Vi brugte denne gang (PAN) til vores
undersøgelser. Vi havde ikke de store forventninger, og det viste sig da også,
selvom det ikke var lige så tydeligt som i vurderingen af modifikation 1 alene,
at der ikke var tale om en besparelse, der kunne opveje omkostningen ved
investeringen. Alt i alt nåede vi frem til, at det mest rentable udfald blev
opnået ved udelukkende at benytte modifikation 2 med en Batch size på ti.

Appendices
27

Contest Problem 9: SM
Electronics
29

CONTEST PROBLEM 9
IIE/RA Contest Problems
IIE/RA CONTEST PROBLEMS
B.9 Ninth Annual Contest: SM Electronics
SM Electronics is a small manufacturer that produces electronic parts used by a variety of
other manufacturers. Recently, we noticed problems in a department that produces three
different parts. The demand mix for these three products has changed slowly over time.
The department is almost fully automated and consists of four lines. Each of the first three
lines produces a single product and they have all been modified over time to meet the
current demand mix. When the almost-finished parts (Parts A, B, and C) exit these three
lines, they all enter the fourth line where the final operations are performed for all product
types. The new product mix has caused the fourth line to become a bottleneck.
SM Electronics employed several consultants to collect data and recommend modifications
to this line. Although we’ve received sufficient information to proceed with the
modifications, the actual performance after the modifications are implemented is in
question. Two different approaches were suggested. At this time, it’s not clear which
approach would provide the best results. It’s also possible that both suggested modifications
may be required in order to achieve the desired performance. In light of this uncertainty,
we are initiating this request for recommendations.
You are asked to evaluate the current design and propose the configuration(s) that
will result in approximately minimizing operating cost while still achieving the desired
performance levels. With this in mind, this document describes the current system and
presents the two different modifications that have been proposed, as well as including
data where they are available.
Your analysis should concentrate on the fourth line, and a schematic of it is shown.
We do not anticipate a need to change the first three lines, so we will give you only
limited information on them.
Parts A, B, and C enter the fourth line on the left. Since the lines that produce these
parts are fully automated, their arrival rates are very predictable. The normal arrivals for
the three parts are: Part A, every 2.8 minutes; Part B, every 1.4 minutes; and Part C,
every 2.0 minutes. There are occasional jams on these lines, which can cause slight
delays in part arrivals. The collected data show that delays occur 2%, 1.75%, and 0.5% of
the time on Lines A, B, and C, respectively. The data for these delays have been analyzed
and triangular distributions have been fitted to the data. The parameters for these
distributions are (5,15,60), (5,20,55), and (5,20,65) for Lines A, B, and C, respectively.
Note that the time units for these parameters are in seconds.
IIE_RA_9.pmd 1
5/30/2006, 12:19 PM
1

2 IIE/RA CONTEST PROBLEMS
Part A Line
Part B Line
Part C Line
7 6 5 4
8 1 2 3
Finished Parts
The arriving parts are merged (in the order in which they arrive) onto a single input
conveyor, which feeds the fourth and final system. The input conveyor from the merge
point to where the parts enter the fourth system has room for 40 parts. If this input
conveyor becomes full and a new part attempts to merge onto the conveyor, then the line
producing that part temporarily shuts down until space becomes available. Currently,
there are numerous shutdowns during each day. For analysis purposes, you can assume
that if a part arrives and the input conveyor is full, that part is considered to be lost
production. The cost for a lost part is $0.89, $0.63, and $0.72 for Parts A, B, and C,
respectively.
The fourth system consists of eight work cells connected by a power-and-free
conveyor. The distance between each work cell is 18 feet. When a new part enters the
system from the input conveyor at Work Cell 8, it must wait for a special pallet that will
hold the part as it travels through the system. Presently, there are 40 pallets in the system,
each requiring 2 feet of space. Thus, there is room for eight pallets between each pair of
successive work cells (16 feet of buffer space and 2 feet for the work cell). The travel
time between work cells (18 feet) is 15 seconds.
When both a pallet and a new part are available at Work Cell 8, the finished part is first
removed from the pallet, and then the new part is loaded. This unload/load process is fully
automated and takes 25 seconds. A jam occurs approximately 1% of the time, requiring
additional time. The time to respond to a jam follows a triangular distribution with
parameters (5,15,75). These parameters are expressed in seconds. Once the unload/load
process is complete, the pallet moves to the buffer area in front of Work Cell 1. If there is
no room in the buffer area, the pallet remains at the unload/load work cell until room
becomes available. In effect, the waiting loaded pallet blocks the unload/load work cell.
The new part moves through the system where an operation is performed at each of
the remaining seven work cells. Work Cells 1, 3, 4, 5, and 6 are automated operations.
Work Cells 2 and 7 are manual operations.
When a pallet enters an automated work cell, a scanner reads the part type on that
pallet. If the part type is different from the last part type at that work cell, the work cell
must undergo a setup. The required setup time is dependent only on the new part type.
These setup times (in seconds) are given in the table below.
IIE_RA_9.pmd 2
5/30/2006, 12:19 PM

IIE/RA CONTEST PROBLEMS
Arriving
Part Type Work Cell 1 Work Cell 3 Work Cell 4 Work Cell 5 Work Cell 6
Part A 25 52 35 29 11
Part B 20 21 22 14 19
Part C 17 34 24 37 17
For example, if a Part B arrives at Work Cell 1 and the previous part at that work cell
was either an A or C, then a 20-second setup is required. If the previous part was a B,
then no setup is required.
The operation or process time at the automated work cells is also part dependent.
These operation times (in seconds) are given in the following table. For example, a Part B
at Work Cell 4 requires a 38-second operation time.
Part Type Work Cell 1 Work Cell 3 Work Cell 4 Work Cell 5 Work Cell 6
Part A 37 39 41 33 31
Part B 46 27 38 41 24
Part C 39 23 47 35 51
The operation or process times at the two manual work cells follow triangular
distributions with the parameters given, in seconds. No setup is required at the manual
work cells.
Part Type Work Cell 2 Work Cell 7
Part A 36,45,52 27,35,41
Part B 21,32,39 31,39,43
Part C 32,36,42 22,27,38
Based on our observations, we feel that you can safely assume that no jams or failures
occur at Work Cells 1 through 7.
The factory is currently working two shifts, a 16-hour production day, five days a
week. The lines are shut down at the end of each day, leaving the incomplete parts in the
system, and they are restarted at the beginning of the next working day.
Although casual observations by the consultants and our production engineers
indicate that our lost production cost is high, we are not able to place a dollar value on
that loss. Thus, the first question we would like you to address is: What is the cost of lost
production for our current system? Please provide this as a weekly cost.
We would then like you to evaluate the two proposed modifications to see if they
make economic sense. The first proposed modification requires that we add pallets to the
existing fourth system. Since the current control logic for that system was developed
specifically for 40 pallets, that logic must be modified. The fixed cost for this
modification is $17,000. This cost is incurred even if only one pallet is added. In
addition, there is an incremental cost of $3,000 for each pallet added.
IIE_RA_9.pmd 3
5/30/2006, 12:19 PM
3

4 IIE/RA CONTEST PROBLEMS
The second proposed modification requires that we insert additional space for
incoming parts by adding three new buffer conveyors. The amount of additional storage
is limited, based on available space. The current available space would allow three buffer
conveyors to be added at the incoming merge point, one conveyor for each part type.
Each of these conveyors would have space for an additional ten parts. The concept is that
each of the first three lines would insert their parts into their own buffer conveyor
(limited to ten parts on each conveyor). Logic would then be developed that would allow
these parts to be released in batches to the existing buffer conveyor (limited to 40 parts).
For example, you might release in batches of five. When these batches of five (all the
same part) are processed by the final system, there would be only one setup at each of the
automated operations at the start of the batch. We have already priced this option with a
conveyor manufacturer. The cost to implement this modification is $56,000. This cost
includes the equipment cost, installation cost, and the development of whatever release
logic is required.
SM Electronics requests that during your analysis you evaluate and answer the
following questions:
1. What is the cost of lost production for our current system?
2. What is the cost savings, if any, resulting from the implementation of the first
proposed modification?
� How many additional pallets should be added?
3. What is the cost savings, if any, resulting from the implementation of the second
proposed modification?
� Include a detailed description of your proposed release logic.
4. Should we implement both of the proposed modifications?
Please provide all cost comparisons in dollars per week. Your report should include a
recommendation for the most cost-effective system. Your analysis may reveal that neither
of the two options should be considered.
We are currently occupied by other activities and will not require a solution until
early April. Since there are several groups competing for this contract, we have decided
that we will not provide additional information during the analysis period. However, you
are encouraged to make additional reasonable, documented assumptions. We look
forward to receiving your report in April and reviewing your proposed solution.
IIE_RA_9.pmd 4
5/30/2006, 12:19 PM

Output fra grundmodel
35

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
System
Average
Number Out 7,517
Values Across All Replications
Key Performance Indicators
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 1 of 11

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Conveyor
Usage
Values Across All Replications
Blocked Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Conveyor 0.4041
0,00 0.3965 0.4086 0.00 1.0000
Input Conveyor 0.00
0,00 0.00 0.00 0.00 0.00
Utilization Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Conveyor 0.04378898
0,00 0.04282192 0.04432481 0.00 0.1806
Input Conveyor 0.01330404
0,00 0.01305691 0.01342110 0.00 0.03750000
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 2 of 11

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Entity
Time
Values Across All Replications
VA Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 0.9670
0,01 0.8575 1.0911 0.00 3.0040
Part B 1.0071
0,01 0.9105 1.0529 0.00 2.8038
Part C 0.9135
0,01 0.8661 0.9548 0.00 2.8785
NVA Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 0.00
0,00 0.00 0.00 0.00 0.00
Part B 0.00
0,00 0.00 0.00 0.00 0.00
Part C 0.00
0,00 0.00 0.00 0.00 0.00
Wait Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 40.2441
0,65 35.3891 46.2952 0.00 81.2402
Part B 47.2050
0,33 43.6137 48.7974 0.00 83.6583
Part C 43.7199
0,26 41.1690 45.6697 0.00 82.2126
Transfer Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 2.2339
0,03 1.9873 2.5100 0.00 6.2050
Part B 2.5645
0,02 2.3122 2.6805 0.00 6.6809
Part C 2.3882
0,01 2.2773 2.5117 0.00 6.6990
Other Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 3.0922
0,05 2.7457 3.4873 0.00 5.5500
Part B 2.5902
0,02 2.3829 2.6869 0.00 4.5333
Part C 3.1320
0,02 2.9674 3.2609 0.00 5.4000
Total Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 46.5372
0,74 40.9796 53.3835 0.00 92.7234
Part B 53.3669
0,38 49.2193 55.2177 0.00 92.2647
Part C
Other
50.1536
0,29 47.2798 52.3615 0.00 92.1767
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 3 of 11

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Entity
Other
Values Across All Replications
Number In Minimum Maximum
Average Half Width Average Average
Part A 1708.80 0,30 1707.00 1711.00
Part B 3410.04 0,68 3405.00 3415.00
Part C 2397.60 0,26 2396.00 2400.00
3600,000
3400,000
3200,000
3000,000
2800,000
2600,000
2400,000
2200,000
2000,000
1800,000
1600,000
Number Out Minimum Maximum
Average Half Width Average Average
Part A 1709.90 1,85 1697.00 1722.00
Part B 3408.52 2,13 3393.00 3425.00
Part C 2398.08 1,23 2389.00 2409.00
WIP Minimum Maximum
Average Half Width Average Average
Minimum
Value
Part A
Part B
Part C
Maximum
Value
Part A 16.5554
0,27 14.6211 19.0088 2.0000 30.0000
Part B 37.9062
0,27 34.9322 39.2276 21.0000 55.0000
Part C 25.0426
0,14 23.6132 26.1357 10.0000 38.0000
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 4 of 11

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Process
Time per Entity
Values Across All Replications
VA Time Per Entity Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Process 2 0.5899
0,00 0.5859 0.5977 0.3506 0.8662
Process 7 0.5708
0,00 0.5676 0.5729 0.3673 0.7165
Wait Time Per Entity Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Process 2 0.01075151
0,00 0.00950411 0.01244499 0.00 1.0080
Process 7 0.07579734
0,00 0.06733613 0.08117324 0.00 1.2599
Total Time Per Entity Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Process 2 0.6007
0,00 0.5966 0.6083 0.3506 1.5228
Process 7
Accumulated Time
0.6466
0,00 0.6350 0.6529 0.3673 1.8689
Accum VA Time Minimum Maximum
Average Half Width Average Average
Process 2 2719.11 2,00 2701.91 2731.94
Process 7 2624.63 5,43 2561.67 2650.68
2720,000
2700,000
2680,000
2660,000
2640,000
2620,000
Process 2
Process 7
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 5 of 11

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Process
Accumulated Time
Values Across All Replications
Accum Wait Time Minimum Maximum
Average Half Width Average Average
Process 2 49.5580 0,94 43.9470 57.4585
Process 7 348.57 4,65 303.89 375.86
Other
360,000
320,000
280,000
240,000
200,000
160,000
120,000
80,000
40,000
Number In Minimum Maximum
Average Half Width Average Average
Process 2 4609.36 7,33 4524.00 4649.00
Process 7 4598.02 7,34 4514.00 4639.00
4610,000
4608,000
4606,000
4604,000
4602,000
4600,000
4598,000
Number Out Minimum Maximum
Average Half Width Average Average
Process 2 4609.36 7,31 4525.00 4649.00
Process 7 4597.86 7,35 4513.00 4640.00
Process 2
Process 7
Process 2
Process 7
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 6 of 11

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Queue
Time
Values Across All Replications
Waiting Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Leave Work Station 1.Queue 0.00358265
0,00 0.00332983 0.00386060 0.00 0.7675
Leave Work Station 2.Queue 0.00421123
0,00 0.00403889 0.00440867 0.00 0.9374
Leave Work Station 3.Queue 0.00362525
0,00 0.00319744 0.00438670 0.00 0.9950
Leave Work Station 4.Queue 0.00341479
0,00 0.00317966 0.00374328 0.00 0.9048
Leave Work Station 5.Queue 0.00341958
0,00 0.00313982 0.00382948 0.00 0.9113
Leave Work Station 6.Queue 0.00406262
0,00 0.00369289 0.00459082 0.00 1.1977
Leave Work Station 7.Queue 0.00458415
0,00 0.00446420 0.00476928 0.00 0.6469
load point.Queue 0.00
0,00 0.00 0.00 0.00 0.00
merge point.Queue 0.00319506
0,00 0.00287445 0.00348787 0.00 0.04131701
Process 2.Queue 0.01075072
0,00 0.00950411 0.01244928 0.00 1.0080
Process 7.Queue 0.07579870
0,00 0.06732121 0.08117324 0.00 1.2599
Queue for load point.Queue 40.1324
0,07 39.7643 40.9238 32.5036 46.6082
Seize work Station 1.Queue 0.7759
0,02 0.6267 0.9987 0.00 14.7529
Seize Work Station 3.Queue 0.5966
0,01 0.5234 0.7219 0.00 6.2905
Seize Work Station 4.Queue 30.7022
0,07 30.3200 31.4282 15.0443 36.9273
Seize Work Station 5.Queue 0.2279
0,00 0.1995 0.2500 0.00 1.9934
Seize Work Station 6.Queue
Other
0.1270
0,00 0.1145 0.1383 0.00 1.6000
Number Waiting Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Leave Work Station 1.Queue 0.00344038
0,00 0.00314107 0.00372415 0.00 1.0000
Leave Work Station 2.Queue 0.00404399
0,00 0.00387137 0.00425412 0.00 1.0000
Leave Work Station 3.Queue 0.00348178
0,00 0.00306421 0.00423957 0.00 2.0000
Leave Work Station 4.Queue 0.00327096
0,00 0.00304188 0.00355846 0.00 2.0000
Leave Work Station 5.Queue 0.00327571
0,00 0.00299591 0.00369146 0.00 2.0000
Leave Work Station 6.Queue 0.00389162
0,00 0.00347209 0.00438040 0.00 2.0000
Leave Work Station 7.Queue 0.00439120
0,00 0.00425351 0.00459937 0.00 1.0000
load point.Queue 0.00
0,00 0.00 0.00 0.00 1.0000
merge point.Queue 0.00306048
0,00 0.00276666 0.00334690 0.00 2.0000
Process 2.Queue 0.01032382
0,00 0.00915562 0.01197465 0.00 2.0000
Process 7.Queue 0.07262165
0,00 0.06330999 0.07828780 0.00 2.0000
Queue for load point.Queue 38.4369
0,00 38.4148 38.4712 35.0000 40.0000
Seize work Station 1.Queue 0.7299
0,02 0.5850 0.9462 0.00 15.0000
Seize Work Station 3.Queue 0.5726
0,01 0.5056 0.6951 0.00 8.0000
Seize Work Station 4.Queue 29.4726
0,03 29.2617 29.7265 14.0000 34.0000
Seize Work Station 5.Queue 0.2184
0,00 0.1887 0.2415 0.00 3.0000
Seize Work Station 6.Queue 0.1217
0,00 0.1084 0.1337 0.00 3.0000
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 7 of 11

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Resource
Usage
Values Across All Replications
Instantaneous Utilization Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Work Station 1 0.9348
0,00 0.9235 0.9401 0.00 1.0000
Work Station 2 0.5665
0,00 0.5629 0.5692 0.00 1.0000
Work Station 3 0.8876
0,00 0.8757 0.9018 0.00 1.0000
Work Station 4 1.0000
0,00 1.0000 1.0000 0.00 1.0000
Work Station 5 0.9343
0,00 0.9274 0.9386 0.00 1.0000
Work Station 6 0.7534
0,00 0.7469 0.7613 0.00 1.0000
Work Station 7 0.5468
0,00 0.5337 0.5522 0.00 1.0000
Number Busy Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Work Station 1 0.9348
0,00 0.9235 0.9401 0.00 1.0000
Work Station 2 0.5665
0,00 0.5629 0.5692 0.00 1.0000
Work Station 3 0.8876
0,00 0.8757 0.9018 0.00 1.0000
Work Station 4 1.0000
0,00 1.0000 1.0000 0.00 1.0000
Work Station 5 0.9343
0,00 0.9274 0.9386 0.00 1.0000
Work Station 6 0.7534
0,00 0.7469 0.7613 0.00 1.0000
Work Station 7 0.5468
0,00 0.5337 0.5522 0.00 1.0000
Number Scheduled Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Work Station 1 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 2 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 3 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 4 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 5 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 6 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 7 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 8 of 11

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Resource
Usage
Values Across All Replications
Scheduled Utilization Minimum Maximum
Average Half Width Average Average
Work Station 1 0.9348 0,00 0.9235 0.9401
Work Station 2 0.5665 0,00 0.5629 0.5692
Work Station 3 0.8876 0,00 0.8757 0.9018
Work Station 4 1.0000 0,00 1.0000 1.0000
Work Station 5 0.9343 0,00 0.9274 0.9386
Work Station 6 0.7534 0,00 0.7469 0.7613
Work Station 7 0.5468 0,00 0.5337 0.5522
1,000
0,950
0,900
0,850
0,800
0,750
0,700
0,650
0,600
0,550
0,500
Total Number Seized Minimum Maximum
Average Half Width Average Average
Work Station 1 4609.20 7,34 4524.00 4649.00
Work Station 2 4609.36 7,33 4524.00 4649.00
Work Station 3 4609.98 7,26 4525.00 4649.00
Work Station 4 4598.00 7,33 4512.00 4638.00
Work Station 5 4598.00 7,35 4513.00 4639.00
Work Station 6 4598.00 7,34 4513.00 4639.00
Work Station 7 4598.04 7,35 4514.00 4640.00
4610,000
4608,000
4606,000
4604,000
4602,000
4600,000
4598,000
Work Station 1
Work Station 2
Work Station 3
Work Station 4
Work Station 5
Work Station 6
Work Station 7
Work Station 1
Work Station 2
Work Station 3
Work Station 4
Work Station 5
Work Station 6
Work Station 7
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 9 of 11

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Station
Other
Values Across All Replications
Number Entities Transferring Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Enter load station.Station 1.0643
0,00 1.0446 1.0737 0.00 3.0000
Enter Work Station 1.Station 0.2130
0,00 0.2091 0.2152 0.00 2.0000
Enter Work Station 2.Station 0.3794
0,00 0.3659 0.3865 0.00 3.0000
Enter Work Station 3.Station 0.4002
0,00 0.3934 0.4059 0.00 2.0000
Enter Work Station 4.Station 0.3831
0,00 0.3722 0.3885 0.00 4.0000
Enter Work Station 5.Station 0.3788
0,00 0.3655 0.3882 0.00 3.0000
Enter Work Station 6.Station 0.3798
0,00 0.3710 0.3879 0.00 3.0000
Enter Work Station 7.Station 0.3872
0,00 0.3799 0.3922 0.00 3.0000
Exit conveyor.Station 0.2272
0,00 0.2225 0.2308 0.00 2.0000
Leaving load station 0.00
0,00 0.00 0.00 0.00 0.00
Leaving unload station 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 1 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 2 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 3 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 4 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 5 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 6 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 7 0.00
0,00 0.00 0.00 0.00 0.00
merge station 0.00
0,00 0.00 0.00 0.00 0.00
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 10 of 11

Category Overview
13:45:22 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
User Specified
Counter
Values Across All Replications
Count Minimum Maximum
Average Half Width Average Average
Record Part A lost parts 756.28 14,03 635.00 862.00
Record Part B lost parts 1208.86 18,95 1114.00 1417.00
Record Part C lost parts 953.46
8,57 889.00 1031.00
1250,000
1200,000
1150,000
1100,000
1050,000
1000,000
950,000
900,000
850,000
800,000
750,000
Time Persistent
Variable Minimum Maximum
Average Half Width Average Average
Record Part A lost parts
Record Part B lost parts
Record Part C lost parts
Minimum
Value
Maximum
Value
cost counter 0.00
0,00 0.00 0.00 0.00 0.00
Entity Counter
Output
1.0674
0,00 1.0475 1.0768 0.00 3.0000
Output Minimum Maximum
Average Half Width Average Average
Lost Cost A 673.09 12,49 565.15 767.18
Lost Cost B 761.58 11,94 701.82 892.71
Lost Cost C 686.49 6,17 640.08 742.32
Total Lost Cost 2121.16 2,08 2107.21 2141.86
2200,000
2000,000
1800,000
1600,000
1400,000
1200,000
1000,000
800,000
600,000
Lost Cost A
Lost Cost B
Lost Cost C
Total Lost Cost
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\bachelor endelig
Page 11 of 11

Output fra modifikation
49

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
System
Average
Number Out 7,516
Values Across All Replications
Key Performance Indicators
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 1 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Conveyor
Usage
Values Across All Replications
Blocked Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Buffer A 0.00
0,00 0.00 0.00 0.00 0.00
Buffer B 0.00
0,00 0.00 0.00 0.00 0.00
Buffer C 0.00
0,00 0.00 0.00 0.00 0.00
Conveyor 0.5353
0,00 0.5328 0.5383 0.00 1.0000
Input Conveyor 0.00
0,00 0.00 0.00 0.00 0.00
Utilization Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Buffer A 0.00494444
0,00 0.00493924 0.00495082 0.00 0.05000000
Buffer B 0.00986701
0,00 0.00985243 0.00988137 0.00 0.05000000
Buffer C 0.00693736
0,00 0.00693287 0.00694198 0.00 0.05000000
Conveyor 0.06434975
0,00 0.06386248 0.06478937 0.00 0.2222
Input Conveyor 0.01760920
0,00 0.01754629 0.01766558 0.00 0.1500
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 2 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Entity
Time
Values Across All Replications
VA Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 1.3501
0,02 1.2034 1.5541 0.00 2.9758
Part B 1.2987
0,01 1.2003 1.3698 0.00 2.8585
Part C 1.2151
0,00 1.1829 1.2500 0.00 2.7625
NVA Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 0.00
0,00 0.00 0.00 0.00 0.00
Part B 0.00
0,00 0.00 0.00 0.00 0.00
Part C 0.00
0,00 0.00 0.00 0.00 0.00
Wait Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 44.9924
0,67 40.7359 50.8752 0.00 64.7568
Part B 45.1621
0,33 42.2437 47.3467 0.00 60.4259
Part C 44.6981
0,16 43.7588 45.8212 0.00 62.0937
Transfer Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 3.8212
0,06 3.4535 4.3417 0.2775 7.6343
Part B 3.8194
0,03 3.5441 4.0117 0.2775 7.9871
Part C 3.7348
0,01 3.6367 3.8360 0.2775 7.7887
Other Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 2.8451
0,04 2.5825 3.2083 0.00 5.5500
Part B 2.7068
0,02 2.5201 2.8404 0.00 4.5333
Part C 3.0209
0,01 2.9568 3.1004 0.00 5.4000
Total Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Part A 53.0088
0,80 47.9752 59.9794 0.2775 76.0037
Part B 52.9870
0,39 49.5082 55.5439 0.2775 70.5745
Part C
Other
52.6689
0,19 51.5419 53.9931 0.2775 72.4180
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 3 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Entity
Other
Values Across All Replications
Number In Minimum Maximum
Average Half Width Average Average
# Batches 1502.90 0,22 1501.00 1504.00
Part A 1708.80 0,30 1707.00 1711.00
Part B 3410.04 0,68 3405.00 3415.00
Part C 2397.60 0,26 2396.00 2400.00
3600,000
3200,000
2800,000
2400,000
2000,000
1600,000
1200,000
Number Out Minimum Maximum
Average Half Width Average Average
# Batches 1502.90 0,22 1501.00 1504.00
Part A 1711.66 1,26 1705.00 1720.00
Part B 3406.32 1,32 3398.00 3416.00
Part C 2398.46 0,77 2393.00 2404.00
WIP Minimum Maximum
Average Half Width Average Average
Minimum
Value
# Batches
Part A
Part B
Part C
Maximum
Value
# Batches 0.00
0,00 0.00 0.00 0.00 1.0000
Part A 18.8992
0,29 17.0829 21.3689 7.0000 27.0000
Part B 37.6496
0,28 35.2405 39.4182 26.0000 48.0000
Part C 26.3160
0,09 25.7414 26.9623 17.0000 35.0000
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 4 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Process
Time per Entity
Values Across All Replications
VA Time Per Entity Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Process 2 0.5927
0,00 0.5872 0.6009 0.3506 0.8662
Process 7 0.5701
0,00 0.5670 0.5720 0.3670 0.7164
Wait Time Per Entity Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Process 2 0.08760054
0,00 0.07767864 0.0951 0.00 1.6388
Process 7 0.2325
0,00 0.2157 0.2469 0.00 2.4015
Total Time Per Entity Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Process 2 0.6803
0,00 0.6649 0.6959 0.3506 2.4330
Process 7
Accumulated Time
0.8025
0,00 0.7844 0.8189 0.3670 3.0287
Accum VA Time Minimum Maximum
Average Half Width Average Average
Process 2 3615.40 4,36 3590.50 3659.87
Process 7 3470.98 3,41 3443.59 3492.72
3620,000
3600,000
3580,000
3560,000
3540,000
3520,000
3500,000
3480,000
3460,000
Process 2
Process 7
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 5 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Process
Accumulated Time
Values Across All Replications
Accum Wait Time Minimum Maximum
Average Half Width Average Average
Process 2 534.33 6,08 475.00 579.64
Process 7 1415.46 14,06 1311.62 1507.34
Other
1600,000
1400,000
1200,000
1000,000
800,000
600,000
400,000
Number In Minimum Maximum
Average Half Width Average Average
Process 2 6100.18 2,64 6075.00 6118.00
Process 7 6089.26 2,60 6065.00 6109.00
6102,000
6100,000
6098,000
6096,000
6094,000
6092,000
6090,000
6088,000
Number Out Minimum Maximum
Average Half Width Average Average
Process 2 6099.84 2,67 6074.00 6118.00
Process 7 6088.70 2,58 6065.00 6106.00
Process 2
Process 7
Process 2
Process 7
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 6 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Queue
Time
Values Across All Replications
Waiting Time Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Batch 2.Queue 3.8317
0,00 3.8281 3.8365 0.00 12.6704
Leave Part A Line.Queue 0.00
0,00 0.00 0.00 0.00 0.00
Leave Part B Line.Queue 0.00
0,00 0.00 0.00 0.00 0.00
Leave Part C Line.Queue 0.00
0,00 0.00 0.00 0.00 0.00
Leave Work Station 1.Queue 0.00366070
0,00 0.00319727 0.00428433 0.00 0.9848
Leave Work Station 2.Queue 0.00436478
0,00 0.00402659 0.00483652 0.00 1.0350
Leave Work Station 3.Queue 0.00383503
0,00 0.00323843 0.00433585 0.00 1.1498
Leave Work Station 4.Queue 0.00378261
0,00 0.00335110 0.00419512 0.00 0.9180
Leave Work Station 5.Queue 0.00343074
0,00 0.00297389 0.00393603 0.00 1.0924
Leave Work Station 6.Queue 0.00457547
0,00 0.00408256 0.00506101 0.00 1.1155
Leave Work Station 7.Queue 0.00338256
0,00 0.00304802 0.00388276 0.00 0.8769
load point.Queue 0.00
0,00 0.00 0.00 0.00 0.00
merge point.Queue 0.05051293
0,00 0.04948186 0.05167219 0.00 0.2493
Process 2.Queue 0.08760294
0,00 0.07767864 0.0951 0.00 1.6388
Process 7.Queue 0.2325
0,00 0.2158 0.2469 0.00 2.4015
Queue for load point.Queue 27.5547
0,03 27.3262 27.7338 21.2845 32.8481
Seize work Station 1.Queue 1.1914
0,07 0.8739 1.8282 0.00 11.4875
Seize Work Station 3.Queue 0.2870
0,00 0.2756 0.3001 0.00 2.3795
Seize Work Station 4.Queue 20.6595
0,07 19.9490 21.0475 8.2181 23.9244
Seize Work Station 5.Queue 0.2709
0,00 0.2565 0.2882 0.00 1.9456
Seize Work Station 6.Queue
Other
0.4297
0,00 0.4153 0.4513 0.00 2.2806
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 7 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Queue
Other
Values Across All Replications
Number Waiting Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Batch 2.Queue 6.0004
0,00 5.9969 6.0038 0.00 13.0000
Leave Part A Line.Queue 0.00
0,00 0.00 0.00 0.00 1.0000
Leave Part B Line.Queue 0.00
0,00 0.00 0.00 0.00 1.0000
Leave Part C Line.Queue 0.00
0,00 0.00 0.00 0.00 1.0000
Leave Work Station 1.Queue 0.00465233
0,00 0.00406919 0.00544200 0.00 2.0000
Leave Work Station 2.Queue 0.00554679
0,00 0.00510622 0.00615649 0.00 1.0000
Leave Work Station 3.Queue 0.00487165
0,00 0.00410471 0.00551285 0.00 2.0000
Leave Work Station 4.Queue 0.00479826
0,00 0.00424054 0.00531819 0.00 2.0000
Leave Work Station 5.Queue 0.00435119
0,00 0.00376879 0.00499137 0.00 2.0000
Leave Work Station 6.Queue 0.00580472
0,00 0.00516359 0.00643908 0.00 2.0000
Leave Work Station 7.Queue 0.00429077
0,00 0.00386781 0.00493272 0.00 2.0000
load point.Queue 0.00
0,00 0.00 0.00 0.00 1.0000
merge point.Queue 0.06405115
0,00 0.06267703 0.06543335 0.00 9.0000
Process 2.Queue 0.1113
0,00 0.0990 0.1208 0.00 3.0000
Process 7.Queue 0.2950
0,00 0.2733 0.3144 0.00 4.0000
Queue for load point.Queue 34.9565
0,03 34.7173 35.1937 27.0000 40.0000
Seize work Station 1.Queue 1.5020
0,08 1.0997 2.3151 0.00 15.0000
Seize Work Station 3.Queue 0.3647
0,00 0.3512 0.3812 0.00 4.0000
Seize Work Station 4.Queue 26.2464
0,09 25.3887 26.6655 10.0000 30.0000
Seize Work Station 5.Queue 0.3436
0,00 0.3253 0.3664 0.00 3.0000
Seize Work Station 6.Queue 0.5449
0,00 0.5267 0.5728 0.00 4.0000
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 8 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Resource
Usage
Values Across All Replications
Instantaneous Utilization Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Work Station 1 0.9820
0,00 0.9734 0.9886 0.00 1.0000
Work Station 2 0.7532
0,00 0.7480 0.7624 0.00 1.0000
Work Station 3 0.7578
0,00 0.7514 0.7661 0.00 1.0000
Work Station 4 1.0000
0,00 1.0000 1.0000 0.00 1.0000
Work Station 5 0.9107
0,00 0.9033 0.9167 0.00 1.0000
Work Station 6 0.7976
0,00 0.7931 0.8015 0.00 1.0000
Work Station 7 0.7231
0,00 0.7175 0.7277 0.00 1.0000
Number Busy Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Work Station 1 0.9820
0,00 0.9734 0.9886 0.00 1.0000
Work Station 2 0.7532
0,00 0.7480 0.7624 0.00 1.0000
Work Station 3 0.7578
0,00 0.7514 0.7661 0.00 1.0000
Work Station 4 1.0000
0,00 1.0000 1.0000 0.00 1.0000
Work Station 5 0.9107
0,00 0.9033 0.9167 0.00 1.0000
Work Station 6 0.7976
0,00 0.7931 0.8015 0.00 1.0000
Work Station 7 0.7231
0,00 0.7175 0.7277 0.00 1.0000
Number Scheduled Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
Work Station 1 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 2 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 3 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 4 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 5 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 6 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Work Station 7 1.0000
0,00 1.0000 1.0000 1.0000 1.0000
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 9 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Resource
Usage
Values Across All Replications
Scheduled Utilization Minimum Maximum
Average Half Width Average Average
Work Station 1 0.9820 0,00 0.9734 0.9886
Work Station 2 0.7532 0,00 0.7480 0.7624
Work Station 3 0.7578 0,00 0.7514 0.7661
Work Station 4 1.0000 0,00 1.0000 1.0000
Work Station 5 0.9107 0,00 0.9033 0.9167
Work Station 6 0.7976 0,00 0.7931 0.8015
Work Station 7 0.7231 0,00 0.7175 0.7277
1,000
0,960
0,920
0,880
0,840
0,800
0,760
0,720
Total Number Seized Minimum Maximum
Average Half Width Average Average
Work Station 1 6100.20 2,69 6075.00 6119.00
Work Station 2 6100.10 2,65 6075.00 6118.00
Work Station 3 6099.80 2,68 6074.00 6118.00
Work Station 4 6088.64 2,59 6065.00 6107.00
Work Station 5 6088.22 2,64 6064.00 6107.00
Work Station 6 6089.02 2,62 6064.00 6108.00
Work Station 7 6088.88 2,59 6065.00 6107.00
6102,000
6100,000
6098,000
6096,000
6094,000
6092,000
6090,000
6088,000
Work Station 1
Work Station 2
Work Station 3
Work Station 4
Work Station 5
Work Station 6
Work Station 7
Work Station 1
Work Station 2
Work Station 3
Work Station 4
Work Station 5
Work Station 6
Work Station 7
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 10 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
Station
Other
Values Across All Replications
Number Entities Transferring Minimum Maximum
Average Half Width Average Average
Minimum
Value
Maximum
Value
A Enters Merge Point.Station 0.0989
0,00 0.0988 0.0990 0.00 1.0000
B Enters Merge Point.Station 0.1973
0,00 0.1970 0.1976 0.00 1.0000
C Enters Merge Point.Station 0.1387
0,00 0.1387 0.1388 0.00 1.0000
Enter load station.Station 1.4087
0,00 1.4037 1.4132 0.00 12.0000
Enter Work Station 1.Station 0.2870
0,00 0.2846 0.2890 0.00 3.0000
Enter Work Station 2.Station 0.5835
0,00 0.5766 0.5898 0.00 3.0000
Enter Work Station 3.Station 0.6032
0,00 0.5966 0.6113 0.00 3.0000
Enter Work Station 4.Station 0.5580
0,00 0.5499 0.5637 0.00 4.0000
Enter Work Station 5.Station 0.5864
0,00 0.5788 0.5954 0.00 3.0000
Enter Work Station 6.Station 0.5707
0,00 0.5610 0.5792 0.00 3.0000
Enter Work Station 7.Station 0.5376
0,00 0.5319 0.5428 0.00 4.0000
Exit conveyor.Station 0.3715
0,00 0.3648 0.3768 0.00 3.0000
Leaving load station 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Part A Line 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Part B Line 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Part C Line 0.00
0,00 0.00 0.00 0.00 0.00
Leaving unload station 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 1 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 2 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 3 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 4 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 5 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 6 0.00
0,00 0.00 0.00 0.00 0.00
Leaving Work Station 7 0.00
0,00 0.00 0.00 0.00 0.00
merge station 0.00
0,00 0.00 0.00 0.00 0.00
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 11 of 12

Category Overview
13:38:13 maj 5, 2009
SM Electronics
Replications: 50 Time Units: Minutes
User Specified
Counter
Values Across All Replications
Count Minimum Maximum
Average Half Width Average Average
Record Part A lost parts 378.26 23,03 177.00 520.00
Record Part B lost parts 572.76 24,12 417.00 787.00
Record Part C lost parts 476.98
7,77 422.00 526.00
600,000
560,000
520,000
480,000
440,000
400,000
360,000
Time Persistent
Variable Minimum Maximum
Average Half Width Average Average
Record Part A lost parts
Record Part B lost parts
Record Part C lost parts
Minimum
Value
Maximum
Value
cost counter 0.00
0,00 0.00 0.00 0.00 0.00
Entity Counter
Output
1.4728
0,00 1.4673 1.4779 0.00 12.0000
Output Minimum Maximum
Average Half Width Average Average
Lost Cost A 336.65 20,49 157.53 462.80
Lost Cost B 360.84 15,19 262.71 495.81
Lost Cost C 343.43 5,59 303.84 378.72
Total Lost Cost 1040.92 4,87 995.43 1067.93
1100,000
1000,000
900,000
800,000
700,000
600,000
500,000
400,000
300,000
Lost Cost A
Lost Cost B
Lost Cost C
Total Lost Cost
Model Filename: C:\Users\Lene\Documents\Arena\bachelor\modification_2[1]
Page 12 of 12

Litteratur
[1] W. D. Kelton, R. P. Sadowski, and D. T. Sturrock. Simulation with Arena.
McGraw-Hill Book Co., New York, 2007. McGraw-Hill Series in Industrial
Engineering and Management Science.
[2] Averill M. Law. Simulation modeling and analysis. McGraw-Hill Book
Co., New York, 2007. McGraw-Hill Series in Industrial Engineering and
Management Science.
[3] David G. Luenberger. Investment Science. Oxford University Press, inc.,
New York, 1998.
63