Simulation af SM Electronics    Simulation of SM Electronics     Bachelorprojekt i Matematik-Økonomi    Lene O. Sønder Mor...
IndholdsfortegnelseAbstract                                                                                               ...
AbstractThis project is written in connection with the course „Modelling, simulationand analysis“ at Aarhus University, De...
ForordDette bachelorprojekt omhandler virksomheden SM Electronics som beskre-vet i „Contest Problem 9“. Formålet med proje...
Kapitel 1Indledning1.1     ProblemformuleringMed udgangspunkt i „Contest Problem 9“ (se appendiks s. 35) har vi forsøgtat ...
2                                                        Kapitel 1. Indledningbliver fragtet rundt i systemet på nogle tra...
1.2. Modellen og Antagelser                                                     3     Den del af SM Electronics, vi analys...
4                                                          Kapitel 1. Indledningdenne løsning, fordi vi i beskrivelsen af ...
1.2. Modellen og Antagelser                                                 5vi pålæsningen tage 25 sekunder plus en forsi...
Kapitel 2Modelkonstruktion,verificering og valideringI dette kapitel vil vi grundigt gennemgå, hvordan modellen er bygget o...
8                    Kapitel 2. Modelkonstruktion, verificering og validering                             Figur 2.1: Ankoms...
2.3. Arbejdsstation 8                                                           9afgøre elementtypen blot vha. følgende te...
10                   Kapitel 2. Modelkonstruktion, verificering og validering                           Figur 2.4: Workstat...
2.4. Automatiserede arbejdsstationer                                         11igennem decide modulet, er den samme som de...
12                    Kapitel 2. Modelkonstruktion, verificering og valideringvi have reduceret modellen, så den fx ikke ha...
2.7. Run Setup                                                                  132.7     Run SetupDet sidste, vi vil komm...
14                    Kapitel 2. Modelkonstruktion, verificering og validering                            Figur 2.9: # i sy...
2.8. Verificering og Validering                                                 15når der samlet er færre end 40 i „merge p...
16                   Kapitel 2. Modelkonstruktion, verificering og valideringhar vi dog fået løst ved at styre alle talstrø...
2.8. Verificering og Validering                                                 17arbejdsstation 1 end ved arbejdsstation 4...
Kapitel 3Analyse og konklusion3.1    Mulige forbedringerSom den oprindelige model fungerer, sendes forholdsvist mange enhe...
20                                           Kapitel 3. Analyse og konklusionvære, undersøger vi blot de to modifikationer,...
3.3. Modifikation 2                                                             21                                Figur 3.1...
22                                           Kapitel 3. Analyse og konklusionhver gruppering, styrer vi ved hjælp af en va...
3.4. Kombinationer af modifikation 1 og 2                                         232097.121 − 1009.757 = $1087.363 i tilfæ...
24                                            Kapitel 3. Analyse og konklusion                                Figur 3.3: P...
3.5. Konklusion                                                              25    Dette betyder med en årlig rente på 3%,...
26                                           Kapitel 3. Analyse og konklusionvidere i systemet. Konklusionen var her, at m...
Appendices    27
Contest Problem 9: SMElectronics            29
IIE/RA CONTEST PROBLEMS          1                       CONTEST PROBLEM 9                       IIE/RA Contest Problems  ...
2      IIE/RA CONTEST PROBLEMS                                                              7           6          5      ...
IIE/RA CONTEST PROBLEMS             3                   Arriving                   Part Type     Work Cell 1    Work Cell ...
4      IIE/RA CONTEST PROBLEMS                            The second proposed modification requires that we insert additio...
Output fra grundmodel             35
13:45:22                                  Category Overview                               maj 5, 2009                     ...
13:45:22                                  Category Overview                                                maj 5, 2009    ...
13:45:22                                  Category Overview                                               maj 5, 2009     ...
13:45:22                                   Category Overview                                              maj 5, 2009     ...
13:45:22                                   Category Overview                                                  maj 5, 2009 ...
13:45:22                                   Category Overview                                            maj 5, 2009       ...
13:45:22                                  Category Overview                                               maj 5, 2009     ...
13:45:22                                       Category Overview                                                maj 5, 200...
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Bachelor
Upcoming SlideShare
Loading in...5
×

Bachelor

885

Published on

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
885
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Bachelor"

  1. 1. 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
  2. 2. IndholdsfortegnelseAbstract iiiForord vKapitel 1 Indledning 1 1.1 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Modellen og Antagelser . . . . . . . . . . . . . . . . . . . . . . 2Kapitel 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 . . . . . . . . . . . . . . . . . . . . . 14Kapitel 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Appendices 27Contest Problem 9: SM Electronics 29Output fra grundmodel 35Output fra modifikation 49Litteratur 63 i
  3. 3. AbstractThis project is written in connection with the course „Modelling, simulationand 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 describesthe system. This is discussed in the first part of the assignment. We have thenestablished where the problem arised and as a conseqence of that, we havemade 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 theproblem and also seen which modifications that improved the system. In de-ciding which modifications to be used, we also took into account the cost ofimplementing the change and the savings obtained from the modification. iii
  4. 4. ForordDette bachelorprojekt omhandler virksomheden SM Electronics som beskre-vet i „Contest Problem 9“. Formålet med projektet har været at modellereen 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 afden omtalte model, en diskussion af hvorfor den virker, samt en analyse afproblemstillingen med udgangspunktet i de resultater vi har opnået i løbet afprocessen. Vi har set på forskellige modifikationer af modellen for at undersøgehvilke forbedringer, der er mulige at lave, og hvilke der kan forbedre systemet,samt lavet en analyse af, hvilke ændringer i grundmodellen, der således kanbetale sig at gennemføre.Århus, Maj 2009 Lene Sønder & Morten Petersen v
  5. 5. Kapitel 1Indledning1.1 ProblemformuleringMed udgangspunkt i „Contest Problem 9“ (se appendiks s. 35) har vi forsøgtat benytte simulation til at analysere og forbedre en vis problemstilling hosSM Electronics. Virksomheden fremstiller elektroniske elementer, som andrevirksomheder videreforarbejder. I den konkrete problemstilling ser vi på enafdeling som producerer tre elementer, A, B og C. Disse bliver hovedsageligtproduceret separat, men ender alle i en fælles afsluttende proces. Helt konkretbliver elementerne placeret på et transportbånd, der fragter dem mellem ottearbejdsstationer, jvf. figur 1.1. Figur 1.1: Oversigt Der er tre forskellige typer arbejdsstationer. Station 8 er en på-/aflæ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 og6 er automatiserede stationer, hvor elementerne bliver forarbejdet af maski-ner, og hvor maskinerne evt. skal omstilles, hvis forrige element ikke var afsamme type som det nuværende. Til sidst har vi også de manuelle arbejds-stationer, hvor elementerne bliver behandlet af medarbejdere. Elementerne 1
  6. 6. 2 Kapitel 1. Indledningbliver 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ænsningernepå transportbåndene kunne være et problem, eller måske er arbejdsstationer-ne ikke hurtige nok. Yderligere kunne man forestille sig, at arbejdsstationernekunne udnyttes bedre. Selve problemstillingen samt disse mulige årsager vilvi tage op og analysere i denne opgave.1.2 Modellen og AntagelserData for SM Electronics’ fjerde linje omhandler ankomster af enhederne A, Bog 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 forskelligetyper 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 atkomme ind på det første transportbånd til det videre system. Da der er taleom et faktisk system, som virksomheden har og arbejder med, må det forven-tes, at tiderne er en god repræsentation af virkeligheden. Samlet producererde tre første linjer omkring 60 60 60 ( + + ) stk/time · 16 timer ≈ 1500 stk 2.8 1.4 2hver dag, og det er derfor muligt at samle ret gode data om, hvordan enhedernekommer, og hvad der sker med dem igennem systemet. Man kan diskutere, om en triangulær fordeling normalt vil give et godtbillede af, fx hvor lang tid et stykke arbejde tager, men da virksomhedennetop har haft et konsulentfirma til at finde data, og da der er så meget dataat lave analyser ud fra, må det forventes, at de oplyste tal giver et nogenlundegodt 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 svarertil virkeligheden, da vi ikke har nogen andre omkostninger i forbindelse medsystemet, og vi intet får at vide om, hvordan disse omkostninger er fundet. Vimå derfor blot antage, at data i opgavebeskrivelsen er en god repræsentationaf virkeligheden, især fordi vi behandler et system, der allerede eksisterer, oghvor det er muligt at lave faktiske målinger. Mht. de to modifikationer er der til gengæld tale om endnu ikke afprøvedesystemer, hvilket gør, at det ikke er muligt at se, hvordan de fungerer. Menda der kun er tale om små modifikationer i det faktiske system, som ikkeumiddelbart vil have nogen effekt på andet end hhv. antallet af enheder isystemet, eller hvor ofte nogle enheder skal igennem setuptid, må vi ogsåforvente, at data i disse tilfælde er gode nok.
  7. 7. 1.2. Modellen og Antagelser 3 Den del af SM Electronics, vi analyserer, er et system, hvor der kommertre typer enheder ind, A, B og C, som er blevet forarbejdet på hver dereslinje og nu kommer ind på en fælles linje. Alle tre enheder kommer fra enanden 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 kommerind. På (IC) er der plads til 40 enheder. Vi har antaget at en enhed fylder2 fod på (IC) (og de tre buffer conveyors fra modifikation 2), ligesom det ertilfældet på transportbåndet mellem arbejdsstationerne, som vi har valgt atkalde „Conveyor“ (C). Ligeledes har vi antaget, at alle transportbånd kørermed samme hastighed som (C), dvs. 72 fod pr. min. Dette betyder i det storehele 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 giveren bedre repræsentation af virkeligheden at lave disse transportbånd i forholdtil 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 oppå en slags pallet, som enhederne nu skal fragtes i, i det videre system. Dissepalletter er placeret på (C), som er forbindelsen mellem otte stationer, hvorafde syv forarbejder enheden. På (C) er der 40 palletter, dvs. der også på dettetransportbå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 typeenhed, der skal behandles. Af-/pålæsningsstationens proces tager en konstanttid, 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 nyenhed ned i en pallet, så snart den færdiggjorte enhed er blevet fjernet, hvilketikke var muligt, hvis systemet skulle bestå af kun et transportbånd. Havdeder kun været ét bånd, skulle det efter aflæsning af en færdig enhed tilbagetil stationen, hvor enhederne kommer ind på linjen, og først derefter hen tilpålæsningsstationen. Denne løsning ville også give problemer mht. palletten,da enhederne ikke skal anbringes i en pallet med det samme, de kommer indpå transportbåndet, og det ville derfor blive nødvendigt, at fjerne pallettenfra 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 vivalgt 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. fremtil 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
  8. 8. 4 Kapitel 1. Indledningdenne 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 villedet aldrig kunne lade sig gøre, at arbejdet på stationerne blev lavet, hviselementerne skulle blive på båndet, og båndet skulle køre med den opgivnehastighed. Vi har derfor valgt, at enhederne forlader båndet ved alle arbejds-stationer, da alternativet ville være, at båndets hastighed skulle bestemmesaf den langsomste proces, og hastigheden på de 72 fod i minuttet ville dermedvæ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 tilarbejdsstationerne. 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å arbejdstidernepå 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 imellemto 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åndetog arbejdsstationerne i det videre system. For at begrænse antallet af enhederi systemet, dvs. for at undgå så stor en kø før (IC), at den aldrig ville kunneafvikles, 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øberhele systemet, mens enheden smides ud, hvis der er 40 på båndet og områdetomkring den. I de fem automatiserede arbejdsstationer er der en konstant procestid, derer afhængig af, hvilken type den ankomne enhed har, men der er også ensetuptid, som enheden skal igennem, hvis den forrige enhed var af en andentype end den nyankomne. Når arbejdsdagen slutter skal alle enheder stoppeder, hvor de er, og næste dag fortsættes der, hvor man slap. Det betydernaturligvis også, at setuptid for den første, der ankommer en morgen, afhængeraf, hvilken type den sidste, der var igennem stationen dagen før, havde. Vi harsamtidigt antaget, at når systemet begynder, er alle maskiner gjort klar til enenhed af type A. Dette betyder dog ikke noget pga. opvarmningsperioden. Den arbejdsopgave at fjerne et element fra en pallet og pålæsse en nytager samlet 25 sekunder plus en forsinkelse nogle procent af gangene. Dettehar vi modelleret lidt anderledes dog uden at ændre på, hvordan modellenfungerer. Vi har ladet station 8, som er af-/pålæsningsstationen, opdele i tostationer. En station i starten, der læsser enheder på (C), og en station til sidsti modellen, der fjerner dem fra den igen. Afstanden mellem disse to stationerhar 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
  9. 9. 1.2. Modellen og Antagelser 5vi pålæsningen tage 25 sekunder plus en forsinkelse 1% af gangene. På denmåde bliver den samlede tid i systemet for hver enhed ikke ændret, og førstnår systemet er fyldt (og det er først når systemet er fyldt, vi begynder atmåle), vil der alligevel ikke kunne pålæsses en enhed før, en færdig enhed erblevet taget af palletten. Dette gør, at det ikke har nogen betydning, at helepå-/aflæsningstiden tilføjes i starten. I forbindelse med arbejdsstationerne, hvor det ankomne element fjernes fratransportbå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 iarbejdstiden ved den enkelte station.
  10. 10. Kapitel 2Modelkonstruktion,verificering og valideringI 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 erformuleret i afsnit 1.2 på side 2.2.1 AnkomsterLad os nu tage fat på modellen. I figur 2.1 på næste side ser vi, at vi har tretyper af ankomster. Der foregår dog essentielt det samme i alle tre modulernemlig, 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 brugeroperatoren DISC til at modellere, at der en vis procentdel af gangene skerforsinkelser af typen TRIA. Eksempelvis ankommer der et element af typenA hver 168 sekund bortset fra, at det 2% af gangene bliver forsinket meden stokastisk variabel, der er triangulær fordelt med parametrene 5, 15 og60. Bemærk i øvrigt også, at vi styrer talstrømmene (her symboliseret med zog w) således, at vi er sikre på, at der kommer det samme antal ankomster ibåde vores grundmodel samt i vores modifikationer. Efter disse indledende create moduler kommer elementerne nu til et assignmodul, hvis eneste opgave er at tildele de forskellige typer af elementer enværdi 1, 2 eller 3, afhængig af om elementet er af type A, B eller C. Hvad vihelt konkret bruger disse værdier til, kommer vi tilbage til i afsnit 2.2 på denfølgende side. 7
  11. 11. 8 Kapitel 2. Modelkonstruktion, verificering og validering Figur 2.1: Ankomster2.2 Ankomst til input conveyorVi er nu nået dertil, hvor vi skal afgøre, om der plads på (IC) eller ej. Dettesø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 ethold 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 osvidere 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 moduleti starten af modellen, kommer ind i billedet. Vi er nemlig nu i stand til at
  12. 12. 2.3. Arbejdsstation 8 9afgøre elementtypen blot vha. følgende tests if assigned value = i, i = 1, 2, 3Vi 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 ganget 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 standardstatistikken fra run setup, har vi yderlige defineret nogle ekstra linjer i data-modulet „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: Statistikganger med enhedsomkostningen for de respektive typer. På denne måde fårvi skabt noget statistik, der fortæller, hvad omkostningerne har været, fordeltpå 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 stedetkommer til assign modulet, „Increment # of Entities in input Conveyor“,hvis eneste opgave er at tælle variablen „Entity Counter“ én op. Elementetankommer herefter til en station, „merge station“, som modellerer ankomstentil (IC). „Merge point“, som er det efterfølgende leave modul, søger så for, atelementerne faktisk kommer op på (IC).2.3 Arbejdsstation 8Inden vi fortsætter med de næste moduler, vil vi her lige forklare, hvordanvores 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 somder står i opgaveteksten (jvf. „Contest Problem 9: SM Electronics“ på side35), 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 alleleave modulerne givet „# of Cells“ værdien 2. Disse værdier har vi valgt, fordien enhed skal optage to fod på et transportbånd, hvilket vi sørger for ved atlade 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 simulationenmere præcis jvf. [1].
  13. 13. 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 entermodul, som har til opgave at tage vores element af (IC). Inden vi kommer tildet 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 styrpå antallet af elementer på (IC). Hold modulet holder på elementerne indtilfølgende betingelse er opfyldt Entity Counter 2 < NrOfEntitieshvor „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å effekterne af en evt.udvidelse af antallet af palletter på (C). Så det, betingelsen siger, er, at viskal holde på vores elementer, indtil der er plads på (C). Dette venteområdebetragter vi også som en del af (IC). Grunden hertil er, at vi mener, det giverdet 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 erogså 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 skalvores 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 dennemanø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 arbejdsstationerMed 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 thesame in 1?“, der afgør, om den pågældende enhed er af samme type, som denforegående. Dvs. vi har en variabel, „Variabel 1“, som har en værdi 1, 2 eller3, og decide modulet tester, om „assigned value“ ved den enhed, der kommer
  14. 14. 2.4. Automatiserede arbejdsstationer 11igennem 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 enprocestid, 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 typesom den foregående, skal enheden blot igennem procestiden. Inden ressourcenfrigives 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, derlige har været igennem arbejdsstationen. Denne værdi bruges således til atafgøre, om den næste enhed skal igennem setup eller blot kan sendes direkteind i processen. Herefter fragtes elementet igennem et release modul, der fri-giver ressourcen, et station modul, der bruges til at angive transportbåndetsrute 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 enenhed, der befinder sig i setup. På denne måde kan et element ikke kommeind i decide modulet, før det foregående er færdigbehandlet, og dets type ergemt i Variabel 1. Figur 2.5: Automatiseret arbejdsstation Procestiderne og setuptiderne har vi valgt at lave i et array med hhv. 21og 15 indgange. Det betyder, at den første indgang i udtrykket Process erarbejdstiden i arbejdsstation 1 på et element af typen A. Anden indgang erarbejdstiden i arbejdsstation 1 på et element af typen B, fjerde indgang erarbejdstiden i arbejdsstation 2 på et element af typen A osv. Setuptiderne erdefineret 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 viunder 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 haveværdien 1 som assigned value, og Arena vil derfor finde Process(1), som er denførste indgang i Process. Ved hver af de efterfølgende arbejdsstationer har viblot lagt hhv. 3, 6, 9, 12, 15 og 18 til assigned value, og derved finder Arenade tider, elementet skal forsinkes med baseret på, hvilken type det er, og hvordet er i systemet. Denne løsning har vi valgt frem for at have et expression tilhver proces-/setuptid, fordi vi ved at have et expression til alle tider fik formange siman objekter, og derfor ikke kunne køre modellen. Alternativt kunne
  15. 15. 12 Kapitel 2. Modelkonstruktion, verificering og valideringvi have reduceret modellen, så den fx ikke havde så mange arbejdsstationer,men denne løsning ville vi selvfølgelig gerne undgå.2.5 Manuelle arbejdsstationerDe manuelle arbejdsstationer er en simplere udgave af de automatiserede.Her er det ikke nødvendigt med en setuptid, hvilket gør, at det ikke blivernødvendigt at holde styr på, hvilke typer der tidligere har været igennem. Dissearbejdsstationer er derfor kun opbygget af et enter modul, der tager enhederneaf transportbåndet, et process modul, der har samme effekt som seize-delay-release-konstruktionen fra de automatiserede arbejdsstationer, og til slut enstation og et leave modul, der gør, at transportbåndets rute kan blive beskreveti datamodulet „Segment“, og at enhederne sættes tilbage på transportbåndet.Som ved de automatiserede arbejdsstationer vælges procestiderne vha. Processunder „Expression“, og de rigtige indgange i denne liste findes vha. attributtenassigned value plus en konstant. Eneste ændring er, at tiderne her ikke erkonstante, men triangulært fordelte. Figur 2.6: Manuel arbejdsstation2.6 De sidste 4 modulerNu er vi så nået til afslutningen af vores model. Her kommer elementet i førsteomgang til et enter modul, „Exit conveyor“, som igen blot tager elementet af(C). Dernæst har vi en station, „Leaving unload station“, som markerer detsidste 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ølgeligsker gennem et assign modul, som her hedder „Decrement # of Entities inConveyor“. Figur 2.7: Exit
  16. 16. 2.7. Run Setup 132.7 Run SetupDet 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“ til5000 minutter (5 dage med 16 timer pr. dag angivet i minutter plus 200 min. iopvarmningsperiode) 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æreti gang med nogle overvejelser. Mere præcist har vi til opvarmningsperiodenbenyttet Output Analyzer (OA). Da produktionen bliver lukket ned hver daguden, 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ærepå det normale niveau. Til at undersøge hvad dette normale niveau er, har Figur 2.8: Run Setupvi 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 manblot ser på et kort tidsinterval, jvf. figur 2.9 på næste side, så for det fuldebillede, 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ærepå den sikre side sætter vi derfor opvarmningsperioden til 200 min. Bemærkat 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 palletterpå båndet, men i forbindelse med vores kørsler i (PAN) var det en fordel atsystemet var fyldt uafhængigt af NrOfEntities. Mht. antallet af replikationer,så har vi her gjort os nogle overvejelser mht. vores konfidensintervaller. Vi hari den forbindelse lavet kørsler med hhv. 10, 40, 50, 70 og 100 replikationer,
  17. 17. 14 Kapitel 2. Modelkonstruktion, verificering og validering Figur 2.9: # i systemet Figur 2.10: # i systemet, set over hele periodenog det viser sig, at når antallet kommer over 50, bliver ændringerne megetsmå, og vi har derfor valgt, at det ikke kan betale sig at lave flere end 50replikationer. Dette er selvfølgelig et skøn, vi har gjort os, men virksomhedenkunne jo sagtens tænkes at have andre præferencer end os. Man kunne sagtensforestille sig, at de gerne ville have en meget præcis simulation, og derfor villesætte pris på mange flere replikationer eller omvendt, at de ikke vil bruge formange ressourcer, og derfor kunne være fint tilfredse med fx 10 replikationer.2.8 Verificering og ValideringI opbygningen af vores model har vi ikke, som anbefalet i [2], startet medat lave en mindre model og udbygget den efterhånden, men i stedet forsøgtat 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 visyntes, at det var nødvendigt med mindst én arbejdsstation af hver type ogvores af/-pålæsningsstation for at lave en grundmodel, der nogenlunde kunnerepræsentere virksomheden, og dermed give et overblik over opbygningen afdenne produktionslinje. Da fem af arbejdsstationerne er identiske, bortset franogle proces- og setuptider, valgte vi at lave alle fem på én gang. Ligeledeslavede 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 etoverblik over, om elementerne blev fragtet igennem systemet som ønsket, ogisær om transportbåndene fungerede, som de skulle. Sidenhen har vi forenkletmodellen bl.a. for at undersøge, om decide modulerne i modellen fungeredesom forventet. Det første decide modul (Is Input Conveyor avaliable?) afgør, om der erså mange elementer på vores (IC), at det pågældende element, der er kommetind 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,
  18. 18. 2.8. Verificering og Validering 15nå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 detogså, at summen af antal ventende ved hhv. merge point, Queue for load pointog 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 harvi kunnet nå frem til, at vores hold modul inden load point (Queue for loadpoint) fungerer efter hensigten, da man under „Entity“ → „Other“, kan se, atdet samlede work in process for A, B og C er under, men dog forholdsvist tætpå 80. Da der aldrig er mere end 40 i (IC) og køerne omkring denne betyderdette, 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 kunhar sendt én type ind, og derved har kunnet se, at decide modulerne senderalle 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, atmaskinerne er gjort klar til type A. Derefter sendte vi kun elementer af typeA og B ind i systemet på en sådan måde, at hver anden var af type A, hveranden af type B, og kunne så observere, som ønsket, at alle elementer skulleigennem 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 omden 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 outputfra kørslerne (se „Output fra grundmodel“ på side 35) for at se, om tallenevirker realistiske. Både ud fra køtider, antal elementer i kø og udnyttelse afressourcerne ses det, at flaskehalsen i systemet er arbejdsstationerne, hvilketogså er det forventede, da transportbåndene kører 72 fod i minuttet, og detdermed vil tage ca. 14 sekunder at blive transporteret de 16 fod, der er mellemto 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 virkeliggø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 afelementer 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 deikke var ens, når man så på modifikation 2 i forhold til grundmodellen. Dette
  19. 19. 16 Kapitel 2. Modelkonstruktion, verificering og valideringhar vi dog fået løst ved at styre alle talstrømme, dvs. ved at bruge forskelligetalstrømme til alle diskrete og triangulære fordelinger i de forskellige createmoduler, 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 fjerdelinje, 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, atdet kan give et indblik i, hvordan der kan komme flere igennem systemet, ogdermed få færre elementer smidt ud. Var SM Electronics et virkeligt firma, ville det være forholdsvist simpeltat få et overblik over, om vores model svarer til virkeligheden, fordi grund-modellen beskriver et produktionssystem, der allerede eksisterer, og det villederfor 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 atse, om det i virkeligheden var de samme arbejdsstationer, der gav anledningtil flaskehalse, som dem i vores model og lignende. Desværre er det ikke muligtfor os, da vi ganske enkelt ikke har de tal. Alligevel er det dog muligt ud fradet data, der er opgivet at se på nogle af modellens resultater. Bemærk at defølgende udregninger er baseret på overslag. Ankomsterne i modellen svarergodt 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 120elementer ind i systemet af hhv. type A, B og C (eller ca 343, 686 og 480 omdagen). Bemærk at disse tal er lidt over det faktiske, og de tal som Arenagiver, da vi i disse udregninger ikke har taget højde for de forsinkelser, dernogle gange er i ankomsterne. Mht. flaskehalsene i systemet, er det klart, atdet i virkeligheden, som i vores model, må være arbejdsstationerne, der erflaskehalsene, fordi det, som forklaret ovenfor, for alle arbejdsstationer tagermere end 14 sekunder at behandle en enhed. At det især er ved arbejdsstation4, 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 procestiderneved arbejdsstationerne 1, 3, 4, 5 og 6 vægtet med, hvor mange enheder derkommer af hver type. Da fås hhv. ca. 41.7, 28.5, 41.5, 37.3 og 34.2, hvoreksempelvis det første tal er udregnet på følgende måde 37 · 343 + 46 · 686 + 39 · 480 ≈ 41.7 343 + 686 + 480Dette 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 enhederneskal igennem setup i grundmodellen, er det også nødvendigt at tage disse medi overvejelserne. Her ses det, at setuptiderne for alle tre typer er kortere ved
  20. 20. 2.8. Verificering og Validering 17arbejdsstation 1 end ved arbejdsstation 4. Mht. arbejdsstation 3 er proces-tiderne så meget kortere end procestiderne i arbejdsstation 4, at det virkerfornuftigt, at det vil tage en enhed længere tid at passere arbejdsstation 4 end3, 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å forsinkendefor systemet, som arbejdsstation 4, fordi setuptiderne i station 5 og 6 stortset alle er mindre end de tilsvarende tider fra station 4, og fordi stationerne 2og 7 ikke har setuptider, og derfor må være væsentligt hurtigere. Alt i alt erdet plausibelt, at det bør være arbejdsstation 4, der samler kø, ligesom det ertilfældet i modellen. Mht. modifikationen, der gør, at enhederne bliver samletalt efter type, virker det også troværdigt, at det stadig er arbejdsstation 4,der er flaskehalsen i systemet, fordi procestiderne i denne station var blandtdem, 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 antalletaf enheder, der skal gennem setup, er stærkt reduceret, er der dog stadig taleom et stort antal enheder, som skal igennem setup.
  21. 21. Kapitel 3Analyse og konklusion3.1 Mulige forbedringerSom den oprindelige model fungerer, sendes forholdsvist mange enheder udaf 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 atmindske antallet af enheder, der smides ud, er det derfor nødvendigt at sepå æ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 skalforsø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ærreelementer 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 deotte arbejdsstationer. Ligeledes kunne en forøgelse af hastigheden, som de totransportbå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, ogden samlede tid pr. enhed på den fjerde linje ville derfor kunne mindskes. Forbedringer på arbejdsstationerne skal kunne gøre det hurtigere for etelement at blive behandlet på den enkelte arbejdsstation. Da vi antager, atdet ikke er muligt at forkorte proces- og setuptiderne, er den eneste mulighedfor at forkorte tiden i en arbejdsstation at få færrest mulige elementer igennemsetuptiden. I modifikation 2 laves der en model, der netop gør dette ved atgruppere enhederne således, at der fx kommer fem elementer af samme type itræ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øsningogså 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 ikkekan vide, om det er fysisk muligt at lave sådanne udvidelser, og heller ikkehar mulighed for at vurdere, hvad omkostningerne ved disse udvidelser ville 19
  22. 22. 20 Kapitel 3. Analyse og konklusionvære, undersøger vi blot de to modifikationer, der er foreslået, og hvorom vihar fået data. Hvilken en af modifikationerne, der bedst kan betale sig, og om det er enkombination af ændringerne, der er den bedste løsning kommer naturligvis anpå, om det er arbejdsstationerne eller transportbåndet, der er hovedårsagentil flaskehalsen, eller om det er en kombination. Dette vil vi analysere i detfølgende. Det er dog værd at bemærke, at denne undersøgelse af forbedringeraf modellen kun koncentrerer sig om minimering af „Total lost cost“ somperformancemål, og tager derfor ikke nødvendigvis hensyn til at fx antallet afenheder, der forlader systemet, kunne forringes. I den oprindelige model, svarende til SM Electronics, som virksomhedenser ud nu, har vi, bl.a. vha. vores record moduler i output fra Arena, antalletaf enheder, der bliver smidt ud af det fjerde system om ugen, fordelt på de tretyper. 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ålfor, om en ændring forbedrer systemet så meget, at det kan betale sig atinvestere. Som SM Electronics fungerer nu, sendes der samlet omkring 2800 elementerud 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 iløbet af en uge.3.2 Modifikation 1For at se på modifikation 1, har vi vha. (PAN) kørt vores grundmodel, hvorvariablen NrOfEntities har værdierne hhv. 40, 45, 50, 55, 60, 65 og 72. Dettesvarer til ændringen af modellen, hvor der er tilføjet 0, 5, 10, 15, 20, 25 eller32 palletter til transportbåndet, hvilket betyder, at det nu er muligt at haveflere enheder på båndet ad gangen. I øvrigt bemærkes at 72 er en øvre grænsefor antallet af elementer der kan være på (C), da transportbåndets samledelængde er 16 · 8 + 2 · 8 = 144og é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 setkonstant ligegyldigt, hvilken værdi NrOfEntities antager. Derfor kan det klartkonkluderes, at det ikke kan betale sig at tilføje flere palletter på (C), da derer 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 erto steder, hvor der samles kø, Queue for load point og Seize Work Station 4. Atder 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
  23. 23. 3.3. Modifikation 2 21 Figur 3.1: PANændring, fordi flere enheder vil blive sendt videre i systemet på (IC), men detikke vil gå hurtigere med at læsse dem på transportbåndet, da transportbåndetikke kører hurtigere eller pålæsningstiden ikke forkortes. Alt i alt vil ændringenfra 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 kanvære på båndet, videre igennem den fjerde linje, men tiden igennem systemetvil ikke blive forkortet, og derfor vil der blot være flere ufærdige enhederpå transportbåndet, når arbejdsdagen slutter. Dette vil betyde, at der villevæ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 reeltsvarer det bare til at tage nogle enheder fra i systemet, når de ellers skullekasseres, og undlade at tælle denne tabte omkostning med. Men da systemetaldrig kører tomt, hvilket vi, som nævnt i afsnit 2.7 på side 13, modellerer veden opvarmningsperiode, der sikrer, at systemet er på sit normale niveau, nårvi begynder at samle data, sker dette aldrig, og dermed vil end ikke lost costkunne forbedres ved at have flere palletter. Denne modifikation vil altså betyde, at der kører flere halvfærdige enhederrundt i systemet. Samtidig vil den tid, det tager en enhed at komme igennemsystemet, forlænges, og der vil ikke blive færdiggjort flere enheder. Da systemetaldrig kører tomt, vil denne ændring derfor ikke hjælpe til at færre enhedersmides ud inden (IC), og det vil naturligvis ikke kunne betale sig at investerei noget, som ikke giver anledning til en forbedring.3.3 Modifikation 2Som tidligere nævnt har vi lavet en modifikation, som skal gøre, at vi mindskersetuptiden på vores arbejdsstationer. Dette kommer ud på, at vi har lavet trebuffer 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 økonomiskeside af modellen, skal vi komme tilbage til senere. Antallet, der skal være i
  24. 24. 22 Kapitel 3. Analyse og konklusionhver gruppering, styrer vi ved hjælp af en variabel, „Batch size“, der somudgangspunkt antager værdien 5. Vi kan så vha. (PAN) undersøge forskelligestørrelser af denne Batch size, hvilket også fremgår af figur 3.2. Når vi har Figur 3.2: PANen Batch size på 1, svarer det selvfølgelig til tilfældet, hvor vi ikke har nogenbuffer conveyors, dog med den forskel, at der er lidt transporttid på dissebånd. Som det fremgår arbejder vi også med størrelserne 2, 5, 7 og 10. Derer en naturlig grænse på 10 for hvor mange ankomster, man kan gruppere, dader, jvf. appendix „Contest Problem 9: SM Electronics“ på side 35, er pladstil 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 mereend 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 enTotal Lost Cost på 681.758. Disse tal skal selvfølgelig sættes i forhold til deninvestering, man skal lave for at opnå disse besparelser, men mere om detsenere. Først vil vi nemlig lige prøve at give en forklaring på, hvorfor vi opnårdisse store besparelser, i modsætning til den første modifikation beskrevet iafsnit 3.2 på side 20. Kodeordet i den sammenhæng er setuptid. Den helt storefordel ved denne løsningsmodel er nemlig, at der kommer mange færre enhe-der gennem setuptid. Hvor mange enheder af samme type, der kommer efterhinanden, 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) afgangene. 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 underbyggevores endelige konklusion, om at virksomhedens flaskehals i virkeligheden ik-ke er transportbåndene, men derimod arbejdsstationerne, eller mere specifiktsetuptiden 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 sikrerden lavere lost cost, er alt for omkostningsfyldt. Derfor vil vi nu tage denneproblemstilling 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å
  25. 25. 3.4. Kombinationer af modifikation 1 og 2 232097.121 − 1009.757 = $1087.363 i tilfældet, hvor Batch size er 5. Spørgsmåleter nu hvor lang tid, der går, før investeringen er tjent hjem.2 Her bruger viselvfølgelig annuitetsformlen A 1 PV = (1 − ) (3.1) r (1 + r)nog 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.2847Det vil altså sige, at det tager lidt mere end 52 uger, før investeringen er tjenthjem. 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 atbestemme 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 bedstmuligt. 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 manforestille sig, at antallet af fejl på transportbåndet stiger med Batch size, mendette kan vi dog ikke tage hensyn til uden at lave en masse antagelser.3.4 Kombinationer af modifikation 1 og 2Ud 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 deto modifikationer, og vi ser derfor på, om modifikation 1 kan betale sig, givetvi har investeret i modifikation 2. Ligesom ved modifikation 1, forventede vi, at der ikke ville blive tale omnogen besparelse ved at tilføje flere palletter, fordi vi, som forklaret i afsnit 3.2på side 20, ikke får et system, der er hurtigere, og ændringen derfor kunbetyder, 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
  26. 26. 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 ladeBatch size være 10, jvf. afsnit 3.3 på side 21, havde vi egentlig blot tænkt osat se på dette tilfælde. Men da det ud fra (PAN) ikke var fuldstændig oplagtat se, om ændringer i NrOfEntities ikke havde nogen effekt, har vi alligevelvalgt at lave kørsler for flere forskellige værdier af Batch size. Dette har vigjort for at få et mere generelt overblik over, hvordan Total lost cost ændresfor forskelligt antal palletter på (C). Selvom der i figur 3.3 ses noget størrespredning af Total lost cost er der ikke noget, der tyder på en generel tendenstil at Total lost cost falder, når værdien af NrOfEntities stiger. Skulle begge investeringer gennemføres ville det, som forklaret i afsnit 3.3på side 21, og som det også tydeligt fremgår af figur 3.3, klart være optimaltat lade Batch size være 10. Givet denne værdi er den største besparelse, derkan 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
  27. 27. 3.5. Konklusion 25 Dette betyder med en årlig rente på 3%, at nutidsværdien af investeringenikke kan blive større end 13.6 = $23918.4 0.0005686Dette er lavere end omkostningen ved at få tre palletter mere på (C), og deter derfor tydeligt, at det ikke kan betale sig at investere i en kombination afmodifikation 1 og 2. Vi har valgt at vurdere investeringerne, ved at se på hvor mange år derskal gå, før nutidsværdien af vores besparelse er lige så stor som prisen påinvesteringen. Denne løsning tager naturligvis ikke hensyn til afskrivningerog lign., men for at undgå at skulle lave antagelser, som vi egentlig ikke harnoget hold i, har vi alligevel valgt denne løsning. Denne metode kan godtbruges til at afgøre, om en enkelt investering kan betale sig, men er ikke godtil sammenligning af alternativer, og da vi direkte kan afvise modifikation 1 ogen 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 KonklusionVi har i det foregående lavet en simulation af SM Electronics, hvor vi harbetragtet fire scenarier; virksomhedens nuværende setup, to modifikationersamt en kombination af de to. Vha. Arena har vi lavet ændringer i, hvordanvirksomheden fungerer nu, først ved at ændre på antallet af enheder, der kanvæ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 forskelligearbejdsstationer. På baggrund af kørsler af de forskellige modifikationer harvi 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 erdenne 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 manderfor forudsige, at modifikation 1 ikke vil have nogen mærkbar effekt. Påtrods af dette gennemgik vi selvfølgelig modifikationen med et resultat somforventet; ingen ugentlig besparelse. Dette kunne vi klart afvise som en dårliginvestering og dermed yderligere forstærke vores opfattelse af, at det ikke vartransportbåndet, der var årsag til flaskehalsen. I modifikation 2 ændrede vi systemet sådan, at enhederne blev grupperetefter deres type, og dermed undgik vi at så mange enheder skulle sendes gen-nem setup ved de automatiserede arbejdsstationer. Dette havde som forventetstor effekt, netop fordi tiden i arbejdsstationerne blev nedsat kraftigt. Her vi-ste vores beregninger, at investeringen var yderst fordelagtig. Vi diskuteredeogså, i hvor store mængder vi skulle gruppere elementerne, inden de sendtes
  28. 28. 26 Kapitel 3. Analyse og konklusionvidere i systemet. Konklusionen var her, at man blot skulle benytte den fuldekapacitet på ti. Dette var dog set i det perspektiv, at der ikke var nogen ekstraomkostning forbundet med større Batch size, hvilket vi også satte spørgsmåls-tegn ved troværdigheden af. Dog endte vi med at tage opgavebeskrivelsensoplysninger for gode varer. Et sidste forsøg på at minimere de tabte omkostninger, blev gjort vedførst at antage modifikation 2 gennemført, og derefter se på modifikation 1gennemført i denne nye modificerede model. Vi valgte den antagelse, da derikke kunne være nogen som helst tvivl om, at modifikation 2 skulle være endel af den endelige ændring af systemet. Vi brugte denne gang (PAN) til voresundersø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 vedinvesteringen. Alt i alt nåede vi frem til, at det mest rentable udfald blevopnået ved udelukkende at benytte modifikation 2 med en Batch size på ti.
  29. 29. Appendices 27
  30. 30. Contest Problem 9: SMElectronics 29
  31. 31. 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
  32. 32. 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
  33. 33. 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
  34. 34. 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
  35. 35. Output fra grundmodel 35
  36. 36. 13:45:22 Category Overview maj 5, 2009 Values Across All ReplicationsSM Electronics Replications: 50 Time Units: Minutes Key Performance Indicators System Average Number Out 7,517 Model Filename: C:UsersLeneDocumentsArenabachelorbachelor endelig Page 1 of 11
  37. 37. 13:45:22 Category Overview maj 5, 2009 Values Across All ReplicationsSM Electronics Replications: 50 Time Units: MinutesConveyor Usage Blocked Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValueConveyor 0.4041 0,00 0.3965 0.4086 0.00 1.0000Input Conveyor 0.00 0,00 0.00 0.00 0.00 0.00 Utilization Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValueConveyor 0.04378898 0,00 0.04282192 0.04432481 0.00 0.1806Input Conveyor 0.01330404 0,00 0.01305691 0.01342110 0.00 0.03750000 Model Filename: C:UsersLeneDocumentsArenabachelorbachelor endelig Page 2 of 11
  38. 38. 13:45:22 Category Overview maj 5, 2009 Values Across All ReplicationsSM Electronics Replications: 50 Time Units: MinutesEntity Time VA Time Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValuePart A 0.9670 0,01 0.8575 1.0911 0.00 3.0040Part B 1.0071 0,01 0.9105 1.0529 0.00 2.8038Part C 0.9135 0,01 0.8661 0.9548 0.00 2.8785 NVA Time Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValuePart A 0.00 0,00 0.00 0.00 0.00 0.00Part B 0.00 0,00 0.00 0.00 0.00 0.00Part C 0.00 0,00 0.00 0.00 0.00 0.00 Wait Time Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValuePart A 40.2441 0,65 35.3891 46.2952 0.00 81.2402Part B 47.2050 0,33 43.6137 48.7974 0.00 83.6583Part C 43.7199 0,26 41.1690 45.6697 0.00 82.2126 Transfer Time Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValuePart A 2.2339 0,03 1.9873 2.5100 0.00 6.2050Part B 2.5645 0,02 2.3122 2.6805 0.00 6.6809Part C 2.3882 0,01 2.2773 2.5117 0.00 6.6990 Other Time Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValuePart A 3.0922 0,05 2.7457 3.4873 0.00 5.5500Part B 2.5902 0,02 2.3829 2.6869 0.00 4.5333Part C 3.1320 0,02 2.9674 3.2609 0.00 5.4000 Total Time Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValuePart A 46.5372 0,74 40.9796 53.3835 0.00 92.7234Part B 53.3669 0,38 49.2193 55.2177 0.00 92.2647Part C 50.1536 0,29 47.2798 52.3615 0.00 92.1767 Other Model Filename: C:UsersLeneDocumentsArenabachelorbachelor endelig Page 3 of 11
  39. 39. 13:45:22 Category Overview maj 5, 2009 Values Across All ReplicationsSM Electronics Replications: 50 Time Units: MinutesEntity Other Number In Minimum Maximum Average Half Width Average AveragePart A 1708.80 0,30 1707.00 1711.00Part B 3410.04 0,68 3405.00 3415.00Part 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 Average Half Width Average AveragePart A 1709.90 1,85 1697.00 1722.00Part B 3408.52 2,13 3393.00 3425.00Part C 2398.08 1,23 2389.00 2409.00 WIP Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValuePart A 16.5554 0,27 14.6211 19.0088 2.0000 30.0000Part B 37.9062 0,27 34.9322 39.2276 21.0000 55.0000Part C 25.0426 0,14 23.6132 26.1357 10.0000 38.0000 Model Filename: C:UsersLeneDocumentsArenabachelorbachelor endelig Page 4 of 11
  40. 40. 13:45:22 Category Overview maj 5, 2009 Values Across All ReplicationsSM Electronics Replications: 50 Time Units: MinutesProcess Time per Entity VA Time Per Entity Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValueProcess 2 0.5899 0,00 0.5859 0.5977 0.3506 0.8662Process 7 0.5708 0,00 0.5676 0.5729 0.3673 0.7165 Wait Time Per Entity Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValueProcess 2 0.01075151 0,00 0.00950411 0.01244499 0.00 1.0080Process 7 0.07579734 0,00 0.06733613 0.08117324 0.00 1.2599 Total Time Per Entity Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValueProcess 2 0.6007 0,00 0.5966 0.6083 0.3506 1.5228Process 7 0.6466 0,00 0.6350 0.6529 0.3673 1.8689 Accumulated Time Accum VA Time Minimum Maximum Average Half Width Average AverageProcess 2 2719.11 2,00 2701.91 2731.94Process 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 Model Filename: C:UsersLeneDocumentsArenabachelorbachelor endelig Page 5 of 11
  41. 41. 13:45:22 Category Overview maj 5, 2009 Values Across All ReplicationsSM Electronics Replications: 50 Time Units: MinutesProcess Accumulated Time Accum Wait Time Minimum Maximum Average Half Width Average AverageProcess 2 49.5580 0,94 43.9470 57.4585Process 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 Average Half Width Average AverageProcess 2 4609.36 7,33 4524.00 4649.00Process 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 Average Half Width Average AverageProcess 2 4609.36 7,31 4525.00 4649.00Process 7 4597.86 7,35 4513.00 4640.00 Model Filename: C:UsersLeneDocumentsArenabachelorbachelor endelig Page 6 of 11
  42. 42. 13:45:22 Category Overview maj 5, 2009 Values Across All ReplicationsSM Electronics Replications: 50 Time Units: MinutesQueue Time Waiting Time Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValueLeave Work Station 1.Queue 0.00358265 0,00 0.00332983 0.00386060 0.00 0.7675Leave Work Station 2.Queue 0.00421123 0,00 0.00403889 0.00440867 0.00 0.9374Leave Work Station 3.Queue 0.00362525 0,00 0.00319744 0.00438670 0.00 0.9950Leave Work Station 4.Queue 0.00341479 0,00 0.00317966 0.00374328 0.00 0.9048Leave Work Station 5.Queue 0.00341958 0,00 0.00313982 0.00382948 0.00 0.9113Leave Work Station 6.Queue 0.00406262 0,00 0.00369289 0.00459082 0.00 1.1977Leave Work Station 7.Queue 0.00458415 0,00 0.00446420 0.00476928 0.00 0.6469load point.Queue 0.00 0,00 0.00 0.00 0.00 0.00merge point.Queue 0.00319506 0,00 0.00287445 0.00348787 0.00 0.04131701Process 2.Queue 0.01075072 0,00 0.00950411 0.01244928 0.00 1.0080Process 7.Queue 0.07579870 0,00 0.06732121 0.08117324 0.00 1.2599Queue for load point.Queue 40.1324 0,07 39.7643 40.9238 32.5036 46.6082Seize work Station 1.Queue 0.7759 0,02 0.6267 0.9987 0.00 14.7529Seize Work Station 3.Queue 0.5966 0,01 0.5234 0.7219 0.00 6.2905Seize Work Station 4.Queue 30.7022 0,07 30.3200 31.4282 15.0443 36.9273Seize Work Station 5.Queue 0.2279 0,00 0.1995 0.2500 0.00 1.9934Seize Work Station 6.Queue 0.1270 0,00 0.1145 0.1383 0.00 1.6000 Other Number Waiting Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValueLeave Work Station 1.Queue 0.00344038 0,00 0.00314107 0.00372415 0.00 1.0000Leave Work Station 2.Queue 0.00404399 0,00 0.00387137 0.00425412 0.00 1.0000Leave Work Station 3.Queue 0.00348178 0,00 0.00306421 0.00423957 0.00 2.0000Leave Work Station 4.Queue 0.00327096 0,00 0.00304188 0.00355846 0.00 2.0000Leave Work Station 5.Queue 0.00327571 0,00 0.00299591 0.00369146 0.00 2.0000Leave Work Station 6.Queue 0.00389162 0,00 0.00347209 0.00438040 0.00 2.0000Leave Work Station 7.Queue 0.00439120 0,00 0.00425351 0.00459937 0.00 1.0000load point.Queue 0.00 0,00 0.00 0.00 0.00 1.0000merge point.Queue 0.00306048 0,00 0.00276666 0.00334690 0.00 2.0000Process 2.Queue 0.01032382 0,00 0.00915562 0.01197465 0.00 2.0000Process 7.Queue 0.07262165 0,00 0.06330999 0.07828780 0.00 2.0000Queue for load point.Queue 38.4369 0,00 38.4148 38.4712 35.0000 40.0000Seize work Station 1.Queue 0.7299 0,02 0.5850 0.9462 0.00 15.0000Seize Work Station 3.Queue 0.5726 0,01 0.5056 0.6951 0.00 8.0000Seize Work Station 4.Queue 29.4726 0,03 29.2617 29.7265 14.0000 34.0000Seize Work Station 5.Queue 0.2184 0,00 0.1887 0.2415 0.00 3.0000Seize Work Station 6.Queue 0.1217 0,00 0.1084 0.1337 0.00 3.0000 Model Filename: C:UsersLeneDocumentsArenabachelorbachelor endelig Page 7 of 11
  43. 43. 13:45:22 Category Overview maj 5, 2009 Values Across All ReplicationsSM Electronics Replications: 50 Time Units: MinutesResource Usage Instantaneous Utilization Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValueWork Station 1 0.9348 0,00 0.9235 0.9401 0.00 1.0000Work Station 2 0.5665 0,00 0.5629 0.5692 0.00 1.0000Work Station 3 0.8876 0,00 0.8757 0.9018 0.00 1.0000Work Station 4 1.0000 0,00 1.0000 1.0000 0.00 1.0000Work Station 5 0.9343 0,00 0.9274 0.9386 0.00 1.0000Work Station 6 0.7534 0,00 0.7469 0.7613 0.00 1.0000Work Station 7 0.5468 0,00 0.5337 0.5522 0.00 1.0000 Number Busy Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValueWork Station 1 0.9348 0,00 0.9235 0.9401 0.00 1.0000Work Station 2 0.5665 0,00 0.5629 0.5692 0.00 1.0000Work Station 3 0.8876 0,00 0.8757 0.9018 0.00 1.0000Work Station 4 1.0000 0,00 1.0000 1.0000 0.00 1.0000Work Station 5 0.9343 0,00 0.9274 0.9386 0.00 1.0000Work Station 6 0.7534 0,00 0.7469 0.7613 0.00 1.0000Work Station 7 0.5468 0,00 0.5337 0.5522 0.00 1.0000 Number Scheduled Minimum Maximum Minimum Maximum Average Half Width Average Average Value ValueWork Station 1 1.0000 0,00 1.0000 1.0000 1.0000 1.0000Work Station 2 1.0000 0,00 1.0000 1.0000 1.0000 1.0000Work Station 3 1.0000 0,00 1.0000 1.0000 1.0000 1.0000Work Station 4 1.0000 0,00 1.0000 1.0000 1.0000 1.0000Work Station 5 1.0000 0,00 1.0000 1.0000 1.0000 1.0000Work Station 6 1.0000 0,00 1.0000 1.0000 1.0000 1.0000Work Station 7 1.0000 0,00 1.0000 1.0000 1.0000 1.0000 Model Filename: C:UsersLeneDocumentsArenabachelorbachelor endelig Page 8 of 11

×