Studie van een gemodifieerd bucket brigade concept op...

Tom Van Steertegem

basis van parallel werkstationsStudie van een gemodifieerd bucket brigade concept op

Academiejaar 2009-2010Faculteit IngenieurswetenschappenVoorzitter: prof. dr. ir. Hendrik Van LandeghemVakgroep Technische bedrijfsvoering

Master in de ingenieurswetenschappen: computerwetenschappen Masterproef ingediend tot het behalen van de academische graad van

Begeleiders: ir. Joris April, Kurt De CockPromotor: prof. dr. ir. Dirk Van Goubergen

Voorwoord

In dit voorwoord zou ik graag van de gelegenheid gebruik willen maken om alle mensente bedanken die, rechtstreeks of onrechtstreeks, hebben bijgedragen tot de voltooiing vandeze masterproef.

In het bijzonder wens ik Prof. Van Goubergen te bedanken voor het creeren van demogelijkheid om een masterproef te voltooien in overeenstemming met mijn interesses.Daarnaast ben ik ook Joris erg dankbaar voor de opvolging van deze masterproef, en hetbijsturen waar nodig; ook bedank ik Kurt voor zijn bijdrage aan deze masterproef.

Niet het minst gaat mijn dank ook algemeen uit naar het bedrijf Van Hoecke voor degeboden opportuniteit, en specifiek naar mevr. Sophie Verhaert als zeer geapprecieerdaanspreekpunt binnen Van Hoecke. Ook de mensen rondom de Halux-productielijn wil ikgraag bedanken voor hun hulp en uitleg, en in het bijzonder de operatoren Robby, Haliseen Eli.

Tom Van Steertegem, 20 augustus 2010

i

VOORWOORD ii

“If you do what you’ve always done, you’ll get what you’ve always gotten.”Tony Robbins

Toelating tot bruikleen

“De auteur en promotor geven GEEN toelating deze masterproef voor consultatie beschik-baar te stellen en/of delen ervan te kopieren voor persoonlijk gebruik. Elk ander gebruikvalt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot deverplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit dezemasterproef.”

“The author and promoter DO NOT give the permission to use this thesis for consultationand/or to copy parts of it for personal use. Every other use is subject to the copyrightlaws, more specifically the source must be extensively specified when using results fromthis thesis.”

Tom Van Steertegem, 20 augustus 2010

iii

Studie van een gemodifieerd

bucket brigade concept

op basis van parallel werkstationsdoor

Tom Van Steertegem

Promotor: prof. dr. ir. Dirk Van Goubergen

Begeleiders: ir. Joris April, Kurt De Cock

Masterproef ingediend tot het behalen van de academische graad van

Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Technische bedrijfsvoering

Voorzitter: prof. dr. ir. Hendrik Van Landeghem

Faculteit Ingenieurswetenschappen

Universiteit Gent, Academiejaar 2009-2010

Samenvatting

“Bucket Brigade productielijnen” zijn seriele productielijnen die op een bijzondere manierzijn georganiseerd: de werkers voltooien producten langsheen de verschillende werkstationsen houden zich hierbij aan enkele eenvoudige regels. Een dergelijke opstelling blijkt vaakbijzonder doeltreffend in verschillende opzichten (productiesnelheid, flexibiliteit, work-in-process, . . . ), en zal bovenal zonder externe tussenkomst zichzelf organiseren, totdat demeest optimale manier van werken (onder dit model) is bereikt. In deze masterproef wordthet concept uitgebreid tot productielijnen waarbij een deel van het werk in parallel kangebeuren. Ook werd een softwarematig simulatiemodel ontworpen, waarmee de verschil-lende opstellingen en verwachte resultaten experimenteel kunnen worden geverifieerd. Totslot zal dit simulatiemodel worden gebruikt om een aantal openstaande vragen over eenreal-life case te beantwoorden.

Trefwoorden

Bucket Brigade, parallelle werkstations, simulatie, productielijnen, werkverdeling

Study of a modified bucket brigade concept basedon parallel workstations

Tom Van Steertegem

Supervisor(s): Dirk Van Goubergen, Joris April, Kurt De Cock

Abstract— Under bucket brigades, a production line is or-ganised in a special manner; each worker follows some simplerules, and so the line becomes self-balancing and reachesgood, possibly optimal, throughput. Mostly, a serial andwell-defined order of stations is assumed. In this article, weextend the original concept of bucket brigades with parallelworkstations. Our results will be checked with the help ofour developed software model, capable of simulating almostany ideal and realistic situation.

Keywords— bucket brigade production, parallel worksta-tions, simulation, production line, work sharing

I. Introduction

Bucket Brigade production lines have been introduced byBartholdi and Eisenstein [1]. Along a production line, eachworker continues work on his item (unless he is blocked),and follows 2 simple rules:Forward rule: Work forward at your item along the dif-ferent workstations. If your work is taken by a successor(or when you reach the end of the line), leave the item be-hind and follow the “backward rule”.Backward rule: Walk back along the production line.When you encounter another worker (are at the begin ofthe line), take over his work (start a new product) andfollow the “forward rule”.

Under the condition that the workers are sequenced fromslowest to fastest along the line (= convergence condition),and the assumption that walk-backs are instantaneous, thesystem converges without management intervention (it willbe self-organising) and after a short period of convergence,to stable handover points and a stable production rate.When the work content of the stations is well chosen sothat no workers block (waiting for a station) in steady-state, workers invest the same clock time in each item, andthe production rate will be the best achievable.

When the convergence condition isn’t respected, the pro-duction rate may drop significantly, and leads to a systemwith no stability at all. The randomness of the line cycletime is shown in Fig. 1.

II. Continuous workstation

One assumption of the classic model of bucket brigades,is that at any station exactly one worker is required tocomplete the tasks at that station, and each station maybe occupied by at most one worker. This may leave workerswaiting for a station to become available. To avoid suchblocking, we introduce a continuous workstation as an infi-nite sequence of infinitesimal workstations, with as sum ofthe infinitesimal work contents, the original work content

0

50

100

150

200

250

300

350

400

0 10 20 30 40

Fig. 1. Random line cycle time when the convergence condition isnot respected

of the (ordinary) workstation it replaces. At such a con-tinuous workstation, an arbitrary number of workers canwork simultaneously. This can instinctively be seen as anassembly line where each manipulation is small enough.

III. Parallel workstations

While classic bucket brigade production lines assumethat the stations are sequenced in a serial way, one canimagine the need to duplicate one or more stations to avoidblocking workers and so speeding up the production rate.We will denominate such a sequence of duplicated stationsa “parallel path”.

1 2 . . .

p1;1

p1;2

p2;1

p2;2

. . . m

parallel path 1

parallel path 2

Fig. 2. Simple production line with parallel paths

Under bucket brigade(-alike) working methods, workershave to handover work to a successive worker that has fin-ished his work or has handed over his own work. Such ahandover poses no problem when the line is simply serial,but will require clear rules on what station to visit next(working forward or walking backward) in case of parallel-lism. We assume the following rules:Working forward: If all paths are empty, make an arbi-trary choice. If one or more workers are already workingalong a path, choose the path where the worker closest tothe start of the line has the furthest progress.Walking backward: If all paths are empty, make an ar-bitrary choice. If one or more workers are already workingalong a path, choose the path where the worker closest tothe end of the line has the furthest progress.

We notice that there are two options for handovers:Mutually between paths: workers break the idea ofpaths and (try to) handover with the previous (in order)furthest progressed worker along another path (see Fig. 3).

0 awk1

wk3

wk2

wk4

Fig. 3. Handover mutually between paths

Along the paths: workers walk back following thepaths and handover independently of workers on other par-allel paths (see Fig. 4).

0 a

wk1

wk3

wk2

wk4

Fig. 4. Handover along the paths

In the case of handovers mutually between paths, we findthat the production line with parallel workstations simpli-fies to the parallel workstations being replaced by the previ-ously introduced continuous station, with as many workersallowed as there are parallel paths. The same results as forthe classic modeling apply; however, handovers mutuallybetween paths may be difficult in practice (large distances,progresses may be unclear between production lines, . . . ).

When handovers occur along the path, we find that thebehaviour of the line (handoff points, line cycle time) isquasi-periodic after a convergence period: the same be-haviour occurs every x cycles (see Fig. 5). When we cal-culate the moving average of the production rate, we againfind that the line converges to a good throughput and incase no blocking occurs in steady-state, an optimal produc-tion rate.

50

100

150

200

0 10 20 30 40 50

Fig. 5. Quasi-periodic (orange) line cycle time of a production linewith parallel workstations. Moving average line cycle time con-verges after a convergence period (blue).

IV. Simulation model

The simulation model uses discrete event simulation, andis programmed in Java [2]. It is developed to be able to sim-

ulate some ideal bucket brigade systems, as well as real lifecases. Moreover, the program should be accessible enoughto allow further development if needed.

Again, bucket brigade production lines appear to be avery robust way of working in numerous settings. Oneassumption we can make, is that stations are separated bypaths with a well-defined length, and workers have a finitewalking speed along them. Our simulation model showsthat the line cycle time again converges to a stable value(Fig. 6).

60

80

100

120

140

160

180

200

0 10 20 30 40 50

Fig. 6. System convergence when using paths

We achieve a spectacular result when we introduce faultdetection along the stations: at a particular station onediscovers that an error has been introduced at an earlierstage. This error leads to an additional processing time.We simulated a situation where (on average though ran-domly introduced) 1 per 25 products appeared erroneous,and led to a (deterministic) additional work penalty of 25s.In the graph below (Fig. 7), the fault detection is clearlyvisible, leading to a disturbance of the equilibrium, afterwhich the system converges (exponentially fast) to a stablesystem.

60

80

100

120

140

160

180

200

0 50 100 150

Fig. 7. Line cycle time when introducing fault detection

V. Case study

We applied the gained knowledge about bucket brigades(an specifically parallel workstations) to solve some man-agement questions about a real-life bucket brigade produc-tion line of aluminium doorframes, where one step (assem-bly/packaging) occured in parallel due to the high cycletime.

References

[1] J.J. Bartholdi, III and D.D. Eisenstein, A production line thatbalances itself, Operations research, 44(1), (1996), 21-34.

[2] http://www.java.com/

Inhoudsopgave

Voorwoord i

Toelating tot bruikleen iii

Overzicht iv

Extended abstract v

Inhoudsopgave vii

1 Inleiding 1

2 Bucket Brigades 22.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Klassiek model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2.1 Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2.2 Praktijk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.3 Simulatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Veralgemeend model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.1 Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.2 Praktijk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.3.3 Simulatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 Bucket Brigades met parallelle werkstations . . . . . . . . . . . . . . . . . 222.4.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.2 Voorbeeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4.3 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.4.4 Aanname van het “klassieke model” . . . . . . . . . . . . . . . . . . 242.4.5 Keuze tussen parallelle paden . . . . . . . . . . . . . . . . . . . . . 252.4.6 Overdrachten tussen de paden onderling . . . . . . . . . . . . . . . 252.4.7 Overdrachten langsheen hetzelfde pad . . . . . . . . . . . . . . . . . 28

2.5 Andere variaties op Bucket Brigades . . . . . . . . . . . . . . . . . . . . . 342.5.1 Bucket Brigades met stochastische werktijden . . . . . . . . . . . . 342.5.2 Bucket Brigades met niet-uniforme werksnelheden . . . . . . . . . . 352.5.3 Bucket Brigades met leereffect bij werkers . . . . . . . . . . . . . . 35

vii

INHOUDSOPGAVE viii

2.5.4 Bucket Brigades in de natuur . . . . . . . . . . . . . . . . . . . . . 35

3 Simulatiemodel 363.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2 Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.1 Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.2.2 Configuratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3 Algemene instellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.1 Aantal runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.2 Simulatieduur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.3 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.3.4 Klokfrequentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.3.5 Loglevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.4 Onderdelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.5 Instellingen van items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.5.1 Batchgrootte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.5.2 Productmix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.6 Onderdelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.6.1 Paden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.6.2 Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.6.3 Stations met terugwandelsnelheid . . . . . . . . . . . . . . . . . . . 473.6.4 Verdelers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.6.5 Verdelers volgens label . . . . . . . . . . . . . . . . . . . . . . . . . 503.6.6 Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.6.7 Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.7 Werkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.7.1 Werksnelheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.7.2 Wandelsnelheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.8 Andere bouwblokken van het model . . . . . . . . . . . . . . . . . . . . . . 543.8.1 Distributies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.8.2 Package help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.9 Uitvoeren simulatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.9.1 Nauwkeurigheid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.10 Uitbreidingen, verbeteringen . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4 Enkele simulaties in de praktijk 634.1 Stations gescheiden door paden, eindige wandelsnelheid . . . . . . . . . . . 634.2 Stations met stochastische werkinhoud . . . . . . . . . . . . . . . . . . . . 644.3 Stations met overdrachtstijden . . . . . . . . . . . . . . . . . . . . . . . . . 654.4 Items met verschillend padverloop . . . . . . . . . . . . . . . . . . . . . . . 674.5 Items met rework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.6 Vergelijking overdrachten bij parallelle paden . . . . . . . . . . . . . . . . . 68

INHOUDSOPGAVE ix

5 Case study 705.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.2 Situatieschets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705.3 Tijdsmetingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.3.1 De Cauchy-verdeling . . . . . . . . . . . . . . . . . . . . . . . . . . 755.3.2 Post 1: Voorraad aluminium . . . . . . . . . . . . . . . . . . . . . . 755.3.3 Post 2 (2a + 2b): zagen . . . . . . . . . . . . . . . . . . . . . . . . 765.3.4 Post 3: Frees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775.3.5 Post 4: Dichtingen . . . . . . . . . . . . . . . . . . . . . . . . . . . 785.3.6 Post 5: Boor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.3.7 Post 6: assemblage . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.3.8 Post 7: Verpakken . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.4 Abstractie voor simulatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.5 Simulatie standaardopstelling . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.5.1 Instellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.5.2 Simulatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.5.3 Werkverdeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 835.5.4 Bufferbezetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 845.5.5 Gemiddelde werkinhouden . . . . . . . . . . . . . . . . . . . . . . . 845.5.6 Bespreking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.6 Vraagstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 865.7 Bespreking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

5.7.1 Is dit optimaal? Is er verbetering mogelijk? . . . . . . . . . . . . . 865.7.2 Beste manier van overdragen aan assemblage? . . . . . . . . . . . . 915.7.3 Beste manier om rework op te vangen? . . . . . . . . . . . . . . . . 935.7.4 Wat is de impact van niet werken volgens werksnelheid? . . . . . . 945.7.5 Hoe kan post verpakken best worden ingepast? . . . . . . . . . . . . 99

A Configuratiedetails 102

B Details simulaties 115

Bibliografie 124

Hoofdstuk 1

Inleiding

Bucket Brigade productielijnen zijn zeer aantrekkelijk als productiesysteem, door de inhe-rente flexibiliteit om zich aan te passen aan veranderende omstandigheden, en dit op eenspontane, niet-centraal gecoordineerde manier. Ook is men zeker dat wanneer men zichaan enkele eenvoudige voorwaarden onderwerpt, het systeem exponentieel snel naar eenstabiele toestand evolueert, en dat dit de meest snelle manier zal zijn om een welbepaaldproduct te produceren met x aantal werkers.

Klassieke Bucket Brigade productielijnen zullen in de praktijk echter zelden tot nooit voor-komen, door de ideale manier waarop ze min of meer kunstmatig zijn geconstrueerd. Zobetekent elke niet-deterministische werkinhoud van een station, een flinke afwijking van hetklassieke model. Elke dergelijke afwijking maakt een zuiver mathematische voorspellingvan het systeemgedrag moeilijk, zoniet onmogelijk.

Realistische productielijnen die zijn geınspireerd op het Bucket Brigade-principe, lenen zichechter uitstekend tot simulaties op computer. Dit zal toelaten om verschillende opstellingenop een handige manier onderling te vergelijken, en hiermee een afdoende, zoniet optimaleoplossing te vinden.

Deze masterproef behelst een studie van het klassieke model van Bucket Brigades, alsookhet creeren van een stuk software om meer algemene Bucket Brigade productielijnen te gaansimuleren, in het bijzonder productielijnen met een werkgedeelte in parallel. De modellenworden getoetst aan de resultaten bekomen met de software; zo kan zowel de juistheidvan de modellen experimenteel worden bevestigd, als de software worden geverifieerd opcorrectheid.

Dit werk bestaat uit 4 belangrijke delen. Vooreerst wordt het concept Bucket Brigadestheoretisch-praktisch benaderd in zijn verschillende modellen. Vervolgens zal het soft-warematige simulatiemodel worden overlopen en besproken. Hierna simuleren we enkelesystemen, en tot slot zal de case worden toegelicht en opgelost.

1

Hoofdstuk 2

Bucket Brigades

2.1 Algemeen

Een Bucket Brigade, soms vertaald als “emmerbrigade”, is in oorsprong een menselijkeketting met de bedoeling items te transporteren langsheen een ketting van stationair ge-plaatste mensen. Een klassiek voorbeeld hiervan is het blussen van een brand, door eenmenselijke ketting te vormen tussen water en de brand. Langsheen de ketting worden volleemmers als bluswater aangevoerd, en lege emmers afgevoerd om opnieuw te vullen.

Hier zullen Bucket Brigade productielijnen worden beschreven. Langsheen dergelijke pro-ductielijnen zullen werkers een of meerdere items (orders, producten,...) voltooien oververschillende stations (voorraadrekken, machines,...), zonder daarbij noodzakelijkerwijs ge-bonden te zijn tot welbepaalde zones of stations.

In dit hoofdstuk zullen hoofdzakelijk de 3 bucket brigade modelleringen worden besproken(in logische volgorde) die een praktisch belang zullen hebben in deze masterproef: hetklassieke model, het veralgemeende model en het zelf geformaliseerde model met parallellewerkstations. Telkens zullen de modellen in theorie worden benaderd, zal de toepassing inde praktijk worden overschouwd en zullen de modellen (en omgekeerd de software) wordengeverifieerd door simulatie. Het hoofdstuk wordt afgesloten met een korte samenvattingvan variaties op bucket brigades die werden bestudeerd, doch hier van minder belang zijn.

Het ontwikkelde softwarematige simulatiemodel zal in dit hoofdstuk worden geıntroduceerdzonder meer; enkel de resultaten zullen worden gebruikt en besproken, hoewel de configu-ratiedetails zullen worden opgenomen in bijlage. Voor een uitgebreide bespreking van hetsimulatiemodel en bijbehorende instellingen wordt verwezen naar Hoofdstuk 3.

2

HOOFDSTUK 2. BUCKET BRIGADES 3

2.2 Klassiek model

2.2.1 Theorie

Het klassieke model, ook wel normatief model genoemd, van Bucket Brigade productielijnenwerd beschreven in de paper “A production line that balances itself”[1] door John J.Bartholdi en Donald D. Eisenstein. Er wordt vertrokken van een seriele productielijn waarn werkers bewegen langsheen m vast geordende werkstations, met n < m.

1 2 . . . m

Figuur 2.1: Eenvoudige seriele productielijn bestaande uit m stations

Onder een seriele productielijn wordt een productielijn verstaan waar alle stations eendui-dig in serie1 zijn geplaatst. Een voorbeeld van een seriele productielijn met m stationswordt getoond in Figuur 2.1.

Er is geen gecentraliseerd management nodig over de lijn: elke werker werkt onafhankelijken transparant volgens 2 uiterst eenvoudige regels:

Voorwaartse regel (Eng.: forward rule)Werk aan eenzelfde product (item) over verschillende werkstations. Als je pro-duct wordt overgenomen door een volgende werker (of wanneer het is voltooid),laat het achter en volg de “achterwaartse regel”.

Achterwaartse regel (Eng.: backward rule)Wandel terug langsheen de productielijn. Wanneer je een vorige werker tegen-komt (of wanneer je aan het begin van de productielijn bent aangekomen), neemzijn product over (start een nieuw product) en volg de “voorwaartse regel”.

In het klassieke model zullen de werkers elkaar nooit inhalen; dit betekent dat hun volgordewordt vastgelegd bij het begin, en daaropvolgend niet zal wijzigen. Wanneer een werkeraan het einde van de productielijn komt, laat hij zijn afgewerkte product achter en wandelthij terug om het werk van zijn voorligger over te nemen, die op zijn beurt het werk vanzijn voorligger overneemt enzoverder, tot de eerste werker een nieuw product begint; opeen dergelijk ogenblik reset de lijn zich.

Elke werker i langsheen de lijn wordt gekenmerkt door zijn werksnelheid vi en zijn positiexi (volgorde). De positie xi is het percentage voltooide werk t.o.v. de totale werkinhoud

1Analoog de serieschakeling bij elektronische configuraties, of eenvoudigweg “na elkaar”


van een item. De werkers worden tevens verondersteld oneindig snel (terug) te wandelen.Dit laatste betekent dat elke werker voortdurend ook effectief werkt, tenzij hij geblokkeerdwordt (station onbeschikbaar, geblokkeerd door een voorligger, . . . ).

Wanneer de positie van werkers aan een productielijn grafisch dient te worden weergegeven,zal dat in wat volgt gebeuren zoals in Figuur 2.2. De totale werkinhoud a van een item2

wordt voorgesteld als het lijnsegment tussen 0 en a, en zal worden onderverdeeld in inter-vallen die corresponderen met de werkinhoud van de stations si langs deze productielijn.De positie van de werkers wordt voorgesteld als xi.

0 as1 s2 sm

x1 x2 xn

Figuur 2.2: Grafische weergave van de positie van werkers

De werksnelheid vi van een werker is eenheidsloos, omdat ze is gedefinieerd relatief t.o.v.1. Een werker met snelheid 1 zal even lang werken aan een station dan de werkinhoudvan dat station aangeeft; een werker met snelheid 2 zal dubbel zo snel klaar zijn aandatzelfde station dan de werker met snelheid 1. Om deze reden wordt voortaan nergensmeer het begrip cyclustijd van een station gebruikt: deze cyclustijd (om de hoeveel tijd eenstation een voor hem afgewerkt product produceert) is immers afhankelijk van de werkeraan het station werkt. We spreken dan ook over de standaard werkinhoud, of kortweg dewerkinhoud van een station.

Er wordt in het klassieke model bovendien aangenomen dat:

• Aan elk station slechts een werker tegelijk kan werken, het werk aan een stationexact een werker vereist, en er meer stations zijn dan werkers (zoniet zullen er steedswerkers geblokkeerd zijn).

• Het werk aan een station kan worden overgenomen (afgebroken) zonder tijdsverlies.

• De werksnelheid vi constant is langsheen de productielijn, en is bovendien niet bij-zonder (oneindig) klein of bijzonder groot.

De volgende convergentievoorwaarde wordt vooropgesteld:

Iedere werker langsheen de productielijn wordt gerangschikt volgens zijn werk-snelheid vi, waarbij de traagste werker als eerste aan de lijn plaatsneemt, en desnelste werker als laatste:

v1 < v2 < . . . < vn−1 < vn

2Meestal zou de totale werkinhoud worden genormaliseerd tot 1 voor de eenvoud van voorstellen, endus zou a = 1. Voor de eenvoud van simulatie, en om redenen van eenduidigheid t.o.v. de realistischecase study, zal in deze masterproef consequent van deze normalisatie worden afgeweken; de eigenlijkewerkinhoud van de stations (cyclustijden) worden gebruikt.


Onder de gemaakte aannames en mits respecteren van de convergentievoorwaarde, blijkt:

1. dat er unieke posities xi bestaan waar telkens de overdracht gebeurt aan een stationwanneer de lijn reset, na een zekere inlooptijd met overgangsverschijnselen.

2. wanneer er geen werkers blokkeren, convergeert de lijn exponentieel snel naar dezeunieke overdrachtsposities (anders geformuleerd: de overgangsverschijnselen stervenexponentieel snel uit).

3. bij vaste overdrachtsposities en wanneer er geen werkers blokkeren, zal de productie-snelheid de hoogst haalbare zijn, en worden gegeven door v

tijdseenheid, met v =

∑ni=1 vi.

Er worden dan v producten per tijdseenheid3 afgewerkt.

Het is zeer belangrijk op te merken dat het klassieke model geen uitspraken doet over devoorwaarden waaronder er geen werkers zullen blokkeren. Er wordt enkel gezegd dat deoverdrachtspunten uniek zijn (dit geldt immers ook bij blokkerende werkers, zij zullen bijelke cyclus gedurende dezelfde periode en op dezelfde plaats blokkeren), en dat wanneer ergeen blokkeringen zijn, de overgangsverschijnselen exponentieel snel zullen uitsterven ende productiesnelheid optimaal zal zijn.

Blokkeringen

Een werker zal in het klassieke model blokkeren, wanneer het station waaraan hij wilstarten met werken nog in gebruik is door een volgende werker. Beschouw als voorbeeldFiguur 2.3. Deze figuur stelt een productielijn voor met 2 werkers (wk1, wk2) en 3 stations(s1, s2, s3). De werksnelheid v1 van wk1 zal kleiner zijn dan de werksnelheid v2 van wk2.Deze productielijn zal dus convergeren naar (o.a.) een vast overdrachtspunt, dat we hieraanduiden als o1;2.

0 as1 s2 s3

o1;2

Figuur 2.3: Voorbeeld van een productielijn met 2 werkers en 3 stations

In stabiele toestand zal wk1 telkens opnieuw werken in het interval [0; o1;2], en werker wk2

in [o1;2; a]. Het is gemakkelijk in te zien dat wk1 na elke reset van de lijn een tijdje zalblokkeren: bij een reset wandelt wk2 (oneindig snel) terug en zal wk1 ontmoeten ter hoogtevan o1;2. Op dat moment zal wk1 zijn product afstaan en (oneindig snel) terugwandelennaar positie 0 om een nieuw product te beginnen. Station s1 zal echter niet beschikbaar zijnvoor wk1, zolang wk2 zich binnen het interval [o1;2; s1] bevindt (of dus werkt aan station

3= de totale werkinhoud van alle stations


s1). Werker wk1 zal zolang aan het begin van de lijn blokkeren, als de tijd die wk2 nodigheeft aan station s1.

Het zal dus belangrijk zijn om blokkeringen zoveel mogelijk te vermijden, zeker in stabieletoestand. Dat kan door de werkinhoud van de stations goed te kiezen, of een voldoendeaantal stations te kiezen.

0 as1 s2 s3

o1;2

(a) Goed gekozen werkinhouden

0 as1 s2 s3 s4

o1;2

(b) Kiezen van een voldoende aantal stations

Figuur 2.4: Voorbeeld van een productielijn met 2 werkers en 3 stations

In Figuur 2.4 worden de aangehaalde oplossingen voor het vermijden van blokkeringengrafisch weergegeven. In beide gevallen zal wk1 bij een reset van de lijn nu onmiddellijkkunnen beginnen werken aan station s1.

Merk op dat het kiezen van een goede oplossing niet altijd even rechttoe rechtaan is.

• Bij het opheffen van een blokkering in een praktisch geval zullen ook de overdrachts-punten opschuiven. In de nieuwe evenwichtssituatie zal wk1 immers meer werk ver-richten, en zou het punt o1;2 dus verder opschuiven naar rechts. Dit zou kunnenleiden tot nieuwe blokkeringen.

• Door deze betere keuze, zou het kunnen dat wk1 nu niet meer zal hoeven te wachtenop station s1, maar wel bv. op station s2 als wk2 (bv. in Figuur 2.4(a)) onvoldoendesnel voortwerkt aan station s2.

Om een goede oplossing te creeren kan best worden uitgegaan van de optimale situatiezonder blokkeringen. De werkintervallen (en hieruit de overdrachtspunten) zijn dan im-mers zeer gemakkelijk te berekenen: voor 2 werkers met werksnelheden v1 en v2 aan eenproductielijn met totale werkinhoud a, zullen de werkers respectievelijk intervallen metlengte v1

v1+v2a en v2

v1+v2a afwerken. Het overdrachtspunt zal dan liggen op v1

v1+v2a. Men kan

de werkinhoud van de stations navenant kiezen, en prima inschatten (a.d.h.v. de werkin-tervallen) hoe snel een bepaalde werker een station zal verlaten om geen nieuwe blokkeringte creeren.

De plaats van overdrachtspunten kan ook algemeen uitgebreid worden voor n werkers langseen productielijn met totale werkinhoud a. De plaats van het overdrachtspunt tussen


werker wki en wki+1, of kortweg oi;i+1, ligt op:

oi;i+1 = a

∑ik=1 vk∑nk=1 vk

De oplossingen die zijn aangedragen in Figuur 2.4, kunnen dan weer ontoereikend zijn wan-neer we het aantal werkers wijzigen, bv. wanneer we een extra snelle werker toevoegen aanhet einde van de productielijn. Het aantal overdrachtspunten zal dan met een toenemen,en het oude overdrachtspunt zal opschuiven naar links. We zullen dan zeer waarschijnlijkopnieuw het aantal stations moeten doen toenemen, of de werkinhouden opnieuw beterkiezen.

De meest eenvoudige manier om zo weinig mogelijk moeite te hebben met het goed kiezenvan werkinhouden van stations t.o.v. wisselende overdrachtspunten, is meteen een vol-doende aantal stations te kiezen. Deze redenering leidde tot het gebruik van een nieuwconcept: het continue station.

Continu station

Veronderstel opnieuw het blokkeringsprobleem uit Figuur 2.3, en beschouw meer specifiekhet “probleemstation” s1. Een oplossing voor het blokkeren was s1 op te splitsen in meer-dere stations; in de limiet zouden we dit station kunnen opsplitsen in een oneindig aantalinfinitesimale deelstations met als (oneindige) som van werkinhouden de oorspronkelijkewerkinhoud van station s1.

Aan elk van deze (oneindig aantal) deelstations zal slechts een werker kunnen werken zoalsde aanname vereist. Als we nu dit oneindige aantal infinitesimale deelstations groeperentot een continu station, dan kunnen aan dit continue station oneindig veel werkers werken;aangezien elk deelstation slechts een infinitesimale werkinhoud heeft, zal een werker ditstation ook maximaal een infinitesimale tijd bezetten, of anders geformuleerd, kunnen deoverdrachtspunten langs dit continue station op eender welke (doch welgedefinieerde) plaatsvoorkomen.

Langs een dergelijk continu station kunnen dus zoveel werkers werken als nodig, en kunnenoverdrachtspunten vrij voorkomen zonder dat ze leiden tot blokkeringen van werkers. Nietsweerhoudt ons om alle bestaande (ordinaire) stations langs een productielijn te vervangendoor een continu station, met als werkinhoud de som van de werkinhouden van voorheen.

Het idee van een continu station strookt intuıtief bijvoorbeeld met de praktische situatie vaneen voorraadlijn, waarlangs een voldoende groot aantal (kleine) producten wordt gepicked,en waarbij elke handeling voldoende kort is. Elke pick kan dan worden aanzien als aan eenstation met een zeer kleine werkinhoud. Als elke handeling dan maar voldoende kort is,zal een station telkens slechts voldoende kort worden bezet, en kan een werker maximaalvoldoende kort blokkeren.


Voordelen van Bucket Brigades

De voordelen van een werkwijze volgens het klassieke Bucket Brigade model, zijn belangrijk:

• Een dergelijke opstelling convergeert dus exponentieel snel tot een stabiel systeem,met een stabiele, optimale en voorspelbare productiesnelheid ; deze productiesnelheidis eenvoudig aan te passen door werkers aan de lijn toe te voegen of van de lijn wegte halen.

• Wanneer wijzigingen worden doorgevoerd (zoals een werker toevoegen of wegnemen),zal het systeem (bij afwezigheid van blokkeringen) exponentieel snel naar een nieuwestabiele toestand evolueren; dit maakt het systeem erg flexibel.

• Doordat elke werker slechts een zeer lokaal zicht hoeft te hebben op de productielijn(hij hoeft immers slechts 2 zeer eenvoudige regels te volgen), is er geen overkoepelend,sturend orgaan nodig: de lijn balanceert zichzelf, zonder externe tussenkomst.

• In dit model zullen zich ook geen tussenvoorraden opstapelen, en wordt het werk inbehandeling (Eng.: work in process) tot het strikte minimum gehouden.

Chaotisch gedrag van bucket brigades

De vereiste dat werkers dienen te worden gerangschikt volgens hun werksnelheid, metde meest snelle werker laatst op de lijn, is erg belangrijk. Zonder deze ordening, is hetwaarschijnlijk dat de lijn nooit zal evolueren naar een stabiel systeem, met een onstabieleen/of dus suboptimale productiesnelheid tot gevolg.

Een dergelijk onstabiel systeem vertoont in het slechtste geval chaotisch gedrag: de over-drachtspunten en de productiesnelheid wisselt ogenschijnlijk totaal willekeurig. In het bes-te geval vertoont de productielijn quasi-periodiek gedrag: een bepaalde opeenvolging vanoverdrachtspunten (en lijncyclustijden) treedt elke x cycli op. Hoewel het quasi-periodiekegedrag dan wel mag voorspelbaar zijn (hetzelfde gedrag herhaalt zich immers elke x cycli),zal het niet-stabiel zijn. Quasi-periodiek gedrag, zeker met een korte periode, zal echterbeter zijn dan chaotisch gedrag, omdat werkers zich hierop beter kunnen instellen (bv.door leereffect).

Wanneer werkers onoordeelkundig aan de productielijn worden toegevoegd, kan dit zelfsleiden tot een (forse) daling van de productiesnelheid, anders dan een verbetering: wanneeraan het einde van een lijn een zeer trage werker wordt toegevoegd, zal deze laatste ook hettempo aan het laatste station (de laatste stations) bepalen; alle snellere werkers vroegerop de lijn zullen beginnen blokkeren, met een daling van de productiesnelheid tot gevolg.

2.2.2 Praktijk

De aannames die het klassieke model maakt, lijken niet of moeilijk toepasbaar op eenrealistische situatie. In een aantal opstellingen echter, zal de realiteit voldoende dicht


liggen bij de gemaakte aannames, zodat ook het klassieke Bucket Brigade model praktischetoepassing kent.

Een typisch voorbeeld is een lijn, waarlangs werkers een order gaan picken onder gunstiggeorganiseerde omstandigheden. Immers:

• wanneer de te picken items goed zijn georganiseerd, zal de totale wandelafstandverwaarloosbaar zijn t.o.v. de totale tijd nodig om het gehele order te picken.

• de overdrachtstijd van een pickorder kan voldoende klein worden gehouden.

• bij een gelijkaardige opstelling van te picken items zal de werksnelheid vrijwel con-stant zijn gedurende de lijn.

• wanneer het aantal te picken goederen telkens gelijkaardig is, zal de totale werktijdgelijkaardig (en bij uitbreiding deterministisch) zijn.

Algemeen zullen Bucket Brigade productielijnen meest aangewezen zijn bij een aantal ken-merken van een welbepaalde productielijn[2]:

• Het uit te voeren werk is in essentie een variatie op een bepaalde vaardigheid. Opdatde werkers flexibel moeten kunnen bewegen langsheen de verschillende werkstations,moet hij ook over de vaardigheden beschikken om vlot en uniform aan al deze werk-stations te kunnen werken. Het is ook nodig om werkers ondubbelzinnig te kunnenordenen volgens het enige doch noodzakelijke criterium: werksnelheid.

• Er is een grote variatie in de vraag. Bucket Brigade productielijnen zijn zeer flexi-bel; door werkers toe te voegen of weg te nemen, kan de productiesnelheid snel ennauwkeurig worden gestuurd. Bovendien werken Bucket Brigade productielijnen vol-gens het Pull -principe[3]: de work in process is minimaal, en dit zowel globaal (overde hele lijn) als lokaal (per werkzone bekeken). Een nieuw item wordt slechts ge-start wanneer een item wordt beeindigd, en nergens treden tussenvoorraden op: dedoorlooptijd (Eng.: production lead time) wordt beperkt gehouden.

• Werkers moeten snel kunnen wisselen van station, en snel werk kunnen overnemenvan een andere werker. Dit is noodzakelijk voor een goede en efficiente werking vande productielijn. Zonder dit kenmerk zal er teveel tijd verloren gaan aan wandelen(verplaatsingen) en/of aan overdracht van werk.

2.2.3 Simulatie

3 werkers, 5 goedgekozen stations

Het softwarematige simulatiemodel laat toe om werkers een oneindige wandelsnelheid tegeven, en een welbepaalde werksnelheid (relatief t.o.v. 1). De standaard werkinhoud kan


naar believen (doch voor het klassieke model deterministisch) worden gekozen. We kiezenvoor de praktische simulatie een opstelling met 3 werkers met werksnelheden (1, 2 en 3)en 5 stations met een goedgekozen4 deterministische (standaard) werkinhoud van (in dezevolgorde) 60s, 30s, 110s, 100s en 150s. De duurtijd van de simulatie wordt voldoende langgenomen (is hier van ondergeschikt belang), en er wordt gesimuleerd met een klok van10Hz (= nauwkeurigheid 0,1s). Alle werkers starten vanaf het begin van de productielijn.

0s 450s

s1 s2 s3 s4 s5

o1;2 o2;3

Figuur 2.5: 3 werkers, 5 goedgekozen stations

Het te verwachten resultaat is dat er v =∑3

i=1 = 1 + 2 + 3 = 6 producten wordengeproduceerd per tijdseenheid t =

∑5i=1 = 60 + 30 + 110 + 100 + 150 = 450s. De stabiele

lijncyclustijd is aldus 4506

= 75 seconden per product. We simuleren met bovenvermeldegegevens, en het verschil tussen de tijden waarop 2 producten worden afgewerkt wordtberekend. Het resultaat hiervan wordt getoond in Figuur 2.6, de waarden in Tabel 2.1.

60

80

100

120

140

160

0 5 10 15 20 25 30

Figuur 2.6: Gesimuleerde lijncyclustijd van 3 werkers aan 5 goedgekozen stations

1 2 3 4 5 6 7 8 9 100 149,93 64,39 73,58 79,4 72,54 75,21 75,69 74,54 75,07 75,0910 74,93 74,94 75,01 75,06 74,96 74,99 75,04 74,98 74,99 75,0220 74,99 74,99 75,02 74,99 75 75 75 75 75 75

Tabel 2.1: Tijdsverschillen (in s) tussen 2 opeenvolgende afgewerkte items

4Gezien de opgelegde beperking dat er slechts een werker tegelijk kan werken aan een station, dientde werkinhoud goed worden gekozen; zoniet zullen werkers blokkeren langs de lijn (wachtend op hetbeschikbaar komen van een station) en zal de productiesnelheid slechts suboptimaal zijn. Zie ook vroegerpunt over blokkeringen.


Volgens de simulatie wordt het eerste product geproduceerd na 149,93s. Theoretisch ishier 150s te verwachten, gezien de laatste werker zonder enige beperking/overdacht vanbegin naar einde kan werken met werksnelheid 3. Reeds vanaf waarde 9 ligt het resultaaterg dicht bij de verwachte 75s, na 24 producten is de lijncyclustijd stabiel op exact detheoretisch te verwachten waarde.

3 werkers, 5 willekeurig gekozen stations

We nemen dezelfde werkers als in het vorige gesimuleerde geval, en opnieuw 5 stations meteen totale werkinhoud van 450s, maar ditmaal met een respectievelijke werkinhoud van150s, 110s, 30s, 60s en 100s. Het is eenvoudig in te zien dat de overdrachtspunten in hetoptimale geval op 75 en 225 van 450, zijnde 1

6en 3

6= 1

6+ 2

6liggen.

0s 450s

s1 s2 s3 s4 s5

o1;2 o2;3

Figuur 2.7: 3 werkers, 5 willekeurige stations

Deze opstelling zal leiden tot geblokkeerde werkers, en tot een daling van de lijncyclustijd.Een blokkering is zeer eenvoudig in te zien: werker 1 zal op station s1 (werkinhoud 150s)maximaal 75s ver kunnen produceren (wanneer de andere werkers niet blokkeren), totwanneer zijn product wordt overgenomen door werker 2 bij de reset van de lijn. Werker 2moet dan nog minstens 75 werkinhoud aan werksnelheid 2 afleggen, en houdt zolang hetstation bezet voor werker 1. Pas wanneer werker 2 klaar is aan station s1, kan werker 1starten aan zijn cyclus.

Merk op dat de overdrachtspunten hier zijn aangegeven voor het ideale, niet-blokkerendegeval. In realiteit zullen de overdrachtspunten elders liggen, door het gewijzigde evenwichtten gevolge van de blokkeringen.

Figuur 2.8 geeft het resultaat van deze simulatie weer. De lijncyclustijd convergeert zoalsverwacht, maar door het blokkeren van werkers slechts naar de suboptimale waarde 85.7s(t.o.v. 75s); dit is maar liefst 14% slechter dan in het optimale geval. De lijn convergeertzelfs iets sneller naar een stabiele toestand, omdat de startsituatie waar werkers sowiesogaan blokkeren, dichter ligt bij de stabiele toestand dan bv. bij de voorgaande simulatie.


80

90

100

110

120

130

140

150

0 5 10 15 20 25 30

Figuur 2.8: Gesimuleerde productiesnelheid van 3 werkers aan 5 station

3 werkers, 1 continu station

Alternatief kan ook een “continu station” worden beschouwd, waaraan onbeperkt veel wer-kers kunnen werken (zie ook voorgaand). Langs een dergelijk continu station kunnen dewerkers nooit blokkeren, en zullen de simulatieresultaten iets beter zijn5. Een bijkomendvoordeel is dat op deze manier, van iedere werker het voortgangspercentage handig uit teprinten is. De simulatie zal worden herhaald met dezelfde 3 werkers uit de voorgaandesimulatie, doch ditmaal met slechts een station met een werkinhoud van 450s, waarlangsoneindig veel werkers tegelijk kunnen werken. Ook zal de software licht worden aangepast,zodat het voortgangspercentage wordt uitgeprint bij elke reset van de lijn. Het te verwach-ten resultaat is hetzelfde als de situatie van 3 niet-blokkerende werkers aan 5 stations.

40

60

80

100

120

140

160

0 5 10 15 20 25 30

Figuur 2.9: Gesimuleerde productiesnelheid van 3 werkers aan een continu station

5De afrondingsfout bij het bepalen wanneer een product klaar is zal slechts eenmaal doorwegen op hetresultaat, i.p.v. eenmaal per station.


1 2 3 4 5 6 7 8 9 100 150 50 66,67 88,88 68,52 74,69 77,37 73,52 75,2 75,3610 74,69 75,09 75,04 74,94 75,03 75 74,99 75,01 74,99 7520 75 75 75 75 75 75 75 75 75 75

Tabel 2.2: Tijdsverschillen (in s) tussen 2 opeenvolgende afgewerkte items

Figuur 2.9 is vrij gelijkaardig aan Figuur 2.6. Na een korte tijd van overgangsverschijnse-len, convergeert de productiesnelheid naar een vaste waarde, zoals te verwachten opnieuw75. Uit Tabel 2.2 blijkt inderdaad dat ook de eerste waarden uit de simulatie nauwkeurigerzijn t.o.v. Tabel 2.1. De overgangsverschijnselen zijn heviger, maar sterven sneller uit; ditdoordat de werkers in geen enkel geval zullen blokkeren, ook niet tijdens de convergentie-periode.

Voor

tgan

g in

de

tijd

(s)

0

100

200

300

400

500

600

700

800

900

1.000

Voortgang in %0 20 40 60 80 100

Figuur 2.10: Grafische weergave van de voortgang van de werkers

Figuur 2.10 geeft grafisch de voortgang van de werkers weer (op de x-as van links naarrechts resp. werkers 1, 2 en 3, op de y-as de voortgang in de tijd). De plaatsen methorizontaal snijdende lijnen, zijn de tijdstippen waarop de lijn zich reset. Werker 3 voltooitzijn product (= 100%), en wandelt op dat exacte moment oneindig snel terug naar werker2; werker 2 staat zijn product af en wandelt oneindig snel terug naar werker 1; werker 1


staat zijn product af en wandelt oneindig snel terug naar positie 0 (= 0%), waar hij eennieuw product start. De snijpunten van de lijnen zijn de overdrachtspunten, die na verloopvan tijd convergeren naar vaste punten. Dat laatste geheel conform de theorie van klassiekeBucket Brigades.

In Figuur 2.11 wordt dit resultaat nogmaals weergegeven, maar ditmaal geannoteerd metuitleg.

Voor

tgan

g in

de

tijd

(s)

0

100

200

300

400

500

600

700

800

900

1.000

Voortgang in %0 20 40 60 80 100

Allen startpositie 0

werker 1

werker 3

werker 2

Overdrachtspunten

Eén product, van begin tot einde, langs 3 verschillende werkers

lijncyclustijd

stabiele overdrachtspunten

stabiele lijncyclustijd

Figuur 2.11: Grafische weergave van de voortgang van de werkers, geannoteerd

4 werkers, 1 continu station

De productiesnelheid van een Bucket Brigade productielijn is eenvoudig te verhogen (bv.bij verhoogde vraag), door een of meerdere werkers aan de lijn toe te voegen6. Stel wevoegen een vierde werker, met werksnelheid v4 = 1.2 toe aan de lijn, tussen werker 1 en 2om de volgorde in werksnelheid te respecteren. Zoals kan worden verwacht (Figuur 2.12),convergeert de lijncyclustijd naar 450

1+1,2+2+3= 62, 5 seconden per product.

4 slecht geordende werkers, 1 continu station

Stel dat we echter deze vierde werker onoordeelkundig toevoegen aan het einde van deproductielijn. Op die manier wordt de ordening in werksnelheid niet gerespecteerd.

6Analoog kan de productiesnelheid worden verlaagd door werkers weg te nemen van de lijn


40

60

80

100

120

140

160

0 5 10 15 20 25 30

Figuur 2.12: Gesimuleerde lijncyclustijd van 4 werkers aan een continu station

0

50

100

150

200

250

300

350

400

0 10 20 30 40

Figuur 2.13: Gesimuleerde lijncyclustijd van 4 slecht geordende werkers aan een continustation

In Figuur 2.13 is totaal geen convergentie meer waar te nemen. De productielijn werktproducten af op een vrijwel willekeurige manier, en ook de waargenomen waarden zijn veelgroter dan in het voorgaande geval. De experimenteel bekomen gemiddelde lijncyclustijd(waarbij gedurende 10 uur werd geproduceerd, voor een totaal van 520 afgewerkte produc-ten), is 69.03 seconden per product. Dit is flink slechter dan het vorige resultaat, ondanksevenveel werkers. Zouden we hier geen continu station hebben genomen, dan zal de resul-terende lijncyclustijd doorgaans nog hoger liggen, doordat de laatste werker ook effectiefeen station zal bezet houden, en de voorgaande werkers effectief staan wachten (i.p.v. nute kunnen meewerken aan het tempo van de trage werker).

In Figuur 2.14 wordt opnieuw de voortgang van de werkers weergegeven. Het verloop ischaotisch, er zijn geen vaste overdrachtspunten te vinden en er is duidelijk te zien datwerker 2 en 3 voortdurend geblokkeerd worden in hun uitvoering door de laatste, tragewerker.


Voor

tgan

g in

de

tijd

(s)

0

200

400

600

800

1.000

1.200

1.400

1.600

Voortgang in %0 20 40 60 80 100


Wanneer deze ordening van 4 werkers zou toegepast worden op de 5 afzonderlijke station,zou de lijncyclustijd nog dramatischer omhoog gaan. Dit omdat de laatste werker hetlaatste station zal bezet houden, en dus de voorlaatste werker frequent zelfs niet zal kunnen“meewerken” aan het tempo van de laatste, maar geblokkeerd zal staan “wachten” voorhet station.

2.3 Veralgemeend model

2.3.1 Theorie

In het veralgemeend model van Bucket Brigades[4] wordt gewerkt volgens het klassiekemodel, met als belangrijkste verschillen:

• Werkers hebben een eindige, welbepaalde (terug)wandelsnelheid wi7.

• Werkers mogen elkaar inhalen (Eng.: overtaking). Een werker mag een andere werkerinhalen wanneer ze beiden hetzij terugwandelen, hetzij (voorwaarts) werken.

• Werkers mogen elkaar passeren (Eng.: passing). Een werker die terugwandelt pas-seert een andere werker met een grotere index.

7merk het verschil op met een werker wki


De regels waaraan de werkers zich moeten houden, worden aldus:

Voorwaartse regel (Eng.: forward rule)Werk aan eenzelfde product (item) over verschillende werkstations. Als je pro-duct wordt overgenomen door een volgende werker (of wanneer het is voltooid),laat het achter en volg de “achterwaartse regel”.

Achterwaartse regel (Eng.: backward rule)Wandel terug langsheen de productielijn. Wanneer je een vorige werker wkj

tegenkomt met een lagere index (j < i), neem zijn product over; indien aan hetbegin van de lijn, start een nieuw product. Volg vervolgens de “voorwaartseregel”.

In het veralgemeende model hebben de werkers wel een (start)ordening, maar die is onbe-langrijk; deze ordening kan immers, onder voorwaarden, wijzigen tijdens de uitvoering. Dewerkers worden niet langer enkel gekenmerkt door hun werksnelheid vi, maar ook door hunwandelsnelheid wi. Bij het terugwandelen moeten ze enkel items overnemen van werkersmet een lagere index, zoniet moeten ze deze werker passeren.

De wandelsnelheid wi, net zoals de werksnelheid vi, is opnieuw eenheidsloos. Ze is gedefini-eerd relatief t.o.v. 1, waarbij 1 opnieuw “conform werkinhoud” voorstelt. Een werker metwerksnelheid 2 en wandelsnelheid 1 zal aan een station met werkinhoud 10s, over het helestation gedurende 5s werken, en bij het terugwandelen, hier 10s over doen. Een anderewerker met wandelsnelheid 4 zal terugwandelen aan dit station in amper 2.5s, of 4x snellerdan de vorige werker.

Uiteraard is de convergentievoorwaarde nu ook anders. De werkers bij een veralgemeendeBucket Brigade productielijn dienen geındexeerd ( 6= geordend) te worden zodanig dat:

1

v1

− 1

w1

>1

v2

− 1

w2

> . . . >1

vn

− 1

wn

concreet heeft de werker die het minst vertraagd wordt door te “werken” t.o.v. terugwan-delen, de grootste index.

Een systeem waarbij de werkers worden geındexeerd volgens de convergentievoorwaarde,gaat door 2 fases: een sorterings- en een convergentiefase. Tijdens de sorteringsfase zullende werkers zichzelf gaan ordenen door elkaar in te halen, tijdens de convergentiefase gaathet systeem convergeren tot een stabiel systeem, met vaste overdrachtspunten en stabieleproductiesnelheid.

Merk op dat bij het veralgemeende model, de veronderstelling van afzonderlijke stationswaaraan telkens een werker kan werken zoals bij het klassieke model, spaak loopt. Immers,voor een item wordt nog steeds vereist dat het de nodige bewerkingen (in volgorde) door-loopt langs elk station. Wanneer de werkinhoud van dergelijke stations maar voldoende


groot is, zou dit technisch betekenen dat een werker die op het punt staat (voorwaarts) in-gehaald te worden, na dit station moet wachten: dit staat de vorige werker toe de bewerkingop het huidige station te voltooien, de werker in te halen en meteen aan het daaropvolgen-de station te beginnen werken (waarbij de ingehaalde werker opnieuw zal blokkeren tot devrijgave van dit volgende station).

Ook in de referentietekst[4] wordt niet langer gesproken van stations, maar wel van eenassemblagelijn (waarlangs het werk continu en uniform is verdeeld). Deze aanname van eencontinue assemblagelijn, is hier dus opnieuw het analogon van het voorheen geıntroduceerdecontinue station.

Enkel dus om redenen van “logische groepering” kan dus nog van afzonderlijke stationsworden gesproken. Bovenal moeten aan elk van deze afzonderlijk beschouwde stationsvoldoende (en bij uitbreiding oneindig) veel werkers tegelijk kunnen werken; iedere han-deling/manipulatie moet bovendien voldoende kort zijn, zodat werkers elkaar onderlingvoorwaarts kunnen inhalen.

2.3.2 Praktijk

Het veralgemeende model maakt twee belangrijke nieuwe aannames:

1. werkers wandelen niet langer oneindig snel terug, maar met een eindige, reele snelheid.

2. wanneer de werkers in hun werken of (terug)wandelen worden geblokkeerd, gaan zeniet langer (domweg) trager werken of wandelen, maar de tragere werker inhalen.

Wat voor een productielijn in dit geval dus zeker zal moeten mogelijk zijn, is dat wer-kers elkaar kunnen inhalen (en passeren). Vooreerst moet er voldoende ruimte zijn, zodatwerkers elkaar ook praktisch zullen kunnen inhalen/passeren. Elke handeling aan de pro-ductielijn moet bovendien voldoende kort zijn, zodat een inhalende werker de ingehaaldezo kort mogelijk doet blokkeren.

In sommige gevallen zal dit inhalen/passeren zelfs ongewenst zijn: de volgorde waarmeeitems worden begonnen, is bij het veralgemeende model niet noodzakelijk de volgordewaarmee de items de lijn verlaten. Wanneer dit niet is toegelaten, mag niet voor hetveralgemeende model worden gekozen.

Het praktische voorbeeld voor het veralgemeende model, is bv. een assemblagelijn metvoldoende loopruimte waarlangs een niet te groot product wordt geassembleerd. Elkehandeling kan kort worden gehouden (klein onderdeel aanbrengen, schroef aandraaien,. . . ), zodat de werkers elkaar gemakkelijk kunnen inhalen.


2.3.3 Simulatie

Om het veralgemeend model te simuleren, kiezen we 4 werkers (wk1, wk2, wk3 en wk4)met de volgende kenmerken (c naar de berekening volgens convergentievoorwaarde):

cwk1 =1

v1

− 1

w1

=1

2.5− 1

1.5= −0.27

cwk2 =1

v2

− 1

w2

=1

2.0− 1

0.5= −1.5

cwk3 =1

v3

− 1

w3

=1

4.0− 1

2.0= −0.25

cwk4 =1

v4

− 1

w4

=1

1.0− 1

4.0= 0.75

Indexering conform convergentievoorwaarde

We kiezen een continu station8, met een werkinhoud van 250s, en indexeren de werkerszoals de convergentievoorwaarde voorschrijft cwk4 > cwk3 > cwk1 > cwk2 , maar houden destart(volg)orde van de werkers zoals hierboven (zie samenvattend Tabel 2.3). Uit Figuur2.15 blijkt dat de productiesnelheid convergeert naar een stabiele waarde.

startorde kleur werksnelheid wandelsnelheid 1vx− 1

wxindex

werker 1 1 oranje 2.5 1.5 −0.27 3werker 2 2 groen 2.0 0.5 −1.5 4werker 3 3 zwart 4.0 2.0 −0.25 2werker 4 4 blauw 1.0 4.0 0.75 1

Tabel 2.3: Overzicht volgorde, kleur en indexering werkers

20

40

60

80

100

120

0 5 10 15 20 25 30

Figuur 2.15: Gesimuleerde productiesnelheid van 4 correct geındexeerde werkers

8zal in de simulatie een longstation worden genoemd


In Figuur 2.16 wordt de voortgang van elke werker weergegeven, volgens de gegevens inTabel 2.3.

Voor

tgan

g in

de

tijd

(s)

0

200

400

600

800

1.000

1.200

Voortgang in %0 20 40 60 80 100


Opnieuw wordt Figuur 2.16 geannoteerd met uitleg. Dit wordt weergegeven in Figuur2.17. De sorteringsfase is duidelijk waar te nemen onderaan de grafiek: werker 3 werkt alseerste een product af; hij wandelt terug en passeert achtereenvolgens werker 1 en werker2. Wanneer de werkers in hun definitieve volgorde staan, is de productiesnelheid nog nietstabiel: nu volgt de convergentiefase. Hierna convergeren de overdrachtspunten, en wordtde productiesnelheid stabiel.


Voor

tgan

g in

de

tijd

(s)

0

200

400

600

800

1.000

1.200

Voortgang in %0 20 40 60 80 100

werker 4 (index 1)

werker 2 (index 4)

werker 1 (index 3)

werker 3 (index 2)

werkers gaan elkaar passeren

sorteringsfase

convergentiefase

stabiele lijncyclustijdstabiele overdrachtspunten

Figuur 2.17: Grafische weergave van de voortgang van de werkers, geannoteerd

Indexering niet volgens de convergentievoorwaarde

Veronderstel dezelfde werkers en dezelfde stations als hierboven. De indexering gebeurt nuechter volgens de volgorde waarin de werkers starten (index wordt gelijk genomen aan destartorde), en respecteert dus de convergentievoorwaarde niet. De verwachting is dan ookdat de productiesnelheid en de overdrachtspunten niet netjes zullen convergeren tot eenenkele waarde, maar willekeurig zullen zijn of in het beste geval quasi-periodiek. Figuur2.18 toont de productiesnelheid van deze opstelling. De waardes hebben geen enkele neigingtot convergeren, noch tot enig quasi-periodiek gedrag.

0

20

40

60

80

100

120

140

160

0 5 10 15 20 25 30

Figuur 2.18: Gesimuleerde productiesnelheid van 4 verkeerd geındexeerde werkers


De overdrachten tussen de werkers gebeuren als het ware op chaotische punten en zonderregelmaat. Figuur 2.19 illustreert dit treffend.

Voor

tgan

g in

de

tijd

(s)

0

200

400

600

800

1.000

1.200

Voortgang in %0 20 40 60 80 100


2.4 Bucket Brigades met parallelle werkstations

2.4.1 Inleiding

In deze thesis zullen Bucket Brigade productielijnen worden bestudeerd, waarbij een wel-bepaalde stap (die bestaat uit een of meerdere stations) een of meerdere malen zal wordengedupliceerd. Het concept van parallelle paden binnen Bucket Brigade productielijnen istotaal nieuw: de theoretische overschouwing die volgt is dan ook eigen werk en een deelvan het doel van deze masterproef.


2.4.2 Voorbeeld

Om de overgang naar Bucket Brigades met parallelle werkstations vlot te maken, wordtgeopteerd om te beginnen met een voorbeeld uit het klassieke model, om dit voorbeeldvervolgens uit te breiden naar parallelle werkstations.

Beschouw in Figuur 2.20 een seriele productielijn met zijn stabiele overdrachtspunten voor5 werkers (= 4 overdrachtspunten). Aan elk station kan ten hoogste een werker werken.De werkers werken conform het klassieke model van Bucket Brigades, en zijn geordendvolgens de convergentievoorwaarde (van traag naar snel).

0 as1 s2 s3 s4 s5 s6

o1;2 o2;3 o3;4 o4;5

Figuur 2.20: Seriele productielijn met vaak blokkerende werkers

Er vallen meteen een aantal zaken op in deze Figuur 2.20:

• Het overdrachtspunt o2;3 ligt exact aan het begin van station s2.

• Het voltooide werk per werker (de intervallen [0; o1;2], [o1;2; o2;3], . . . ) zou gezien deordening volgens werksnelheid, ook moeten toenemen van klein naar groot; dit isechter totaal niet zo.

Het blijkt dat, oorzakelijk door de hoge werkinhoud aan station s2, werkers 1 tot 3 vaakgeblokkeerd staan wachten: zolang werker 4 (interval [o3;4; o4;5]) station s2 bezet houdt, kanwerker 3 niet beginnen. Wanneer werker 2 vervolgens aankomt bij station s2, blijkt werker3 reeds aan s2 begonnen, zodat hij de rest van zijn cyclus ook spendeert aan wachten.

Het management besluit dan ook dat de productiesnelheid te laag ligt door het onaan-vaardbaar lang wachten van de werkers op station s2, en besluit station s2 te duplicerenzodat aan dit station in parallel kan gewerkt worden (Figuur 2.21).

0 as1

s2;1

s2;2

s3 s4 s5 s6

o1;2

o2;3

o3;4

o4;5

Figuur 2.21: Productielijn met een parallel werkstation

Er blijken nu geen werkers meer te blokkeren, en hierdoor is de productiesnelheid flinkverhoogd. Dit is een goed voorbeeld van een productielijn waar een station (of een aantalstations) parallelliseren een goede oplossing is.


2.4.3 Algemeen

Typisch bij het gebruik van parallelle paden (stations) is dat de werktijd van een bottle-neck 9pad oorspronkelijk onaanvaardbaar hoog is (in het voorbeeld was dit een pad metslechts een station, namelijk s2) in verhouding tot de beoogde productiesnelheid, en duswordt dit pad (desgevallend meer dan tweemaal) gedupliceerd om blokkeringen (zoveelmogelijk) te vermijden.

1 2 . . .

p1;1

p1;2

p2;1

p2;2

. . . m

parallel pad 1

parallel pad 2

Figuur 2.22: Eenvoudige productielijn met 2 parallelle paden

In Figuur 2.22 wordt een eenvoudige productielijn weergegeven met 2 parallelle paden.Langs elk pad staan telkens 2 stations p1 en p2. Elk item zal telkens de opeenvolging vanstations doorlopen, doch slechts langs een parallel pad worden bewerkt. Elk item wordtdus voltooid langsheen een van deze sequenties van stations:

• 1→ 2→ . . .→ p1;1 → p2;1 → . . .→ m

• 1→ 2→ . . .→ p1;2 → p2;2 → . . .→ m

In de theoretische beschouwing zal er steeds van worden uitgegaan dat elk parallel padidentiek is, en elk station langs de productielijn een deterministische werkinhoud heeft.Voor de eenvoud van voorstellen, zal er tevens van worden uitgegaan dat elk parallel padover een (en hetzelfde) station beschikt; er is echter geen reden waarom dit niet zomaar isuit te breiden naar meerdere stations.

2.4.4 Aanname van het “klassieke model”

Zoals eerder gesteld bij het veralgemeende model van Bucket Brigades, zal het moeilijk zijnte spreken van stations bij dit veralgemeende model, mede omdat langs elk dergelijk stationimmers (althans theoretisch) oneindig veel werkers kunnen werken. Werkers kunnen dus(theoretisch) ook niet blokkeren doordat een station onbeschikbaar is.

Het is dus onlogisch om het veralgemeend model te betrekken bij een concept voor parallellewerkstations. Hierna wordt dan ook enkel de aanname van een (in oorsprong) klassieke

9flessenhals


modellering gemaakt. We nemen dan ook aan dat de werkers telkens zijn geordend volgensde convergentievoorwaarde (volgens werksnelheid, van traag naar snel).

2.4.5 Keuze tussen parallelle paden

Een werker zal op een bepaald moment een (goede) keuze moeten maken tussen de verschil-lende parallelle paden: waarlangs hij het product verder wenst te voltooien of waarlangshij zal terugwandelen.

We concretiseren de keuze voor een werker als volgt:

• Voorwaarts werkend

– Indien er lege paden zijn, maak een willekeurige keuze tussen deze lege paden.

– Indien alle paden bezet zijn door een of meerdere werkers, kies het pad waaraande eerste10 werker reeds het verst is gevorderd langs dit pad; indien gelijken,maak een willekeurige keuze onder deze gelijken.

• Achterwaarts wandelend

– Indien alle paden leeg zijn, maak een willekeurige keuze tussen deze lege paden.

– Indien alle paden bezet zijn door een of meerdere werkers, kies het pad waaraande laatste werker reeds het verst is gevorderd langs dit pad; indien gelijken,maak dan een willekeurige keuze onder deze gelijken.

Een dergelijke keuze is vooral logisch. Ingeval van lege paden is de keuze duidelijk. Wanneeralle paden bezet zijn, kiest een werker voorwaarts het pad met de eerste werker die hetverst gevorderd is: dit geeft hem de beste kans om zo snel mogelijk te kunnen beginnenaan een vrijgekomen station; in achterwaartse richting kiest een werker de werker die hetverst is gevorderd langs de lijn: dit zal de ordening volgens werksnelheid zo goed mogelijkrespecteren.

Deze keuze mag dan wel logisch zijn, ze zal in de praktijk maken niet altijd even gemakkelijkzijn omdat de exacte voortgang van werkers niet steeds gemakkelijk is in te schatten.

2.4.6 Overdrachten tussen de paden onderling

Er dient opgemerkt dat in het geval van parallelle paden, de overdracht op een dergelijkparallel pad op 2 verschillende manieren kan gebeuren:

• tussen de paden onderling (de traditionele “lijn” verbreken)

10hij die zich het dichtst bij het begin van de lijn bevindt


• volgens het reeds afgelegde pad terug te keren tot een vorige werker wordt tegenge-komen

Beide benaderingen vergen een totaal andere bespreking. In deze sectie 2.4.6 zullen over-drachten tussen paden onderling worden besproken; in de hieropvolgende sectie 2.4.7 zullenoverdrachten langsheen hetzelfde pad worden behandeld.

Theorie

In het geval dat overdrachten gebeuren tussen de paden onderling, zal een werker die zijnproduct moet afstaan terwijl hij zich op het parallelle pad bevindt, eerst (proberen) eenproduct over te nemen van een voorganger langsheen een ander parallel pad. Dit wordtgrafisch weergegeven in Figuur 2.23 (voor de eenvoud van voorstellen is geen onderverdelinggemaakt volgens stations). Een werker zal bij een reset het product overnemen van zijndichtste voorganger; indien meerdere keuzes, zal hij zijn dichtste natuurlijke11 voorgangernemen.

0 awk1

wk3

wk2

wk4

Figuur 2.23: Overdracht tussen de paden onderling (wk3 → wk2) bij een reset

Het is eenvoudig in te zien dat elke werker dus het werk zal overnemen van de werker diezich volgens de convergentievoorwaarde exact een plaats voor hem bevond. Deze maniervan overnemen behoudt dus strikt de volgorde van de werkers volgens de convergentievoor-waarde.

We zouden deze manier van overnemen tussen de parallelle paden onderling dus kunnenaanzien als overnames langs een serieel pad (gezien het behoud in ordening), met datverschil dat er langs dit pad verschillende werkers kunnen voorkomen. Gezien onze veron-derstelling dat er zich langs elk parallel pad juist een station bevindt (die bovendien alleidentiek zijn), kunnen we alle parallelle stations gaan aanzien als een enkel station, maardan wel een waaraan nu evenveel werkers tegelijk kunnen werken als er parallelle stationszijn.

Dit nieuwe station is dan ook niets anders dan een vroeger deıntroduceerd continu station,zij het met een beperkt doch goedgedefinieerd aantal werkers (anders dan een oneindig

11de dichtstbijzijnde voorganger volgens de startvolgorde (conform de convergentievoorwaarde)


aantal werkers). Door het gebruik van een dergelijk (vervangend) continu station, vereen-voudigt de parallelle lijn zich tot een seriele lijn.

Het gedrag van deze seriele lijn zal hetzelfde zijn als het “klassieke analogon”, alleen kandit continue station nu meerdere12, stel x, overdrachtspunten bevatten i.p.v. slechts een.Het continue station (= het equivalent van de parallelle stations) wordt in het geval vanmeerdere (x) overdrachtspunten gebruikt om te verhinderen dat x− 1 werkers, die in hetklassieke analogon geblokkeerd zouden staan wachten voor het station, nu aan de parallellestations (alias het continue station) toch kunnen doorwerken. Dit strookt ook met deoorspronkelijke reden om een station te gaan dupliceren.

Beschouw ter verduidelijking een productielijn (met totale werkinhoud genormaliseerd tot1) volgens het klassiek model van Bucket Brigades, met overdrachtspunten zoals in Figuur2.24 van 3 werkers met respectievelijke snelheden 1, 2 en 3. De overdrachtspunten bevindenzich dus in het optimale geval op 1

6en 3

6= 1

6+ 2

6.

0 1o1;2 o2;3

Figuur 2.24: Stabiele overdrachtspunten in een optimaal klassiek systeem

We kiezen nu 4 stations op een slechte manier, zoals in Figuur 2.25. Opnieuw zijn de over-drachtspunten (ter referentie) uit het optimale systeem weergegeven. Deze overdrachts-punten zijn voor deze gekozen stations echter onmogelijk: aan station s2 kan slechts eenwerker tegelijk werken. Hier zouden de overdachtspunten dus verschuiven naar links , toter maximaal een per station voorkomt. De productiesnelheid zal suboptimaal zijn: hetis immers duidelijk dat werker 2 een tijdje zal geblokkeerd staan wachten op station s2,zolang het wordt bezet gehouden door werker 3. Vervolgens zal werker 1 op zijn beurtstaan wachten zolang werker 2 aan dit station werkzaam is.

0 1o1;2 o2;3

s1 s2 s3 s4

Figuur 2.25: 4 slecht gekozen stations met de vroegere overdrachtspunten

Station s2 heeft veruit de grootste werkinhoud, en vertraagt de productiesnelheid dusdanigdat wordt besloten station s2 te dupliceren, zoals Figuur 2.26 weergeeft.

12evenveel als er werkers kunnen werken, of dus evenveel als er parallelle paden zijn


0 1

o1;2

o2;3s1

s2;1

s2;2

s3 s4

Figuur 2.26: Model met overdrachtspunten en gedupliceerd station s2

Door station s2 te dupliceren, zal de lijn opnieuw kunnen produceren zonder geblokkeerdewerkers, en dus naar een optimale productiesnelheid convergeren. Gezien werker 2 echterwisselt van pad, zal werker 1 daaropvolgend het andere (lege) pad nemen, en zullen deoverdrachtspunten wel afwisselend op het ene, dan wel het andere pad voorkomen. Ditheeft echter geen invloed op de productiesnelheid.

Bedenkingen bij deze modellering

Hoewel deze modellering perfect legitiem is, en zich eenvoudigerwijs simplificeert tot de ori-ginele modelleringen zij het met bijzondere, continue stations, zullen de opgelegde vereistende uitvoering praktisch moeilijk, en soms zelfs onmogelijk maken. Er zijn meerdere redenente bedenken om niet te kiezen voor overdrachten tussen de parallelle paden onderling:

• De oorspronkelijk zeer eenvoudige regels, zijn nu een flink stuk ingewikkelder: dewerker, onderweg naar een overdracht, dient steeds te weten wie zijn voorganger is,en aan welk parallel pad die zich bevindt. Wanneer de werkruimte onoverzichtelijkis (bv. een werker kan zich “wegstoppen” achter een station), dan kan er veel tijdverloren gaan bij het zoeken naar deze unieke, correcte werker.

• De afstand tussen de verschillende parallelle paden kan groot zijn, of zelfs niet over-brugbaar (fysiek gescheiden ruimtes, geen plaats om te wandelen tussen de stationsdoor, te onveilig om te overbruggen, . . . ).

2.4.7 Overdrachten langsheen hetzelfde pad

Een oplossing voor de problemen met overdrachten tussen de paden onderling, kan zijnde werkers te instrueren steeds de paden te volgen. In dit geval hoeft een werker slechtsterug te wandelen langs het pad dat hij (vermoedelijk) reeds doorlopen heeft, op zoeknaar een vorige werker; in het slechtste geval dient hij een goede keuze te maken tussenverschillende mogelijke parallelle paden. Deze manier van overdragen zal hoe dan ook quaprincipe dichter aanleunen bij het originele concept van Bucket Brigades, gezien een werkerslechts over een eerder lokaal zicht op de lijn dient te beschikken.

Een voorbeeld van deze manier van overdragen, wordt gegeven in Figuur 2.27.


0 a

wk1

wk3

wk2

wk4

Figuur 2.27: Overdracht langsheen hetzelfde pad (wk3 → wk1) bij een reset

Theorie

In het klassieke model wordt een volgorde ingesteld bij het begin, die daaropvolgend nietzal wijzigen: wanneer 2 werkers elkaar immers in tegenovergestelde richting ontmoeten,draagt de ene zijn product over aan de andere, en beiden wijzigen hun richting. Bijoverdrachten langsheen parallelle paden, kan een werker terugwandelen onafhankelijk vanzijn natuurlijke voorligger, die zich op het andere parallelle pad bevindt; hij zal dan ookniet het item overnemen van deze voorligger, maar van een eerdere voorligger (of een nieuwitem starten).

De volgorde van de werkers wordt dus globaal gezien niet langer gerespecteerd. Langsheende verschillende paden die een item kan doorlopen zal deze volgorde wel steeds wordengerespecteerd, zij het dan dat niet steeds alle werkers zullen voorkomen. De andere aan-names uit het klassieke model, zoals het feit dat werkers elkaar niet zullen inhalen nochpasseren en de oneindige wandelsnelheid, blijven gelden.

Veronderstel dat de oorspronkelijke ordening van de werkers in Figuur 2.27 was volgens deconvergentievoorwaarde:

v1 < v2 < v3 < v4

wk4 is aan het einde van de productielijn, laat zijn product achter en start terug te wande-len. Aan de opsplitsing in parallelle paden kiest hij de dichtstbijzijnde werker, wk3, neemtzijn product over en start verder te werken. Werker wk3 wandelt langsheen het pad terug,en komt als eerste wk1 tegen, onafhankelijk van de positie van wk2 die zich langs een anderparallel pad bevindt. wk3 neemt het product over van wk1 en start vooruit te werken, wk1

wandelt terug en start een nieuw product. De globale ordening, voor zover hiervan kanworden gesproken bij parallelle paden, is nu:

wk1 → wk3 → wk2 → wk4

Het opleggen van een convergentievoorwaarde, dezelfde als bij het klassieke model, zalechter een voldoende voorwaarde zijn opdat de werkers zich steeds in deze zelfde volgorde


bewegen op de seriele paden (voor en na het parallelle gedeelte), indien de keuzeregels aande parallelle paden worden gerespecteerd. Het klassieke model heeft reeds aangetoond datdeze ordening optimaal is voor de seriele paden in kwestie.

De convergentievoorwaarde zal een voldoende voorwaarde zijn om de werkers op de serielestukken op de beste manier te ordenen, maar geen nodige voorwaarde zijn. Beschouwimmers (bijvoorbeeld) het volgende systeem met 3 werkers, waarbij de werkers vanaf positienul starten in de volgorde van hun indexen:

wk1 → wk2 → wk3

Er geldt echter v1 = 1, v2 = 3 en v3 = 2. En dus voldoet de ordening van de werkers nietaan de convergentievoorwaarde.

Beschouw nu een opstelling met 3 stations, waarvan station 2 gedupliceerd is en in parallelstaat. Station s1 heeft een werkinhoud van 10s, station s2 van 70s en station s3 van 20s.Aan elk station kan slechts een werker tegelijk werken. De evolutie van het systeem vanaftijdstip 0 is weergegeven in Figuur 2.28; de aanduidingen zijn vanaf (b) weggelaten om defiguren overzichtelijk te houden.

0s 100ss1

s2;1

s2;2

s3

(a) Opstelling

wk1

wk2

wk3

(b) Na 5s

wk1wk2

wk3

(c) Na 8.33s

wk1 wk2

wk3

(d) Na 18.33s

Figuur 2.28: Evolutie in de tijd van 3 werkers

Reeds na 18,33s zal wk2 zijn voorligger wk3 duidelijk ingehaald hebben. wk2 zal dan ookals eerste het parallelle pad beeindigen, en dus de volgorde (conform de convergentievoor-


waarde) herstellen. Hoewel de startvolgorde afweek van de convergentievoorwaarde, zalhet systeem zichzelf corrigeren; dit zal echter niet steeds het geval zijn. De convergentie-voorwaarde is dus een voldoende voorwaarde, doch geen nodige.

Quasi-periodiek gedrag

Deze keuze van overdrachten zal echter, tenzij in 2 bijzondere gevallen die laterop wordenbesproken, nooit convergeren naar een stabiele productiesnelheid met stabiele overdrachts-punten. De reden is dat een terugwandelende werker op een bepaald moment een keuzezal moeten maken tussen 2 parallelle paden, die elk wijzigen in de tijd. Dit is eenvoudigin te zien met een kort bewijs uit het ongerijmde.

Wanneer de overdrachtspunten in elke cyclus gelijk zijn, moeten zij logischer-wijs op dezelfde hoogte liggen op de parallelle paden. Indien dit immers niet zozou zijn, zouden deze punten in de loop van de tijd toch onderling van positiewijzigen, doordat de lijn niet eindig is en steeds de verst liggende wordt over-genomen; de dichtst liggende zal dus blijven verder liggen, en op een bepaaldmoment voorop liggen op het andere punt; op dat moment zal het overdrachts-punt daar liggen, en dus op een andere hoogte dan het vorige punt. Neem dusde situatie waar beide punten op dezelfde hoogte liggen; de keuze moet dan af-wisselen tussen de twee paden. Het punt voor de parallelle paden moet echterook stabiel zijn, en dus moeten 2 werkers om beurten evenveel werk opknappenen dus even snel werken. Dit laatste is echter strijdig met de convergentievoor-waarde, die een strikte ordening vereist van de werkers.

Dat betekent dus dat een parallel systeem per definitie niet stabiel zal zijn. Het zal zichechter wel quasi-periodiek gedragen, waarbij de periode in essentie afhangt van het aantalcycli dat de parallelle paden nodig hebben om elkaar “in te halen”.

Aangezien de productiesnelheid zich dus ook quasi-periodiek zal gedragen, is het wel moge-lijk een stabiele gemiddelde productiesnelheid (over een periode) te berekenen. De gemid-delde productiesnelheid zal opnieuw optimaal zijn, wanneer geen werkers blokkeren. Hetparallelle pad kan echter zijn aangewend om een blokkering uit het klassieke model te ver-helpen; in dat geval zal de gemiddelde productiesnelheid beter zijn dan de (suboptimale)productiesnelheid in het klassieke model. Ook zal deze gemiddelde productiesnelheid nogsteeds exponentieel convergeren.

In 2 bijzondere gevallen echter, kan er nog van een echt klassiek model met stabiel gedragworden gesproken bij overdrachten langsheen paden:

• Wanneer er slechts een stabiel overdrachtspunt blijkt voor alle parallelle paden samen.Dit betekent echter concreet dat in evenwichtstoestand, telkens slechts een parallelpad zal worden gebruikt. Dit geval is dus equivalent met een ordinaire seriele pro-ductielijn, zonder parallellismen.


• Wanneer alle stabiele overdrachtspunten zich op de parallelle paden bevinden, en deconvergentieregel wordt gerespecteerd per apart beschouwd pad. Hier kan elk parallelpad dan eigenlijk als een aparte productielijn worden aanzien, zij het met hetzelfdebegin- en eindpunt. Dit systeem is eigenlijk een verzameling van aparte, ordinaireseriele productielijnen, evenveel als er parallelle paden zijn.

Bedenkingen bij deze modellering

Quasi-periodiek gedrag is eerder ongewenst bij Bucket Brigades, omdat (binnen een perio-de) de overdrachtspunten telkens zullen wijzigen: dit zal o.a. nefast zijn voor een optimaalleereffect van de werkers. Bovendien is de periode van dit quasi-periodiek gedrag onbe-grensd en niet zomaar te voorspellen.

Ook deze modellering zal dus met de nodige omzichtigheid moeten worden geevalueerdwanneer ze wordt ingevoerd. Er is een goede kans dat dit systeem, mits een voldoen-de kleine periode, prima zal presteren onder de aannames van Bucket Brigades. In eenaantal gevallen echter kan de prestatie ondermaats zijn door de praktische neveneffecten(blokkeringen door niet-onmiddellijke overdrachten, . . . ) van de onstabiliteit; variaties opdit model (zoals bv. het opbouwen van kleine tussenvoorraden aan begin/einde van deparallelle paden) kunnen hier oplossingen bieden.

Simulatie

Beschouw een productielijn voor 3 werkers, met werksnelheden 1, 2 en 3. Ze wordengeordend volgens de convergentievoorwaarde. Langs deze productielijn staan 4 stations,met werkinhoud respectievelijk 40s, 350s, 130s en 80s (samen 600s).

In Figuur 2.29 wordt het resultaat weergegeven. De oranje lijn is de lijncyclustijd. Nade convergentieperiode is duidelijk het quasi-periodiek gedrag waar te nemen, hier metperiode 3. De blauwe lijn is het voortschrijdende gemiddelde van de afgelopen periode(hier dus van de laatste 3 op dat moment bekende lijncyclustijden). Ook dit gemiddeldekent een convergentieperiode zoals vroeger, en convergeert hierna naar een vaste waarde,in dit geval 106.8 seconden per product. Deze waarde is te verklaren doordat er alsnogblokkeringen optreden.


50

100

150

200

0 10 20 30 40 50

Figuur 2.29: Gesimuleerde lijncyclustijd van 3 werkers met 4 stations

Om het gedrag nogmaals te bekijken en te verifieren of de software inderdaad de verwachtegemiddelde waarde van 100 seconden per product geeft, maken we opnieuw gebruik vancontinue stations om alle blokkeringen te vermijden. Uit Figuur 2.30 blijkt de correcteverwachte waarde.

50

100

150

200

0 10 20 30 40 50

Figuur 2.30: Gesimuleerde lijncyclustijd van 3 werkers met continue stations

Zouden we deze zelfde gegevens gebruiken in een klassieke modellering zonder parallellepaden en zonder continue stations, dan is duidelijk dat de werkers een groot stuk van detijd zullen geblokkeerd staan. Immers, in een klassiek systeem zonder blokkeringen, zoudende overdrachtspunten op 100 en 300 liggen; beide punten liggen nu echter binnen station2. Ten overvloede dient opgemerkt dat de werktijd en deze blokkeringen als logisch gevolgzouden hebben om te overwegen om station 2 te gaan dupliceren. Het resultaat wordtweergegeven in Figuur 2.31. Merk op dat de eerste 50 resultaten zijn weergegeven. Delijncyclustijd convergeert vrijwel onmiddellijk naar de (zeer suboptimale) 140s (tegenover100s in het beste geval, en 106.8s met een extra station in parallel).


140

150

160

170

180

190

200

0 10 20 30 40 50

Figuur 2.31: Gesimuleerde lijncyclustijd van 3 werkers zonder parallelisme

2.5 Andere variaties op Bucket Brigades

In het kader van de algemene (literatuur)studie rond Bucket Brigade productielijnen, wer-den nog een aantal variaties op Bucket Brigades bestudeerd; deze bleken echter van minderrechtstreeks belang voor deze masterproef. In wat volgt werden deze artikels kort samenge-vat; wie verder geınteresseerd is in deze onderwerpen verwijs ik graag door naar de origineleartikels (Engels).

2.5.1 Bucket Brigades met stochastische werktijden

De aanname dat werk langsheen een productielijn vast en uniform verdeeld is, is realistischvoor een aantal gevallen (die dan steeds verder worden bijgestuurd om zoveel mogelijk vari-abiliteit en bottlenecks te vermijden). In de gevallen dat er echter to order wordt gewerkt,en zeker wanneer deze order een grote variabiliteit vertonen, is een dergelijke aannameonrealistisch. Het artikel [5] dat hier wordt besproken, is deels een theoretische beschrij-ving, deels een case study van een lijn waar order-pickers (hoogst variabele) klantenordersuitvoeren.

Bucket Brigades zullen dan ook worden uitgebreid tot stochastische systemen: wanneereen lijn bestaat uit voldoende veel (m) werkstations, en de werkinhoud aan elk stationonafhankelijk is en een exponentiele distributie volgt met gemiddelde 1, dan zal deze lijnconvergeren naar het deterministische model van deze lijn met een totale werkinhoud van1.

De case study toonde bovendien een verbetering van 34% in de pickingsnelheid bij deinvoering van Bucket Brigades, t.o.v. zone picking, waar elke werker is gelimiteerd tot eenwelbepaalde zone voor het gaan picken van een deel van zijn order.


2.5.2 Bucket Brigades met niet-uniforme werksnelheden

In dit artikel[6] wordt het effect beschreven wanneer de werksnelheid van werkers nietuniform is langsheen de productielijn, maar bv. in een eerste interval sneller dan in eentweede interval.

Er worden 2 werkers beschouwd: werker 1 heeft een snelheid v1;1 in het interval [0;X[, eneen andere snelheid v1;2 in het interval [X; 1]; werker 2 heeft een vaste snelheid v2 = 1; ergeldt bovendien v1;1 < 1 < v1;2.

Onafhankelijk van de startpositie en de initiele ordening van de werkers (indien we toelatendat de werkers eenmalig van volgorde wisselen wanneer ze elkaar inhalen), zal de productie-lijn opnieuw convergeren naar hetzij volkomen stabiel gedrag (een stabiel overdrachtspunt),hetzij naar quasi-periodiek gedrag met periode van maximaal 2 (2 overdrachtspunten waar-langs de overdracht afwisselend plaats vindt).

2.5.3 Bucket Brigades met leereffect bij werkers

Wanneer een werker een bepaalde vaste taak (vaste opeenvolging van bewerkingen aanverschillende stations) verricht, zal hij (tot een zekere limiet) deze taak alsmaar snellerkunnen uitvoeren; dit fenomeen heet het leereffect bij een werker. Het artikel “BucketBrigades with Worker Learning”[7] beschrijft de invloed van dergelijk effect op bucketbrigades. Het leereffect zal extra belangrijk zijn wanneer een nieuwe, onervaren werkerwordt toegevoegd aan de lijn.

De aannames van het klassieke model worden gemaakt. Bijzonder aan deze paper is echter,doordat de werksnelheid toeneemt in de tijd door het leereffect, een manier van passerenwordt geıntroduceerd voor het klassieke model: wanneer een werker geblokkeerd wordtdoordat hij een andere werker inhaalt, wisselen ze van positie.

Opnieuw blijkt het klassieke Bucket Brigademodel (met aangepast inhalen) een zeer ro-buuste manier van werken: de lijn balanceert zichzelf na een convergentieperiode, metvaste overdrachtspunten; echter, deze convergentieperiode kan zeer lang zijn (waar in datgeval ingrijpen door het management, of een goede initiele keuze van ordening, kan leidentot snellere convergentie).

2.5.4 Bucket Brigades in de natuur

Hoewel eerder zeldzaam, blijken Bucket Brigades ook voor te komen in de natuur[8]. Eenvorm van Bucket Brigades werd beschreven bij een Messor barbarus mierenkolonie: bijtransport van zaden naar het nest, werden de zaden doorgegeven van kleinere (tragere)mieren naar grotere (snellere) mieren dichter bij het nest.

Hoofdstuk 3

Simulatiemodel

3.1 Model

Het simulatiemodel is ontwikkeld in de programmeertaal Java (JDK 6). Dit zowel omwillevan de openheid en toegankelijkheid1, als omwille van de vertrouwdheid met Java. Alsontwikkelomgeving werd NetBeans2 gebruikt. Door de portabiliteit van Java, kan hetsimulatiemodel worden gedraaid op vrijwel elk courant besturingssysteem waarop de JavaRuntime Environment3 (minimaal 6.0) is geınstalleerd.

Het model werkt volgens het principe van discrete gebeurtenissensimulatie (Eng.: discreteevent simulation). Dat betekent dat tijdens de simulatie, er met (discrete) stappen zalworden voortgegaan in de tijd. Een seconde wordt bijvoorbeeld opgedeeld in 10 (i.e. eenklokfrequentie van 10Hz); tijdens elke stap van het simulatieprogramma wordt dus 0.1sverder gegaan in de tijd. Na elke stap kan de toestand van het systeem worden geevalueerd,en desgevallend actie worden ondernomen. Ook tijdens de voortgang kan een werker eenexceptie opwerpen wanneer hij zich in een of andere probleemsituatie bevindt (nood aaneen volgend onderdeel, . . . ); dit probleem kan meestal meteen worden opgelost (toewijzendaaropvolgend onderdeel, . . . ).

Deze discrete benadering, alsook door het feit dat getallen in een computer niet oneindignauwkeurig kunnen worden weergegeven, zal onherroepelijk leiden tot afrondingsfouten,die groter zullen zijn naarmate de stap groter wordt genomen. Volgens beschikbare reken-kracht, kan de stapgrootte willekeurig klein worden gemaakt, en dus ook de afrondingsfout.

De algemene structuur volgens pakketten (Eng.: packages) van het model is weergegevenin Figuur 3.1. Het is een voornamelijk logische onderverdeling van de code, waarondergelijkaardige klassen (Eng.: classes) worden gegroepeerd.

1zowel van de codetaal zelf als van het platform2NetBeans IDE, http://netbeans.org/3of JRE, gratis te verkrijgen via http://www.java.com/

36

HOOFDSTUK 3. SIMULATIEMODEL 37

1bucketbrigades

1bucketbrigades

2parts2

parts3

workers3

workers

4statistics4

statistics

Figuur 3.1: Structuur (packages) van het softwaremodel

1. bucketbrigadesHet “belangrijkste” onderdeel. Bevat de hoofdfunctie (Main) die wordt aangeroepenen die alle acties start en desgevallend actie onderneemt. Ook de algemene functies(Common) zijn hier terug te vinden, alsook controleklassen (Consistency, FlatLine,PathMonitor).

2. partsDit pakket verzamelt de verschillende onderdelen in het model, en bevat een in-terface (PartInterface) waaraan de “vaste” onderdelen (Path, Station, Longstation,Switchnode, Labelnode, Machine, Buffer) moeten voldoen. Bevat ook de “beweegba-re” onderdelen zoals de producten (Item), die (per een of meerdere) moeten wordengegroepeerd in een batch (Batch). LabelCycle is een hulpklasse.

3. workersBevat de implementatie van een effectieve werker (Worker) en de excepties (Eng.Exception) die deze kan opwerpen (FinishedWorkException, WorkingException, Out-OfSyncException).

4. statisticsHier worden alle duurtijdfuncties verzameld. Elke tijdsinitialisatie in het simulatie-model is eigenlijk een distributie (interface Distribution) of statistische verdeling. Datkan bv. een vaste, deterministische waarde voorstellen (Deterministic), een continueuniforme verdeling (Random), een verdeling conform ingelezen waarden (FromFile),. . . . Dit pakket bevat ook een algemene klasse (Common), die instaat voor het om-zetten van configuratiegegevens naar een geschikte distributie. Dit pakket kan inprincipe door elk onderdeel worden aangeroepen, maar wordt praktisch gezien enkelaangeroepen binnen het pakket parts (aldus de interconnectie in Figuur 3.1).

Van de code is voldoende uitgebreide javadoc (Nederlandstalig) beschikbaar, alsook is de


code zelf aangevuld met verklarende commentaar (meestal Engels). Tijdens de implemen-tatie werd steeds gepoogd zo transparant mogelijk te werken (zoals door het slim onder-verdelen in functies), en de uitvoering zo performant mogelijk te houden (door vervroegdafbreken lussen, . . . ). De javadoc is digitaal beschikbaar op de meegeleverde CD-ROM,net zoals de broncode van de software.

3.2 Werking

3.2.1 Algemeen

Algemeen en licht vereenvoudigd, verloopt het programma volgens de stappen in Figuur3.2.

Inlezenconfiguratie

Inlezenconfiguratie

VerifiërenconfiguratieVerifiëren

configuratieInitialisatieobjecten

Initialisatieobjecten

Uitvoerensimulatie

Uitvoerensimulatie Meerdere runs?Meerdere runs?

ja

einde

Figuur 3.2: Algemene stappen van het softwaremodel

1. Inlezen configuratieIn deze stap wordt de configuratie, die bestaat uit een XML-bestand, ingelezen. Eris gekozen voor XML, omdat dit de de facto standaard is geworden voor configura-tiebestanden, alsook omdat ze netjes gestructureerd zijn en dus gemakkelijk leesbaar(aanpasbaar) voor zowel mens als computer. Het XML-bestand wordt serieel ingele-zen volgens het SAX (Simple API for XML) model, voor de eenvoud in gebruik engezien extreme performantie hier niet nodig is.

2. Verifieren configuratieDe zonet ingelezen configuratie wordt hier naar best vermogen geverifieerd op cor-rectheid (juiste connectiviteit, unieke gebruik van namen, . . . ). Het verifieren vanelke mogelijke fout (en het uitprinten van een behulpzame foutmelding) is een zeercomplex (en dus tijdrovend) proces. Er is in dit onderdeel een duidelijke afweginggemaakt tussen nut (waarschijnlijkheid van de fout, ernst van de invloed op de simu-latie), benodigde rekenkracht voor de verificatie en tijd van implementeren; er wordtde nodige attentheid van de gebruiker verwacht bij het aanmaken of aanpassen vaneen configuratiebestand.

3. Initialisatie objectenIn deze stap worden een aantal objecten, die nodig zullen zijn voor het doorlopenvan de configuratie, geınitialiseerd en zo nodig geoptimaliseerd.


4. Uitvoeren simulatieDeze stap bevat de eigenlijke simulatie, die laterop in detail zal worden besproken. In-dien dezelfde simulatie meerdere malen (verschillende runs) moet worden uitgevoerd(willekeurige keuzes binnen het model zullen afwijkende resultaten geven), wordt dezestap herhaald zolang gewenst.

3.2.2 Configuratie

Zoals eerder vermeld, is het configuratiebestand een XML-bestand. Er wordt dan ook eenbasiskennis XML verondersteld voor het correct aanmaken of aanpassen van dit bestand.

Via het configuratiebestand worden de gegevens aangeleverd, zodat de software naar wenskan simuleren. Het is opgebouwd uit een aantal standaardelementen:

<?xml version="1.0" encoding="utf-8"?>

<config>

<general>...</general>

<items>...</items>

<parts>...</parts>

<workers>...</workers>

</config>

De eerste regel is vast, en duidt aan dat het om een XML-bestand zal gaan. Alle configu-ratiedetails dienen te zijn vervat binnen <config> en </config>. Binnen <config> zijner opnieuw 4 onderverdelingen.

• general

Bevat de algemene instellingen.

• items

Bevat meer informatie over de geproduceerde items. Deze tag is optioneel: indienniet vermeld wordt een batchgrootte van 1 ondersteld en standaard items zonderlabel.

• parts

De verzameling van onderdelen en hun onderlinge interconnectie, die samen de lay-out zullen vormen van de te bestuderen productielijn.

• workers

Bevat de verschillende werkers die actief zullen zijn tijdens de simulatie en hun res-pectievelijke instellingen.

In wat volgt, zullen voor deze onderverdelingen (algemene instellingen general, werkersworkers en onderdelen parts) telkens een aparte sectie zijn voorzien.


3.3 Algemene instellingen

De algemene instellingen, de onderverdeling <general>, is op zijn beurt onderverdeeld alsvolgt:

<general>

<num_runs>1</num_runs>

<run_for>3h</run_for>

<model>0</model>

<clock>10</clock>

<loglevel>0</loglevel>

</general>

3.3.1 Aantal runs

XML Tag: num_runs

Toegelaten waarden: gehele getallen groter dan 0

Deze waarde geeft aan hoeveel maal de simulatie dient te worden herhaald, telkens onaf-hankelijk van elkaar.

3.3.2 Simulatieduur

XML Tag: run_for

Toegelaten waarden: tijdsnotatie: elke combinatie van xhymzs met x, y en zgehele getallen, zoals bv. 8h, 2h30m, 30m25s, 7h36m30s

Duidt aan over welke (reele) tijd de simulatie zal lopen.

3.3.3 Model

XML Tag: model

Toegelaten waarden: 0, 1 en 2

Geeft het model aan volgens hetwelke de simulatie zal verlopen. De verschillende waardengeven aan:

0. Simulatie volgens de principes van klassieke Bucket Brigades: de werkers hebben eenvaste ordening die bij de start van de simulatie wordt vastgelegd, en wandelen (aanstations) oneindig snel terug.

1. Simulatie volgens de principes van veralgemeende Bucket Brigades: de werkers heb-ben geen vaste ordening (ze kunnen elkaar inhalen of passeren), maar wel een indexe-ring; ze nemen producten van elkaar over gebaseerd op hun indexering, en wandelenaan een longstation terug met een eindige snelheid.


2. Simulatie volgens een (eigen) generiek model: de werkers hebben geen vaste ordeningnoch indexering; ze kunnen elkaar inhalen (zelfde richting) doch niet passeren: elke“ontmoeting” leidt tot overdracht. Is overdracht aan een station niet mogelijk, danzal de terugwandelende werker blokkeren aan dit station.

3.3.4 Klokfrequentie

XML Tag: clock

Toegelaten waarden: gehele getallen groter dan 0

Geeft de klokfrequentie aan in Hz. De klokfrequentie geeft de stapgrootte aan per discreetevent, en zal een invloed hebben op de nauwkeurigheid van afronden. Een klokfrequentievan 20 (Hz) betekent dat bij elke stap 1

20s zal worden opgeschoven in de tijd.

3.3.5 Loglevel

XML Tag: loglevel

Toegelaten waarden: 0, 1, 2 en 3

Geeft de aard van de uitgangsgegevens aan die het model zal produceren. De gegevens dieworden geproduceerd zijn waarden die worden gescheiden door een puntkomma, wat ge-makkelijke invoering in bv. Excel toelaat. Tijdstippen worden steeds gegeven in seconden,de voortgang is procentueel uitgedrukt.

0. Print de afgewerkte producten (FP) uit en het tijdstip in reele tijd.

FP;tijdstip;werker

1. Print de afgewerkte producten (FP) en de nieuw gestarte producten (NP) uit en hettijdstip in reele tijd.

FP;tijdstip;werker

NP;tijdstip;werker

2. Print afgewerkte producten (FP), nieuw gestarte producten (NP) en overdrachten(HO) uit (werker1 werkte vooruit, staat zijn product af aan werker2 en wandeltterug).

FP;tijdstip;werker

NP;tijdstip;werker

HO;tijdstip;werker1->werker2

3. Print afgewerkte producten (FP), nieuw gestarte producten (NP), overdrachten (HO)en bovendien de voortgang van elke werker en dit aan welk onderdeel uit.


FP;tijdstip;werker

NP;tijdstip;werker

HO;tijdstip;werker1->werker2

werker;onderdeel;voortgang

Ingeval er labels (zie productmix) worden gebruikt, worden deze labels eveneens afgeprintbij afgewerkte producten (FP) en nieuw gestarte producten (NP):

FP;tijdstip;werker;label@end[padnaam]

NP;tijdstip;werker;label@begin[padnaam]

3.4 Onderdelen

Binnen de onderdelen of parts, worden de verschillende onderdelen als volgt aangegeven:

<parts>

<part type="..." name="...">

...

</part>

...

</parts>

De volgende algemene regels bij onderdelen zijn belangrijk voor een correcte werking vanhet model

• De naam die aan de onderdelen wordt gegeven, is niet-hoofdlettergevoelig4 en dientuniek te zijn.

• Er is slechts een startpunt toegelaten aan de lijn.

• Een station, longstation of een switchnode dient steeds voorafgegaan en gevolgd teworden door een pad (desgewenst van lengte 0).

Verderop worden de verschillende onderdelen en hun bijbehorende instellingen besproken.

3.5 Instellingen van items

Alle instellingen die betrekking hebben op items, en kortweg de onderverdeling <items>,zijn optioneel. Indien dit wel wordt vermeld, kan het de volgende instellingen bevatten:

4Station1 is dus gelijkwaardig aan station1 of sTaTiOn1


<items>

<batch_size>5</batch_size>

<group>

<product_mix pct="40">label1</product_mix>

<product_mix pct="60">label2</product_mix>

</group>

...

</items>

3.5.1 Batchgrootte

XML Tag: batch_size

Toegelaten waarden: Gehele getallen groter dan 0Opmerking: Deze tag is optioneel (batchgrootte wordt 1 verondersteld indienniet gedefinieerd).

Een Batch is een verzameling van 1 of meerdere items, die steeds samen door de werkersworden voltooid langsheen de productielijn.

3.5.2 Productmix

XML Tag: product_mix

Attributen:pct Het percentage van voorkomen van deze labels

Toegelaten waarden: Een of meerdere namen van labels, gescheiden door eenpuntkomma (zonder spaties)Opmerking: Deze tag is optioneel (er worden geen labels verondersteld indienniet gedefinieerd), en kan worden herhaald.

Batches die worden geproduceerd langs een productielijn kunnen bestaan uit verschillendeitems. Om dit te gaan simuleren, kan aan een item een welbepaald “label” worden gegeven(of meerdere labels). Deze labels worden toegekend door de tag product_mix, alsookhun mate van voorkomen. Door het gebruik van labels kunnen producten een welbepaaldpad afleggen langs een productielijn, en een andere werkinhoud toegewezen krijgen op deverschillende stations. Bij het beginnen van een nieuw item door een werker, wordt eenwillekeurige keuze gemaakt tussen de labels, weliswaar volgens de opgegeven verdeling.

Door gebruik te maken van de tag group (dit kan meermaals worden herhaald), kunnenarbitrair complexe labels worden gedefinieerd.

Voorbeeld: Langs een productielijn worden 2 items geproduceerd, groot en klein. 72% vande items zijn ’klein’, de overige 28% zijn ’groot’. Onafhankelijk van de grootte, geldt bo-vendien dat 35% ’wit’ is, 40% ’grijs’ en 25% ’zwart’. Dit zou als volgt worden gedefinieerd:


<items>

<group>

<product_mix pct="72">klein</product_mix>

<product_mix pct="28">groot</product_mix>

</group>

<group>

<product_mix pct="35">wit</product_mix>

<product_mix pct="40">grijs</product_mix>

<product_mix pct="25">zwart</product_mix>

</group>

</items>

Opmerking: Ook de oude syntax kan nog worden gebruikt, eveneens desgewenst met ver-schillende labels gescheiden door puntkomma.

<items>

<product_mix>klein;smal[47]</product_mix>

<product_mix>klein;breed[25]</product_mix>

<product_mix>groot;breed[28]</product_mix>

</items>

3.6 Onderdelen

3.6.1 Paden

Paden zijn verbindingsonderdelen binnen het model, waarlangs kan worden gewandeld.Ze dienen om verschillende onderdelen te verbinden, en als definitie van begin- en eind-punt. Paden komen als dusdanig niet voor in de originele beschrijving van het klassieke ofveralgemeende model, maar zijn wel essentieel voor het simulatiemodel. Desgewenst kaner langs een pad oneindig snel gewandeld worden, door de afstand van het pad als 0 inte stellen, of de wandelsnelheid van een werker op 0; merk op dat eindige (voorwaartse)wandelsnelheden een totaal nieuw concept zijn.

<part type="path" name="...">

<distance>10</distance>

<begin_point>onderdeel1</begin_point>

<end_point>onderdeel2</end_point>

</part>

Afstand

XML Tag: distance

Toegelaten waarden: Reele waarden groter of gelijk aan nul


Geeft de afstand van het pad aan in meter (m), tot maximaal 2 decimale getallen nauw-keurig. Ingeval simulatie volgens het model 1, mag enkel de waarde 0 worden gebruikt(gezien het verschil in definitie van wandelsnelheid bij een pad en een longstation).

Beginpunt

XML Tag: begin_point

Toegelaten waarden: Ledig of de naam van een onderdeel

Geeft het beginpunt van het pad aan. Indien hier geen waarde wordt aangegeven, is dithet beginpunt van het systeem.

Eindpunt

XML Tag: end_point

Toegelaten waarden: Ledig of de naam van een onderdeel

Geeft het eindpunt van het pad aan. Indien hier geen waarde wordt aangegeven, is dit eeneindpunt van het systeem.

3.6.2 Stations

Stations zijn onderdelen waarlangs wordt gewerkt. Terugwandelen aan dit soort stationsis instantaan (gebeurt dus met oneindige snelheid), onafhankelijk wat werd ingesteld alswandelsnelheid bij de werkers. Het gebruik van dit type station is enkel zinnig bij modellen0 en 2.

<part type="station" name="...">

<work_content>150</work_content>

<hand_off>1</hand_off>

<hand_off_time>0</hand_off_time>

<max_workers>1</max_workers>

<error_rate>0.001</error_rate>

<error_penalty>random(10;35)</error_penalty>

</part>

Standaard werkinhoud

XML Tag: work_content

Attributen:label Het label (of combinatie van labels) waarop deze werkinhoud van

toepassing is. Indien niet vermeld, is deze work_content de (label-onafhankelijke)standaard.

factor De factor waarmee de teruggegeven waarde van de distributie


moet worden vermenigvuldigd. Indien niet vermeld, is de factor 1.Toegelaten waarden: Een reele waarde groter dan 0 of een distributie

Hier wordt de standaard werkinhoud van een bepaald item aan dit station ingesteld. Ditkan een vaste (deterministische) waarde zijn, of een (stochastische) distributie. De tijddat een werker effectief aan dit product zal spenderen, zal afhangen van zijn ingesteldewerksnelheid.

Voorbeeld: Op dit station vereisen items met het label ’klein’ een werkinhoud van 100s,met het label ’groot’ een werkinhoud van 165s en de overige items 150s. Dit zou als volgtworden gedefinieerd:

<part type="station" name="...">


<work_content label="klein">100</work_content>

<work_content label="groot">165</work_content>

...

</part>

Overdrachten toegelaten

XML Tag: hand_off

Toegelaten waarden: 0 of 1, no of yes, false of trueOpmerking: Deze tag is optioneel (er wordt verondersteld dat overdrachten zijntoegelaten indien niet vermeld).

Middels deze waarde wordt aangegeven of overdrachten aan dit station zijn toegelaten.Indien een werker volgens een model werk van een voorganger aan dit station moet over-nemen, maar dit niet is toegelaten, dan zal deze werker blokkeren tot de voorganger klaaris met zijn batch aan dit station.

Overdrachtstijd

XML Tag: hand_off_time

Toegelaten waarden: Een reele waarde groter of gelijk aan 0, of een distributieOpmerking: Deze tag is optioneel (er wordt een overdrachtstijd van 0 veron-dersteld indien niet vermeld).

Soms zal een werker nog enkele stappen moeten voltooien, alvorens hij zijn product kanoverdragen aan een volgende werker. De tijd die een werker nog zal nodig hebben alvorenszijn product over te dragen, kan hier worden ingesteld; tot zolang zal de volgende werkergeblokkeerd staan wachten.


Aantal simultane werkers

XML Tag: max_workers

Toegelaten waarden: Gehele getallen groter dan 0, of -1Opmerking: Deze tag is optioneel (er wordt een maximum van 1 werker veron-dersteld indien niet vermeld).

Met deze waarde wordt ingesteld hoeveel werkers simultaan aan dit station kunnen werken.In de meeste gevallen zal dit slechts een werker zijn. In het geval van een continu station,zoals vroeger geıntroduceerd, zal deze waarde -1 zijn (een onbeperkt aantal simultanewerkers) of een welbepaalde eindige waarde.

Gedetecteerd aantal fouten

XML Tag: error_rate

Toegelaten waarden: Een reele waarde groter of gelijk aan 0Opmerking: Deze tag is optioneel (geen foutendetectie verondersteld indienniet vermeld).

Geeft het gedetecteerde foutenpercentage (0.001 betekent 1 gedetecteerde fout op 1000items) aan dit station.

Fouten zullen willekeurig worden geıntroduceerd aan een bepaald station. Deze foutenworden typisch vastgesteld bij een welbepaalde manipulatie (waar dan iets niet blijkt tekloppen), en niet noodzakelijk aan het station volgend op het station dat de fout heeftgeıntroduceerd. Net zoals de stations volgens een bepaalde distributie fouten zullen intro-duceren, zullen deze fouten aan een ander station met een qelijkaardige distributie wordenvastgesteld (dezelfde distributie indien alle fouten worden vastgesteld).

Extra werkinhoud per fout

XML Tag: error_penalty

Toegelaten waarden: Een reele waarde groter dan 0 of een distributieOpmerking: Deze tag is verplicht wanneer de tag error_rate voorkomt. Zonietzal deze tag worden genegeerd.

Deze waarde geeft aan hoeveel extra werkinhoud het detecteren van een fout zal inhoudenvoor een welbepaald item.

3.6.3 Stations met terugwandelsnelheid

Stations met terugwandelsnelheid of kortweg longstations, zijn stations waarlangs gewerktkan worden, maar waarlangs terugwandelen in principe niet oneindig snel is. De snelheidvan terugwandelen wordt ingesteld bij de werkers, en is een verhouding tot de waarde1 (analoog de werksnelheid); dit in tegenstelling tot wandelen langs een pad, waar de


wandelsnelheid wordt uitgedrukt in km/h. Het gebruik van dit type station is voornamelijkaangewezen bij model 1, in mindere mate bij model 2.

Langsheen een longstation kunnen zich steeds onbeperkt veel werkers bevinden.

<part type="longstation" name="...">


</part>

Bij een longstation is enkel de werkinhoud in te stellen. Deze instelling is volkomen analoogaan de instelling bij een (gewoon) station, en er wordt dan ook daarnaar verwezen.

3.6.4 Verdelers

Verdelers zijn onderdelen, specifiek om de seriele structuur van Bucket Brigades op tesplitsen, zoals bij sub-productielijnen of parallelle paden. Een verdeler kan een of meerdereingangen hebben, en een of meerdere uitgangen. Typisch gebruik is een ingang en ver-schillende uitgangen (als demultiplexer) en als tegenhanger laterop de lijn, hetzelfde aantalingangen en een uitgang (als multiplexer).

<part type="switchnode" name="...">

<input>...</input>

...

<output>...</output>

...

<blocking>0</blocking>

</part>

Ingang

XML Tag: input

Toegelaten waarden: De naam van een padOpmerking: Deze tag mag worden herhaald

Geeft aan dat het pad met deze naam een ingang is van deze verdeler.

Uitgang

XML Tag: output

Toegelaten waarden: De naam van een padOpmerking: Deze tag mag worden herhaald

Geeft aan dat het pad met deze naam een uitgang is van deze verdeler.


Blokkerend

XML Tag: blocking

Toegelaten waarden: 0 of 1Opmerking: Deze tag is optioneel. Indien niet vermeld, wordt 0 verondersteld.

Geeft aan of deze verdeler blokkerend zal werken:

• demux-gedrag (meer uitgangen dan ingangen)De verdeler houdt een drempelwaarde bij: dit zal de laagste (initiele) ordening zijnvan alle werkers die in voorwaartse richting langs deze verdeler zijn gepasseerd. Inachterwaartse richting zullen enkel de werkers zijn toegelaten te passeren met een(initiele) ordening lager of gelijk aan deze drempelwaarde. De drempelwaarde wordtindien nodig verhoogd.

• mux-gedrag (meer ingangen dan uitgangen)De drempelwaarde is nu de hoogste (initiele) ordening van de werker die voorwaartslangs deze verdeler is gepasseerd. In voorwaartse richting zullen enkel werkers mogenpasseren met een (initiele) ordening lager dan deze drempelwaarde.

Dit blokkerend gedrag van een verdeler dient in een poging de ordening van werkers tebewaren, wanneer zij bv. vanaf een parallel pad terug op een serieel deel terecht komen.

Controlepaden

Om de voortgang van werkers te kunnen opzoeken tussen 2 (tegengestelde) verdelers, bv.om te voldoen aan de vooropgestelde regels bij parallelle paden, zal het nodig zijn eencontrolepad te definieren tussen de twee verdelers. De namen van de controlepaden dieneneveneens uniek te zijn, en worden na de naam van het ingangs- of uitgangspad te wordenvermeld tussen vierkante haken. Een controlepad zal bijhouden welke werkers zich op ditpad bevinden, en zal er dan ook de voortgang van kunnen opvragen.

Het gebruik van controlepaden wordt verduidelijkt met een voorbeeld in Figuur 3.3.

1 sn1

2a

2b

3a

3b

sn2 4

controlepad1

controlepad2

Figuur 3.3: Voorbeeld gebruik controlepaden

Behorend bij Figuur 3.3, zou de verdeler sn1 bijvoorbeeld als volgt worden gedefinieerd:


<part type="switchnode" name="sn1">

<input>pad2</input>

<output>pad3a[controlepad1]</output>

<output>pad3b[controlepad2]</output>

</part>

en zijn tegenhanger sn2 als volgt:

<part type="switchnode" name="sn2">

<input>pad5a[controlepad1]</input>

<input>pad5b[controlepad2]</input>

<output>pad6</output>

</part>

Zonder gedefinieerde controlepaden, zal een verdeler het eerste pad kiezen (ingang → uit-gang of uitgang → ingang) waarlangs het minste aantal werkers zijn gepasseerd. Perpasserende werker zal een ingang met 1 worden verlaagd en de gekozen uitgang met 1worden verhoogd (voorwaarts passerende werker), of de uitgang met 1 worden verminderden de ingang met 1 worden verhoogd (achterwaarts passerende werker).

3.6.5 Verdelers volgens label

Een verdeler volgens label heeft een input, en meerdere outputs die worden geselecteerdnaargelang het label van het passerende item.

<part type="labelnode" name="...">

<input>...</input>

<output>...</output>

...

</part>

Ingang

XML Tag: input

Toegelaten waarden: De naam van een pad

Geeft aan dat het pad met deze naam een ingang is van deze verdeler volgens label. Er isslechts een ingang toegelaten.

Uitgang

XML Tag: output

Toegelaten waarden: De naam van een pad, met de naam van het label5 tussen

5van de items die hierlangs moeten worden gestuurd


vierkante haken.Opmerking: Deze tag mag worden herhaald

Geeft aan dat het pad met deze naam een uitgang is van deze verdeler, voor items met eenwelbepaald label.

Deze verdeler is ingevoerd specifiek voor de case study in het volgende hoofdstuk. Merk opdat “verdelen volgens label” slechts zin heeft in voorwaartse richting: bij het terugwandelendraagt een werker immers geen batch met items meer bij zich. Eventueel kan de uitsplitsingterug worden samengevoegd met een gewone verdeler.

3.6.6 Machines

Machines zijn gelijkaardig aan stations, met het belangrijke verschil dat de werkinhoudonafhankelijk is van de werksnelheid van de werker. Het zijn eigenlijk stations met eencyclustijd die afhankelijk is van het item dat wordt bewerkt, en niet van de werker die demachine bedient.

<part type="machine" name="...">


<work_content label="rework">75</work_content>

</part>

Werkinhoud of cyclustijd

XML Tag: work_content

Attributen:label Het label (of combinatie van labels) waarop deze werkinhoud van

toepassing is. Indien niet vermeld, is deze work_content de (label-onafhankelijke)standaard.Toegelaten waarden: Een reele waarde groter dan 0 of een distributie

Hier wordt de cyclustijd van deze machine aan een item ingesteld. Toegelaten zijn eenvaste waarde en een distributie.

3.6.7 Buffers

Buffers zijn onderdelen waar een tussenvoorraad (FIFO6) kan worden opgeslagen. Eenbuffer zal voorwaarts niet door een werker worden gepasseerd (hij laat er zijn batch achteren wandelt terug) tenzij de buffer vol is (dan laat hij zijn batch achter, en pikt de eerstebatch in de buffer op, die hij bewerkt aan de stations volgend op de buffer). Omgekeerd

6First In First Out: de batch die eerst in de buffer is geplaatst wordt er ook als eerste opnieuw uitgehaald.


zal een buffer achterwaarts niet worden gepasseerd, tenzij hij leeg is; tot zolang zal eenwerker telkens een batch oppikken uit de buffer en die voorwaarts bewerken. Deze vastepasseerregels kunnen naar believen worden bijgewerkt met fpass (forward pass) en bpass

(backward pass), om bv. de voorkeur aan te duiden dat een welbepaalde werker zich voorof achter de buffer bevindt.

<part type="buffer" name="...">

<content>5</content>

<fpass>werker1[0]</fpass>

<bpass>werker2[2]</bpass>

</part>

Buffercapaciteit

XML Tag: content

Toegelaten waarden: Een gehele waarde

Duidt de (batch-)capaciteit aan van de buffer, of anders gezegd, het aantal batches datdeze buffer kan bevatten. Een waarde kleiner dan 0 duidt aan dat de capaciteit van dezebuffer onbeperkt (oneindig) is.

Alternatieve waarde bij voorwaarts passeren

XML Tag: fpass

Toegelaten waarden: De naam van een werker met tussen vierkante haken degehele waarde groter of gelijk aan nul.

Duidt de inhoud aan van de buffer, vanaf wanneer de gespecificeerde werker deze zalpasseren (onafhankelijk of de buffer al dan niet vol is). Een waarde van nul betekent datde werker deze buffer steeds voorwaarts zal passeren, onafhankelijk van zijn inhoud.

Alternatieve waarde bij achterwaarts passeren

XML Tag: bpass

Toegelaten waarden: De naam van een werker met tussen vierkante haken degehele waarde groter of gelijk aan nul.

Duidt de inhoud aan van de buffer, vanaf wanneer de gespecificeerde werker deze achter-waarts zal passeren (onafhankelijk of de buffer al dan niet leeg is). Een waarde van nulbetekent dat de werker deze buffer steeds achterwaarts zal passeren, onafhankelijk van zijninhoud.


3.7 Werkers

De werkers zijn, zoals de naam het zegt, de werkers binnen het model. Zij zullen zichverplaatsen langs de paden en werken langs de stations, en hierbij telkens opnieuw batchesmet items verder tot voltooiing brengen.

Binnen het onderdeel werkers of workers, worden de afzonderlijke werkers gedefinieerd alsvolgt:

<workers>

<worker name="..." initial_order="x" index="y">

...

</worker>

...

</workers>

Merk op dat elke werker nu door 2, soms 3, attributen wordt gekenmerkt:

• name

De naam van de werker, die opnieuw dient uniek te zijn.

• initial_order

De volgorde in dewelke de werkers zullen starten met werken. Bij model 0 zal dezevolgorde worden gerespecteerd gedurende de hele uitvoering. Voor een goede definitiemoet elke werker een andere initiele ordening krijgen; de initiele ordening is uniek,start bij 1, en heeft als maximale waarde het aantal werkers.

• index

Dit attribuut heeft enkel betekenis in geval van model 1. Bij andere modellen kan ditattribuut weggelaten worden. Het geeft de (opnieuw unieke) indexering weer volgensde veralgemeende convergentievoorwaarde. Deze waarden dienen te liggen vanaf 1tot en met het aantal werkers.

Een werker wordt verder door 2 tags gekenmerkt

<worker name="..." initial_order="x" index="y">

<work_speed>1.2</work_speed>

<walk_speed>5</walk_speed>

</worker>

3.7.1 Werksnelheid

XML Tag: work_speed

Toegelaten waarden: Een reeel getal groter dan nul

Deze waarde, relatief t.o.v. 1, duidt de uniforme werksnelheid aan van deze werker.


3.7.2 Wandelsnelheid

XML Tag: walk_speed

Toegelaten waarden: Een reeel getal groter dan nul

Deze wandelsnelheid is uitgedrukt in km/h (langs paden) of relatief t.o.v. 1 (langs long-stations). Gezien het verschil in definitie, kunnen geen paden voorkomen met een lengteverschillend van 0 wanneer longstations worden gebruikt en omgekeerd.

3.8 Andere bouwblokken van het model

3.8.1 Distributies

Distributies werden al meermaals vermeld in het kader van het simulatiemodel, maar nognergens gedefinieerd. Zij zullen hier worden beschreven.

Elke tijdswaarde, zoals die bv. voorkomt bij een station of longstation, is achterliggend een(statistische) distributie. Op dit moment zijn de volgende distributies geımplementeerdbinnen het softwaremodel:

• Deterministische distributieDeze distributie geeft telkens dezelfde waarde terug. Ze stelt dan ook een vastewaarde voor.Aanroepwijze configuratie: Eenvoudigweg de vaste waarde (vb.: 1.2 of 1,5 of 3) oflangweg deterministic(waarde) met als waarde elk reeel getal groter dan 0.

• Uniforme distributie (continu)Deze distributie geeft een willekeurig reeel getal terug binnen een welbepaald interval.Aanroepwijze configuratie: random(waarde1;waarde2) met waarde1 een positief reeelgetal dat de start van het interval aangeeft, en waarde2 een positief reeel getal (groterof gelijk aan waarde1) dat het einde van het interval aangeeft.

• Cauchy-verdelingStelt een Cauchy-verdeling of een som (combinatie) van Cauchy-verdelingen voor.Aanroepwijze configuratie: cauchy(opties) met als opties in deze volgorde, zon-der spaties: begininterval; eindeinterval; y0; A1; w1; xc1; A2; w2; xc2; . . . ) met alleopgegeven waarden reele getallen.

• Willekeurige distributie uit bestandDeze distributie gaat reele waarden inlezen uit een opgegeven bestand. Dit bestanddient een waarde per regel te bevatten; commentaarregels dienen te beginnen met ’#’(zonder de ’). Er wordt een geheel willekeurige keuze gemaakt tussen deze waarden.Eenzelfde waarde kan meermaals voorkomen: dit verhoogt de probabiliteit dat diewaarde zal worden gekozen.Op deze manier kunnen handig moeilijk of niet te “matchen” distributies worden


gedefinieerd.Aanroepwijze configuratie: fromfile(bestandsnaam) met als bestandsnaam de vol-ledige bestandsnaam (incl. extensie zoals .txt) van het in te lezen bestand, hetzij eenabsoluut of relatief pad (t.o.v. de map waarin het programma wordt uitgevoerd).

3.8.2 Package help

De package help heeft geen rechtstreeks belang voor de uitvoering van de simulatie. Zebevatten een aantal op zichzelf staande bestanden voor de gemakkelijke verwerking vanlogbestanden die door het simulatiemodel worden gegenereerd. Ze zullen dankbaar wordengebruikt bij het verwerken van de gegevens die worden aangemaakt bij de Case Study.

• MergeStationsVoegt de bestanden station6a.txt en station6b.txt samen tot een bestand station6.txt,alsook station7a.txt en station7b.txt tot station7.txt. Dit voor een snelle bepalingvan de (relatieve) werkinhoud van de parallelle stations 6 en 7 in de standaardsituatie.

• SplitBufferSplits het gegenereerde bestand buffer.txt op in aparte, instelbare buffers.

• WorkerPerZoneBepaalt de zonebezetting van de verschillende (instelbare) werkers op basis van hetzonelog.txt-bestand.

3.9 Uitvoeren simulatie

De simulatiestap zelf (zoals die werd vermeld in Figuur 3.2), is op zijn beurt onderverdeeldin een aantal aparte stappen. Zoals kan worden verondersteld, schuilt in deze stap de warekracht van het simulatiemodel: de snelheid van uitvoering, de consistentie van uitvoeren,de nauwkeurigheid, . . . . Zonder hier al te technisch te worden, zal toch geprobeerd wordeneen goed beeld te schetsen van de werking “onder de motorkap”.

De simulatiestap wordt schematisch voorgesteld in Figuur 3.4. Een lus (Eng.: loop) wordtvoorgesteld door een rechthoek met afgeronde hoeken; een rechthoek is een effectieve uit-voeringsstap; een ruit duidt een keuzemogelijkheid (if. . . then . . . else) aan.

Vooreerst vallen de 3 lussen op aan het begin van de simulatie

• Lus ALus A kijkt of het aantal seconden simulatie (zie run_for) al is gehaald. Zo ja, danhoudt de simulatie hier op. Zo nee, dan worden de onderliggende stappen (meer-maals) uitgevoerd.


C. Ga telkens1 subtick verder

A. Ga telkens1s verder

B. Ga telkens1 tick verder

1. Sla statussen op

2. Bepaal volgorde werkers

3. Zolang werkerswijzigen, herhaal

3a. Doe werker werken

4. Consistent?

5a. Bevestig status

Ga een stap verder

5b. Herstel vorige statusVergroot aantal subticks

Herbegin deze stap

+

Einde lu s

ja nee

Figuur 3.4: Overzicht van de simulatiestap


• Lus BLus B werkt het aantal ticks af per seconde, overeenkomstig met de ingestelde klok-frequentie (zie clock). Is de klokfrequentie 10Hz (en dus de stap 0.1s), dan zal dezelus B telkens 10x worden uitgevoerd.

• Lus CIn een normaal geval heeft lus C geen functie, en zal ze telkens slechts eenmaal de on-derliggende functionaliteit doorlopen. Het systeem kan echter, door problemen metde consistentie van de simulatie (zie ook laterop stappen 4 en 4b), intern en transpa-rant beslissen om de nauwkeurigheid te verhogen, door elke tick van lus B nogmaalsonder te verdelen in 10, 100, 1000, . . . subticks, totdat de gewenste nauwkeurigheid isbereikt.

Onder deze 3 lussen, begint de echte uitvoering van de simulatie. Grofweg worden 5 stappendoorlopen:

1. Sla statussen opTijdens deze stap wordt de volledige status van elk onderdeel en elke werker opgesla-gen. Dit zal toelaten om, bij desgevallende inconsistentie laterop, als het ware terugte keren in de tijd naar dit moment van opslaan.

2. Bepaal volgorde werkersHet is niet mogelijk om alle werkers exact tegelijk aan te sturen, en dus zal er eenkeuze moeten worden gemaakt in de volgorde. Tijdens deze stap worden de werkersgeordend volgens voortgang: van laatste aan de lijn tot eerste. De keuze om tebeginnen bij de verst gevorderde werker, is tweeledig:

• de laatste werker heeft het minste kans om geblokkeerd te zijn, maar zal welbepalend zijn voor het blokkeren van (in principe) al zijn voorgangers.

• de laatste werker verricht meestal het meeste werk.

3. Zolang werkers wijzigen, doe ze werkenIn deze stap gebeurt het echte werken: een werker wordt geınstrueerd te werkenbinnen een bepaalde tijdslimiet.De voortgang van een bepaalde werker, kan ook voortgang betekenen voor anderewerkers (bv. bij blokkeringen). Om de invloed van het doorlopen naargelang volgordete beperken, wordt opnieuw geprobeerd om werkers te doen vorderen van zodra eenwerker voortgang vertoont.

4. Is deze status consistent?In deze stap wordt gekeken of alle werkers in de volgorde staan die door het modelworden opgelegd. Wanneer 2 werkers voldoende dicht tot elkaar zijn genaderd in te-genovergestelde richting (voorwaarts werkend ↔ achterwaarts wandelend), wordt debatch (de verzameling items) overgedragen en zullen zij bij de volgende tick wijzigenvan richting.


5. Was de status consistent?

• a: JaBevestig deze (correcte) nieuwe status, en ga een tick verder.

• b: NeeHerstel het systeem naar de eerdere toestand (uit 1.). Vermenigvuldig het aantalsubticks met 10 en probeer opnieuw (met verhoogde nauwkeurigheid).

3.9.1 Nauwkeurigheid

De fases Opslaan status → Verifieren consistentie → Doorgaan of herstellen zijn belangrijkvoor een correcte en nauwkeurige overdracht. We illustreren dit met een voorbeeld inFiguur 3.5.

In Figuur 3.5(a) wordt de beginsituatie geschetst: beschouw 2 werkers langs een pad, wkA

en wkB. Werker wkA wandelt vooruit met een bepaalde snelheid en in bezit van een item.Werker wkB wandelt terug, en moet het product van wkA overnemen. De (wandel)snelheidvan wkB is bovendien dubbel zo groot als de snelheid van wkA. Het exact nauwkeurigeoverdrachtspunt wordt weergegeven als o. De werkers zijn vast geordend, en de maximaaltoelaatbare fout is de afstand tussen 2 streepjes in.

Figuur 3.5(b) schetst een hypothetische situatie: door de volgorde om werkers te gaanbewegen, komt wkB eerst aan de beurt. Hij beweegt voort tot exact hetzelfde punt alswkA, en merkt op dat ze beiden in tegenovergestelde richting bewegen. wkB besluit omhet item van wkA over te nemen, en beiden wijzigen hun richting. Het overdrachtspuntligt 2 streepjes verwijderd van het goede, nauwkeurige punt o. Deze situatie is echterhypothetisch: werkers bewegen in tegenovergestelde richting t.o.v. elkaar, zonder weet tehebben van elkaars positie. Wat dus in realiteit gebeurt, wordt weergegeven in Figuur3.5(c).

De werkers zijn elkaar gepasseerd zonder overdracht, en bewegen nog steeds in hun respec-tievelijke richtingen. In deze situatie echter, staat wkB vroeger op de lijn dan wkA. Ditwordt gedetecteerd (stap 4), er wordt gemeld dat het systeem inconsistent is.

Deze inconsistentie leidt ertoe dat het systeem in zijn oorspronkelijke toestand wordt her-steld, en dat de stapgrootte (d.m.v. subticks) wordt verkleind (voor de eenvoud nemenwe aan dat de stapgrootte met een factor 5 wordt verkleind, in tegenstelling tot 10 in hetechte softwaremodel). De nieuwe situatie wordt weergegeven in Figuur 3.5(d)

In Figuren 3.5(e) tot 3.5(g) wordt verdergegaan met deze verkleinde stapgrootte. BijFiguur 3.5(g) detecteert het systeem dat wkA en wkB in tegenovergestelde richting bewegen,en voldoende dicht zijn genaderd (tolerantie van een blokje) voor een overdracht. De


overdracht wordt dan ook ingezet, en de richting van beide werkers wordt omgekeerd(Figuur 3.5(h)).

Dit overdrachtspunt ligt, op een afrondingsfout na door de tolerantiegrens, erg dicht bij hetideale overdrachtspunt. Dit zal alleszins veel beter zijn dan een afrondingsfout zoals bv.in Figuur 3.5(b). Na de fase van subticks (lus C) wordt de subtickwaarde terug ingesteldop 1 (om performantieredenen), opnieuw tot zolang de consistentieregels anders opleggen.

Afronden - tolerantie

Reele getallen kunnen niet met oneindige precisie worden voorgesteld binnen een compu-ter (oneindige precisie zou een oneindig groot geheugen vereisen). Voor de interne bere-kening wordt gebruik gemaakt van de klasse BigDecimal7, voor exacte representatie meteen nauwkeurigheid van 15 decimalen; bovendien zal, ingeval van noodzakelijke afronding,deze afronding op willekeurige basis naar boven en naar beneden gebeuren (om versterkingvan het effect van de afronding in opeenvolgende ticks te vermijden).

De tolerantie die zal worden gebruikt bij vergelijkingen, wordt gekozen op basis van deingestelde klokfrequentie:

tolerantie =1

100 ∗ klokfrequentie

Bij een ingestelde klokfrequentie van 20(Hz) wordt het volgende interval als ‘voldoendedicht bij 0’ aanzien om als 0 te worden beschouwd: ]− 0.0005; 0.0005[, waarbij:

tolerantie =1

100 ∗ 20= 0.0005

3.10 Uitbreidingen, verbeteringen

Zonder noodzakelijk in volgorde van belangrijkheid te zijn vermeld, worden hier een aantalideeen tot uitbreiding of verbetering aangegeven.

• Warming-up faseDe meeste simulatiemodellen werken met een zgn. warming-up fase: een tijd ge-durende welke het systeem de tijd heeft om zich te stabiliseren, zonder dat tijdensdie warming-up al resultaten worden geproduceerd. Het is een optie om dit ook indit softwaremodel te gaan gebruiken, hoewel net tijdens deze warming-up-fase deconvergentie van het systeem zal waar te nemen zijn.

7http://java.sun.com/javase/6/docs/api/java/math/BigDecimal.html


wkA wkBo

(a) Beginsituatie

wkA

wkB

o

(b) Domweg overnemen

wkAwkB

(c) Realistische situatie

wkA wkB

(d) Herstelde situatie, kleinere stapgrootte

wkA wkB

(e) Na 1 verkleinde stap

wkA wkB

(f) Na 2 verkleinde stappen

wkA wkB

(g) Na 3 verkleinde stappen

wkA wkB

(h) Na 3 verkleinde stappen gebeurt de overdracht

Figuur 3.5: Illustratie verschillende fasen


• Willekeurige startposities werkersHet zou handig zijn wanneer we werkers zouden kunnen laten starten vanaf eenwillekeurige positie binnen het systeem, i.p.v. zoals nu op startpositie nul. De vraagis hoe deze positionering dan best kan gedefinieerd worden (procentueel t.o.v. dewerkinhoud? → stochastische werktijden?, . . . ). Een dergelijke aanpassing kan,maar is niet zomaar rechttoe rechtaan bij te programmeren.

• Onderbreken/herinvoegen werkersOok bij realistische productielijnen is het mogelijk dat een werker na een bepaalde (si-mulatie)tijd van de lijn verdwijnt (bv. externe oorzaak, pauze) of wordt toegevoegdaan de lijn (bv. na onderbreking, bij toegenomen hoeveelheid orders, na verlofdag).Herinvoegen vereist opnieuw een goede definiering (regels) waar de werker precies op-nieuw begint te werken, onderbreking vereist dat batches kunnen worden gedroppedop een willekeurige plaats langsheen de productielijn (en naderhand worden opge-pikt).

• Afbreken subticks na oplossen probleemWanneer een inconsistentie wordt vastgesteld, wordt de status van het systeem (aldan niet meerdere keren) teruggerold naar een vorige toestand, en de stapgrootteverkleind. Na het oplossen van een dergelijke inconsistentie, is er echter geen redenmeer waarom de huidige klokcyclus wordt verdergesimuleerd in deze verkleinde stap-grootte. Er zou dan echter moeten bijgehouden worden wanneer de (en liefst ookwelke) inconsistentie werd opgelost; bovendien moet het teruggaan naar een groterestapgrootte ook gebeuren op een veelvoud van 10 (om de subtick met 10x te kunnenverhogen).

• Analoog subticks, stap vergrotenMisschien is het mogelijk om, naar analogon van de subticks, op bepaalde momentende stapgrootte te vergroten; dit zal de uitvoeringstijd van de simulatie uiteraard tengoede komen. Het is echter niet zomaar te voorspellen wanneer het vergroten vandeze stapgrootte mogelijk of aangewezen is.

• Software opsplitsen per modelIn dit softwaremodel werd gekozen om de modellering aan te geven in het configu-ratiebestand (model = 0, 1 of 2). Ieder model echter vereist aparte aannames enaparte functies, die onnodig of overbodig kunnen zijn voor een ander model. Hetware waarschijnlijk beter geweest het model van begin af aan uit te splitsen in 3aparte simulatiemodellen, voor betere overzichtelijkheid en betere performantie. Ditzou echter leiden tot veel dubbele code, en veel knippen/plakken-bewerkingen leidenbij software bijna onvermijdelijk tot moeilijk te vinden fouten.

• GUI (Graphical User Interface)Het zou visueel aantrekkelijk zijn wanneer de positie van de werkers grafisch zou kun-nen worden gevolgd. Dit op zich is echter flink wat programmeerwerk, en bovendien


zal goed moeten worden nagedacht hoe niet-deterministische werkinhouden duidelijkzouden kunnen worden weergegeven.

• Verbeteren configuratiecontrole, betere foutmeldingenZoals vroeger reeds aangegeven, kan de controle van de instellingen uit het confi-guratiebestand nog beter, en kunnen de foutmeldingen die worden gegeven bij devaststelling van een fout ongetwijfeld nog verbeterd worden. Hier dient echter steedsde afweging programmeertijd↔ uitvoeringstijd↔ alomvattendheid worden gemaakt.

• Races bij gelijke snelhedenModel 2 kent geen controle op de goede volgorde van werkers: werker zijn enkelgebonden tot overdracht van hun items wanneer ze elkaar tegenkomen, maar kunnenelkaar bv. gaan inhalen langs een pad (zoals in de realiteit). Wanneer 2 werkersechter met gelijke (wandel-/werk-)snelheid starten aan een bepaald onderdeel, kande ordening worden verstoord: door zeer kleine afrondingsfouten kan een werker,hoewel heel beperkt, een andere werker voorbijsteken (terwijl ze in principe exactgelijk zouden moeten voortbewegen). Dit kan leiden tot ongewenst gedrag, maaris niet eenvoudig te verhelpen. Best is dus, wanneer een bepaalde ordening wordtbeoogd bij model 2, de werkers toch een verschillende werk- of wandelsnelheid tegeven maar dan met een zeer klein verschil.

• Vereiste van proper einde kan simulatie flink vertragenOm realistische posities van andere werkers te kunnen afdrukken wanneer de lijn zichreset, zal worden vereist dat een werker die een product voltooit aan het einde vande lijn, dit doet (afgerond) exact aan het einde van zijn werkcyclus; hiervoor zal dusmogelijk de stapgrootte worden verkleind door subticks te gebruiken. De voortgangaan een onderdeel wordt steeds procentueel bekeken; is de werk- of wandelinhoudvan een onderdeel echter kort, dan zal telkens een vrij groot percentage wordenvoortgegaan aan dit onderdeel. Bij grote percentagevoortgangen kan het dus nodigzijn dat de stapgrootte zeer klein wordt gemaakt om juiste voltooiing te bekomen, enkan dus de simulatie enorm vertragen. Het is dan ook niet aangewezen om een kleinstation of een kort pad aan het einde van een gesimuleerde productielijn te plaatsen.

Hoofdstuk 4

Enkele simulaties in de praktijk

In Hoofdstuk 3 werd het simulatiemodel voornamelijk theoretisch benaderd, bijna eerderopgevat als een soort “handleiding”. Het mag hieruit al duidelijk zijn dat het model flinkwat meer kan simuleren dan wat de beperkte aannames van de modellen opleggen. In dithoofdstuk zullen een aantal variaties op de modellen besproken in Hoofdstuk 2, wordenvoorgelegd aan het simulatiemodel. Een aantal van deze resultaten zullen ook helpen omde case uit het volgende hoofdstuk op te lossen.

4.1 Stations gescheiden door paden, eindige wandel-

snelheid

In de praktijk zullen de afzonderlijke stations niet steeds voldoende dicht bij elkaar liggen,zodat niet steeds kan worden aangenomen dat het aandeel wandelen t.o.v. het aandeelwerker voldoende klein is om te worden verwaarloosd.

We beschouwen een productielijn met de volgende opstelling (een pijl stelt een pad voormet aangegeven lengte, een blokje stelt een station voor met aangegeven standaard werk-inhoud):

40s 65s 30s 85s8m 2m 3m 1.5m 0m

Figuur 4.1: Opstelling simulatie

We veronderstellen het klassieke model, en nemen 2 werkers met werksnelheden 1 en 1.2,en wandelsnelheden van 4.8km/h1 en 4.81km/h2. De werkers worden geordend volgens deconvergentievoorwaarde op hun werksnelheid.

1conform het normale Bedaux-tempo2om races te vermijden

63

HOOFDSTUK 4. ENKELE SIMULATIES IN DE PRAKTIJK 64

Bij oneindige wandelsnelheid zouden de werkers niet blokkeren, en een lijncyclustijd van220s1+1.2

= 100 seconden per product behalen. We zijn nu benieuwd naar de lijncyclustijdwanneer er wordt gewandeld (die zal ongetwijfeld hoger liggen), en of deze lijn convergeertnaar een stabiele toestand.

60

80

100

120

140

160

180

200

0 10 20 30 40 50

Figuur 4.2: Lijncyclustijd bij gebruik van paden

Uit Figuur 4.2 blijkt dat de lijn inderdaad convergeert, en wel naar de waarde 101.4. Delijncyclustijd ligt dus inderdaad een fractie hoger door wandelen, doch de lijn convergeertwel naar een stabiele waarde (en dus stabiele overdrachtspunten).

4.2 Stations met stochastische werkinhoud

In de praktijk is het evenmin steeds aan te nemen dat de werkinhoud aan elk stationdeterministisch is, bijvoorbeeld door inherente variatie in de bewerkte soorten items.

We hernemen het vorige voorbeeld, doch nu nemen we de werkinhouden variabel (maarwel nog steeds gehele getallen):

35-45s 60-70s 25-35s 80-90s8m 2m 3m 1.5m 0m


We vermoeden een resultaat conform Punt 2.5.1, een besproken artikel[5]. In dit artikelgaat men echter uit van een voldoende aantal stations; vermoedelijk zullen de 4 beschouwdestations te weinig zijn om van voldoende te kunnen spreken, en zullen er werkers regelmatiggaan blokkeren.


60

80

100

120

140

160

180

200

220

0 20 40 60

Figuur 4.4: Lijncyclustijd bij stochastische werkinhouden

In Figuur 4.4 is duidelijk te zien dat de lijncyclustijd zich volkomen willekeurig gedraagt. Ineen tweede stap (niet opgenomen in bijlage) wordt de klokfrequentie tot 10Hz verkleind, ende gesimuleerde tijd verhoogd tot 300 uren. We zullen hiervan het gemiddelde berekenen,kijken of dit convergeert en zo ja, naar welke waarde?

100

120

140

160

180

200

0 100 200 300 400 500

Figuur 4.5: Gemiddelde lijncyclustijd bij stochastische werkinhouden

De gemiddelde waarde convergeert reeds na een 100-tal afgewerkte producten richting eenwaarde. Deze waarde is na meer dan 9500 waarden geconvergeerd tot 110.43, hoewel dezewaarde slechter is dan voorgaand (door blokkeren).

4.3 Stations met overdrachtstijden

In niet alle gevallen kan het werk aan een station niet zomaar onmiddellijk worden doorge-geven wanneer een terugwandelende werker daarom vraagt: soms zal de huidige bewerkingbv. eerst moeten worden afgerond.


Beschouw opnieuw het originele voorbeeld, maar nu is er aan elk station een vaste over-drachtstijd van 10s.

40s (+10s) 65s (+10s) 30s (+10s) 85s (+10s)8m 2m 3m 1.5m 0m


In Figuur 4.7 wordt het resultaat getoond. Hoewel moeilijk te zien op de figuur, sprin-gen de waarden in stabiele toestand tussen 115.92 en 115.96; dit kan toeval zijn doorafrondingsfouten, of wijzen op quasi-periodiek gedrag.

60

80

100

120

140

160

180

200

0 10 20 30 40 50

Figuur 4.7: Lijncyclustijd met overdrachtstijden

Om het mogelijke quasi-periodieke gedrag te onderzoeken, herhalen we de simulatie, maarnu met de middelste stations omgewisseld (enkel de 2 middelste stations, de paden blijvenzoals voorheen).

60

80

100

120

140

160

180

200

0 10 20 30 40 50

Figuur 4.8: Lijncyclustijd met overdrachtstijden


Uit Figuur 4.8 blijkt inderdaad duidelijk dat stations met overdrachtstijden, (kunnen)leiden tot quasi-periodiek gedrag.

4.4 Items met verschillend padverloop

Wanneer we items een label geven, kunnen we ze via een verschillend pad laten afwerken.Gezien de labels willekeurig worden toegewezen (zelfs indien 50/50 kunnen twee opeenvol-gende batches zonder probleem hetzelfde label dragen), verwachten we ook een willekeurigelijncyclustijd, ook per item afzonderlijk beschouwd.

Beschouw de volgende productielijn.

40s 65s ln

55s

30s 85s8m 2m 1m 2m

2.5m

1.5m 0m

0m


De verschillende producten worden willekeurig gestart, en geeft inderdaad aanleiding toteen willekeurige lijncyclustijd (Figuur 4.10). Uitsplitsen per product geeft geen beter re-sultaat, ook dit is willekeurig.

0

50

100

150

200

250

0 20 40 60

Figuur 4.10: Lijncyclustijd met labels

4.5 Items met rework

We hernemen opnieuw het allereerste voorbeeld. Aan het vierde station wordt nu echterbij 1 op 25 items ( 1

25= 0.04) een fout vastgesteld. Deze fout geeft aanleiding tot een extra


bewerking, die een vaste 25s duurt. Om niets te missen, verhogen we de simulatieduureveneens naar 5 uren. De fouten worden opnieuw willekeurig gedetecteerd.

40s 65s 30s 85s (+25s?)8m 2m 3m 1.5m 0m


In Figuur 4.12 worden de lijncyclustijden van de eerste 150 producten weergegeven. Erzijn zeer mooi 6 hickups te zien in de lijncyclustijd, waarna de lijn zich opnieuw organiseerttot een stabiele output.

60

80

100

120

140

160

180

200

0 50 100 150

1 2 3 45

6

Figuur 4.12: Lijncyclustijd met rework

4.6 Vergelijking overdrachten bij parallelle paden

Voor de volgende simulaties kiezen we drie werkers met resp. werksnelheden 1, 1.1 en1.2 en wandelsnelheden 4.80, 4.81 en 4.82; we nemen een nieuwe opstelling met parallellepaden als volgt:

40s 25s

180s

180s

30s 55s0m 1.5m

5m

5m

5m

5m1m 0m



Voor de overdrachten tussen de paden onderling hoeven we het parallelle station enkel tevervangen door een continu stations waaraan maximum 2 werkers kunnen werken. Hetresultaat van de simulatie wordt getoond in Figuur 4.14. Zoals kan worden verwachtconvergeert de grafiek, en wel naar een lijncyclustijd van 106.20 seconden per item.

50

100

150

200

250

300

0 20 40 60 80 100

Figuur 4.14: Lijncyclustijd bij overdrachten tussen de paden onderling

Voor de overdracht langsheen de paden moeten we gebruik maken van switchnodes enbijbehorende pathmonitors. Het resultaat is weergegeven in Figuur 4.15. Hoewel moeilijkte zien, is de periode van het quasi-periodieke gedrag = 6. Het voortschrijdende gemiddeldeis 106.37 seconden per item. Dit blijkt marginaal slechter dan de simulatie in voorgaandgeval.

50

100

150

200

250

300

0 20 40 60 80 100

Figuur 4.15: Lijncyclustijd bij overdrachten langsheen de paden

Hoofdstuk 5

Case study

5.1 Inleiding

Een deel van deze thesis bestaat erin het ontwikkelde simulatiemodel te gaan toepassenop een praktische case. In wat volgt, zal deze case worden beschreven, de vraagstellingworden besproken, en worden gepoogd een voldoende antwoord te bieden met behulp vande software. Dit heeft als concreet voordeel dat op zeer korte tijd een aantal variaties kun-nen worden bekeken op verschillende situaties, zonder dat deze effectief dienen te wordenuitgeprobeerd in de praktijk met alle praktische bezwaren (en zelfs economische verliezen)vandien.

Bij het ontwikkelen van het softwaremodel werd de toepassing in deze case study sterkindachtig gehouden. Hiervan getuigen o.a. het onderdeel buffer; tussenvoorraden komenstrikt gezien immers nooit voor bij Bucket Brigade productielijnen.

5.2 Situatieschets

Bij het bedrijf Van Hoecke te Sint-Niklaas, beschouwen we de Halux-productielijn. Hetbetreft de productie van aluminium kaderdeuren voor o.a. huishoudelijke toepassing (zo-als keukens). Er wordt steeds vertrokken van aluminium profielen en diverse onderdelen(vijzen, glas, montagehoeken,. . . ); deze aluminium latten worden to order 1 gezaagd en be-werkt. Afhankelijk van de vraag, worden deze onafgewerkte aluminium frames vervolgenshetzij geassembleerd met extern aangeleverd glas (meest voorkomend), hetzij verlaten zijde productielijn niet-geassembleerd doch verpakt.

De layout van de productielijn wordt weergegeven in Figuur 5.1. De flow start bij de grijzedriehoek rechtsonderaan (voorraad courante aluminium latten), en eindigt bij (een van) degrijze pijlen linksbovenaan. De kaderdeuren doorlopen doorgaans de productielijn in eenbatch van 5 kaderdeuren, op karretjes voorzien van wieltjes.

1van build to order, (op maat) gemaakt nadat het product is besteld.

70

HOOFDSTUK 5. CASE STUDY 71

11

2a2a

2b2b

33

44

77

5a5a

5b5b

6a6a

88

6b6b

Figuur 5.1: Layout van de beschouwde productielijn

1 Voorraad aluminium latten2a Dubbele zaag2b Enkele zaag (latten < 400mm)3 Freesmachine (gaten scharnieren, e.d.)4 Aanbrengen van dichtingen

5a, 5b Boor (gaten voor samenschroeven kader)6a, 6b Parallelle assemblagepost

7 Verpakking kaders zonder glas8 Oven

Tabel 5.1: Legenda bij Figuur 5.1

Om een goed beeld te kunnen schetsen van de productielijn, zal elke post afzonderlijk kortworden beschreven.


Post 1: voorraad aluminium

De productie start bij het oppikken van aluminium latten. Hier liggen enkel de meestcourante profielen; de overige latten moeten worden gehaald in de naastgelegen ruimte(hal). Tegelijk worden de latten nauwkeurig gecontroleerd op fouten (zoals krassen), dieworden gemarkeerd.

Post 2a: dubbele zaag

Vooreerst worden de profielen op maat gezaagd. Alle profielen groter of gelijk aan 400mmworden op de dubbele zaag gezaagd. De bedoeling is dat de dubbele zaag telkens 2 profielengelijktijdig zal zagen in de toekomst. Bij het tijdsmeten was dit gelijktijdig zagen slechtshet geval voor een minderheid van de profielen: door onvoldoende bovenlangse inklemmingverplaatst het tweede profiel zich lichtjes door de zijdelingse inklemming; gevolg is dat hetverstek van het tweede profiel incorrect is. Gelijktijdig zagen wordt echter in de nabijetoekomst mogelijk gemaakt, zodat gelijktijdig zagen zal worden bij de simulaties voor hetoplossen van de vragen bij de case. De opgemeten tijden kunnen aldus simpelweg gedeeldworden door 2 zonder noemenswaardige afwijking.

Post 2b: enkele zaag

Profielen kleiner dan 400mm vereisen bewerking op deze zaag. Het instellen van deze zaagduurt echter langer, alsook het eigenlijke zagen. Er kan steeds slechts een profiel per keerworden gezaagd.

Post 3: freesmachine

De freesmachine freest gaten in de kaderzijden die dit vereisen. Deze gaten dienen o.a.voor het laterop aanbrengen van scharnieren e.d..

Post 4: dichtingen aanbrengen

Kaders die niet worden gekleefd, vereisen het aanbrengen van een kunststof dichting omhet glas te fixeren. Dit gebeurt aan deze post.

Post 5a/b: boor

In elke kaderzijde worden 2 gaten geboord, die later zullen dienen om de kaderzijden aanelkaar te verbinden. Er staan 2 boren, een voor brede profielen en een voor smalle profielen,zodat de boormal minder vaak moet worden vervangen. De tijden zijn echter gelijkaardig,en er zal dan ook worden aangenomen dat post 5 een enkele post is.


Post 6a/b: assemblage

Aan de assemblagepost worden de aparte zijden en het (extern aangeleverd) glas geassem-bleerd tot een geheel. Deze stap is de probleemstap, omwille van de grote hoge (en sterkvarierende) assemblagetijd. Om deze reden zijn er 2 (a en b) parallelle (!) assemblagetafelsvoorzien.

Post 7: verpakken

Kaders die ongeassembleerd (en zonder glas) naar de klant worden verzonden, worden aandeze tafel verpakt samen met de nodige onderdelen (montagehoeken en schroeven). Dekaderzijden worden o.a. in bubbelfolie verpakt. Voor buitenlandse klanten (5% van deverpakte kaders) wordt het pakket daarenboven verpakt in karton (dat op maat wordtgesneden aan de andere kant van de productiehal), wat extra tijd vereist. Verpakken kanin principe ook in parallel gebeuren: 2 werkers kunnen gelijktijdig producten verpakkenaan beide zijden van de tafel.

Post 8: oven

De afgewerkte kaders worden aan post 8 voorzien van krimpfolie ter bescherming tijdensde verzending. Door een technologische beperking, zal de oven slechts tweemaal daagsworden opgestart en gebruikt. In wat volgt, zal deze oven dan ook buiten beschouwingworden gelaten; er worden voor de gesimuleerde productielijn dus afgewerkte productenverondersteld ofwel na stap 6 (assembleren), ofwel na stap 7 (verpakken).

Algemeen

Er werken doorgaans 3 werkers aan deze lijn. Zij worden niet specifiek geordend volgenswerk- of wandelsnelheid; meer nog, de positie van de werkers wordt wekelijks geroteerd,om te zorgen voor afwisseling in het werk.

Idealiter wordt langs deze productielijn volgens het principe van Bucket Brigades gewerkt:geen werker is (in principe) vast verbonden met een welbepaald werkstation, en zij vol-tooien hun batch langsheen de productielijn, tot hun batch wordt overgenomen door eenachterligger.

In de praktijk echter, houdt elke werker zich aan een denkbeeldige zone. Tussen dezezones bevinden zich tussenvoorraden, naargelang het aantal beschikbare vrije karretjes(maximaal 4):

• Zone 1Aanhalen en controleren (bv. op krassen) van de correcte aluminium latten, en dezevolgens het order zagen.

• Zone 2Frezen, (desgevallend) dichtingen aanbrengen en boren


• Zone 3Assembleren of verpakken

Tussen zone 1 en 2 wordt een tussenvoorraad opgebouwd van een karretje (een batch),tussen zone 2 en 3 wordt een tussenvoorraad van 3 karretjes (3 batches) opgebouwd. Slechtsuitzonderlijk (bij een gebrek aan extra karretjes om welke reden dan ook) zal een operatorzijn ’zone’ verlaten. Typisch springt de operator uit zone 2 bij in zone 3 (helpt bij hetassembleren), waarbij de operator uit zone 1 dan de zones 1 en 2 voor zijn rekening neemt.

5.3 Tijdsmetingen

Om realistisch te kunnen gaan simuleren, is het nodig om per post over realistische (cy-clus)tijden te beschikken. Voor de gebruiksvriendelijkheid werd ervoor gekozen om eeneigen stuk software te schrijven (zie Figuur 5.2) in de programmeertaal C#, en zelf terplaatse tijden te gaan opmeten. Het programma kan zowel met muis als toetsenbord aan-gestuurd worden, en toont grafisch de layout (en supplementaire gegevens per station).De opgemeten waarden worden weggeschreven in een tekstbestand, gescheiden door ; ennieuwe regels.

Figuur 5.2: Hulpprogramma voor tijdsmetingen in C#

De resultaten van de metingen worden deels manueel, deels met behulp van een klein spe-cifiek Java-programmaatje (project Transformer, zie ook CD-ROM) verwerkt tot bruik-


bare gegevens. De gevonden waarden worden afgerond (op een seconde, tenzij andersvermeld), gegroepeerd en gesorteerd. Aldus kunnen de (kansdichtheids)gegevens gemat-ched worden aan een distributie, of een combinatie van distributies. Een combinatie vanCauchy-verdelingen was het meest voor de hand liggend.

Hierna wordt vooreerst de keuze voor Cauchy-verdelingen verduidelijkt, gevolgd door eenbespreking en grafische weergave van de resultaten per werkpost.

5.3.1 De Cauchy-verdeling

De Cauchy-verdeling wordt ook Cauchy-Lozentz-verdeling, Lorentzverdeling of Lorentziaangenoemd ([9] en [10]). De Cauchy-verdeling is een symmetrische, klokvormige verdelingnet zoals de normale (Gauss) verdeling, echter de staart is langer.

Uit de metingen bleek immers dat een groot deel van de tijden wel degelijk rond een ofmeerdere pieken te concentreren zijn, doch dat er ook tijden veel langer uitvallen dangewoonlijk door bv. nameten en eventueel herinstellen van de machine.

De volgende vergelijking wordt gebruikt voor een Cauchy-verdeling:

y = y0 + 2A

π

w

4(x− xc)2 + w2(5.1)

Hierin staat A voor de hoogte van de piek, w voor de breedte van de klok, xc voor depositie van het centrum en is y0 een offset voor de y-waarden.

Meerdere Cauchy-verdelingen kunnen eenvoudig worden gecombineerd (meerdere pieken,afvlakken aan begin en einde,. . . ) door optelling:

y = y0 + 2A1

π

w1

4(x− xc1)2 + w2

1

+ 2A2

π

w2

4(x− xc2)2 + w2

2

+ . . . (5.2)

De integraal van deze Cauchy-functie zal worden gebruikt door de simulatiesoftware voorhet bepalen van willekeurige waarden in overeenstemming met de kansdichtheidsfunctie.De verdelingsfunctie is aldus:

y = y0x+A

πarctan(

2(x− xc)

w) (5.3)

5.3.2 Post 1: Voorraad aluminium

Tijdens het tijdsmeten is er geen aandacht geschonken aan het oppikken van de aluminiumlatten, gezien het niet echt een werkstation is/lijkt. Achteraf bekeken is het oppikken vande aluminium latten echter een deeltaak van de operator in zone 1, waarbij de tijd die


hier wordt besteed een belangrijke invloed zal hebben bv. op het vullen van de eventuelebuffers.

Het oppikken en controleren van de latten aluminium zal dan ook worden meegenomen inde simulatie, en dit als (geschat) uniform verdeeld tussen 90s en 120s (per item).

5.3.3 Post 2 (2a + 2b): zagen

Van alle kaderdeuren vereist ongeveer 15% bewerking op de enkele zaag. Gezien het feitdat de kaderdeuren rechthoekig zijn, kunnen we aannemen dat voor die 15% kaders slechts2 van de 4 zijden moeten gezaagd worden op de enkele zaag. Voor een normaal kaderzijn dus 2 zaagbewerkingen nodig op de dubbele zaag (immers 2 gelijktijdig), voor eenkader met een zijde < 400mm zijn er 2 zaagbewerkingen nodig op de enkele zaag, en 1zaagbewerking op de dubbele zaag.

Post 2a: dubbele zaag

Voor de dubbele zaag (1 zaagbewerking) worden tijden gemeten tussen 5s en 109s. De-ze gegevens worden gematched aan een tweevoudige Cauchy-verdeling, zoals getoond inFiguur 5.3. De tweede verdeling komt tot uiting in het feit dat de staart links de X-asbijna snijdt, ondanks de staart rechts (de Cauchy-verdeling is immers een symmetrischeverdeling).

P(x)

0

2

4

6

8

10

12

Benodigde tijd (s)0 20 40 60 80 100 120

Figuur 5.3: Tijdsmetingen en gecombineerde Cauchy-verdeling voor post 2a

De parameters voor deze Cauchy-verdelingen zijn als volgt (Tabel 5.2):


Interval 5 → 109y0 0.8569

Cauchy1 A1 = 124.3625; w1 = 8.5950; xc1 = 11.3561Cauchy2 A2 = −24.6069; w2 = 3.9176; xc2 = 5.6073

Tabel 5.2: Parameters Cauchy-verdelingen voor post 2a

Post 2b: enkele zaag

Voor de enkele zaag (2 zaagbewerkingen per kader met zijde < 400mm) liggen de tijden inhet interval 12s tot 77s. Opnieuw is een tweevoudige Cauchy-distributie een goede keuze,zoals getoond in Figuur 5.4.

P(x)

0

2

4

6

8

10

12

14

Benodigde tijd (s)10 20 30 40 50 60 70 80

Figuur 5.4: Tijdsmetingen en gecombineerde Cauchy-verdeling voor post 2b

De parameters voor deze Cauchy-verdelingen worden weergegeven in Tabel 5.3:

Interval 12 → 77y0 0.8678

Cauchy1 A1 = 165.5329; w1 = 12.9186; xc1 = 21.1713Cauchy2 A2 = −34.8335; w2 = 5.2293; xc2 = 26.5808

Tabel 5.3: Parameters Cauchy-verdelingen voor post 2b

5.3.4 Post 3: Frees

Afgaand op de orderpapieren, worden de te frezen profielen in de frees gelegd. De freeswordt ingesteld en geactiveerd. Tijdens het effectieve frezen laat de operator de freesalleen en gaat intussen bv. dichtingen steken of boren. Nadat de frees de bewerking heeft


voltooid, blaast de operator de profielen schoon (perslucht), haalt ze uit de frees en voertdesgevallend een kwaliteitscontrole uit.

Tijdens het frezen zelf kan de operator een andere taak uitvoeren. Om die reden werden en-kel de tijden gemeten voor het klaarzetten van de frees en het verwijderen/controleren vande profielen. Deze 2 tijden werden bovendien opgeteld, en berekend per aparte kaderzijde.Dit geeft een enkele Cauchy-verdeling als volgt (Figuur 5.5 en Tabel 5.4):

P(x)

2

4

6

8

10

12

14

16

Benodigde tijd (s)10 20 30 40 50 60 70

Figuur 5.5: Tijdsmetingen en Cauchy-verdeling voor post 3

Interval 14 → 69y0 3.8259

Cauchy1 A1 = 87.9326; w1 = 15.4993; xc1 = 25.4128

Tabel 5.4: Parameters Cauchy-verdeling voor post 3

Telkens werd genoteerd hoeveel kaderzijden tegelijk werden gefreesd, en op hoeveel kader-deuren dit betrekking had. Uit deze gegevens blijkt dat er per kaderdeur gemiddeld 1.96freesbewerking nodig is.

5.3.5 Post 4: Dichtingen

Bij 20% van de kaders wordt het glas aan het kader gelijmd. De overige 80% van de kadersvereisen dichtingen, die worden bevestigd aan post 4. Bij het meten is aanvankelijk eenonderscheid gemaakt tussen grote (> 850mm) en kleine profielen, omdat de grote profieleneen extra bewerking met een dichtingenrollertje vereisen om goed te worden bevestigd. Bijhet verwerken bleek dit onderscheid nauwelijks nuttig, waardoor dit is weggelaten. Hetresultaat is een enkele Cauchy-verdeling, en wordt getoond in Figuur 5.6.


P(x)

0

2

4

6

8

10

Benodigde tijd (s)0 10 20 30 40 50


Interval 5 → 50y0 0.8077

Cauchy1 A1 = 116.3205; w1 = 13.7484; xc1 = 9.5698


5.3.6 Post 5: Boor

De gemeten tijden zijn voor het boren van 2 gaten in de uiteinden van 1 profiel (voor hetassembleren tot een kader d.m.v. montagehoeken). Per kader moeten telkens de 4 profielenworden geboord. De 2 pieken vereisen 2 Cauchy-verdelingen voor een goede overeenkomst.

P(x)

0

2

4

6

8

10

12

Benodigde tijd (s)0 10 20 30 40 50 60 70

Figuur 5.7: Tijdsmetingen en Cauchy-verdelingen voor post 5


Interval 7 → 63y0 0.1498

Cauchy1 A1 = 50.6019; w1 = 3.2214; xc1 = 10.4220Cauchy2 A2 = 60.8009; w2 = 7.1541; xc2 = 22.0220

Tabel 5.6: Parameters Cauchy-verdelingen voor post 5

5.3.7 Post 6: assemblage

Voor de assemblagepost worden de metingen afgerond op 10s. Tijdens de metingen werdeen onderscheid gemaakt tussen kleefkaders en niet-kleefkaders (= met dichtingen), dochdoor de inherent sterke afwijkingen van de tijden bleek het logischer uiteindelijk geenonderscheid aan te houden. De metingen vertonen aldus een piek rond 400s.

P(x)

2

3

4

5

6

7

8

9

Benodigde tijd (s)100 200 300 400 500 600 700 800


Interval 150 → 790y0 1.9976

Cauchy1 A1 = 655.4722; w1 = 67.2354; xc1 = 396.7393


5.3.8 Post 7: Verpakken

Slechts 7% van de kaderdeuren dient los verpakt. Daarvan wordt een 5% extra kartonver-pakt. Tijdens de drie werkdagen opmeten, konden er amper 2 tijden worden opgemeten.Dit is uiteraard te weinig voor een zeer nauwkeurige aanmeting van een distributie.


Voor de niet-kartonverpakte kaderdeuren wordt dan ook een uniforme verdeling genomentussen 360s en 540s, voor de kartonverpakte komt hier extra tijd bij voor het gaan halenvan het karton, en nemen we een uniforme verdeling van 480s tot 660s.

5.4 Abstractie voor simulatie

Wanneer we deze situatie abstraheren, komen we tot de volgende standaard lay-out van deproductielijn t.b.v. het simulatiemodel:

1 2b 2a 3 4 5 s

6a 7a

6b 7b

0m 4.5m 6m 5.8m 0.3m 3.8m 2.8m3m

3m

4.2m

4.2m

1.5m

1.5m

Figuur 5.9: Abstractie voor simulatiemodel

Deze lay-out zal de meest logische zijn, de opstelling in acht genomen. Een aantal keuzeszijn misschien niet voor de hand liggend, en worden daarom verduidelijkt:

• De namen van de stations zijn conform de lay-out in Figuur 5.1.

• Zoals vroeger reeds gesteld, kan stap 5a/b samengenomen worden tot een station 5.

• Bovenaan de verbindingspaden wordt de realistische afstand aangegeven. De distri-buties van de stations worden gekozen conform vorig punt.

• De omgekeerde driehoekjes duiden de plaatsen aan waar zich in de praktijk een bufferbevindt. In de simulaties voor de case zullen we steeds buffers gebruiken, desgevallendvan capaciteit 0, om redenen van logging.

• Door gebruik te maken van (complexe) labels kunnen de werkinhouden per item aaneen station anders worden ingevuld. Een item kan een station ook zonder bewerkingpasseren (werkinhoud 0): zo zal een te verpakken kader station 6 passeren zondermeer, maar wel werkinhoud hebben aan station 7 (en omgekeerd).De volgende groepen van labels worden gedefinieerd:

Naar grootte (2a en 2b)Klein 15%Groot 85%

Naar montage (4, 6a en 6b)Dichten 80%Kleven 20%


Assembleren of verpakken binnen-/buitenland (6a, 6b, 7a, 7b)Assembleren 93%Verpakken;Buitenland 1%Verpakken;Binnenland 6%

5.5 Simulatie standaardopstelling

Om een idee te hebben van de waarde van de simulatie en de correctheid van de tijdsmetin-gen, wordt er eerst gesimuleerd exact op de manier dat de productielijn ook is vastgesteld.Zo kunnen het handigst realistisch de verschillen worden bekeken tussen de realiteit ende simulatie. Als enige (doch belangrijke) verschil met de simulaties laterop, zal aan dedubbele zaag slechts een profiel per keer worden gezaagd.

5.5.1 Instellingen

Werktijd

Aan de lijn wordt gewerkt van 7h50 tot 10h, van 10h10 tot 12h en van 12h30 tot 16h25. Inde voormiddag wordt er dus gedurende 4h gewerkt, in de namiddag 3h55. De oven wordtnet voor de middag en ’s namiddags opgestart en bediend gedurende 30min, tijd die dusvoor onze (posten 1 t.e.m. 7) geproduceerde items onbeschikbaar is. Voor het dagelijksschoonmaken van de werkplek (15min) + varia (toiletbezoeken,. . . ) nemen we een totaleextra onbeschikbare tijd van 25min. Dagelijks wordt er dus gedurende 6h30 geproduceerdbij de posten 1 t.e.m. 7. Gezien de output niet zo heel groot is, zal er worden gesimuleerdop weekbasis, en dus gedurende 32h30.

We gaan effectief simuleren over 35h. Aangezien er buffers worden gebruikt, zullen dewaarden enkel bekeken worden vanaf 2h30 (warming-up), om eerst tot een steady-statetoestand te komen (mede gezien de operatoren in de simulatie vanaf positie 0 vertrekken).

Buffers

In de praktische situatie worden buffers gebruikt. De buffer na post 2a kan hoogstens eenbatch (een karretje) bevatten, de buffer na post 5 kan maximaal 3 batches (3 karretjes)bevatten. Bovendien wordt het passeren aan de buffers zo ingesteld, dat er een natuurlijkevoorkeur ontstaat volgens de reele indeling in zones. Zo zal werker 1 enkel passeren aanbuffers wanneer die vol zitten, en werker 3 enkel terugwandelen voorbij buffer 2 wanneerdie leeg is.

Logging

De software wordt plaatselijk aangepast, zodat extra gegevens zullen worden gelogged:


• Er wordt gelogged wanneer en welke werker aan een buffer passeert. Na verwerkingkan zo worden bekeken hoeveel tijd een werker in een bepaalde zone vertoeft.

• Elke 300s wordt de inhoud van de buffers weggeschreven. Zo kan de inhoud van debuffers in de tijd worden bekeken.

• De ingestelde werktijden worden weggeschreven per station, per item (ook als diewerktijd voor dat item nul is). Zo kunnen gemiddelde tijden per station wordenberekend.

5.5.2 Simulatie

Geproduceerde items

Tijdens de simulatietijd (na warming-up) worden er exact 75 batches van elk 5 items ge-produceerd, zijnde 375 kaderdeuren of 75 per dag. In realiteit worden er dagelijks ongeveer60 kaderdeuren geproduceerd.

De ingestelde labels worden willekeurig aan de batches gegeven. 75 batches is te weinigvoor een accurate overeenkomst met de ingestelde waarden (vooral bij de minder courantelabels).

Gemeten VerwachtGroot 90% 85%Klein 10% 15%

Dichten 71% 80%Kleven 29% 20%

Assembleren 98% 93%Verpakken binnenland 0% 6%Verpakken buitenland 2% 1%

5.5.3 Werkverdeling

Hoeveel percent van de tijd bevinden de werkers zich in welke zone? Deze waarden zijngeen activiteitsgraadmeter: een werker kan geblokkeerd staan wachten in een zone.

Zone 1 Zone 2 Zone 3Werker 1 82.04% 17.96% 0%Werker 2 0.30% 44.48% 55.22%Werker 3 0.00% 0.00% 100.00%


5.5.4 Bufferbezetting

Hierna wordt de inhoud van de twee buffers weergegeven in functie van de tijd.

Inhoud buffer 1

Inho

ud b

uffer

(bat

ches

)

0

0,2

0,4

0,6

0,8

1

Tijdsverloop (s)2e+04 4e+04 6e+04 8e+04 1e+05 1,2e+05

Figuur 5.10: Inhoud van buffer 1

Inhoud buffer 2

Inho

ud b

uffer

(bat

ches

)

1

1,5

2

2,5

3

Tijdsverloop (s)2e+04 4e+04 6e+04 8e+04 1e+05 1,2e+05

Figuur 5.11: Inhoud van buffer 2

5.5.5 Gemiddelde werkinhouden

Hieronder zijn de werkinhouden per station weergegeven. De kolom relatief is de tijd diegemiddeld voor alle items is besteed per station. In de kolom absoluut is de werkinhoudgegeven per bewerkte eenheid, of dus eigenlijk het experimenteel bekomen gemiddelde vande gedefinieerde functies hierboven.


relatief absoluutStation 1 104.52 104.52Station 2b 5.43 65.14Station 2a 136.86 35.09Station 3 76.19 38.87Station 4 53.35 19.88Station 5 76.52 19.13Station 6 448.14 459.63Station 7 14.81 577.54

Tabel 5.8: Experimenteel bekomen werkinhoud per station

Wanneer de (relatieve) tijden van de stations worden opgeteld naargelang de zone, bekomenwe een goed idee van de verdeling van het evenwicht langsheen de productielijn.

Werkinhoud (s)Zone 1 246.81Zone 2 206.06Zone 3 462.95

Tabel 5.9: Relatieve werkinhoud per zone

5.5.6 Bespreking

De gevonden resultaten van de simulatie zijn zeer realistisch, in het bijzonder m.b.t. dewerkverdelingen. Uiteraard is het simulatiemodel steeds optimistischer qua output, omwillevan verschillende redenen:

• Er zijn gemiddeld 13 rework-kaders per week. Het meeste rework wordt pas vastge-steld bij de montage, waardoor veel tijd verloren gaat, en het effectief aantal gepro-duceerde kaders daalt.

• Werkers werken niet continu. Onderbrekingen door management, ophalen van nieuweorders, aanvullen voorraden onderdelen (kleefband, spuitbussen,. . . ), aanhalen nieu-we assemblagevoorraad glas,. . . gebeuren in de praktijk, doch zijn niet opgenomen inde simulatie.

• Tijdens het opmeten waren de werkers veel meer gebonden tot hun zone. Doorproblemen met de freesmachine had de werker in zone 2 veel controlewerk en rework.De werker in zone 1 bleef niet gebonden tot de productielijn maar ging elders helpenof voorraden aanvullen. De werkers gaven wel aan dat, in normale omstandigheden,de werker uit zone 2 regelmatig doorschuift tot de assemblage, waarbij ondertussende werker uit zone 1 ook zone 2 voor zijn rekening neemt (geheel conform met desimulatie).


De werker uit zone 1 komt praktisch nooit tot assemblage, en de werker uit zone 3 komteigenlijk nooit tot latten zagen, wat wordt bevestigd door de simulatie.

5.6 Vraagstelling

Simulatie laat toe dat, zonder de productie te onderbreken, op een snelle manier wijzigingenkunnen worden uitgeprobeerd. Specifiek voor de Halux-productielijn, werden vijf vragengeformuleerd.

1. Is deze manier van werken optimaal? Is er verbetering mogelijk?

2. Wat is de beste manier of volgorde van overdracht tijdens de assemblagestap?

3. Op welke manier is rework best op te vangen?

4. Wat is de impact van het niet werken (geordend) volgens werksnelheid?

5. Hoe kan post 6b (verpakken zonder assemblage) best worden ingepast?

5.7 Bespreking

5.7.1 Is dit optimaal? Is er verbetering mogelijk?

Uitgebreide vraagstelling

Gegeven de situatie zoals bovenstaand beschreven; is deze manier van werken optimaal?Is er verbetering mogelijk, en zo ja, hoe en waar?

Simulatie 1a

De standaardsituatie zoals besproken in 5.5.2 zal niet worden gebruikt. Zoals vroeger reedsaangehaald is het de bedoeling de dubbele zaag in de toekomst te gebruiken om 2 profielengelijktijdig te zagen. Hiermee rekening houdend, herhalen we de simulatie, en nemen ditvanaf nu als referentie. We bekijken de gemiddelde lijncyclustijd, de verdeling van dewerkers over de zones alsook de werkinhoud zowel per station als per zone.

Zone 1 Zone 2 Zone 3Werker 1 59.48% 31.56% 8.96%Werker 2 0.03% 39.14% 60.83%Werker 3 0.00% 0.00% 100.00%

Tabel 5.10: Zonebezetting van de werkers


0

500

1.000

1.500

2.000

2.500

3.000

0 10 20 30 40 50 60 70 80

Figuur 5.12: Gemiddelde lijncyclustijd (standaardsituatie)

relatiefStation 1 105.11Station 2b 10.22Station 2a 67.10Station 3 75.17Station 4 66.85Station 5 78.15Station 6 415.83Station 7 145.87

Tabel 5.11: Werkinhoud per station

Werkinhoud (s)Zone 1 182.43Zone 2 220.17Zone 3 561.70

Tabel 5.12: Relatieve werkinhoud per zone

Aan de dubbele zaag is nu de helft minder werkinhoud, waardoor de totale werkinhoudvan zone 1 fors daalt. Werker 3 is nog steeds de volledige tijd te vinden in zone 3. Werker1 besteedt echter minder tijd in zone 1, waardoor die bijspringt in zone 2, en werker 2 opzijn beurt meer gaat assembleren. Werker 1 schuift zelfs bijna 9% van de tijd door tot zone3, waar hij echter meestal geblokkeerd zal staan wachten op de bezette stations 6a en 6b(door werkers 2 en 3).


De lijncyclustijd middelt uit naar een waarde van ongeveer 1451s/batch per batch. Delijncyclustijd zelf is als willekeurig te bestempelen, wat gezien de niet-deterministischewerkinhouden geheel logisch is. Er worden nu 80 batches per week geproduceerd.

Simulatie 1b

Wat uiteraard opvalt is het gebruik van buffers bij Bucket Brigades. We stellen nu debuffercapaciteit in op 0, en kijken wat de invloed is op de lijncyclustijd en de zonebezetting.

0

500

1.000

1.500

2.000

2.500

3.000

3.500

0 10 20 30 40 50 60 70

Figuur 5.13: Gemiddelde lijncyclustijd (zonder buffers)



De lijncyclustijd wordt gemiddeld ongeveer 1505s/batch, met slechts 77 geproduceerdebatches. Dat een klassieke implementatie van Bucket Brigades slechter is dan een andereimplementatie, kan enkel te wijten zijn aan blokkeringen, die optreden doordat de werkers’in elkaars weg’ gaan lopen doordat ze niet langer min of meer zijn gebonden tot een zone.

Door natuurlijke rotatie tengevolge van de parallelle stations zal ook werker 1 productenvoltooien, en werker 3 producten starten.


Simulatie 1c

Het feit dat werkers min of meer vast verbonden zijn tot een zone, blijkt optimaler. Dewerkers zijn gebonden tot die zones, door het gebruik van buffers. Door die buffers tevergroten kan dus mogelijk nog meer winst worden behaald, aangezien elke werker danvaster zal verbonden zijn met een welbepaalde zone. We simuleren met de gegevens vansimulatie 1a, maar dan met buffers die 3 maal groter zijn.

0

500

1.000

1.500

2.000

2.500

3.000

3.500

0 10 20 30 40 50 60 70 80

Figuur 5.14: Gemiddelde lijncyclustijd (met grotere buffers)



De lijncyclustijd blijft hangen rond 1495s, het aantal geproduceerde batches is 77. Ditresultaat is slechts marginaal beter dan simulatie 1b, en blijft slechter dan de uitgangssi-tuatie. Wat opvalt is dat werker 2 nu meer vertoeft in zone 2 dan in de uitgangssituatie,en mogelijk daar blokkeringen veroorzaakt.

Simulatie 1d

Gelet op simulatie 1c en Tabel 5.12, is het misschien logischer om zone 1 en 2 te groeperen,en van zone 3 te scheiden door een iets grotere buffer (capaciteit 5). Op die manier pogenwe werker 1 min of meer te binden tot die nieuwe zone (1+2), en werkers 2 en 3 tot deassemblagetafels.


0

500

1.000

1.500

2.000

2.500

3.000

0 10 20 30 40 50 60 70 80

Figuur 5.15: Gemiddelde lijncyclustijd (met andere indeling zones)



In dit geval komt het resultaat zeer dicht in de buurt van simulatie 1a. Er worden op-nieuw 80 batches geproduceerd, en de gemiddelde lijncyclustijd is iets beter: ongeveer1445s/batch. Dit lijkt de beste optie, zeker wanneer de tijden op de dubbele zaag gaanhalveren door gelijktijdig zagen.

Antwoord / besluit

Een zuivere opdeling in zones met oneindige tussenvoorraden is duidelijk geen optie, hier-voor is de lijn onvoldoende gebalanceerd. Merkwaardig genoeg zorgt de invoering vanbuffers in een Bucket Brigade systeem tot een verbetering van de lijncyclustijd: door eengrotere binding van de werkers tot een zone (doch niet onvoorwaardelijk) is er minder kansdat zij elkaar gaan blokkeren. Bovendien zal een dergelijke zonebinding een positief effecthebben op het korte-termijn leereffect, en zullen eventuele (negatieve) hand-offtijden vrijdoeltreffend worden vermeden. Bufferopbouw is de keerzijde van de medaille, maar debuffers zijn klein genoeg om nauwelijks impact te hebben.

Het is echter wel aangewezen, zeker wanneer door het aanpakken van de dubbele zaag dewerkinhoud in zone 1 zal verlagen, om ervoor te opteren om zone 1 en 2 samen te nemen,en de buffer tussen zone 1+2 en zone 3 iets te vergroten. Het feit dat de nadruk van de


werkers dan duidelijk ligt op de assemblage is ook logisch: dit is immers de reden om hetassemblagestation te gaan verdubbelen.

Onafhankelijk van de manier van werken zijn er ook op andere domeinen nog verbeteringenmogelijk, hoewel de lijn reeds voortdurend wordt verbeterd (nieuwe assemblagestations,aanduiding vaste plaatsen materiaal,. . . ):

• De afbeelding (die louter intern wordt gebruikt) waarop een werker zich baseert voorde assemblage is afgedrukt in vooraanzicht, terwijl de eigenlijke montage achteraanhet kader gebeurt. Dit leidt tot twee keer nadenken, extra verifieren en soms zelfsfouten, zeker wanneer de freesgaten niet symmetrisch zijn. Deze afbeelding uitprintenin spiegelbeeld zou veel handiger zijn, omdat de profielen kunnen gelegd worden zoalsafgebeeld (optische herkenning). Mijn inschatting is dat dit 2 geassembleerde kadersper dag meer oplevert, of dus 2 volledige batches per week.

• Er gaat teveel tijd verloren aan kwaliteitscontrole. Kwaliteitscontrole is absoluutnodig om een hoge standaard te behouden, maar sommige controles zouden overbo-dig moeten zijn door betere afstelling van de machines, en bovendien zou moetenafgesproken worden welke controles best aan welk station gebeuren. Bijvoorbeeld:

– Hoewel de lengtes, zowel op de enkele als op de dubbele zaag, digitaal wordeningesteld, is nameten strikt nodig, omdat de tolerantie anders is bij andereprofielen en/of lengtes. Dit zou niet mogen.

– De lengte van een profiel wordt vaak (nauwkeurig) nagemeten aan de zaag, bijhet frezen en bij de assemblage. Dit is overbodig.

– De correctheid van de gaten van de frees wordt soms zowel aan de assemblagegecontroleerd als aan de frees zelf. Beter zou zijn om (bij twijfel) enkel aande frees te meten, mede zodat fouten onmiddellijk ter plaatse kunnen wordengecorrigeerd/gedetecteerd.

– Verkeerde boringen in het aangeleverde glas blijken volgens de operatoren regel-matig voor te komen. Dergelijke problemen leiden tot een forse verhoging vande lead time, indien mogelijk/haalbaar zou dit moeten worden besproken metde leverancier.

• Het is te overwegen om elk assemblagestation ook uit te rusten met een dichtingenrol-lertje. Af en toe is een dichting niet helemaal goed gestoken, een (goedkoop?) plasticrollertje aan elk assemblagestation bespaart een wandeling (en mogelijk onderbrekenvan een collega) naar post 4.

5.7.2 Beste manier van overdragen aan assemblage?


Wat doet een werker die klaar is aan een parallel werkstation best: het werk overnemenaan de andere kant van de tafel (overdracht tussen paden onderling), of terugwandelen


langs de lijn (overdracht langsheen hetzelfde pad).

Simulatie 2a

In de referentiesituatie (1a) wordt er overgedragen langsheen het pad: er wordt overgeno-men onafhankelijk van het anders assemblagepad. Wanneer in die situatie wordt overgedra-gen tussen de paden onderling, wordt werker 2 mogelijk nog meer gebonden tot zijn zone2. Dit kan een verbetering opleveren, omdat hogere gebondenheid tot een zone blijkbaarleidt tot minder blokkeringen.

Deze situatie kan eenvoudig worden gesimuleerd door het tweede pad vanaf de switchnodeweg te nemen, en op de stations 6 en 7 telkens 2 gelijktijdige werkers toe te laten (zievroeger). We meten de (gemiddelde) lijncyclustijd op, alsook de zoneverdeling van dewerkers.

0

500

1.000

1.500

2.000

2.500

3.000

0 10 20 30 40 50 60 70 80 90

Figuur 5.16: Gemiddelde lijncyclustijd (overdrachten tussen paden onderling)



Antwoord / besluit

Overdracht tussen de paden onderling levert inderdaad nog een kleine winst op: er worden81 batches afgewerkt, en de gemiddelde lijncyclustijd zakt tot ongeveer 1435s/batch. Dezoneverdeling is inderdaad ook iets extremer, wat dus leidt tot minder blokkeringen.


Er dient wel opgemerkt dat, opnieuw, overdrachten tussen paden onderling praktisch moei-lijk(er) uitvoerbaar zijn. Zeker in dit geval heeft elke werker zijn (min of meer) vast as-semblagestation, en vooral een andere manier/volgorde van assembleren. Dit zou kunnenleiden tot hogere assemblagetijden na het overnemen, en kan dus netto uiteindelijk geenwinst opleveren, zeker gezien de verbetering toch eerder klein is.

5.7.3 Beste manier om rework op te vangen?


Hier en daar zal een werker een probleem vaststellen met de batch waarmee hij aan deslag is: een beschadiging (kras, deuk,...), een fout gemaakt tijdens een vorige stap, . . . .Een dergelijke fout moet dus gecorrigeerd worden, en/of dient een deel van het kaderopnieuw worden bewerkt vanaf stap 2 (verkeerd geboord, verkeerde afmeting, . . . ): er isrework nodig. Om een idee te geven, worden in Tabel 5.7.3 de meest voorkomende reworksgetoond. Er zijn gemiddeld 13 reworks per week (op ongeveer 300 kaders) nodig, watmeevalt.

Fout in aluminiumBeschadiging (kras, deuk,. . . ) 37%Extra zaagsnede nodig 9%Verstek verkeerd 9%Boring verkeerd 7%Afmeting incorrect 5%

Fout in glasBeschadiging (kras, stuk eraf, . . . ) 13%Fout in behandeling (vlekken, . . . ) 6%

Tabel 5.17: Meest voorkomende reworks

Doordat het glas extern wordt aangeleverd, zal een fout in het glas leiden tot groot opont-houd, van enkele dagen tot 3 weken (volgens het type glas). De gehele batch wordt danook opzij gelegd in afwachting, men is hier extern afhankelijk, er is geen andere optie.

Wordt er een fout vastgesteld in het aluminium, leidt dat in het beste geval tot bijwerkenvan het profiel (zoals extra zaagsnede nodig), tot het herbeginnen van het profiel (bescha-diging, verkeerd geboord, . . . ) of in het slechtste geval het kader van nul herbeginnen.De vraag is dan ook, op welke manier moet dit soort rework worden aangepakt bij dezeproductielijn?

Antwoord / besluit

Deze vraag is helaas niet of nauwelijks te simuleren, temeer daar er niet echt alternatieve(vergelijkings)scenario’s zijn. Wat kan gesimuleerd worden, is een time penalty toevoegen


op willekeurige basis aan elk station. Ik ontbreek echter het inzicht (mede door het weinigvoorkomen van dergelijk rework) om dit op een nauwkeurige, realistische manier te gaandoen. Bovendien zou dit enkel leiden tot een verlaging van het aantal geproduceerdebatches (verhoging van de lijncyclustijd), waaruit weinig is te concluderen, anders dandat rework deel uitmaakt van de productie en moet meegerekend worden om een niet-optimistische lijn-output te krijgen als simulatieresultaat.

Het voorstel is dat de profielen die rework vereisen, op een centrale plaats worden verzameld(bv. aan het begin van de productielijn, gezien rework meestal inhoudt dat het profielvanaf nul moet opnieuw gemaakt worden), samen met de details voor het rework; tot devoltooiing van het rework wordt verder gewerkt aan de andere kaders uit de batch, zonietwordt de batch opzij gehouden. De werker die een nieuwe batch start zou dan, alvorensdie te starten, eerst het nodige rework doen.

De beste tactiek om om te gaan met rework, is die zoals die nu naar best vermogen wordttoegepast: rework vermijden door tijdige en grondige kwaliteitscontrole. Zoals eerderal aangegeven, verdient het wel aanbeveling om vast te leggen wat waar precies wordtgecontroleerd, om dubbelchecks te vermijden. Hoe vroeger een fout wordt vastgesteld, hoesneller ze is op te lossen.

De werker die rework vaststelt, maakt best de inschatting of hij het rework onmiddellijkkan uitvoeren. Lukt dit redelijkerwijs niet, dan is het achterlaten van het rework-stuk opeen centrale plaats de beste alternatieve oplossing.

5.7.4 Wat is de impact van niet werken volgens werksnelheid?


In de praktijk is het niet altijd even gemakkelijk om de werkers te gaan ordenen, doordatde verschillen klein kunnen zijn en niet noodzakelijk constant in de tijd, of doordat heteenvoudigweg niet aanvaardbaar is (bv. vakbonden).

Aan deze productielijn kan er wel enig verschil in werksnelheid zijn t.g.v. het leereffect(bv. nieuwe werkers langs de lijn; hoewel de introductie van nieuwe werkers niet courant is,er is geen abnormaal werknemersverloop), maar ook dat kan klein worden verondersteld.Omdat men het werksnelheidsverschil als klein inschat, gaat men de werkers ook wekelijksroteren (zie vroeger). Toch is de ordening volgens werksnelheid voor het klassieke modelessentieel. Wat is dan deze invloed op de productielijn, en specifiek in dit geval? Waarwordt een nieuwe, onervaren werker best ingevoegd aan de lijn?

Om beurten zullen werker 1, werker 2 en werker 3 in werksnelheid worden verhoogd. Ver-volgens wordt de snelheid van achtereenvolgens werker 1, werker 2 en werker 3 gehalveerdt.o.v. de beginsituatie. Telkens zal de invloed op de lijncyclustijd worden bekeken.


Simulatie 4a

In deze simulatie verhogen we de werksnelheid van werker 1 tot de waarde 2.

0

500

1.000

1.500

2.000

2.500

3.000

3.500

0 20 40 60 80 100

Figuur 5.17: Gemiddelde lijncyclustijd (werker 1 dubbel zo snel)



Er worden 107 batches geproduceerd, met een gemiddelde lijncyclustijd van 1150s/batch.

Simulatie 4b



0

500

1.000

1.500

2.000

2.500

3.000

0 20 40 60 80 100





Simulatie 4c


0

200

400

600

800

1.000

1.200

1.400

1.600

0 20 40 60 80 100






Simulatie 4d

In deze simulatie verlagen we de werksnelheid van werker 1 tot de waarde 0.5.

0

500

1.000

1.500

2.000

2.500

3.000

0 10 20 30 40 50 60

Figuur 5.20: Gemiddelde lijncyclustijd (werker 1 half zo snel)




Simulatie 4e



0

500

1.000

1.500

2.000

2.500

3.000

3.500

0 10 20 30 40 50 60





Simulatie 4f


0

1.000

2.000

3.000

4.000

5.000

0 10 20 30 40 50 60






Antwoord / besluit

Bij het verhogen van de snelheid levert het verhogen van de snelheid van werker 2 merk-waardig genoeg het beste resultaat op. Het is des te merkwaardiger als ook blijkt dat ingeval c de werkers duidelijk sterker gebonden zijn tot hun zone.

Zone 2 kent echter 3 stations met een relatief hoge werkinhoud. Aangezien werker 2 ingeval c veel vaker in zijn zone blijft, zal hij werker 1 (die toch ook 13.13% van zijn werktijdin zone 2 vertoeft) vaker blokkeren. In geval b verblijft werker 2 op zijn beurt vaker inzone 3, doch doordat deze stap parallel wordt uitgevoerd, heeft dit geen invloed op eeneventueel blokkeren van werker 3.

Bij het verlagen van de snelheid van een werker, zoals het invoegen van een nieuwe werker,is het beste resultaat conform de klassieke voorwaarde: deze werker neemt best plaats aanhet begin van de lijn. Het resultaat is zelfs overduidelijk.

5.7.5 Hoe kan post verpakken best worden ingepast?


In de praktijk wordt de assemblage vaak gelijkgesteld met de montage. Indien een batcheen combinatie is van 2 orders, waarvan een verpakken, dan wordt dit verpakken steevastuitgevoerd na de assemblage. Dat is op deze manier ook aangegeven in de beginsituatie(post verpakken in zone 3 na de assemblage).

De verpakkingspost moet hoe dan ook worden ingepast na het boren. Er is echter geenspecifieke reden waarom de verpakkingspost na de assemblage staat, er is zelfs geen spe-cifieke reden waarom de verpakkingspost na buffer 2 (en dus in zone 3) wordt ingedeeld.We simuleren beide gevallen en kijken of dit verschil maakt.


Simulatie 5a

1 2b 2a 3 4 5 s

7a 6a

7b 6b

0m 4.5m 6m 5.8m 0.3m 3.8m 2.8m4.2m

4.2m

3m

3m

1.5m

1.5m

Figuur 5.23: Lay-out simulatiemodel, verpakking voor assemblage

0

500

1.000

1.500

2.000

2.500

3.000

3.500

0 10 20 30 40 50 60 70 80

Figuur 5.24: Gemiddelde lijncyclustijd (verpakking voor assemblage)



Zoals enigszins te verwachten maakt het verplaatsen van de verpakkingspost voor de as-semblage geen verschil. Er worden exact evenveel batches afgewerkt (80) en de gemiddeldelijncyclustijd is gelijkaardig (1440 tgo. 1451).


Simulatie 5b

1 2b 2a 3 4 5 7 s

6a

6b

0m 4.5m 6m 5.8m 0.3m 3.8m 7m 4.2m3m

3m

1.5m

1.5m

Figuur 5.25: Lay-out simulatiemodel, verpakking in zone 2

0

500

1.000

1.500

2.000

2.500

3.000

3.500

0 10 20 30 40 50 60 70 80

Figuur 5.26: Gemiddelde lijncyclustijd (verpakking in zone 2)



Er worden 77 batches afgewerkt, en de gemiddelde lijncyclustijd bedraagt 1480s/batch.

Antwoord / besluit

De huidige situatie blijkt ook hier minstens even goed te doen dan het alternatief. Deverpakkingspost indelen bij zone 2 is echter geen goed idee, de resultaten zijn duidelijkslechter.

Bijlage A

Configuratiedetails

In deze bijlage zijn de configuratiebestanden opgenomen zoals die gebruikt werden bij desimulaties uit Hoofdstuk 2.

Dit laat toe de resultaten te controleren, alsook kunnen deze configuratiebestanden alsvoorbeeld dienen. De paragraaf en titel van het onderdeel waarop deze bestanden slaanzijn bovenaan vermeld als commentaar.

102

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>2h</run_for> <model>0</model> <clock>10</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>2</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker3" initial_order="3"> <work_speed>3</work_speed> <walk_speed>0</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>60</work_content> </part> <part type="path" name="pad2"> <distance>0</distance> <begin_point>station1</begin_point> <end_point>station2</end_point> </part> <part type="station" name="station2"> <work_content>30</work_content> </part> <part type="path" name="pad3"> <distance>0</distance> <begin_point>station2</begin_point> <end_point>station3</end_point> </part> <part type="station" name="station3"> <work_content>110</work_content> </part> <part type="path" name="pad4"> <distance>0</distance> <begin_point>station3</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>100</work_content> </part> <part type="path" name="pad5"> <distance>0</distance> <begin_point>station4</begin_point> <end_point>station5</end_point> </part> <part type="station" name="station5"> <work_content>150</work_content> </part> <part type="path" name="pad6"> <distance>0</distance> <begin_point>station5</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>2h</run_for> <model>0</model> <clock>10</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>2</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker3" initial_order="3"> <work_speed>3</work_speed> <walk_speed>0</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>150</work_content> </part> <part type="path" name="pad2"> <distance>0</distance> <begin_point>station1</begin_point> <end_point>station2</end_point> </part> <part type="station" name="station2"> <work_content>110</work_content> </part> <part type="path" name="pad3"> <distance>0</distance> <begin_point>station2</begin_point> <end_point>station3</end_point> </part> <part type="station" name="station3"> <work_content>30</work_content> </part> <part type="path" name="pad4"> <distance>0</distance> <begin_point>station3</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>60</work_content> </part> <part type="path" name="pad5"> <distance>0</distance> <begin_point>station4</begin_point> <end_point>station5</end_point> </part> <part type="station" name="station5"> <work_content>100</work_content> </part> <part type="path" name="pad6"> <distance>0</distance> <begin_point>station5</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>1h</run_for> <model>0</model> <clock>10</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>2</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker3" initial_order="3"> <work_speed>3</work_speed> <walk_speed>0</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>450</work_content> <max_workers>-1</max_workers> </part> <part type="path" name="pad2"> <distance>0</distance> <begin_point>station1</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>1h</run_for> <model>0</model> <clock>10</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker4" initial_order="2"> <work_speed>1.2</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker2" initial_order="3"> <work_speed>2</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker3" initial_order="4"> <work_speed>3</work_speed> <walk_speed>0</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>450</work_content> <max_workers>-1</max_workers> </part> <part type="path" name="pad2"> <distance>0</distance> <begin_point>station1</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>1h</run_for> <model>0</model> <clock>10</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>2</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker3" initial_order="3"> <work_speed>3</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker4" initial_order="4"> <work_speed>1.2</work_speed> <walk_speed>0</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>450</work_content> <max_workers>-1</max_workers> </part> <part type="path" name="pad2"> <distance>0</distance> <begin_point>station1</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>1h</run_for> <model>1</model> <clock>10</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1" index="3"> <work_speed>2.5</work_speed> <walk_speed>1.5</walk_speed> </worker> <worker name="werker2" initial_order="2" index="4"> <work_speed>2.0</work_speed> <walk_speed>0.5</walk_speed> </worker> <worker name="werker3" initial_order="3" index="2"> <work_speed>4.0</work_speed> <walk_speed>2.0</walk_speed> </worker> <worker name="werker4" initial_order="4" index="1"> <work_speed>1.0</work_speed> <walk_speed>4.0</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="longstation" name="station1"> <work_content>250</work_content> </part> <part type="path" name="pad2"> <distance>0</distance> <begin_point>station1</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>1h</run_for> <model>1</model> <clock>10</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1" index="1"> <work_speed>2.5</work_speed> <walk_speed>1.5</walk_speed> </worker> <worker name="werker2" initial_order="2" index="2"> <work_speed>2.0</work_speed> <walk_speed>0.5</walk_speed> </worker> <worker name="werker3" initial_order="3" index="3"> <work_speed>4.0</work_speed> <walk_speed>2.0</walk_speed> </worker> <worker name="werker4" initial_order="4" index="4"> <work_speed>1.0</work_speed> <walk_speed>4.0</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="longstation" name="station1"> <work_content>250</work_content> </part> <part type="path" name="pad2"> <distance>0</distance> <begin_point>station1</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>3h</run_for> <model>0</model> <clock>10</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>2</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker3" initial_order="3"> <work_speed>3</work_speed> <walk_speed>0</walk_speed> </worker> </workers> <parts> <part type="path" name="pad0"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>40</work_content> </part> <part type="path" name="pad1"> <distance>0</distance> <begin_point>station1</begin_point> <end_point>sn1</end_point> </part> <part type="switchnode" name="sn1"> <input>pad1</input> <output>pad2[pm1]</output> <output>pad4[pm2]</output> <blocking>0</blocking> </part> <part type="path" name="pad2"> <distance>0</distance> <begin_point>sn1</begin_point> <end_point>station2</end_point> </part> <part type="path" name="pad4"> <distance>0</distance> <begin_point>sn1</begin_point> <end_point>station3</end_point> </part> <part type="station" name="station2"> <work_content>350</work_content> </part> <part type="station" name="station3"> <work_content>350</work_content> </part> <part type="path" name="pad3"> <distance>0</distance> <begin_point>station2</begin_point> <end_point>sn2</end_point> </part> <part type="path" name="pad5"> <distance>0</distance> <begin_point>station3</begin_point> <end_point>sn2</end_point> </part> <part type="switchnode" name="sn2"> <input>pad3[pm1]</input> <input>pad5[pm2]</input> <output>pad6</output> <blocking>0</blocking> </part> <part type="path" name="pad6"> <distance>0</distance> <begin_point>sn2</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>130</work_content> </part> <part type="path" name="pad6a"> <distance>0</distance> <begin_point>station4</begin_point> <end_point>station4a</end_point> </part> <part type="station" name="station4a"> <work_content>80</work_content> </part> <part type="path" name="pad7"> <distance>0</distance>

<begin_point>station4a</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>3h</run_for> <model>0</model> <clock>100</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>2</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker3" initial_order="3"> <work_speed>3</work_speed> <walk_speed>0</walk_speed> </worker> </workers> <parts> <part type="path" name="pad0"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>40</work_content> <max_workers>-1</max_workers> </part> <part type="path" name="pad1"> <distance>0</distance> <begin_point>station1</begin_point> <end_point>sn1</end_point> </part> <part type="switchnode" name="sn1"> <input>pad1</input> <output>pad2[pm1]</output> <output>pad4[pm2]</output> <blocking>0</blocking> </part> <part type="path" name="pad2"> <distance>0</distance> <begin_point>sn1</begin_point> <end_point>station2</end_point> </part> <part type="path" name="pad4"> <distance>0</distance> <begin_point>sn1</begin_point> <end_point>station3</end_point> </part> <part type="station" name="station2"> <work_content>350</work_content> <max_workers>-1</max_workers> </part> <part type="station" name="station3"> <work_content>350</work_content> <max_workers>-1</max_workers> </part> <part type="path" name="pad3"> <distance>0</distance> <begin_point>station2</begin_point> <end_point>sn2</end_point> </part> <part type="path" name="pad5"> <distance>0</distance> <begin_point>station3</begin_point> <end_point>sn2</end_point> </part> <part type="switchnode" name="sn2"> <input>pad3[pm1]</input> <input>pad5[pm2]</input> <output>pad6</output> <blocking>0</blocking> </part> <part type="path" name="pad6"> <distance>0</distance> <begin_point>sn2</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>130</work_content> <max_workers>-1</max_workers> </part> <part type="path" name="pad6a"> <distance>0</distance> <begin_point>station4</begin_point> <end_point>station4a</end_point> </part> <part type="station" name="station4a">

<work_content>80</work_content> <max_workers>-1</max_workers> </part> <part type="path" name="pad7"> <distance>0</distance> <begin_point>station4a</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>3h</run_for> <model>0</model> <clock>100</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>2</work_speed> <walk_speed>0</walk_speed> </worker> <worker name="werker3" initial_order="3"> <work_speed>3</work_speed> <walk_speed>0</walk_speed> </worker> </workers> <parts> <part type="path" name="pad0"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>40</work_content> </part> <part type="path" name="pad1"> <distance>0</distance> <begin_point>station1</begin_point> <end_point>station2</end_point> </part> <part type="station" name="station2"> <work_content>350</work_content> </part> <part type="path" name="pad2"> <distance>0</distance> <begin_point>station2</begin_point> <end_point>station3</end_point> </part> <part type="station" name="station3"> <work_content>130</work_content> </part> <part type="path" name="pad4"> <distance>0</distance> <begin_point>station3</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>80</work_content> </part> <part type="path" name="pad5"> <distance>0</distance> <begin_point>station4</begin_point> <end_point /> </part> </parts></config>

Bijlage B

Details simulaties

In deze bijlage zijn de configuratiebestanden opgenomen zoals die gebruikt werden bij desimulaties uit Hoofdstuk 4.

115

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>3h</run_for> <model>2</model> <clock>100</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>4.8</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>1.2</work_speed> <walk_speed>4.81</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>8</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>40</work_content> </part> <part type="path" name="pad2"> <distance>2</distance> <begin_point>station1</begin_point> <end_point>station2</end_point> </part> <part type="station" name="station2"> <work_content>65</work_content> </part> <part type="path" name="pad3"> <distance>3</distance> <begin_point>station2</begin_point> <end_point>station3</end_point> </part> <part type="station" name="station3"> <work_content>30</work_content> </part> <part type="path" name="pad4"> <distance>1.5</distance> <begin_point>station3</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>85</work_content> </part> <part type="path" name="pad5"> <distance>0</distance> <begin_point>station4</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>3h</run_for> <model>2</model> <clock>100</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>4.8</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>1.2</work_speed> <walk_speed>4.81</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>8</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>random(35;45)</work_content> </part> <part type="path" name="pad2"> <distance>2</distance> <begin_point>station1</begin_point> <end_point>station2</end_point> </part> <part type="station" name="station2"> <work_content>random(65;75)</work_content> </part> <part type="path" name="pad3"> <distance>3</distance> <begin_point>station2</begin_point> <end_point>station3</end_point> </part> <part type="station" name="station3"> <work_content>random(20;25)</work_content> </part> <part type="path" name="pad4"> <distance>1.5</distance> <begin_point>station3</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>random(60;65)</work_content> </part> <part type="path" name="pad5"> <distance>0</distance> <begin_point>station4</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>3h</run_for> <model>2</model> <clock>100</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>4.8</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>1.2</work_speed> <walk_speed>4.81</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>8</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>40</work_content> <hand_off_time>10</hand_off_time> </part> <part type="path" name="pad2"> <distance>2</distance> <begin_point>station1</begin_point> <end_point>station2</end_point> </part> <part type="station" name="station2"> <work_content>65</work_content> <hand_off_time>10</hand_off_time> </part> <part type="path" name="pad3"> <distance>3</distance> <begin_point>station2</begin_point> <end_point>station3</end_point> </part> <part type="station" name="station3"> <work_content>30</work_content> <hand_off_time>10</hand_off_time> </part> <part type="path" name="pad4"> <distance>1.5</distance> <begin_point>station3</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>85</work_content> <hand_off_time>10</hand_off_time> </part> <part type="path" name="pad5"> <distance>0</distance> <begin_point>station4</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>3h</run_for> <model>2</model> <clock>10</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>4.8</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>1.2</work_speed> <walk_speed>4.81</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>8</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>40</work_content> </part> <part type="path" name="pad2"> <distance>2</distance> <begin_point>station1</begin_point> <end_point>station2</end_point> </part> <part type="station" name="station2"> <work_content>65</work_content> </part> <part type="path" name="pad3"> <distance>1</distance> <begin_point>station2</begin_point> <end_point>ln</end_point> </part> <part type="labelnode" name="ln"> <input>pad3</input> <output>pad4a[p1]</output> <output>pad4b[p2]</output> </part> <part type="path" name="pad4a"> <distance>2</distance> <begin_point>ln</begin_point> <end_point>station3a</end_point> </part> <part type="station" name="station3a"> <work_content>30</work_content> </part> <part type="path" name="pad5a"> <distance>1.5</distance> <begin_point>station3a</begin_point> <end_point>station4a</end_point> </part> <part type="station" name="station4a"> <work_content>85</work_content> </part> <part type="path" name="pad6a"> <distance>0</distance> <begin_point>station4a</begin_point> <end_point /> </part> <part type="path" name="pad4b"> <distance>2.5</distance> <begin_point>ln</begin_point> <end_point>station3b</end_point> </part> <part type="station" name="station3b"> <work_content>55</work_content> </part> <part type="path" name="pad5b"> <distance>0</distance> <begin_point>station3b</begin_point> <end_point /> </part> </parts> <items> <batch_size>1</batch_size> <product_mix>p1[50]</product_mix> <product_mix>p2[50]</product_mix> </items></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>3h</run_for> <model>2</model> <clock>100</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>4.8</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>1.2</work_speed> <walk_speed>4.81</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>8</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>40</work_content> </part> <part type="path" name="pad2"> <distance>2</distance> <begin_point>station1</begin_point> <end_point>station2</end_point> </part> <part type="station" name="station2"> <work_content>65</work_content> </part> <part type="path" name="pad3"> <distance>3</distance> <begin_point>station2</begin_point> <end_point>station3</end_point> </part> <part type="station" name="station3"> <work_content>30</work_content> </part> <part type="path" name="pad4"> <distance>1.5</distance> <begin_point>station3</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>85</work_content> <error_rate>0.04</error_rate> <error_penalty>25</error_penalty> </part> <part type="path" name="pad5"> <distance>0</distance> <begin_point>station4</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>3h</run_for> <model>2</model> <clock>100</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>4.8</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>1.1</work_speed> <walk_speed>4.81</walk_speed> </worker> <worker name="werker3" initial_order="3"> <work_speed>1.2</work_speed> <walk_speed>4.82</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>40</work_content> </part> <part type="path" name="pad2"> <distance>1.5</distance> <begin_point>station1</begin_point> <end_point>station2</end_point> </part> <part type="station" name="station2"> <work_content>25</work_content> </part> <part type="path" name="pad3"> <distance>5</distance> <begin_point>station2</begin_point> <end_point>station3</end_point> </part> <part type="station" name="station3"> <work_content>180</work_content> <max_workers>2</max_workers> </part> <part type="path" name="pad4"> <distance>5</distance> <begin_point>station3</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>30</work_content> </part> <part type="path" name="pad5"> <distance>1</distance> <begin_point>station4</begin_point> <end_point>station5</end_point> </part> <part type="station" name="station5"> <work_content>55</work_content> </part> <part type="path" name="pad6"> <distance>0</distance> <begin_point>station5</begin_point> <end_point /> </part> </parts></config>

<?xml version="1.0" encoding="utf-8"?><config> <general> <num_runs>1</num_runs> <run_for>3h</run_for> <model>2</model> <clock>100</clock> <loglevel>0</loglevel> </general> <workers> <worker name="werker1" initial_order="1"> <work_speed>1</work_speed> <walk_speed>4.8</walk_speed> </worker> <worker name="werker2" initial_order="2"> <work_speed>1.1</work_speed> <walk_speed>4.81</walk_speed> </worker> <worker name="werker3" initial_order="3"> <work_speed>1.2</work_speed> <walk_speed>4.82</walk_speed> </worker> </workers> <parts> <part type="path" name="pad1"> <distance>0</distance> <begin_point /> <end_point>station1</end_point> </part> <part type="station" name="station1"> <work_content>40</work_content> </part> <part type="path" name="pad2"> <distance>1.5</distance> <begin_point>station1</begin_point> <end_point>station2</end_point> </part> <part type="station" name="station2"> <work_content>25</work_content> </part> <part type="path" name="pad31"> <distance>2</distance> <begin_point>station2</begin_point> <end_point>sn1</end_point> </part> <part type="switchnode" name="sn1"> <input>pad31</input> <output>pad3a[pm1]</output> <output>pad3b[pm2]</output> </part> <part type="path" name="pad3a"> <distance>3</distance> <begin_point>sn1</begin_point> <end_point>station3a</end_point> </part> <part type="path" name="pad3b"> <distance>3</distance> <begin_point>sn1</begin_point> <end_point>station3b</end_point> </part> <part type="station" name="station3a"> <work_content>180</work_content> </part> <part type="station" name="station3b"> <work_content>180</work_content> </part> <part type="path" name="pad4a"> <distance>3</distance> <begin_point>station3a</begin_point> <end_point>sn2</end_point> </part> <part type="path" name="pad4b"> <distance>3</distance> <begin_point>station3b</begin_point> <end_point>sn2</end_point> </part> <part type="switchnode" name="sn2"> <input>pad4a[pm1]</input> <input>pad4b[pm2]</input> <output>pad41</output> </part> <part type="path" name="pad41"> <distance>2</distance> <begin_point>sn2</begin_point> <end_point>station4</end_point> </part> <part type="station" name="station4"> <work_content>30</work_content> </part> <part type="path" name="pad5"> <distance>1</distance> <begin_point>station4</begin_point> <end_point>station5</end_point>

</part> <part type="station" name="station5"> <work_content>55</work_content> </part> <part type="path" name="pad6"> <distance>0</distance> <begin_point>station5</begin_point> <end_point /> </part> </parts></config>

Bibliografie

[1] J.J. Bartholdi, III en D.D. Eisenstein: A production line that balances itself.Operations research, 44(1), (1996), 21-34.

[2] J.J. Bartholdi, III, D.D. Eisenstein, C. Jacobs-Blecha en H.D. Ratliff:Design of Bucket Brigade production lines. (1995), 1-17.

[3] J.J. Bartholdi, III en D.D. Eisenstein: The agility of Bucket Brigade productionlines. (1996), 1-5.

[4] J.J. Bartholdi, III, D.D. Eisenstein en Y.F. Lim: Chaos and convergence inbucket brigades with finite walk-back velocities. Operations research, 00(0), (2006),1-17.

[5] J.J. Bartholdi, III, D.D. Eisenstein en R.D. Foley: Performance of BucketBrigades when work is stochastic. Operations research, 49(5), (2001), 710-719.

[6] D. Armbruster en E.S. Gel: Bucket Brigades when Worker Speeds do not Domi-nate Each Other Uniformly. (2002), 1-17.

[7] D. Armbuster, E.S. Gel en J. Murakami: Bucket Brigades with WorkerLearning. (2004), 1-11.

[8] C. Anderson, J.J. Boomsma en J.J. Bartholdi, III: Task partitioning in insectsocieties: bucket brigades. Insectes soc., 49(0), (2002), 171-180.

[9] Cauchy distribution. Wikipedia, http://en.wikipedia.org/wiki/Cauchy_distribution

[10] Cauchy-verdeling. Wikipedia, http://nl.wikipedia.org/wiki/Cauchy-verdeling

124

Studie van een gemodifieerd bucket brigade concept op...

Documents

Transcript of Studie van een gemodifieerd bucket brigade concept op...