Bachelor

Simulation af SM Electronics
Simulation of SM Electronics

Bachelorprojekt i Matematik-Økonomi

Lene O. Sønder Morten Petersen
20061258 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 si-
mulation 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 de-
ciding 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 beskre-
vet 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 pro-
blemstilling 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 modiﬁkationer 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 Lene Sønder & Morten Petersen

v

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. ﬁgur 1.1.

Figur 1.1: Oversigt

Der er tre forskellige typer arbejdsstationer. Station 8 er en på-/aﬂæs-
ningsstation, hvor de forskellige elementer anbringes i, hhv. fjernes fra en pal-
let, hvori elementerne transporteres i det videre system. Station 1, 3, 4, 5 og
6 er automatiserede stationer, hvor elementerne bliver forarbejdet af maski-
ner, 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 arbejds-
stationer, hvor elementerne bliver behandlet af medarbejdere. Elementerne

1

2 Kapitel 1. Indledning

bliver fragtet rundt i systemet på nogle transportbånd med begrænset kapa-
citet, 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 virksomhe-
den 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 arbejdsstationer-
ne 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 arbejdssta-
tioner, den tid det tager at omstille maskinerne, så de passer til de forskellige
typer enheder og hastigheden på virksomhedens transportbånd. Desuden op-
lyses 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 forven-
tes, at tiderne er en god repræsentation af virkeligheden. Samlet producerer
de tre første linjer omkring

60 60 60
( + + ) stk/time · 16 timer ≈ 1500 stk
2.8 1.4 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 trans-
portbå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 arbejdssta-
tioner, 2 manuelle arbejdsstationer og én på-/aflæsningsstation, hvor alle ar-
bejdsstationerne 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 trans-
portbå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 un-
der 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 arbejds-
stationer, 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 arbejds-
stationerne, 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. Hav-
de 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 enhe-
der 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 en-
hed 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æsningsstatio-
nen. 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 aﬂæ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å-/aﬂæ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 aﬂæ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 der-
for 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 deﬁneret nogle ekstra linjer i data-
modulet „Statistic“ under „Advanced processes“. Disse fremgår af ﬁgur 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 fuld-
stæ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 kon-
stant 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].


Figur 2.4: Workstation 8

Tilbage til modulerne, jvf. ﬁgur 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 mu-
lighed for at bruge Process Analyzer (PAN) til at se på eﬀekterne 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ør-
næ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 automatise-
rede 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 Sta-
tion 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 de-
cide 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 hvil-
ken 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ær-
dien 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 fri-
giver 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 seize-
delay-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 forskel-
lige 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


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 eﬀekt som seize-delay-
release-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 ﬁndes vha. attributten
assigned value plus en konstant. Eneste ændring er, at tiderne her ikke er
konstante, men triangulært fordelte.

Figur 2.6: Manuel arbejdsstation

2.6 De sidste 4 moduler
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ørs-
lerne 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 min-
dre 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 opvarm-
ningsperioden 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 selv-
fø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,


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 under-
sø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 arbejdsstatio-
ner 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 arbejds-
stationerne 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 antal-
let 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 arbejdsstatio-
nerne, 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 na-
turligvis 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


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 grund-
modellen beskriver et produktionssystem, der allerede eksisterer, og det ville
derfor være muligt at se hvor mange enheder af hver type, der blev færdigpro-
duceret, 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 288000 288000
≈ 1714, ≈ 3429 og ≈ 2400
168 84 120
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
≈ 41.7
343 + 686 + 480
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 proces-
tiderne 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 trans-
portbå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 æn-
dres 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 smi-
des 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 arbejdssta-
tion, 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


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ør-
ste, 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 forbed-
ring. 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 enhe-
der gennem setuptid. Hvor mange enheder af samme type, der kommer efter
hinanden, afhænger naturligvis af, hvor mange enheder, der kommer ind i sy-
stemet, 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 ik-
ke 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 an-
lægge disse nye buffer conveyors $56.000, og vi har en ugentlig besparelse på

3.4. Kombinationer af modifikation 1 og 2 23

2097.121 − 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
A 1
PV = (1 − ) (3.1)
r (1 + r)n
og isolerer n. Udregningerne ser således ud
1087.363 1
(1 − ) = 56000
0.0005686 (1.0005686)n
1
1− = 0.02928
(1.0005686)n
1
= 0.9707166788
(1.0005686)n
1.0005686n = 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 om-
kostningen ved investeringen fast, uanset de indstillinger der skal til for at
bestemme Batch size. Dette betyder i realiteten, at man bør udnytte kapa-
citeten 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 mo-
difikation 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


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
PV · r
≤1
A

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 gruppe-
res 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 smi-
des 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 arbejdsstationer-
ne, 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 gen-
nem setup ved de automatiserede arbejdsstationer. Dette havde som forventet
stor effekt, netop fordi tiden i arbejdsstationerne blev nedsat kraftigt. Her vi-
ste vores beregninger, at investeringen var yderst fordelagtig. Vi diskuterede
også, i hvor store mængder vi skulle gruppere elementerne, inden de sendtes


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åls-
tegn 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.

Contest Problem 9: SM
Electronics

29

IIE/RA CONTEST PROBLEMS 1

CONTEST PROBLEM 9

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 modifi-
cations 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 modifica-
tions may be required in order to achieve the desired performance. In light of this uncer-
tainty, 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

2 IIE/RA CONTEST PROBLEMS

7 6 5 4

Part A Line

Part B Line 8 1 2 3

Part C Line

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 3

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

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

13:45:22 Category Overview maj 5, 2009
Values Across All Replications

SM Electronics

Replications: 50 Time Units: Minutes

Key Performance Indicators
System Average
Number Out 7,517

Model Filename: C:UsersLeneDocumentsArenabachelorbachelor endelig Page 1 of 11


SM Electronics


Conveyor

Usage

Blocked Minimum Maximum Minimum Maximum
Average Half Width Average Average Value 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 Minimum Maximum
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



SM Electronics


Entity

Time

VA Time Minimum Maximum Minimum Maximum
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 Minimum Maximum
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 Minimum Maximum
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 Minimum Maximum
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 Minimum Maximum
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 Minimum Maximum
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 50.1536 0,29 47.2798 52.3615 0.00 92.1767
Other



SM Electronics


Entity

Other

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 Part A
2600,000 Part B
Part C
2400,000
2200,000
2000,000
1800,000
1600,000

Number Out Minimum Maximum
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 Minimum Maximum
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



SM Electronics


Process

Time per Entity

VA Time Per Entity Minimum Maximum Minimum Maximum
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 Minimum Maximum
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 Minimum Maximum
Process 2 0.6007 0,00 0.5966 0.6083 0.3506 1.5228
Process 7 0.6466 0,00 0.6350 0.6529 0.3673 1.8689
Accumulated Time

Accum VA Time Minimum Maximum
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
Process 2
Process 7
2660,000

2640,000

2620,000



SM Electronics


Process

Accumulated Time

Accum Wait Time Minimum Maximum
Process 2 49.5580 0,94 43.9470 57.4585
Process 7 348.57 4,65 303.89 375.86

360,000
320,000
280,000
240,000
Process 2
200,000 Process 7
160,000
120,000
80,000
40,000

Other

Number In Minimum Maximum
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
Process 2
4604,000 Process 7

4602,000

4600,000

4598,000

Number Out Minimum Maximum
Process 2 4609.36 7,31 4525.00 4649.00
Process 7 4597.86 7,35 4513.00 4640.00



SM Electronics


Queue

Time

Waiting Time Minimum Maximum Minimum Maximum
Leave Work Station 1.Queue 0.00358265 0,00 0.00332983 0.00386060 0.00 0.7675
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
Other

Number Waiting Minimum Maximum Minimum Maximum
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



SM Electronics


Resource

Usage

Instantaneous Utilization Minimum Maximum Minimum Maximum
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 Minimum Maximum
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 Minimum Maximum
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


Bachelor

Recommended

Recommended

More Related Content

Featured

Featured (20)

Bachelor