VERTROUWELIJK TOT EN MET 31/12/2020 - NIET KOPIEREN, VERDELEN OF PUBLIEK BEKEND MAKEN

Analyse van de technische resources met behulp van Discrete event simulation

Lennert Verstraete, Yves Genetello

Promotoren: Frank De Mets, dhr. Mohsen Karbassi ( Cars Gent)

Masterproef ingediend tot het behalen van de academische graad van Master of Science in de industriële wetenschappen: elektromechanica

Vakgroep Industriële Technologie en Constructie Voorzitter: prof. Marc Vanhaelst Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2014-2015

VERTROUWELIJK TOT EN MET 31/12/2020 - NIET KOPIEREN, VERDELEN OF PUBLIEK BEKEND MAKEN

Analyse van de technische resources met behulp van Discrete event simulation

Lennert Verstraete, Yves Genetello

Promotoren: Frank De Mets, dhr. Mohsen Karbassi ( Gent)

Masterproef ingediend tot het behalen van de academische graad van Master of Science in de industriële wetenschappen: elektromechanica

Vakgroep Industriële Technologie en Constructie Voorzitter: prof. Marc Vanhaelst Faculteit Ingenieurswetenschappen en Architectuur Academiejaar 2014-2015

VERTROUWELIJK TOT EN MET 31/12/2020 - NIET KOPIEREN, VERDELEN OF PUBLIEK BEKEND MAKEN

Deze masterproef bevat vertrouwelijke informatie en/of vertrouwelijke onderzoeksresultaten die toebehoren aan de Universiteit Gent en aan Volvo Car Gent. Deze masterproef of enig onderdeel ervan mag op geen enkele wijze publiek gemaakt worden zonder de uitdrukkelijke schriftelijke voorafgaande toestemming vanwege de Universiteit Gent én Volvo Car Gent. Zo mag de masterproef onder geen voorwaarde door derden worden ingekeken of aan derden worden meegedeeld. Het nemen van kopieën of het op eender welke wijze dupliceren van de masterproef is verboden. Het niet respecteren van de vertrouwelijke aard van de masterproef kan onherstelbare schade veroorzaken aan de Universiteit Gent en aan Volvo Car Gent.

Voorwoord Als sluitstuk op ons masterjaar in de industriële wetenschappen met als afstudeerrichting Elektromechanica aan de universiteit te Gent besloten we een thesis in het bedrijf Volvo Car Gent te aanvaarden. Om dit tot een goed einde te brengen kregen we de hulp van verschillende mensen waarvoor we nu even de tijd nemen om die personen in kwestie te bedanken.

Ten eerste willen we Karbassi Mohsen bedanken voor zijn excellente begeleiding gedurende de gehele masterproef. Ten tweede bedanken we onze promotor De Mets Frank voor zijn opvolging van het project en het controleren van deze scriptie.

Vervolgens bedanken we verschillende mensen aan Volvo Car Gent zelf die ons wegwijs maakten in de fabriek en ons van verschillende data voorzien hebben. Ten eerste Puype Peter voor zijn uitgebreide rondleiding door de lasfabriek. Ten tweede Schwab Jonathan voor zijn prachtig werk met Excel, wat het analyseren van de data een stuk makkelijker maakte. Ten laatste Sagaama Hedi die ons hielp een stap voorwaarts te nemen in het analyseren van de arbeiders in de fabriek.

Verder bedanken we ook nog onze ouders. Dankzij hen werd het voor ons mogelijk gemaakt om deze richting te volgen en tot een succesvol einde te brengen.

Tot slot bedanken we onze vrienden en familie voor morele steun.

Wij hopen met deze thesis een merkbare bijdrage te leven aan Volvo Car Gent.

Samenvatting Volvo Car Gent heeft nood aan een analysetool die controleert of de fabriek over voldoende techniekers beschikt. Men wil hier verschillende zaken mee kunnen controleren, zoals werkbelasting van de techniekers alsook welke fouten zich het vaakst voordoen en dergelijke. Deze thesis controleert de haalbaarheid om deze analysetool te ontwikkelen.

Deze tool wordt ontwikkeld met behulp van Tecnomatix Plant Simulation van Siemens. Dit is een Discrete event simulation software en laat toe het bedrijf virtueel na te maken. Gedurende een bepaalde tijd werden metingen uitgevoerd op de verschillende werkstations in Volvo om de data zo nauwkeurig mogelijk te kunnen integreren in de tool. Ook van de verschillende techniekers werd de nodige data bijgehouden en voorzien voor deze thesis. Uiteindelijk kan men dan op het model testen en experimenten uitvoeren in plaats van in de fabriek. Dit spaart zowel tijd als geld uit.

Uit deze thesis blijkt dat zo een model haalbaar is indien er voldoende data beschikbaar is van alle stations aangezien voor deze thesis maar data voorzien werd voor ongeveer de helft van de stations.

------

Volvo Cars Gent needs an analysis tool that checks if the factory has enough maintenance technicians employed. They want to analyze certain values using this model. These values include the workload of the technicians and which failures are most common. This thesis verifies the feasibility of developing such an analysis tool.

This tool is developed using Tecnomatix Plant Simulation made by Siemens. This is a Discrete event simulation software and allows the user to make a virtual copy of the factory. During a certain time measurements were carried out onto the various workstations in Volvo to be able to integrate the data as accurately as possible into the tool. The necessary data for implementing the different technicians was also included. Ultimately, one can then use the model for tests or perform experiments instead of doing these in the factory. This saves both time and money.

An analysis tool like this seems to be feasible to develop if there is sufficient data available. As for this thesis there was only data available for about fifty percent of the factory’s stations.

Inhoudsopgave Voorwoord ...... 5 Samenvatting ...... 6 Inhoudsopgave ...... 7 Lijst met gebruikte afkortingen ...... 9 Inleiding ...... 10 1 Introductie Volvo Car ...... 11 1.1 Geschiedenis ...... 11 1.2 Volvo Car Gent ...... 13 1.2.1 Algemeen ...... 13 1.2.2 Lasfabriek ...... 13 1.2.3 Spuitfabriek ...... 13 1.2.4 Eindassemblage ...... 14 1.2.5 Logistiek ...... 14 1.2.6 Facts sheet ...... 14 2 Omschrijving opdracht ...... 16 2.1 Doelstelling ...... 16 2.2 Opdracht schematisch voorgesteld ...... 17 2.3 Locatie: UB9 ...... 18 2.4 Het basismodel ...... 19 3 Literatuur ...... 20 4 Tecnomatix Plant Simulation ...... 21 4.1 Algemeen ...... 21 4.1.1 Interface ...... 21 4.1.2 Toolbox & class library ...... 22 4.1.3 Console: ...... 22 4.2 Functieblokken ...... 23 4.3 Workers...... 24 4.4 Method ...... 27 4.4.1 Method soorten ...... 27 5 Ontwikkeling ...... 28 5.1 Excel-files ...... 28 5.1.1 De competentiematrix ...... 28 5.1.2 De robotdata ...... 29 5.1.3 Procestijden ...... 31 5.2 Het model ...... 31 5.2.1 Updaten van proctimes, availability en failures ...... 31 5.2.2 Workers en bijbehorende competentiematrix implementeren ...... 34 5.2.3 Creëren van de link tussen de competenties en het type van de robotfout ...... 35 5.2.4 Implementeren van de gangpadstructuur ...... 37 5.2.5 MWT (Mean Walking Time) ...... 38 5.2.6 Efficiëntie...... 39 5.2.7 Extra features ...... 39 6 Gebruiksaanwijzing ...... 40 6.1 Instellingen ...... 40 6.2 Event controller ...... 41 6.3 Experiment Manager ...... 42 7 Analyse ...... 44 7.1 Charts ...... 44 7.1.1 Chart_output ...... 44 7.1.2 Workerchart ...... 45 7.1.3 WorkerChartFromTBL ...... 47 7.1.4 WorkerChartTotFromTBL ...... 48 7.2 Goodness of Fit testen ...... 48 7.2.1 MWT (Mean Walking Time) ...... 48 7.2.2 Minitab 17 ...... 49 7.3 Simulatie Testen ...... 50 7.3.1 Test 1: Aantal workers...... 51 7.3.2 Test 2: Invloed van de competenties ...... 57 7.3.3 Test 3: Invloed van de wandelsnelheid ...... 62 7.3.4 Test 4: Invloed van de efficiency ...... 66 7.4 Problemen en eventuele oplossingen ...... 70 8 Algemeen besluit ...... 71 Lijst met figuren ...... 72 Lijst met tabellen ...... 73 Lijst met referenties ...... 74 Bijlagen ...... 75 Bijlage 1: overzicht flow UB9 ...... 76 Bijlage 2: De Method codes ...... 79 Bijgevoegde digitale bestanden ...... 99

Lijst met gebruikte afkortingen C Cabriolet

S Sedan

V Versatility

XC Cross Country

GA Gent Lasfabriek

GB Gent Spuitfabriek

GC Gent Assemblagefabriek

JPH Jobs per hour

UB9 UnderBody Sectie Gent

MTTR Mean Time To Repair

MDT Mean Down Time

DES Discrete event simulation

VT Volvo Technieker

VCG Volvo Car Gent

SingleProc Single Proces

Ctrl Control

MWT Mean Walking Time

9 Inleiding Volvo Car Gent beschikt momenteel niet over een tool om te controleren of het bedrijf over genoeg onderhoudstechniekers beschikt. Men weet dus met andere woorden niet als er teveel of te weinig techniekers zijn. Indien men over te weinig techniekers beschikt kan met twee wegen uitgaan: ofwel meer techniekers aannemen ofwel techniekers zodanig bijscholen dat ze meer problemen kunnen aanpakken of de reparaties efficiënter kunnen uitvoeren.

Voor de ontwikkeling van deze tool wordt gebruikt gemaakt van een simulatiesoftware genaamd Tecnomatix Plant Simulation. Deze software werd ontwikkeld door Siemens. Volvo Car Gent gebruikt deze software nog niet lang en het bedrijf heeft nog geen simulaties met werknemers gemaakt. Het doel van deze thesis bestaat eruit om te controleren of dergelijke tool kan ontwikkeld worden en naar behoren zou werken.

De voornaamste bron van informatie voor dit eindwerk is het boek Manufacturing Simulation with Plant Simulation and Simtalk geschreven door Steffen Bangsow. Dit boek toont aan hoe Tecnomatix Plant Simulation in zijn werk gaat aan de hand van simpele voorbeelden.

Het basisidee van dit werk bestaat eruit om Excel files met data te laden in de tool om er dan een output uit te krijgen die toont hoeveel auto’s er per uur worden aangemaakt. Deze Excel files bestaan uit data van de verschillende stations met bijhorende robots die in Volvo te zien zijn maar ook de nodige informatie van de verschillende techniekers. Van elke technieker dient immers geweten te zijn welk soort problemen zij kunnen oplossen.

Met behulp van heel wat programmeerwerk worden deze Excel files automatisch ingeladen en verwerkt in de tool zodanig dat de gebruiker enkel maar een Excel file hoeft up te daten of aan te passen en zo goed als geen kennis over het programma moet hebben. De output bestaat uit verschillende grafieken en waarden die gaan van werkbelasting per technieker tot het aantal auto’s per uur dat maximaal kan geproduceerd worden met de ingestelde parameters in de Excel files.

In deze thesis wordt eerst over de nodige basis gegaan die nodig is om de volgende stappen te snappen. Daarna worden vooral de methodes uitgelegd die toegepast werden om de verschillende problemen op te lossen. Tot slot worden er enkele testen uitgevoerd om te controleren of het programma naar behoren werkt en realistische waarden gegenereerd worden.

10 1 Introductie Volvo Car

1.1 Geschiedenis Volvo kent zijn oorsprong in 1915, maar niet vanwege de auto’s zoals men ze vandaag kent. SKF gekend van de kogellagers, stuurde een zeker Björn Prytz naar de Verenigde Staten van Amerika om te controleren of een goedkope kogellager genaamd Volvo een plaats in de markt zou krijgen. Aangezien dit zo was, liet SKF Volvo als merknaam registreren. Volvo is latijns voor “ik rol” en is afkomstig van het werkwoord volere.

NKA probeerde in 1914 te concurreren met SKF door de volvolagers te produceren maar SKF wist zijn prijzen te verlagen waardoor NKA niet kon concurreren. Uiteindelijk werd NKA overgenomen door SKF. In 1919 werd Volvo op de plank gelegd en ging het verder als een papierbedrijf namelijk AB Volvo.

Assar Gabrielsson was destijds werkzaam in SKF. Samen met het kapitaal van SKF, de papierfabrikant AB Volvo en een leegstaande fabriek te Hisingen startten hij en Gustaf Larson een autofabriek. De eerste Volvo-personenwagen werd getoond in 1927. Dit model heet ÖV4 en is te zien op figuur 1.

Figuur 1: De eerste Volvo-personenwagen

Datzelfde jaar begon Volvo auto’s te maken in Gotenburg in Zweden aan de lopende band. Door de jaren heen is het bedrijf uitgegroeid tot een van de bekendste en meest gerespecteerde automerken in de wereld en worden de wagens verkocht in meer dan 100 landen. Dit dankzij auto’s aan de lopende band uitgerust hoogtechnologische innovaties te fabriceren. Deze auto’s worden altijd gefabriceerd met het oog op veiligheid.

Auto’s worden bestuurd door mensen. Daarom is en moet veiligheid altijd het basisprincipe zijn en blijven bij alles wat we doen.”

(Gabrielsson & Larson, 2014; Gabrielsson & Larson, 2014)

Tijdens het Assar Gabrielsson en Gustaf Larson tijdperk groeide Volvo langzaam, zowel op het gebied van personenauto's als vrachtwagens. Volvo nam na de Tweede Wereldoorlog een grote stap op de personenautomarkt met de PV444.

In 1956 kwam Gunnar Engellau aan het roer. Dankzij deze man zette Volvo een sterke voet op de Amerikaanse markt. Volvo expandeerde krachtig met behulp van geheel nieuwe fabrieken in Göteborg en Gent.

11 Volvo cars maakte deel uit van de Zweedse Volvo Groep genaamd AB Volvo tot 1999. In 1999 nam Ford Motor Company de autotak over. Van 2010 tot vandaag is de eigenaar van Volvo Car Group een chinees genaamd Zhejiang Holding.

De hoofdzetel van Volvo cars bevindt zich in Götenburg, Zweden. De auto’s worden hier ontwikkeld en ook gefabriceerd. De fabriek in Gent is een kopie van die uit Zweden. Aangezien veiligheid een belangrijk aspect is voor Volvo hebben ze in Zweden ook een zogenaamd Safety Centre. Hier worden allerlei testen uitgevoerd om te controleren of de auto’s en trucks wel veilig zijn. Het safety centre is te zien in figuur 2.

Figuur 2: Safety Center

Een van de bekendste ontdekkingen die Volvo heeft ontwikkeld dankzij de testen in dit Safety Centre is de driepuntsgordel. Dit is tot vandaag de dag één van de belangrijkste innovaties ooit. Natuurlijk zijn er nog allerhande innovaties gevonden dankzij dit Safety Centre.

12 1.2 Volvo Car Gent

1.2.1 Algemeen Volvo Car Gent is één van de hoofdfabrieken en is gelegen aan in de Gentse haven. De fabriek is opgedeeld in een lasfabriek (GA), een spuitfabriek (GB) en de eindassemblage (GC) en werd opgericht in 1965. Er werd voor Gent gekozen omdat deze stad een centrale ligging had in de Europese Economische Gemeenschap en een goede infrastructuur heeft. Het was echter niet de eerste Volvofabriek buiten zweden, er was al een fabriek gebouwd in Canada op dat moment. Volvo Car Gent is vanaf dit moment één van de hoofdfabrieken van Volvo Cars.

De eerste wagen die in Gent van de band rolde was de . Een foto van deze wagen is te zien in figuur 3.

Figuur 3: Volvo Amazon

1.2.2 Lasfabriek De productie start in de lasfabriek, waar de carrosserieonderdelen aan elkaar gelast worden tot een koetswerk. Het gebruik van verschillende staalsoorten, waaronder het extra-harde boronstaal, zorgt voor een stevige structuur. Deze wagens zijn altijd zodanig ontworpen om de beste veiligheid en de meest dynamische rijeigenschappen te bieden.

1.2.3 Spuitfabriek In de spuitfabriek zorgen de eerste lagen, aangebracht door het koetswerk onder te dompelen in een reeks grote baden, voor een optimale bescherming tegen roest en voor een goede hechting van de kleurlaag. Een vernislaag (clearcoat) verzegelt de kleur en beschermt het koetswerk. Milieuzorg staat ook in dit deel van het proces centraal. De gebruikte verfsoorten bevatten namelijk water als oplosmiddel in plaats van solventen. Zowel de lasfabriek als de spuitfabriek zijn voor meer dan 80 procent geautomatiseerd.

13 1.2.4 Eindassemblage In de eindassemblage wordt het koetswerk verder afgewerkt tot een auto die de klanten rijplezier, comfort en veiligheid biedt, met krachtige en zuinige motoren. 70 procent van de onderdelen wordt door verschillende leveranciers aangeleverd volgens het just-in-sequence-principe. In exact dezelfde volgorde als waarin de stukken nodig zijn op de assemblagelijn. Kwaliteit is hier de eerste zorg. Alle medewerkers zijn goed opgeleid en de montagevoorschriften zijn duidelijk. Als een operator ondersteuning nodig heeft, maakt hij dat kenbaar door aan het andonkoord te trekken. Het andonkoord is een koord doorheen de fabriek dat bevestigd is aan een trekschakelaar. Dat is een signaal voor alle ondersteuners om eventuele problemen meteen aan te pakken. De operatoren werken in teams van 6 tot 12 leden en roteren gelijkmatig. Een continue aandacht voor ergonomie en veiligheid zorgt voor goede werkomstandigheden.

1.2.5 Logistiek Logistiek is de levensader van de fabriek die dwars door alle processen loopt. Vanaf het aanmaken van het productieplan, het bestellen van het materiaal, het opvolgen en de ontvangst van de goederen, het bevoorraden van de onderdelen aan de operatoren tot het uitleveren van de afgewerkte wagens is de logistiek afdeling betrokken. Een efficiënte doorstroming en een perfecte sequentie van de te bouwen wagens zijn de hoofddoelstellingen van de logistieke afdeling. Rechtstreeks of onrechtstreeks verwerkte de afdeling logistiek dagelijks meer dan acht miljoen onderdelen.

1.2.6 Facts sheet Vandaag worden er 4 verschillende modellen gemaakt in Volvo Car Gent namelijk de , Volvo V40 Cross Country, Volvo XC60 en . Deze wagens zijn te zien in figuur 4:

Figuur 4: Volvo's in productie in Gent

Deze naamgevingen zijn geen random letters. Elke letter of lettercombinatie staat voor een bepaald type. Er zijn 4 types: Cabriolets (C), Sedan (S), Versatility (V) en Cross Country (XC). Men bestelt de onderdelen niet op voorhand maar men maakt auto’s op bestelling. Dankzij dit systeem is elke auto die van de band rolt reeds verkocht.

14 Tabel 1: geproduceerde volvo's in productie

In tabel 1 is te zien hoeveel auto’s er de voorbije jaren geproduceerd werden in Volvo Car Gent. Men kan besluiten dat er meer auto’s worden gemaakt elk jaar, met uitzondering van het jaar 2011 wat blijkbaar een bijzonder goed jaar was.

Volvo verkoopt auto’s over de hele wereld. Zoals te zien is op figuur 5, worden er vooral auto’s verkocht in Europa en dankzij de nieuwe eigenaar nu ook een aanzienlijk deel in China. De omzet van Volvo Car Gent is 5.1 Miljard euro.

Figuur 5: Taartdiagram verkoopcijfers

15 2 Omschrijving opdracht

2.1 Doelstelling Het doel van deze thesis bestaat eruit een tool te creëren die analyseert of het bedrijf over genoeg onderhoudstechniekers beschikt en tegelijk de werkbelasting van elke technieker controleert. Indien dan in een bepaald deel van de fabriek te weinig arbeiders aanwezig zijn dan kan men twee wegen uitgaan: ofwel meer arbeiders aannemen ofwel de arbeiders bijscholen zodanig dat ze over meer competenties beschikken. Indien ze teveel belast worden moeten er meer arbeiders aangenomen worden.

Het is de bedoeling dat er voor deze thesis een klein deel van de lasfabriek geanalyseerd wordt. Het deel dat onderzocht moet worden, noemt UB9. Dit is een afkorting voor UnderBody, het cijfer 9 is gewoon een nummer. In Zweden hebben ze bijvoorbeeld UB7 want het bedrijf is een kopie van dat uit Zweden. De focus wordt gelegd op de P3-flow, deze flow produceert de Volvo S60 en XC60.

Het programma dat gebruikt wordt voor deze thesis is Tecnomatix Plant Simulation van Siemens. Dit is een simulatiesoftware en het wordt dus ook gebruikt om processen in bedrijven te modeleren, simuleren en te analyseren. Deze analyses kunnen leiden tot betere resultaten en een betere omzet. In principe is het de bedoeling om de output van het proces te verbeteren. In dit geval is deze de output jobs per hour (jph). Door het aantal arbeiders te laten variëren kan er gecontroleerd worden of het nodig is om effectief meer arbeiders aan te nemen.

16 2.2 Opdracht schematisch voorgesteld

Figuur 6: structuur simulatie model

In figuur 6 zijn de Bodyshop Competence Matrix en de Actual Disturbance Data eigenlijk Excel files die als input zullen dienen voor het simulatiemodel dat gemaakt wordt met behulp van het programma Tecnomatix. De eerste Excel file is een samenvatting van de competenties van de arbeiders en de tweede file zijn logs van de robots wanneer er fouten optreden. Het is de bedoeling dat deze files kunnen aangepast worden zonder dat er aanpassingen in het simulatie programma nodig zijn. Het simulatiemodel geeft dan als output als er meer arbeiders nodig zijn of als ze moeten bijgeschoold worden. Verder geeft het ook het aantal jobs per hour weer.

17 2.3 Locatie: UB9 Deze opdracht wordt uitgevoerd in de lasfabriek deel UB9, maar zal uiteraard ook toepasbaar zijn voor andere secties mits enkele aanpassingen. De figuren voor de UB9 flow zijn terug te vinden in bijlage 1. UB9 bestaat uit GA1.1 en GA2.

Figuur 7: Onderdeel proces flow UB9

Figuur 7 geeft een klein deel weer van UB9, het deel dat te zien is fabriceert het rear-floor panel. Dit geeft een overzicht door welke stations de onderdelen worden geleid. Een begin van deze flow bepalen is vrij onmogelijk aangezien er op heel veel verschillende plaatsen stukken worden aangevoerd. Op het overzicht zijn er twee belangrijke figuren te zien, enerzijds de driehoeken en anderzijds rechthoeken. De driehoeken zijn buffers, hierin kunnen de stukken tijdelijk worden opgeslagen. Een buffer is op sommige plaatsen nodig door de verschillende procestijden van de verschillende stations. De ene buffer zal al wat groter zijn dan de andere. Hoe groot deze buffers moeten zijn, wordt ook geanalyseerd met Tecnomatix al behoort dit niet tot dit onderzoek. De rechthoeken zijn de stations. In elk station gebeurt een bepaald proces. Voorbeelden van deze processen zijn puntlassen, lijmen, bouten indraaien, stukken toevoegen, …

Zoals te zien is op het overzicht worden de stations samengenomen in bepaalde secties, op het overzicht duidelijk gemaakt door een streeplijn rond de sectie. Deze zijn zodanig opgedeeld dat er in elke sectie een bepaald deel wordt afgewerkt. De benamingen van die delen zijn ook te lezen in de figuur. Verder heeft dit als functie een meer overzichtelijke fabriek te creëren en een systematische naamgeving van de stations te verwezenlijken. Zo kan men verwijzen naar station S17_030, dit is station 030 in sectie S17.

Tot slot zijn er twee flows op één lijn namelijk: Y283 in het blauw en Y413 in het groen. Dit zijn 2 verschillende wagens die gemaakt worden op dezelfde lijn. De rode lijnen zijn mixed flow, dit wil zeggen dat de stations zich aanpassen naargelang de wagen die passeert. De zwarte lijnen zijn common flow, dit zijn stukken die voor beide wagens gebruikt worden.

18 2.4 Het basismodel In figuur 8 is het bestaand model te zien. Dit model is gemaakt door een student genaamd Van Ransbeeck Niels en werd ter beschikking gesteld voor de ontwikkeling van deze tool. Zoals men kan zien is hier dezelfde structuur gebruikt als in de fabriek zelf. Vertrekkend van dit model wordt de tool ontwikkeld.

Figuur 8: Hoofd grondplan met ruwe proces flow UB9

19 3 Literatuur Zoals al eerder aangehaald is Tecnomatix het programma waarmee de tool zal ontwikkeld worden. Deze simulatiesoftware laat toe een proces te visualiseren en te simuleren zodanig dat men er analyses op kan uitvoeren. De bedoeling is de productiviteit van het proces te verhogen.

Om met deze software te leren werken en te verstaan is er een goede samenvatting geschreven door Steffen Bangsow. Aan de hand van eenvoudige voorbeelden worden de principes van Tecnomatix beschreven. Een voorbeeld van de kaft is te zien in figuur 9.

Figuur 9: cover handboek: Manufacturing Simulation with Plant Simulation and simtalk

Dit boek is een goede inleiding voor het programma maar om effectief complexere zaken te gaan programmeren is de help-functie in het programma een aanrader. Op elk moment kan je in het programma de toets F1 indrukken om de help functie op te roepen. Hierin kan men zoeken door middel van wat kernwoorden in te vullen en dan eventueel wat door te klikken door de verschillende pagina’s informatie. Op die manier komt men meestal vrij snel tot wat men zoekt.

20 4 Tecnomatix Plant Simulation

4.1 Algemeen Tecnomatix Plant Simulation is een Discrete-event simulation (DES) tool. Deze software maakt het makkelijk om een digitaal model te creëren van een systeem, in dit geval een productie. Op die manier kunnen we achterhalen hoe het systeem werkt en waar we verbeteringen kunnen aanbrengen. Dit digitaal model laat ons toe om experimenten uit te voeren zonder daarbij het reële systeem onder te laten lijden. Men kan verschillende zaken optimaliseren met als voorbeelden: material flow, resources en logistiek. Maar hier zal er geprobeerd worden om vooral de resources te analyseren. Dit zijn in dit geval de VT’s (Volvo Techniekers) in VCG (Volvo Car Gent).

4.1.1 Interface

Figuur 10: overzicht werkblad in Tecnomatix

In figuur 10 zien we de interface van het programma Tecnomatix. Omkaderd in het rood bevindt zich de class library. In het geel is de toolbox aangeduid, het blauw is de werkomgeving en het groen de console. In de werkomgeving kunnen verschillende zaken tevoorschijn gehaald worden. Ten eerste de verschillende frames, dit zijn in feite werkbladen waarop allerlei functieblokken kunnen toegevoegd worden. Ten tweede is het ook mogelijk om hier methods aan te passen. Methods zijn functieblokken waarin geprogrammeerd kan worden. Tot slot kunnen hier ook de verschillende opties of statistieken van elk station in getoond worden.

21 4.1.2 Toolbox & class library

Figuur 11: Toolbox

In figuur 11 zien we een voorbeeld van de toolbox met het tabblad material flow geopend. De toolbox is eigenlijk een verzameling van verschillende functieblokken die men kan invoegen in het programma. De blokken die worden gebruikt worden uitgelegd in het deel Functieblokken.

Belangrijk om te weten is dat er tussen de toolbox en de class library een link bestaat. Hiernaast zien we figuur 12 van de class library met de map ‘material flow’ geopend. Zoals er te zien is, zijn de meeste mappen gelijkaardig aan de tabbladen in de toolbox. De class library maakt het immers mogelijk om de standaard voor elke functieblok in te stellen. Dit wordt verduidelijkt met een voorbeeld.

Standaard is de proces time voor een SingleProc functieblok ingesteld op één minuut. Stel dat het gewenst is dat elke SingleProc functieblok niet één minuut proces time heeft maar twee minuten. Dan wordt dit aangepast in de class library door via de class library de SingleProc blok te openen. Hieruit volgt dat, wanneer die functieblok uit de toolbox wordt gebruikt, deze blok vanaf nu altijd twee minuten proces time zal hebben. De blokken worden meestal mbv de toolbox geselecteerd aangezien dit gebruiksvriendelijker is.

In de class library is het ook mogelijk zelf mappen te creëren. Dit heeft zo zijn voordelen. In dit project werd alles gemaakt onder de map Volvo_Car. De standaardblokken worden naar die map gekopieerd, dit is aan te raden voor nieuwe gebruikers van het programma zodanig dat men altijd kan terugkeren naar de standaard indien er iets fout gaat. Verder is het werken in verschillende mappen handig in bepaalde toepassingen zoals er later zal worden aangetoond.

4.1.3 Console: De console zorgt voor informatie terwijl het programma loopt, zoals errors. Men kan er ook voor kiezen om bepaalde zaken naar de console te printen. In dit model zullen de namen van de verschillende failures in de console verschijnen.

Figuur 12: Class library

22 4.2 Functieblokken

In Tecnomatix zijn er verschillende functieblokken, waarvan de belangrijkste voor dit model in tabel 4 zullen worden opgesomd.

Tabel 2: Functieblokken proces

/ Entities Source Drain Singleproc assemlby DismantleStation buffer

In UB9 worden er overal onderdelen aangevoerd om een verdere bewerking te kunnen ondergaan. In de simulatie krijgen deze onderdelen de naam ”entities” en worden gegenereerd door een source. Voor deze input bestaat er ook een output, namelijk de drain. De drain in het model geeft een idee hoeveel underbodies per uur worden gemaakt aangezien de statistieken van die blok kunnen bekeken worden. De statistieken kan men uiteraard ook bij elke andere functieblok weergeven.

Figuur 13: basis opstelling

In figuur 13 is een basis opstelling te zien van de te bespreken blokken, dit kan eventueel al wat verduidelijking scheppen over de werking van de blokken.

Voor de verschillende stations zijn er verschillende proces blokken beschikbaar. De eerste en meest eenvoudige blok is een SingleProc. Dit is een afkorting voor single proces en is eigenlijk een proces waar stukken bewerkt worden maar geen stukken worden toegevoegd. Bijvoorbeeld een station waar er enkel extra lassen worden voorzien.

Een tweede belangrijke blok is een assembly proces, in het programma simpelweg assembly genoemd. Dit zal twee stukken samenvoegen m.a.w. dit maakt van twee entities een nieuwe entity. Ook het omgekeerde bestaat en dit noemt men DismantleStation.

Voor elk station kan men verschillende parameters instellen. De belangrijkste voor deze simulatie zijn de proces time en de failures met hun bijhorende MTTR (Mean Time To Repair) en availabilities. Waar men deze instelt is te zien in figuur 14.

23

Figuur 14: station parameters

Buffers spelen een grote rol in Volvo. Deze buffers worden zowel voorzien voor het opvangen van de verschillende procestijden van de verschillende stations, alsook voor de zogenaamde failures die de robots zullen ondervinden. Indien er een robot stilvalt mag en kan dit niet betekenen dat de gehele fabriek erop moet wachten. Vandaar zullen de andere machines de buffers dan vullen zodanig dat men zo snel mogelijk kan verder werken als de robot weer operationeel is. Het is natuurlijk niet de bedoeling dat de buffers vol raken maar hier wordt dieper op ingegaan in een andere thesis.

4.3 Workers Tabel 3: Functieblokken Workers

Worker Worker Workerpool Broker Workplace footpath actief inactief

Wat nog niet in het bestaande model zit maar wel van enorm belang zal zijn voor de ontwikkeling van de tool zijn natuurlijk de arbeiders. We zullen hier dan ook wat dieper op ingaan. De arbeiders of workers zoals het programma ze noemt hebben verschillende functieblokken nodig om naar wens te werken. Deze zijn te zien in tabel 5.

Alle workers verzamelen in een zogenaamde workerpool, in het bedrijf is dit de lounge waar de arbeiders wachten tot ze opgeroepen worden. De workerpool wordt gebruikt om de workers in te stellen. Een eenvoudig voorbeeld van een instelling is bijvoorbeeld de wandelsnelheid. Deze instellingen gebeuren via de creation table. Deze tabel geeft een overzicht van alle workers in het programma. Zoals te zien is in figuur 15 zijn er nog twee zaken die geconfigureerd zijn. Namelijk een broker en een shift calendar. Hier wordt nu verder op ingegaan.

24

Figuur 15: configuratie workerpool

Wanneer een station in fout gaat, dienen de workers opgeroepen te worden. De oproepen worden op hun beurt gegeven door de functieblok genaamd broker. Voor elk station moet een broker ingesteld worden. Dit kan ook gewoon telkens dezelfde broker zijn. Als een station dan in fout gaat zal de broker er een worker op afsturen die het kan oplossen. Dit gebeurt door te controleren of de worker over de juiste competenties beschikt om de fout van het station op te lossen. Deze controle gebeurt eerst in het station. De broker gaat daar kijken naar de zogenaamde service table die geopend wordt zoals in figuur 16 te zien is. In deze tabel is het mogelijk verschillende competenties toe te kennen aan het station. Als voorbeeld stellen we dat station 1 gelast moet worden om terug operationeel te zij. In de service table kunnen we dan lassen invullen. Merk ook op dat hier ook de broker ingesteld dient te worden.

25

Figuur 16: Singleproc met service table

Vervolgens moet in de creation table een worker aanwezig zijn die over dezelfde competentie beschikt. De creation table kan men tevoorschijn halen zoals te zien is op figuur 17.

Figuur 17:workerpool met de creation table

Nu is er een link gecreëerd tussen het station en de worker via de broker en zal de broker de juiste worker sturen naar het station.

Om een worker aan een station te laten sleutelen moet er een workplace voorzien worden in het programma. Wanneer men deze workplace naast het station plaatst zorgt het programma automatisch voor een link tussen het station en de workplace. Men kan dit natuurlijk ook handmatig instellen.

Wanneer het probleem is opgelost zal de worker terugkeren naar de workerpool. Men kan ervoor kiezen om de workers te teleporteren of om voetpaden te tekenen die de worker zal volgen. Dit geeft een basisidee van de werking van de workers en we zullen hier bij de ontwikkeling verder op ingaan.

26 4.4 Method Omdat niet elk bedrijf hetzelfde is en het programma flexibel wil zijn, bestaan er zogenaamde methods. Deze methods kan men oproepen onder bepaalde voorwaarden en daarin laat men de gebruiker vrij om te programmeren wat hij of zij maar wil. Om de tool te Figuur 18: ontwikkelen zullen deze methods uiteraard veel toegepast worden, aangezien het standaard method programma automatisch moet kunnen werken, en zich moet kunnen aanpassen aan veranderingen in de Excel files. Op figuur 18 zien de functieblok die gebruikt wordt in Tecnomatix voor een Method.

4.4.1 Method soorten Het grootste deel van de uitwerking van deze opdracht bestaat uit het programmeren in methods daarom zal er wat dieper worden ingegaan op de verschillende types van methods.

4.4.1.1 Init method Eerst en vooral is er de Init method. Init staat hier voor Initialisation. Met andere woorden deze method zal automatisch uitgevoerd worden bij het starten van het programma. Hierin kan men zaken programmeren die gedurende de gehele cyclus niet zullen veranderen. Een Figuur 19: voorbeeld hiervan is de procestime van een station. Op figuur 19 zien de functieblok die init gebruikt wordt in Tecnomatix voor een Init Method. method

4.4.1.2 Reset method Net zoals er een method bestaat die aangesproken wordt voor de Initialisatie van het programma bestaat er ook een een method voor het resetten van de cyclus. Dit noemt men logischerwijs de reset method. Hierin hoeft men niet te programmeren dat alle entities Figuur 20: verwijderd worden. De reset zorgt er automatisch voor dat de gehele cyclus reset. Dus ook reset alle statistieken van elke functieblok. Op figuur 20 zien de functieblok die gebruikt wordt in method Tecnomatix voor een Reset Method.

4.4.1.3 Control method Een derde soort belangrijke methods zijn de control methods. Meestal afgekort als Ctrl. Er zijn verschillende soorten en in de ontwikkeling van de tool worden er ook verschillende soorten gebruikt. Belangrijk om te weten is dat deze methods zullen opgeroepen worden Figuur 21: tijdens een simulatie en het mogelijk maakt om bepaalde zaken aan te passen tijdens de ctrl simulatie. Een voorbeeld hierop is de RequestCtrl. Deze zal telkens opgeroepen worden per method station als een station een Request uitzend. Een request kan bijvoorbeeld gegenereerd worden wanneer het station in fout gaat en het naar een worker nodig heeft. Een uitzondering is bijvoorbeeld de InitCtrl. Deze control method wordt opgeroepen als de Init method wordt geactiveerd en dus enkel bij de start van het programma. Hoe en waar control methods gebruikt worden zullen in verdere hoofdstukken duidelijk worden. Op figuur 21 zien de functieblok die gebruikt wordt in Tecnomatix voor een Control Method, dit is dezelfde als de algemene Method.

27 5 Ontwikkeling De ontwikkeling van het model bestaat uit verschillende stappen, eerst en vooral zullen we de Excel files aanpassen waar het nodig is zodanig dat het programma deze kan inlezen. Daarna zullen we Excel data in het programma verwerken. Daarnaast moeten de nodige voorzieningen voor de workers gemodelleerd worden.

5.1 Excel-files Zoals al eerder vermeld zijn er twee belangrijke Excel-files die als input gebruikt worden. Enerzijds de competentiematrix en anderzijds de robotdata. Voor de proces tijden worden er nog twee extra Excel-files gebruikt.

5.1.1 De competentiematrix

Figuur 22: een deel van de competentiematrix

Figuur 22 toont de matrix en deze geeft een overzicht weer van de verschillende competenties waarover elke arbeider beschikt. Voorbeelden van competenties zijn: C4G-robots, PLC, Teamster, …

Bij elke werknemer zijn er actuele en gewenste waarden. Logischerwijs worden voor het model de actuele waarden gebruikt. Dit zijn de competenties waarover de werknemer op dit moment beschikt. De gewenste waarden zijn de competenties waarover de werknemer zal beschikken na de voorziene opleidingen. Echter als men de actuele waarden vernieuwt zal het model zich hieraan moeten aanpassen.

We zien dat elke cel ofwel met een X, een P, een O of leeg is. Als ze leeg is wil dat zeggen dat deze technieker de competentie niet hoeft te kennen. Een X wil zeggen dat hij de competentie kent. Een P wil zeggen dat hij een expert is in die competentie en een O wil zeggen dat hij niet beschikt over de competentie maar hiervoor in opleiding is.

De aanpassingen die hier doorgevoerd worden zijn vrij eenvoudig. Aangezien niet alle techniekers die in deze competentiematrix te zien zijn in UB9 werken, werd er een extra kolom voorzien zodanig dat het programma kan weten welke werknemers actief zijn in UB9. Vervolgens werden de X’en en P’s vervangen door waarden. Deze waarden zullen een maat zijn voor de efficiëntie waarmee de arbeider zijn taak uitvoert. Dit werd gevraagd aangezien men in het programma ook voor elke werken een bepaalde efficiëntie kan instellen.

28 5.1.2 De robotdata

Figuur 23: Een deel van de robotdata

De robots C4G zijn de nieuwste generatie robots die in UB9 geïnstalleerd zijn. Deze installaties zijn in staat om allerhande feedback gegevens terug te sturen, wat uiteraard nuttig is voor dataverwerking. De hoeveelheid beschikbare data is bijgevolg dan ook enorm. Er werd voor dit project vier maanden lang data bijgehouden. Dit kunnen we achterhalen door simpelweg de eerste en de laatste log te bekijken. De vraag is dan als vier maanden wel genoeg data zal voorzien om een betrouwbaar model te maken. De logs werden herwerkt naar een overzichtelijke Excel file, die te zien is in figuur 23, dankzij Mr. Schwab Jonathan.

De herwerkte Excel file geeft weer wanneer een robot in fout is gegaan en wanneer deze fout opgelost werd door een technieker. De data geeft verschillende zaken weer, maar wat moet er geweten zijn:

- Welk station? - Welke robot? - Hoe lang heeft de robot stilgelegen? - Welk type fout was het? - Over welke tijdspanne werd er gelogd?

Deze vijf zaken worden allemaal weergegeven hetzij rechtstreeks of onrechtstreeks. Het station en de bijhorende robot die in fout gaat, wordt weergegeven in de robotnaam bijvoorbeeld: 17030R03. Hieruit volgt dat de fout zich bevond in sectie S17, station 030, robot R03. Hoe lang de robot heeft stilgelegen kunnen we zien aan de downtime van de log. Het type van de fout wordt ook weergegeven in de kolom type.

Hier wordt het al duidelijk dat deze types van fouten zullen gelinkt moeten worden aan de competenties van de werknemers. Een werknemer die over de plc competentie beschikt, zal de plc- type fouten kunnen oplossen.

Verder is er in de database overbodige informatie beschikbaar. Daardoor werd voor de tool deze database herwerkt tot een overzichtelijke lijst van parameters. Verder is deze lijststructuur gebruiksvriendelijker om te importeren in Tecnomatix. In het deel Updaten van proctimes, availability en failures meer hierover.

29

Figuur 24: Herwerkte lijst robotdata

In figuur 24 is een voorbeeld te zien van de herwerkte lijst. Telkens wordt aangetoond welke robot in fout gaat in welk station. De fouten, hier van kolom I tot O, zijn telkens de gemiddelden per type van die bepaalde robot.

In kolommen 6 en 7 zien we respectievelijk processing time en availability. Dit zijn ook parameters die ingesteld moeten worden voor elk station. De processing times zijn bepaald met behulp van een andere Excel file die de gemiddelde proces time van elk station berekend. De proces times die we hier zien worden eigenlijk niet meer gebruikt in de meest recente versie van het model. Deze worden uit andere Excel files gehaald maar meer hierover in het deel procestijden.

De availability wordt bepaald met een formule:

Echter enkel de downtime is gegeven. De downtime is namelijk de som van alle fouten per station. Maar:

De Total Time is wel te bepalen uit de logs van de robots. Dit wordt bepaald door het tijdverschil tussen de datum en timestamp van de eerste log en die van de laatste log. Daaruit volgt:

Bij deze laatste vergelijking is alles gegeven.

30 5.1.3 Procestijden Om de werking van de robotstations zo goed mogelijk over te brengen in onze simulatie maken word ook hier gebruik gemaakt van data die afkomstig is uit metingen van Volvo zelf. De meetgegevens die ter beschikking gesteld werden zijn echter niet volledig, sommige stations worden er niet in vermeld. Dit zijn doorloopstations waar bijvoorbeeld metingen worden uitgevoerd. Hiervoor word in het programma tien seconden doorlooptijd voorzien. Een ander probleem met deze data is dat er van sommige stations in bepaalde weken geen data werd opgenomen. Het programma werd zodanig geschreven dat onafhankelijk van de hoeveelheid data, er een juiste procestijd zal ingesteld worden.

Figuur 25: wekelijke meetgegevens procestijd

Deze data is terug te vinden in twee verschillende Excel bestanden. Een voorbeeld hiervan is te zien in bovenstaande figuur. In deze bestanden zitten de gemiddelde procestijden van elke week per station. Om voor elk station een goede referentie te kunnen inladen werd er gekozen om van de gegevens de mediaan te kiezen. Van elke rij gegeven wordt een mediaan bepaald die als procestijd wordt ingeladen. Er werd hier niet gekozen voor het gemiddelde aangezien dit gevoeliger voor afwijkingen als er een paar uitschieters tussen zitten. Dit kan zich voor doen als er eens een week geen metingen beschikbaar zijn zoals ook in het voorbeeld te zien is bij sommige stations. 5.2 Het model Er zijn verschillende aanpassingen die moeten gebeuren om het bestaande model te gebruiken als tool om de werkbelasting van de arbeiders te controleren.

- Updaten van procestijden, availabilities en failures van de stations - Workers en de bijhorende competentiematrix implementeren - Ervoor zorgen dat er een link bestaat tussen de competenties en het type van de robotfout - De beschikbare wandelpaden voor de workers opmeten en implementeren

5.2.1 Updaten van proctimes, availability en failures Hoewel de procestijden van het bestaande model dicht aanleunen tegen de procestijden die bepaald werden uit recentere Excel files was het toch nodig ze aan te passen. De availabilities werden berekend zoals al eerder uitgelegd. Om de failures te implementeren word gebruik gemaakt van de database met disturbance data van de robots.

Het belangrijkste hier is dat de gebruiker bij een verandering van procestijd of availability niet in het programma het station moet gaan zoeken en het manueel moet aanpassen. Maar liever dat men met het inladen van een vernieuwde Excel file, de tool kan gebruiken. Hiervoor wordt gebruik gemaakt van een method, meer bepaald de Init Method. De effectieve programmacodes van de verschillende methods zijn terug te vinden in bijlage 2. Hier zullen de principes worden uitgelegd. Eerder werd al aangehaald dat de structuur van de herwerkte lijst van de robotdata zou helpen bij het programmeren, dit wordt nu verder uitgelegd.

De lijst die te zien is op figuur 24 is zodanig opgebouwd dat er in elke kolom een bepaalde area of zone wordt gezocht. Het programma zal eerst controleren of kolom 1 leeg is of niet. Zo niet dan wordt de sub-area aangepast naar de nieuwe waarde en wordt dit opgeslagen in een string.

31 Ditzelfde gebeurt voor kolom 2 en 3. Door de drie strings samen te voegen en telkens een punt te voorzien tussen de verschillende strings wordt een nieuwe string verkregen met bijvoorbeeld de naam GA1_1.S17_0.S17_010 voor het eerste station in de lijst. Dit is een deel van het pad naar het station in het programma. Het volledige pad ziet er als volgt uit: .Volvo_car.Models.GA1_1.S17_0.S17_030. Het .Volvo_car.Models gedeelte is de map in de class library waar de verschillende frames zijn aangemaakt. Naar deze locatie worden de bijbehorende proctimes, availabilities en failures geschreven.

Elk station heeft een vaste procestijd, deze kan wel eens variëren maar in het model kiezen we voor een vaste waarde. Per station zijn er echter enkele robots. Deze robots hebben elk een verschillende availability. Per robot zijn er dan nog eens types fouten met elk een verschillende MTTR (mean time to repair).

Het wordt dus duidelijk dat de proces times gemakkelijk zijn om in te voeren aangezien deze niet per robot zijn maar per station. De availabilities zijn iets complexer aangezien deze per robot moeten ingegeven worden. Tot slot zijn de failures het meest complexe aangezien deze per robot en per type fout gedefinieerd zijn.

De procestijden worden zoals eerder vermeld uit twee verschillende Excel files gehaald. Deze worden dan overschreven in de data_stations tablefile. Deze tablefile is een kopie van het Excel werkblad dat hieronder te zien is. Echter door de nieuwe procestijden te overschrijven hoeven we enkel nog maar een regeltje code te schrijven dat ervoor zorgt dat de nieuwe procestijden ingeladen worden: station_object.setAttribute("proctime",data_stations[6,i]);

Hier is i de rij in excel waar het programma zich momenteel bevindt.

Figuur 26: Werking robotdata voorbeeld

Zoals te zien is in figuur 26 hierboven gebruiken we als voorbeeld station S17_030. Dit station heeft 4 robots namelijk R1, R2, R3 en R4. Elk hebben ze verschillende types fouten namelijk safety, robot en spot. De bedoeling is dat er failures worden ingevoerd met de naam van de robot en het type fout bijvoorbeeld R1spot voor robot R1.

32

Figuur 27: Mogelijke fout storingen station

Zoals in figuur 27 te zien is zijn de failures inderdaad zo ingevoegd. Het principe dat hier toegepast wordt is vrij eenvoudig te begrijpen. In de Init method wordt de Excel file ingelezen naar een tablefile. Een tablefile is eigenlijk gewoon een tabel in het programma. De tablefile wordt kolom per kolom uitgelezen in de Init Method. De failures worden eerst weggeschreven naar een virtuele tabel in de method. Deze tabel moet aan een structuur voldoen en deze ziet eruit zoals figuur 28 aantoont:

Figuur 28: Station failure table

De belangrijkste parameters zijn: Name, availability, MTTR en Failure relates to. De rest van de parameters krijgen standaard waarden. In de method wordt een table gemaakt met dezelfde structuur en de waarden worden hierin weggeschreven. Uiteindelijk wordt de gehele tabel weggeschreven naar het station.

In de “failure relates to” kolom kunnen er drie verschillende keuzes gemaakt worden namelijk: SimulationTime, OperatingTime en ProcessTime. Hier wordt gekozen voor OperatingTime, als er zich nu een failure voordoet. Dan zal dit station stoppen met werken en kunnen er zich geen andere failures voordoen in dit station. Bij de andere twee opties zou het mogelijk zijn dat er zich bijvoorbeeld twee failures voordoen in eenzelfde station en dit is in het echt niet mogelijk aangezien het station stopt met werken bij één failure. Verder wordt hier enkel tijd gemeten als het station operationeel is, hieruit wordt berekend hoe vaak het station in fout moet gaan afhankelijk van de availability en MTTR.

33 5.2.2 Workers en bijbehorende competentiematrix implementeren Net zoals de stations moeten de workers in het begin van het programma gedefinieerd worden. Er is echter een belangrijk verschil tussen de twee. De stations zijn op voorhand vastgelegd en tenzij men verbouwingen doet in de fabriek zullen er geen stations bijkomen of weggaan. Bij de workers is dit anders. De tool moet zich aanpassen aan de competentiematrix, dit wil zeggen als er meer mensen worden aangenomen, moeten er meer workers gecreëerd worden. Omgekeerd geldt dit ook. De Init method werkt alleen als de zaken al in het programma aanwezig zijn maar men kan geen objecten creëren en die ook parameters toewijzen. Gelukkig bestaat daar een andere method voor met name de InitCtrl method. Deze method activeert voordat de Initmethod in werking treed.

Wat echter wel op voorhand in het programma voorzien wordt is een broker en een workerpool en de verschillende workplaces voor alle stations. Via de workerpool kunnen de workers hun parameters aangepast gebruik makend van de zogenaamde creation table.

Het principe is vrij gelijkaardig aan dat van de stations. Kolom per kolom wordt gecontroleerd over welk soort worker het gaat. Zaken die gecontroleerd worden zijn de shift van de worker en het aantal workers in die shift. Er zijn drie shifts namelijk: A, B en N. Dit wordt herwerkt tot bijvoorbeeld: VT_A_2, dit is dan Volvo Technieker 2 in de A-shift. De nummers worden gebruikt om privacy redenen.

Voor elke technieker die in UB9 werkt wordt er dan een virtuele technieker aangemaakt. Deze worden gecreëerd in een map in de class library. Wanneer men het programma reset worden de workers niet verwijderd. Als we daarna weer starten en dus automatisch ook de InitCtrl en Init activeren worden er nieuwe workers bijgemaakt. Dit is natuurlijk niet de bedoeling. Door de map te verwijderen is dit probleem ineens opgelost en moet er geen lange code voorzien worden om te controleren welke workers er aangemaakt zijn om ze dan te verwijderen aangezien de locatie van elke worker zou moeten gekend zijn.

Het programma gaat ook controleren over welke competenties deze workers beschikken. Uiteindelijk komt het er terug op neer om de Excel file om te zetten naar een tablefile om die dan uit te lezen in een method en naar een virtuele tabel weg te schrijven. De virtuele tabel is in dit geval de creation table. Dit is een tabel speciaal voor workers en deze wordt gedefinieerd in de workerpool.

Figuur 29: Creation table

Uiteindelijk komen we tot een gevulde creation table die te zien is in figuur 29. Deze tabel zou errors geven als we de workers in de Init method hadden gecreëerd in plaats van in de InitCtrl omdat ze in dat geval niet zouden bestaan. De creation table definieert belangrijke parameters zoals het aantal workers van dat type, hier is dit altijd 1. In welke shift ze werken, de wandelsnelheid, hoe efficiënt ze te werk gaan en over welke competenties ze beschikken.

34 5.2.3 Creëren van de link tussen de competenties en het type van de robotfout Eerst en vooral werden de verschillende competenties van de competentiematrix geanalyseerd om te bepalen welke van toepassing zijn in UB9. Vervolgens werden deze gelinkt aan de robotdata. In figuur 30 zien we welke competenties nodig zijn in UB9. Degene die nodig zijn, werden aangeduid in het lichtgroen. Degene die niet nodig zijn, werden aangeduid in het rood. In de eerste kolom zien we hoe de types fouten genoemd worden in de robotdata met uitzondering van schroef. Dit is eigenlijk iets dat men over het hoofd gezien heeft en later nog moet geïmplementeerd worden met vernieuwde data.

Figuur 30: Competenties

35 Deze kolommen zijn dan ook de enige die bekeken worden bij het controleren van de competenties van de workers in het programma.

Het probleem hier bestaat erin dat wanneer er een station in fout gaat, dan zal de broker kijken naar de service table van het station. Dit is zoals eerder aangehaald een tabel waar de soort competenties in weggeschreven worden. Op basis van deze tabel stuurt de broker dan een worker die over één van de competenties beschikt en dit is een probleem. Als we nu terug als voorbeeld station S17_030 gebruiken:

Figuur 31: failures workstation

De verschillende failures, die te zien zijn in figuur 31 in de rode kader, zijn niet gelinkt aan de service table. Dit is standaard in het programma, men kan de failures niet linken aan de service table. Men moet de service table apart instellen. In dit station zouden de competenties safety, spot en robot in de service table moeten geladen worden. Echter wanneer er dan een safety failure is, dan zal de broker kijken naar service table. Die ziet op zijn beurt dan de drie competenties en zal een worker sturen die één van die competenties bezit, uiteraard is dit niet de bedoeling. Iemand die niet over de safety competentie beschikt maar wel over de spot competentie kan geen safety failure oplossen.

Dit wordt opgelost met FailCtrl die men instelt voor elk station in de Init method. Dit is dus een control method en zal telkens opgeroepen worden wanneer er een station in failure gaat. In het programma noemt deze MethodGetProfile. Omdat de FailCtrl per station wordt opgeroepen weet je ook welk station die request uitvoerde. Het komt er dan nog op neer om te zoeken welke fout het is. Als de locatie van het station en het type fout gekend is, weet het programma welke competentie naar de service table moet geschreven worden. Op deze manier wordt er wel altijd een juiste worker naar het station gestuurd.

Er wordt een gelijkaardige method gebruikt om de variërende efficiency van de workers te programmeren. Deze method noemt men OrderCtrl. Deze wordt opgeroepen als de worker een order krijgt van de broker. Er zal dan gecontroleerd worden over welke worker het gaat en over de competentie van het station waar die worker naartoe wandelt. De efficiency zal dan naar gelang worden aangepast.

36 5.2.4 Implementeren van de gangpadstructuur Door de aanwezige functionaliteit die het mogelijk maakt om een worker een nieuwe taak te geven terwijl hij nog onderweg is naar zijn rustplaats, is het zeker aan te raden om de volledige gangpadstructuur in Tecnomatix te implementeren. Om alle gangpaden te definiëren is er een eenmalige, handmatige bewerking nodig. Het nadeel is dan ook dat het niet mogelijk is de gangpaden naar een andere afdeling te kopiëren. Het is dus met andere woorden niet dynamisch zoals bijvoorbeeld de Excel files. De bestaande structuur is terug te vinden in een AutoCAD bestand die UB9 in kaart brengt. De in de AutoCAD opgemeten gangpaden zijn zo nauwkeurig mogelijk overgebracht. De visuele schaal wordt echter niet altijd gerespecteerd. Een pad van 50 meter kan er bijvoorbeeld korter uitzien dan een pad van 35 meter. Dit geeft geen nadelen voor de simulatie, enkel kan het tijdens de visuele weergave lijken dat de worker zich met verschillende snelheden over de gangpaden beweegt. Dit is echter niet het geval, elke worker beweegt zich op elk moment voor met een snelheid van 1.4 m/s of ongeveer 5km/u.

Deze gangpad structuur zorgt voor een meer realistisch model aangezien nu ook ongeveer de tijd dat het duurt om tot het station te komen in verschillende situaties in rekening word gebracht. Dit wordt getoond in figuur 32.

Figuur 32: hoofdgrondplan met wandelpaden

37 5.2.5 MWT (Mean Walking Time) Een probleem met de robotdata is dat de MTTR eigenlijk geen MTTR is maar MDT (Mean Down Time). Het verschil tussen deze twee is de wandeltijd die de worker nodig heeft. De MDT is namelijk de som van de MTTR en de wandeltijd. En in de robotdata is het de MDT die berekend wordt aangezien een log start bij een fout en er dan nog naar het station moet gewandeld worden. Deze wandeltijden zijn afhankelijk van de locatie waar de worker zich, op het moment dat hij wordt opgeroepen, bevindt. Dankzij de aangelegde wandelpaden kan het programma de wandeltijden uitrekenen. Aangezien nu de MDT in het station geladen is en de worker nog naar de locatie moet wandelen, wordt de wandeltijd eigenlijk twee keer verwerkt in het programma. Enerzijds door het verschil tussen MDT en MTTR en anderzijds door de extra bijgerekende Tecnomatix wandeltijd. Dit is natuurlijk een probleem dat opgelost moet worden.

Om de simulatie zo nauwkeurig mogelijk te maken, kan deze fout niet toegelaten worden in het programma. Dit wordt als volgt opgelost. Tijdens de Init wordt eigenlijk de MDT ingelaten, er werd ervoor gekozen dit zo te laten aangezien we het toch nodig hebben voor deze method. Deze MDT’s worden ook bijgehouden in een tablefile die eigenlijk rechtstreeks uit de robotdata Excel file gekopieerd wordt. De wandeltijden worden berekend door het tijdstip dat de worker een order krijgt en het tijdstip dat de worker toekomt in het Workstation op te slaan in tabellen en vervolgens die twee waarden van elkaar af te trekken. Indien deze tijd kleiner is dan 0 dan wordt er drie seconden werktijd geprogrammeerd. Dit zijn dan bijvoorbeeld fouten waarbij men enkel terug op de startknop moet drukken. Er werd een aparte tabel voorzien voor elk station. Deze tabellen werden MWT genoemd, dit staat voor Mean Walking Time. Via de robotdata tablefile die alle werkstations en bijhorende MDT bevat wordt naar het desbetreffende station gezocht, de bijhorende MDT wordt uitgelezen en daar wordt de wandeltijd van afgetrokken met als gevolg dat de juiste MTTR wordt ingeladen.

Als we de MDT niet uit deze tablefile zouden halen maar uit het werkstation zelf dan moest er ook nog een manier bedacht worden om de originele MDT te blijven onthouden. Aangezien anders telkens opnieuw de wandeltijd afgetrokken wordt van de waarde in het station en deze uiteindelijk naar 0 zou gaan. Daarom werd er niet voor deze oplossingsmanier gekozen.

Telkens als er dus een worker toekomt bij een station zal er een nieuwe MTTR berekend worden afhankelijk van de wandeltijd en deze zal ingeladen worden in het juiste station.

Om het met een simpel voorbeeld eventueel duidelijker te maken. Stel dat een worker opgeroepen wordt naar een station. Dan wordt tijd 1 bijgehouden in de tabel voor dat station. Stel dat we al 20 minuten aan het simuleren zijn dan is tijd 1 gelijk aan 20 min. De worker komt nu toe aan het station dat moet gerepareerd worden, op dit moment wordt tijd 2 bijgehouden in de tabel. Stel dat de simulatietijd nu 21 minuten is. Uit deze twee waarden wordt de wandeltijd berekend, in dit geval is dit 1 minuut. Stel dat de MDT in het station 6 minuten is, dan wordt deze aangepast naar 5 minuten en dan is dit nu de MTTR ipv MDT.

38 5.2.6 Efficiëntie De efficiëntie beperkt zich enkel tot een algemene weerspiegeling van de competenties van de werknemer. Aangezien men maar één keer de efficiëntie kan instellen in het programma. Dit vertaald zich in een onnauwkeurige data als deze wordt gebruikt want voor elke competentie is er eigenlijk een verschillende efficiëntie voorzien in de competentiematrix. Als we ons inbeelden dat een werknemer een kernactiviteit heel goed meester is en een nevenhandeling nog aan het aanleren is. Dan zou zich dat vertalen dat hij eigenlijk maar algemeen goede werkkracht is. Terwijl het eigenlijk betekend dat het een heel betrouwbaar persoon is voor zijn kernopdrachten maar niet voor nevenopdrachten. Dit algemeen uitmiddelen zoals Tecnomatix dit doet maakt hem dus minder efficiënt dan hij is. Om deze efficiënte beter tot zijn recht te doen komen in de simulatie is er een zelfgeschreven programmacode voorzien die er voor zorgt dat de algemene efficiënte wordt aangepast naargelang de handeling die moet worden uitgevoerd. Op deze manier is het geen algemene maar wel een specifieke efficiënte voor elke verschillende competentie. Het spijtige aan deze poging op een verhoogde nauwkeurigheid is dat de efficiëntie wel aangepast wordt wanneer het moet, maar dat het programma Tecnomatix het niet toepast wanneer het om reparatie werkzaamheden gaat. In het geval van reparatie werkzaamheden zal er altijd 100% efficiëntie gebruikt worden ook al is het ingesteld op een andere waarde. Dat is wel jammer omdat er enkel gebruik gemaakt wordt van reparatie techniekers. Deze code en manier van denken zou echter wel ideaal geweest zijn als het om werkzaamheden van operatoren zou gaan want daar werkt het wel zoals het moet. Voor elk probleem wordt uiteraard een oplossing gezocht en deze bevindt zich bij de gegevens die worden aangepast naargelang de efficiënte van de workers. In dit geval gaat het dus om de MTTR van de werkstations. Bij het oproepen van de worker voor een welbepaald station wordt de MTTR van dit station aangepast aan de efficiëntie van de worker. Bij 200% efficiëntie duren de werkzaamheden maar de helft van de originele MTTR en bij 50% duren ze dubbel zo lang.

5.2.7 Extra features Een eerste feature dat werd geprogrammeerd is een “update Excel-knop”. Deze zorgt ervoor dat de Excel files niet telkens opnieuw worden ingeladen aangezien dit toch enige tijd duurt. Doordat tijdens de ontwikkelingsfase het programma herhaaldelijk getest werd, heeft het op termijn heel wat tijd gespaard.

Een tweede feature is een “write Excel-knop”. Deze doet precies wat de naam doet vermoeden, het schrijft de tabellen van de wandeltijden weg naar een Excel file en de locatie waar de Excel file opgeslagen moet worden kan hier ook gekozen worden. Het is zodanig geprogrammeerd dat enkel de tabellen die gevuld werden weggeschreven worden. Dit ook om tijd te sparen en geen nutteloze lege tabbladen te hebben in Excel.

39 6 Gebruiksaanwijzing In figuur 33 zijn alle zaken terug te vinden waarmee de gebruiker het programma kan instellen.

Figuur 33: aansturing en controle hoek van de simulatie 6.1 Instellingen Er kunnen in het programma verschillende zaken ingesteld worden. Via de ‘options’ knop kunnen de grote van de buffers en de slings ingesteld worden. Meer details hierover vindt u terug in het eindwerk van Niels van Ransbeeck: “VCG Body shop simulation”.

In dit verslag zijn er niet zoveel zaken die aangepast moeten worden. Aangezien de failure-data en de station-data gemeten werd uit de fabriek zelf, moeten deze waarden natuurlijk niet aangepast worden. Wat wel aangepast kan worden zijn de instellingen van de arbeiders, enerzijds kan de efficiëntie ingesteld worden via de competentiematrix en anderzijds kan met het aantal arbeiders instellen in het programma.

Tot slot kan men instellen via de production sequence Excel file in welke mate er auto’s van de verschillende types moeten gemaakt worden. In dit eindwerk werd er altijd met 80% XC60 en 20% S60 gewerkt. Meer informatie hierover kan u ook terug vinden in het eindwerk van Niels van Ransbeeck: “VCG Body shop simulation”.

Indien u de Excel files aangepast hebt, dient u ze op te slaan in de map: Simulation files\Excel sheets op voorwaarde dat het Tecnomatix bestand in de map Simulation Files opgeslaan is. Daarna moet de ‘update excel’ knop ingedrukt worden zodanig dat er onder de knop ‘update=true’ te zien is. Op die manier zullen, bij de volgende simulatie, de Excel files ingeladen worden. Dit kan enkele minuten duren.

40 6.2 Event controller De eventcontroller heeft een heel eenvoudige functie. Het controleert de simulatietijd. Er kan ingesteld worden hoe snel de simulatie moet gaan. Men kan dit versnellen door eventueel de animaties van het programma uit te zetten. Figuur 34: event controller

Figuur 35: Controls event controller

Op figuur 35 zien we de controls tab. Deze tab legt zichzelf uit. De knoppen van links naar rechts zijn: Reset, Play, Play zonder animaties, Play tot volgende event en de debugger. Indien we op één van de play toetsen drukken zal de simulatie van start gaan en de Init methods automatisch activeren.

Figuur 36: Settings event controller

Op figuur 36 zien we de settings tab. Hier kan men kiezen vanaf wanneer tot wanneer de simulatie moet plaatsvinden. In statistics wordt er ingesteld wanneer het programma statische waarden moet beginnen opnemen. In dit geval is het na vier dagen aangezien het programma eerst op gang moet komen en anders worden de resultaten beïnvloedt door de opstartperiode. De simulatie begint op 1 januari vanaf kwart na vijf en duurt 20 dagen. Delete MUs on reset is hier aangevinkt omdat we willen de stations volledig vrij zijn van onderdelen bij het herstarten van de simulatie.

41 6.3 Experiment Manager De Experiment Manager laat de gebruiker toe om verschillende experimenten te laten uitvoeren direct na elkaar. De functieblok is te zien in figuur 37. Het is belangrijk dat ook iedere keer de Init opnieuw wordt uitgevoerd voor elk experiment. Hierbij zullen er ook geen animaties worden getoond. Wanneer deze experimenten zijn uitgevoerd word een rapport gegenereerd met de verschillende input en output waardes. In dit geval wordt als input gekozen voor het aantal workers en als output het aantal Figuur 37: jobs per hour. ExperimentManager

Figuur 38: Instellingen ExperimentManager

Zoals te zien is in figuur 38 zijn ook hier de knoppen start, stop en reset te vinden. Daaronder bij het tabblad definition kunnen we de verschillende zaken instellen. Bij define output values is het mogelijk meerdere outputs te definiëren maar hier word er maar één ingesteld zoals te zien is in figuur 39 hieronder. Hier wordt eigenlijk een statische waarde van de drain opgevraagd.

Figuur 39: output definiëren bij experimentManager

42 Net zoals de output variabelen worden ingegeven worden ook de input variabelen ingegeven. Hier wordt een globale variable gebruikt die bepaald hoeveel workers er in het programma worden opgenomen. Dit is te zien in figuur 40 hieronder.

Figuur 40: input definiëren bij experimentManager

Tot slot moet er ingesteld worden welke experimenten men zal uitvoeren. In dit geval wordt ervoor gekozen om drie experimenten te doen met respectievelijk één, twee en drie arbeiders. Dit wordt ingesteld via ‘Define Experiments’ Men krijgt dat een venster zoals te zien is in figuur 41 hieronder.

Figuur 41: Aantal experimenten definiëren bij ExperimentManager

Hierna kan er gekozen worden hoeveel keer elk experiment uitgevoerd wordt. Hoe meer experimenten, hoe preciezer de uiteindelijke analyse. Hier wordt er gekozen om elk experiment drie keer uit te voeren.

In het tabblad evaluation kunnen er verschillende resultaten worden opgevraagd na het simuleren, maar deze worden ook getoond in het rapport dat automatisch gegenereerd wordt op het einde van alle experimenten.

43 7 Analyse De grafieken die worden gebruikt in dit hoofdstuk zijn voornamelijk van een 20 dagen durende simulatie met één worker per shift. Merk op dat er door Volvo Car Gent enkel data voorzien werd van C4G robots en dat dit in feite maar de helft van de stations in UB9 is. In het programma zijn er dus ook maar failures voorzien voor ongeveer de helft van de stations. Hierdoor is het niet mogelijk om een simulatie te realiseren die een correcte weerspiegeling van de fabrieksafdeling UB9 kan weergeven. Het is wel mogelijk om te onderzoeken wat de invloed is als er specifieke parameters worden gewijzigd en welke parameters de grootste invloed hebben op het proces. Er moet ook onderzocht worden of de simulatie met de beperktere aanwezige data wel een nauwkeurige werking heeft, zodoende dat er geen aanpassingen meer hoeven te gebeuren als alle data beschikbaar is en in de simulatie wordt ingeladen.

7.1 Charts Charts zijn grafieken of staafdiagrammen die belangrijke informatie weergeven over de workers en de jobs per hour. Deze zijn essentieel om het programma goed te kunnen analyseren. In plaats van bij elke worker naar de statistieken te kijken geven deze een overzicht van alle workers naast elkaar. In het model waarmee er gestart werd, werden er twee charts voorzien. Een eerste chart is ook voor dit eindwerk handig om te gebruiken en deze geeft de output weer ofwel de jobs per hour in functie van de tijd. De tweede chart toont aan hoe vol de buffers zijn op elk moment en wordt in dit verslag niet gebruikt.

7.1.1 Chart_output

Figuur 42: Grafiek JPH

In figuur 42, wordt in eerste instantie de output getoond (jph) in het zwart. Op de y-as zien we het aantal geproduceerde auto’s en op de x-as de simulatietijd. De piek die te zien is komt overeen met het tijdstip wanneer er gestart wordt met statische waarden op te nemen. De piek compenseert de opstartperiode. De rest van de grafieken op deze chart zijn gegevens over de slings en deze zijn niet belangrijk voor dit verslag. Slings zijn ook een soort van transportbuffer, die in de fabriek boven de stations geïnstalleerd werden.

44 7.1.2 Workerchart Wat meer van belang is zijn de workers en er werd dus ook gevraagd om vooral deze activiteiten te visualiseren in het programma. Er werd in het programma een functieblok voorzien voor deze toepassing, de workerchart functieblok. Deze laat toe een chart op te roepen die toont hoeveel van de tijd de workers wachten, op weg zijn en effectief reparatiewerken uitvoeren.

Figuur 43: Instellingen Workerchart

Deze functieblok wordt gelinkt aan een workerpool, zoals te zien is in figuur 43 wordt bovenaan de naam van de workerpool ingevuld. In dit geval is dat Maintenance_UB9. Nu kan men verschillende instellingen voorzien die later natuurlijk ook kunnen gewijzigd worden. Er kan gekozen worden om de gehele workerpool te bekijken maar hier wordt er gekozen om de data per worker te bekijken, merk op dat hiervoor individuals wordt aangeduidt. Verder wordt hier ook voor Working time gekozen omdat Overall time ook de tijd weergeeft wanneer de worker niet gepland is. Omdat er in 3 shifts gewerkt wordt is elke worker 67% van de tijd niet gepland. Hier is dit niet interessant en working time toont enkel statistiek van de tijd dat de worker aan het werk is of gepland is. In figuur 44 is dan het resultaat te zien wanneer er op Show Chart geklikt wordt.

45

Figuur 44: grafiek Workerchart

Bovenstaand voorbeeld, figuur 44, werd gehaald uit een voorbeeld met maar één worker per shift. Zoals in de legende te zien is zijn er heel wat meer zaken die kunnen gevisualiseerd worden maar in dit programma zijn er maar drie van toepassing. Deze grafiek geeft de gebruiker een idee van de belasting per worker. Zoals hier te zien is zijn de workers ongeveer 70 tot 80% van de tijd belast.

Dit is een vrij goed resultaat aangezien in het programma nog geen pauzes werden voorzien, Volvo Car Gent wil ook zien welke competenties het meest voorkomen. Daarvoor werden nog twee extra charts voorzien.

46 7.1.3 WorkerChartFromTBL Een eerste chart die meer in detail bekeken wordt is de WorkerChartFromTBL. Deze toont welke competenties het meest voorkomen. De naamgeving hiervoor werd zo gekozen omdat deze chart in feite een visualisatie is van een tabel. Deze tabel wordt aangemaakt in de OrderCtrl Method. Met andere woorden telkens als een worker een order krijgt van de broker zal er gezocht worden voor welke competentie het is. Vervolgens zal er in de tabel bij die worker voor die bepaalde competentie plus één worden bijgeteld. De tabel zien we hieronder in figuur 45:

Figuur 45: WorkerchartTBL

Dit leidt tot volgende grafiek, die te zien is in figuur 46. Om deze te linken dient volgende code voorzien te worden:

.Volvo_car.Models.GA1_1.Charts.workerChartfromTBL.inputchannels:=.Volvo_car.tablefiles.WorkerC hartTBL.copy({0,0}..{*,*});

Figuur 46: WorkerchartfromTBL

47 7.1.4 WorkerChartTotFromTBL Het enige verschil met de vorige grafiek is dat er hier naar het totaal van de soorten fouten wordt gekeken van failuretypes in de volledige UB9-afdeling ipv per worker. Hetzelfde systeem wordt gebruikt als hiervoor met als verschil dat er niet meer per worker gekeken wordt. Dit geeft eigenlijk een overzicht van de gehele UB9 afdeling. Deze grafiek wordt weergegeven in figuur 47.

Figuur 47: WorkerchartTotTBL

Merk op dat laser in het programma werd voorzien maar er in UB9 geen lasertoepassingen aanwezig zijn. Dit is om eventuele code te kunnen kopiëren als er een nieuwe afdeling wordt geanalyseerd.

7.2 Goodness of Fit testen Deze testen werden uitgevoerd om te controleren of er in de wandeltijd van de workers een bepaalde verdelingsfunctie te herkennen was. Dit werd gecontroleerd voordat de nieuwe MTTR- tijden ingevoerd werden. De bedoeling van deze test was dat er een verdelingsfunctie aan de workers en stations kon worden gelinkt. Daardoor zouden de wandeltijden op een gemakkelijke manier in het programma kunnen worden verwerkt. Hiermee is het resultaat in feite al gezegd maar toch wordt even vermeld hoe er tewerk gegaan is.

7.2.1 MWT (Mean Walking Time) In eerste instantie werden er, zoals eerder gezegd, MWT-tabellen aangemaakt. De testen werden uitgevoerd voor de gehele UB9 afdeling en een aantal verschillende stations, echter hier zullen we maar één station bespreken aangezien het resultaat hetzelfde blijft. Deze tabellen worden verwerkt in statistische software.

48 7.2.2 Minitab 17 De software die gebruikt werd voor de testen is Minitab 17. De MWT tabellen kan men wegschrijven naar Excel. Dit doet men door op de write Excel knop te drukken en daarna de map in te geven waar men de Excel file wil opslaan.

Hierna kan de Excel file geïmporteerd worden en kunnen er testen gedaan worden. In de onderstaande figuur 47 zien we de resultaten van UB9:

Figuur 48: Goodness of Fit UB9

Voor deze test werd er gewerkt met 3403 waarden, dit is genoeg omdat elk station ongeveer elk type fout al heeft ondergaan. Dit zijn waarden van een simulatie van 10 dagen, als er na 10 dagen geen distributie in te herkennen valt dan zal er nooit een distributie te herkennen zijn. Deze resultaten geven aan dat er geen één distributie overeenstemt met de waarden. Dit kan men zien aan de P- waarde. Die waarde dient echter kleiner te zijn dan 0,05. Dit kiezen we in feite op voorhand, maar de meeste gebruikte significantie niveaus zijn 1% en 5%. Deze vooropgestelde waarde noemt men α. Indien p < α dan wil dat zeggen dat de distributie niet genoeg overeenkomt. Bij 5% is zelfs al 1 van de waarden op 20 fout, meer dan dat is onacceptabel.

49 Vervolgens werd dezelfde test eens uitgevoerd op enkele stations, in dit geval wordt station S22_040_2 gebruikt. Hieronder zijn de resultaten te vinden in figuur 48:

Figuur 49: Goodness of Fit S22_040_2

Er wordt hier een gelijkaardig resultaat verkregen, tijdens de ontwikkeling zijn er nog wat stations getest geweest maar na een vijftal stations kon er besloten worden dat er geen enkele distributie genoeg overeen kwam.

7.3 Simulatie Testen Hier wordt er getest als het voor Volvo aan te raden is om al dan niet meer werknemers aan te nemen. De simulatie is echter niet volledig, de helft van de stations beschikken niet over de failure data. Het komt neer op ongeveer 60 stations met failure data en 60 niet. Hierdoor zijn de analyses niet accuraat. Er wordt getest met één, twee en drie workers per shift. In realiteit werken er drie mensen per shift in UB9, echter een van de drie doet enkel reparatiewerken als het echt nodig is en zal analyses uitvoeren voor eventuele verbeteringen in de fabriek. Er zijn dus meestal twee workers aan het werk en dit zorgt in realiteit voor 32 jph.

Alle testen duren 50 dagen in simulatietijd.

50 7.3.1 Test 1: Aantal workers

7.3.1.1 Experiment 1: één worker per shift, 100% efficiëntie, 5km/h Eerst en vooral wordt de jph bekeken aangezien deze zo hoog mogelijk moet zijn.

Figuur 50: Output, 1 worker, 100% efficiëntie, 5km/h

Ten tweede wordt de werkbelasting bekeken:

Figuur 51: werkbelasting, 1 worker, 100% efficiëntie, 5km/h

51 Ten slotte worden de opgeloste fouten bekeken in UB9 en per worker:

Figuur 52: Totale reparaties, 1 worker, 100% efficiëntie, 5km/h

Figuur 53: Individuele reparaties, 1 worker, 100% efficiëntie, 5km/h

52 7.3.1.2 Experiment 2: twee workers per shift

Figuur 54: Output, 2 workers, 100% efficiëntie, 5km/h

Figuur 55: Werkbelasting, 2 workers, 100% efficiëntie, 5km/h

53

Figuur 56: Totale reparaties, 2 workers, 100% efficiëntie, 5km/h

Figuur 57: Individuele reparaties, 2 workers, 100% efficiëntie, 5km/h

54 7.3.1.3 Experiment 3: drie workers per shift

Figuur 58: Output, 3 workers, 100% efficiëntie, 5km/h

Figuur 59: Werkbelasting, 3 workers, 100% efficiëntie, 5km/h

55

Figuur 60: Totale reparaties, 3 workers, 100% efficiëntie, 5km/h

Figuur 61: Individuele reparaties, 3 workers, 100% efficiëntie, 5km/h

56 7.3.1.4 Besluit De output grafieken tonen aan dat naargelang er meer workers zijn er meer jobs per hour zijn maar er is geen lineair verband. Bij experiment 1 en 2 zien we een duidelijke stijging van de JPH maar dit is niet meer het geval bij experiment 2 en 3, daar kent de JPH een lichte stijging. Op een bepaald moment is het dus niet waard om meer techniekers aan te nemen.

Vervolgens wordt de werkbelasting bekeken. Hoe meer workers er geprogrammeerd worden, hoe minder de werkbelasting per worker bedraagt. Bij experiment 1 is er per worker ongeveer 75% werkbelasting, merk wel op dat er geen pauzes in het programma geprogrammeerd zijn en dat dit dus een redelijke goede werkbelasting is. Echter bij experiment 2 en 3 is de werkbelasting merkelijk lager. Ook kan er uit de grafieken afgeleid worden dat de 2de en 3de worker minder werken dan de 1ste in realiteit kan dit misschien meer verdeeld worden maar het programma houdt hier geen rekening mee. De broker zal gewoon gaan kijken als technieker 1 beschikbaar is, zoniet dan gaat hij over naar technieker 2. Op deze manier zal technieker 1 meer moeten werken. Verder kan besloten worden dat het hier ook niet waard is om 3 workers aan te nemen aangezien de 3de worker niet veel werk levert, de JPH toch gelijk bleef en dus geen grote bijdrage levert.

Ten slotte kan gekeken worden naar het aantal failures die gerepareerd worden. In totaliteit blijft dit hetzelfde aangezien er gedurende 50 dagen gesimuleerd wordt. Hieruit kan besloten worden dat één enkele worker het grootste deel van de fouten kan oplossen voordat de volgende fout zich voordoet m.a.w. er doen zich niet veel fouten tegelijk voor maar het gebeurt natuurlijk wel. Dit wordt duidelijk als er 2 workers voorzien worden en er een stijging in JPH wordt vastgesteld. De fouten die per worker worden opgelost zijn meer van toepassing voor grotere afdelingen met meerdere techniekers die over verschillende competenties beschikken. In de volgende test wordt dit aangetoond.

7.3.2 Test 2: Invloed van de competenties

7.3.2.1 Experiment 1: twee workers met dezelfde competenties Dit is hetzelfde experiment als Test 1: Experiment 2.

7.3.2.2 Experiment 2: twee workers met verschillende competenties (1) Hier wordt bekeken wat de invloed is van workers met verschillende competenties gekozen. In dit geval kent:

- Worker 1: stud, spot, hand en plc - Worker 2: glue, robot, safety en plc

Deze competenties werden gebaseerd op Figuur 56: Totale reparaties, 2 workers, 100% efficiëntie, 5km/h. Uit deze grafiek bleek het aantal reparaties ongeveer gelijk te zijn bij een verdeling van deze competenties.

57

Figuur 62: Output, 2 workers, 100% efficiëntie in verschillende competenties (1), 5km/h

Figuur 63: Werkbelasting, 2 workers, 100% efficiëntie in verschillende competenties (1), 5km/h

58

Figuur 64: Totale reparaties, 2 workers, 100% efficiëntie in verschillende competenties (1), 5km/h

Figuur 65: Individuele reparaties, 2 workers, 100% efficiëntie in verschillende competenties (1), 5km/h

59 7.3.2.3 Experiment 3: twee workers met verschillende competenties (2) Hier wordt bekeken wat de invloed is van workers met verschillend gekozen competenties is. In dit geval kent:

- Worker 1: stud, spot, glue en plc - Worker 2: hand, robot, safety en plc

Deze competenties werden gebaseerd op grafiek 11 : :Individuele reparaties, 2 worker, 100% efficiëntie, 5km/h. Uit deze grafiek bleek het aantal reparaties ongeveer gelijk te zijn bij een verdeling van deze competenties.

Figuur 66: Output, 2 workers, 100% efficiëntie in verschillende competenties (2), 5km/h

Figuur 67: Werkbelasting, 2 workers, 100% efficiëntie in verschillende competenties (2), 5km/h

60

Figuur 68: Totale reparaties, 2 workers, 100% efficiëntie in verschillende competenties (2), 5km/h

Figuur 69: Individuele reparaties, 2 workers, 100% efficiëntie in verschillende competenties (2), 5km/h

7.3.2.4 Besluit Uit deze test blijkt dat het beter is om de workers alle competenties mee te geven. Indien de competenties opgedeeld worden, is de uiteindelijke JPH slechter in beide gevallen. De bedoeling was om de taken zo gelijkmatig mogelijk te verdelen gebaseerd op de twee verschillende grafieken. Echter in realiteit blijkt dit niet zo te zijn zoals te zien is aan de werkbelastinggrafieken te zien op figuren 55, 63 en 67. Dit kan zijn omdat deze experimenten gebaseerd zijn op het aantal fouten en niet op de lengte van de fouten.

61 7.3.3 Test 3: Invloed van de wandelsnelheid

7.3.3.1 Experiment 1: 4km/h

Figuur 70: Output, 1 worker, 100% efficiëntie, 4km/u

Figuur 71: Werkbelasting, 1 worker, 100% efficiëntie, 4km/u

62

Figuur 72: Totale reparaties, 1 worker, 100% efficiëntie, 4km/u

Figuur 73: Individuele reparaties, 1 worker, 100% efficiëntie, 4km/u

7.3.3.2 Experiment 2: 5 km/h Zie grafieken Test 1: Experiment 1

63 7.3.3.3 Experiment 3: 6 km/h

Figuur 74: Output, 1 worker, 100% efficiëntie, 6km/u

Figuur 75: Werkbelasting, 1 worker, 100% efficiëntie, 6km/u

64

Figuur 76: Totale reparaties, 1 worker, 100% efficiëntie, 6km/u

Figuur 77: Individuele reparaties, 1 worker, 100% efficiëntie, 6km/u

7.3.3.4 Besluit Er kan besloten worden dat het effect van de wandelsnelheid een groot verschil uitmaakt. Bij de grafieken van experiment 3 ziet men een JPH van ongeveer 30 en bij experiment 1 ongeveer 25. Er werd gekozen om één worker te gebruiken omdat de werkbelasting hier het dichtst aanleunt bij de reële situatie. Indien we twee workers zouden gebruiken zou er niet veel verschil merkbaar zijn in JPH omdat de werkbelasting sowieso al vrij laag ligt. Verdere merkbare verschillen zijn de walking times in de workerchart grafiek die bij experiment 1 veel hoger liggen. Een merkwaardig verschil is dat het totaal aantal gerepareerde fouten hoger ligt bij 4km/u, we komen hier bij het volgende besluit op terug.

65 7.3.4 Test 4: Invloed van de efficiency

7.3.4.1 Experiment 1: 50% efficiency

Figuur 78: Output, 1 worker, 50% efficiëntie, 5km/u

Figuur 79: Werkbelasting, 1 worker, 50% efficiëntie, 5km/u

66

Figuur 80: Totale reparaties, 1 worker, 50% efficiëntie, 5km/u

Figuur 81: Individuele reparaties, 1 worker, 50% efficiëntie, 5km/u

7.3.4.2 Experiment 2: 100% efficiency Zie test 1: experiment 1

67 7.3.4.3 Experiment 3: 200% efficiency

Figuur 82: Output, 1 worker, 200% efficiëntie, 5km/u

Figuur 83: Werkbelasting, 1 worker, 200% efficiëntie, 5km/u

68

Figuur 84: Totale reparaties, 1 worker, 200% efficiëntie, 5km/u

Figuur 85: Individuele reparaties, 1 worker, 200% efficiëntie, 5km/u

69 7.3.4.4 Besluit Het resultaat dat we hier bekomen is heel merkwaardig. Bij 200% efficiency zien we dat er minder auto’s worden gemaakt terwijl de fouten twee maal zo snel worden opgelost. Dankzij deze testen kan besloten worden dat de aanpassing van de efficiency nog altijd niet naar behoren werkt. Het probleem dat zich voordoet is het volgende. De MTTR en availability van de stations zijn met elkaar gelinkt. In het geval van 200% efficiency wordt de MTTR met een factor twee gedeeld. Door de MTTR te halveren maar de availability gelijk te laten blijven, zal zich veel sneller terug een fout voor doen om de juiste availability te behouden. Het programma baseert zich namelijk op de MTTR en availability die origineel bij de Initialisatie ingeladen werden. Daardoor zien we ook veel meer reparaties dan bij 50% en 100%. Doordat de workers zoveel moeten wandelen verliezen ze tijd en dus ook JPH. De wandeltijd heeft geen effect op de availability, pas als er een worker toekomt begint de teller weer.

In feite doet hetzelfde probleem zich voor als de nieuwe MTTR uit de MDT berekend wordt. Hierdoor verkorten we ook de MTTR. Dit is een verklaring voor het merkwaardige verschijnsel dat de workers meer fouten oplosten bij 4km/u wandelsnelheid bij het vorige deel. Nochtans zou dit aanpassen van de MTTR mogelijk moeten zijn aangezien er in de help functie een pagina is die uitlegt hoe men de MTTR tijdens de simulatie kan aanpassen.

7.4 Problemen en eventuele oplossingen Er zijn dus nog enkele problemen met het model zoals het nu is:

- Efficiency - Aanpassing MTTR

De werking van de efficiency is een fout van de software en de oplossing die in dit verslag werd toegepast, was door het te verwerken in de MTTR. Dit bracht een nieuw probleem met zich mee. In feite zou de aanpassing van de MTTR ook moeten werken aangezien het getoond wordt in de help functie.

Eventuele oplossingen:

- De workers laten teleporteren ipv de gangpadstructuur te gebruiken. Hierdoor wordt de wandeltijd maar één keer verwerkt maar zien we geen onderscheid tussen wandeltijd en werktijd in de statistieken en grafieken. Het efficiëntie probleem is hiermee ook niet opgelost. - Een eventuele oplossing voor de efficiëntie kan dan verwezenlijkt worden door de workers te laten wachten voordat ze de fout oplossen. Op die manier kan men de extra tijd door efficiëntie lager dan 100% integreren als wachttijd. Hierdoor kan men wel geen efficiëntie hoger dan 100% gebruiken. - Siemens contacteren over de problemen.

70 8 Algemeen besluit Op vraag van Volvo Car Gent werd deze thesis geschreven met de bedoeling te controleren of er een tool ontwikkeld zou kunnen worden die aantoont als er meer of minder werknemers tewerkgesteld moeten worden. Een probleem dat ondervonden werd was dat er niet voldoende data beschikbaar was voor alle robots maar enkel van de nieuwste. Hierdoor is het actueel model onvolledig. Indien er voldoende data beschikbaar is voor alle stations kan deze nieuwe data bijgevoegd worden via de Excel files.

Tecnomatix Plant Simulation van Siemens was zeker een goede keuze voor deze thesis. De software is vrij gebruiksvriendelijk en een gebruiker heeft de werking van het programma snel onder de knie. De programmeeromgeving SimTalk is vrij standaard en beantwoord ook aan de behoeften van de software. De helpfunctie die voorzien werd in Tecnomatix geeft een oplossing voor de meeste problemen echter niet allemaal, zoals fouten in Tecnomatix zelf. Veel problemen werden er niet ondervonden waar het de fout was van de software. Maar wanneer echter de invloed van de efficiency werd getest, werd al snel geconcludeerd dat dit geen invloed had op de output en dus niet naar behoren werkte. Hierdoor diende de efficiency nog eens apart geprogrammeerd te worden wat een nieuw probleem met zich meebracht. Door de veranderingen van de MTTR werkt het model niet zoals het zou moeten. De invloed van de wandeltijden is echter niet zo groot als de invloed van 200% efficiëntie. Hierdoor kan er wel besloten worden dat het haalbaar is om een betrouwbaar model te verwezenlijken als die problemen van de baan zijn. Dit mede dankzij de realistische JPH waarden.

Het is een groot voordeel dat Tecnomatix Plant Simulation en Microsoft Excel zeer gebruiksvriendelijk met elkaar kunnen werken. Het is absoluut niet moeilijk om in Tecnomatix een Excel bestand uit te lezen of weg te schrijven. Op die manier moet niet alle data handmatig ingegeven worden wat heel wat tijd spaart. Hierdoor was het ook eenvoudig om het programma automatisch te laten werken en als gebruiker enkel Excel files te hoeven aanpassen en wordt het programma en stuk dynamischer. Wat echter wel problemen kan geven zijn de instellingen in Excel betreffende punten en komma’s. Om met Tecnomatix te werken via Excel is het aan te raden deze in te stellen op punten ipv komma’s.

Nog een klein probleem dat ondervonden werd naar het einde van deze thesis is dat de educational version van Tecnomatic maar 1000 verschillende objecten toelaat. Hierdoor werden de goodness of fit testen in andere software uitgevoerd.

Uit de grafieken kunnen we afleiden dat de meeste waarden die bekomen worden, realistisch zijn. Hierdoor neemt de geloofwaardig van het model toe. De resultaten leunen immers ook dicht aan met de realiteit alhoewel dit moeilijk is om met zekerheid te zeggen aangezien er maar een halve fabriekafdeling geïmplementeerd werd en door de fouten in het programma. Hoe dan ook, het is zeker veelbelovend voor de toekomst en een model zoals in deze thesis beschreven werd zorgt ervoor dat Volvo Car Gent testen kan uitvoeren zonder de fabriek te hoeven stilleggen. Hierdoor kan men zowel tijd als geld besparen en productiever te werk gaan.

71 Lijst met figuren Figuur 1: De eerste Volvo-personenwagen ...... 11 Figuur 2: Safety Center...... 12 Figuur 3: Volvo Amazon ...... 13 Figuur 4: Volvo's in productie in Gent...... 14 Figuur 5: Taartdiagram verkoopcijfers ...... 15 Figuur 6: structuur simulatie model ...... 17 Figuur 7: Onderdeel proces flow UB9 ...... 18 Figuur 8: Hoofd grondplan met ruwe proces flow UB9 ...... 19 Figuur 9: cover handboek: Manufacturing Simulation with Plant Simulation and simtalk...... 20 Figuur 10: overzicht werkblad in Tecnomatix ...... 21 Figuur 11: Toolbox ...... 22 Figuur 12: Class library ...... 22 Figuur 13: basis opstelling ...... 23 Figuur 14: station parameters ...... 24 Figuur 15: configuratie workerpool ...... 25 Figuur 16: Singleproc met service table ...... 26 Figuur 17:workerpool met de creation table ...... 26 Figuur 18: standaard method ...... 27 Figuur 19: init method ...... 27 Figuur 20: reset method...... 27 Figuur 21: ctrl method ...... 27 Figuur 22: een deel van de competentiematrix ...... 28 Figuur 23: Een deel van de robotdata ...... 29 Figuur 24: Herwerkte lijst robotdata ...... 30 Figuur 25: wekelijke meetgegevens procestijd ...... 31 Figuur 26: Werking robotdata voorbeeld ...... 32 Figuur 27: Mogelijke fout storingen station ...... 33 Figuur 28: Station failure table ...... 33 Figuur 29: Creation table...... 34 Figuur 30: Competenties ...... 35 Figuur 31: failures workstation ...... 36 Figuur 32: hoofdgrondplan met wandelpaden ...... 37 Figuur 33: aansturing en controle hoek van de simulatie ...... 40 Figuur 34: Controls event controller ...... 41 Figuur 35: Settings event controller ...... 41 Figuur 36: event controller ...... 41 Figuur 37: Instellingen ExperimentManager ...... 42 Figuur 38: output definiëren bij experimentManager ...... 42 Figuur 39: ExperimentManager ...... 42 Figuur 40: input definiëren bij experimentManager ...... 43 Figuur 41: Aantal experimenten definiëren bij ExperimentManager ...... 43 Figuur 42: Grafiek JPH ...... 44 Figuur 43: Instellingen Workerchart ...... 45 Figuur 44: grafiek Workerchart ...... 46 Figuur 45: WorkerchartTBL ...... 47 Figuur 46: WorkerchartfromTBL ...... 47 Figuur 47: WorkerchartTotTBL ...... 48

72 Figuur 48: Goodness of Fit UB9 ...... 49 Figuur 49: Goodness of Fit S22_040_2 ...... 50 Figuur 50: Output, 1 worker, 100% efficiëntie, 5km/h ...... 51 Figuur 51: werkbelasting, 1 worker, 100% efficiëntie, 5km/h ...... 51 Figuur 52: Totale reparaties, 1 worker, 100% efficiëntie, 5km/h ...... 52 Figuur 53: Individuele reparaties, 1 worker, 100% efficiëntie, 5km/h ...... 52 Figuur 54: Output, 2 workers, 100% efficiëntie, 5km/h...... 53 Figuur 55: Werkbelasting, 2 workers, 100% efficiëntie, 5km/h ...... 53 Figuur 56: Totale reparaties, 2 workers, 100% efficiëntie, 5km/h ...... 54 Figuur 57: Individuele reparaties, 2 workers, 100% efficiëntie, 5km/h ...... 54 Figuur 58: Output, 3 workers, 100% efficiëntie, 5km/h...... 55 Figuur 59: Werkbelasting, 3 workers, 100% efficiëntie, 5km/h ...... 55 Figuur 60: Totale reparaties, 3 workers, 100% efficiëntie, 5km/h ...... 56 Figuur 61: Individuele reparaties, 3 workers, 100% efficiëntie, 5km/h ...... 56 Figuur 62: Output, 2 workers, 100% efficiëntie in verschillende competenties (1), 5km/h ...... 58 Figuur 63: Werkbelasting, 2 workers, 100% efficiëntie in verschillende competenties (1), 5km/h ...... 58 Figuur 64: Totale reparaties, 2 workers, 100% efficiëntie in verschillende competenties (1), 5km/h .. 59 Figuur 65: Individuele reparaties, 2 workers, 100% efficiëntie in verschillende competenties (1), 5km/h ...... 59 Figuur 66: Output, 2 workers, 100% efficiëntie in verschillende competenties (2), 5km/h ...... 60 Figuur 67: Werkbelasting, 2 workers, 100% efficiëntie in verschillende competenties (2), 5km/h ...... 60 Figuur 68: Totale reparaties, 2 workers, 100% efficiëntie in verschillende competenties (2), 5km/h .. 61 Figuur 69: Individuele reparaties, 2 workers, 100% efficiëntie in verschillende competenties (2), 5km/h ...... 61 Figuur 70: Output, 1 worker, 100% efficiëntie, 4km/u ...... 62 Figuur 71: Werkbelasting, 1 worker, 100% efficiëntie, 4km/u ...... 62 Figuur 72: Totale reparaties, 1 worker, 100% efficiëntie, 4km/u ...... 63 Figuur 73: Individuele reparaties, 1 worker, 100% efficiëntie, 4km/u ...... 63 Figuur 74: Output, 1 worker, 100% efficiëntie, 6km/u ...... 64 Figuur 75: Werkbelasting, 1 worker, 100% efficiëntie, 6km/u ...... 64 Figuur 76: Totale reparaties, 1 worker, 100% efficiëntie, 6km/u ...... 65 Figuur 77: Individuele reparaties, 1 worker, 100% efficiëntie, 6km/u ...... 65 Figuur 78: Output, 1 worker, 50% efficiëntie, 5km/u ...... 66 Figuur 79: Werkbelasting, 1 worker, 50% efficiëntie, 5km/u ...... 66 Figuur 80: Totale reparaties, 1 worker, 50% efficiëntie, 5km/u ...... 67 Figuur 81: Individuele reparaties, 1 worker, 50% efficiëntie, 5km/u ...... 67 Figuur 82: Output, 1 worker, 200% efficiëntie, 5km/u ...... 68 Figuur 83: Werkbelasting, 1 worker, 200% efficiëntie, 5km/u ...... 68 Figuur 84: Totale reparaties, 1 worker, 200% efficiëntie, 5km/u ...... 69 Figuur 85: Individuele reparaties, 1 worker, 200% efficiëntie, 5km/u ...... 69

Lijst met tabellen Tabel 1: geproduceerde volvo's in productie ...... 15 Tabel 2: Functieblokken proces ...... 23 Tabel 3: Functieblokken Workers ...... 24

73 Lijst met referenties

Bangsow, S. (2010). Manufacturing Simulation with Plant Simulation and SimTalk. Berlin, Springer Verlag.

Tecnomatix Plant Simulation 11. (Version 11.0.1). (2013). Distributor: Siemens SA (Computer-program). Van Ransbeeck, N. (2014). Discrete event simulation of Volvo Cars Gent Body shop.

De Mey, M. (2015, Januari). Volvo Car Gent Fact Sheet. Opgehaald van Volvo Car Gent website op 26 maart: http://www.volvocargent.be/upload/attach-image/factsheet.pdf Volvo Car Gent (2015). Opgehaald van Volvo Car Gent website op 26 maart: http://www.volvocargent.be/nl/over-volvo

Volvo Cars (2015). Opgehaald van Volvo Cars website op 26 maart: http://www.volvocars.com/nl/over-volvo/onze-organisatie/dit-is-volvo Plant Simulation (2015). Opgehaald van Siemens website op 10 april: http://www.plm.automation.siemens.com/en_us/products/Tecnomatix/manufacturing- simulation/material-flow/plant-simulation.shtml

74 Bijlagen Bijlage 1: Overzicht flow UB9 ...... 77 Bijlage 2: De Method codes ...... 79

75 Bijlage 1: overzicht flow UB9

overzicht flow UB9 proces 1/2 overzicht flow UB9 proces 2/2

76 overzicht flow UB9 proces 1/2

77 overzicht flow UB9 proces 2/2

78 Bijlage 2: De Method codes

EntranceCtrl

RequestCtrl

UpdateMethod

WriteMethode

InitCtrl

MethodGetProfile

OrderCtrl init

79 EntranceCtrl /* de entrance control zorgt voor de MWT tabellen van de aankomst tijd van de technieker voorzien hieruit wordt dan ook zijn wandeltijd berekend om dan met deze wandeltijd de Mean down time om te rekenen naar de Mean time to repair. de efficiëntie van de technieker werkt niet in technomatix als het gaat over de reparatie en oplossen van storingen. daarmee wordt in deze methode de berekende MTTR nog eens omrekent naar gelang de efficiëntie van de technieker die de storing komt oplossen.

*/ is -- variable-- --string station : string; stationlocatie : string; looptijd : string; robotnaam : string; --boolean werkstation : boolean; --object tabel : object; tabel_UB9 : object; data_stations : object; --time tijd: time; --integer aantal_rijen: integer; --real efficientie : real; MTTR: time; --table tbl_station_failure : table[string, boolean, string, string, string, string, real, string, string, string, string, string, string]; -- table[Name, Active, Start distribution, Start parameters, Stop, distribution, Stop parameters, Availability, MTTR, Duration distribution, Duration, Interval, Interval, Failure relates to] servicetable : table[ string, integer, string]; -- [service, amount, alternative] do werkstation := false; tbl_station_failure.create; servicetable.create; data_stations := .Volvo_car.tablefiles.data_stations; /* "?" bevat het pad van de workplace gelegen bij het workstation. hier halen we het workstation uit de workplace naam */ if copy(obj_to_str(?),41,1) = "_" then station := strRcopy(obj_to_str(?),9); station := strRcopy(obj_to_str(?),7); end; if copy(obj_to_str(?),21,1) = "_" then

80 stationlocatie := copy(obj_to_str(?),1,27); else stationlocatie := copy(obj_to_str(?),1,29); end; -- aan de hand van de workstation kan nu de bijhorende tabel opgeroepen worden. tabel :=".volvo_car.MWT.TBL_"+ station; aantal_rijen := str_to_num(tabel[4,1]);

-- de aankomst tijd van de technieker in deze tabel oplsaan tabel[2,aantal_rijen] := time_to_str(EventController.simTime); -- de wandelijd berekenen tabel[3,aantal_rijen] := time_to_str(str_to_time(tabel[2,aantal_rijen]) - str_to_time(tabel[1,aantal_rijen])); -- (tijd melding storing) - (aankomst tijd technieker) looptijd := tabel[3,aantal_rijen]; if copy(tabel[3,aantal_rijen],2,1) = ":" then tabel[3,aantal_rijen] := num_to_str(str_to_num(copy(tabel[3,aantal_rijen],1,1))*60 + str_to_num(copy(tabel[3,aantal_rijen],3,4))); -- tijd omzetten naar seconden als de minuten tussen de 1 en 9 liggen elseif copy(tabel[3,aantal_rijen],3,1) = ":" then tabel[3,aantal_rijen] := str_to_num(copy(tabel[3,aantal_rijen],1,2))*60 + str_to_num(copy(tabel[3,aantal_rijen],4,4)); -- tijd omzetten naar seconden vanaf 10 min end; tabel_UB9 := ".Volvo_car.MWT.TBL_UB9"; Tabel_UB9[2,1] := num_to_str(str_to_num(Tabel_UB9[2,1])+1); Tabel_UB9[1,str_to_num(tabel_UB9[2,1])] := tabel[3,aantal_rijen];

------str_to_obj(Stationlocatie +"."+ station).failimp.getservices(servicetable); robotnaam := servicetable[3,1] + servicetable[1,1]; str_to_obj(Stationlocatie +"."+ station).failures.gettable(tbl_station_failure); efficientie := 100/@.efficiency;

local i := 0; while i < data_stations.yDim+1 loop -- yDim = de dimensie van de tabel in de y waarde i:=i+1; --station if data_stations[3,i] = station then werkstation := true; end; if data_stations[5,i] = servicetable[3,1] AND werkstation = true then --robotnummer for local j := 9 to 15 loop --type fouten uit de excel halen en in een locale tabel steken if data_stations[j,0] = servicetable[1,1] then --soort fout

for local k := 1 to tbl_station_failure.ydim loop if robotnaam = tbl_station_failure[1,k] then

if str_to_num(time_to_str(str_to_time(data_stations[j,i]) - str_to_time(looptijd))) > 0 then -- MDT - wandeltijd > 0 -- in te laden MTTR str_to_obj(Stationlocatie +"."+ station).Failures.getFailure(robotnaam).mttr := (str_to_time(data_stations[j,i]) - str_to_time(looptijd));-- * efficientie; -- de efficientie van de technieker in rekening brengen

81 -- correctie aan de MTTR door techniecker te laten wachten vooraleer de reparatie uit tevoeren. @.statWaitingtime:= (str_to_time(data_stations[j,i]) - str_to_time(looptijd)) * corretie_tijd_MTTR; else tbl_station_failure[8,k] := "3"; end;

werkstation := false; i := data_stations.yDim+1; end; next; end; next; end; end; end;

82 RequestCtrl --standaard code voor RequestCtrl (type : integer) -- Importer type (0=failure, 1=setup, 2=processing, 3=transport) is do inspect type when 0 then ?.failImp.import; when 1 then ?.setupImp.import; when 2 then ?.imp.import; end; end;

UpdateMethod -- de updateMethod onthoud de laaste toestand voor de update knop is do if .Volvo_car.Models.GA1_1.Update = false then .Volvo_car.Models.GA1_1.Update := true; else .Volvo_car.Models.GA1_1.Update := false; end; end;

WriteMethode --write methode zorgt voor de layout van de output venster is

do

.Volvo_car.Models.GA1_1.Opslaan.clearData;

.Volvo_car.Models.GA1_1.Opslaan.Label := "Opslaan als";

.Volvo_car.Models.GA1_1.Opslaan.createStaticTextBox("opslaan in folder:",0,0);

.Volvo_car.Models.GA1_1.Opslaan.createeditTextBox("folder locatie",0,1,50);

.Volvo_car.Models.GA1_1.Opslaan.open;

end;

83 InitCtrl --De init_Ctrl zorgt voor: -- - Het inlezen van excelbestand: - Competentiematrix.xlsx tabblad : competentie -- - Data uit de 2laaste bestanden uit middelen en samenvoegn met 'breakdowndata' in de tabel: data_buffers -- - De meetgegevens in de werkstations laden. -- - kanban gegevens inladen -- - sling gegevens inladen -- - buffer gegevens inladen

is -- variable-- --integer rij : integer; aantal : integer; aantal_a : integer; aantal_b : integer; aantal_n : integer; aantal_we : integer; --string str_path : string; worker_path : string; area : string; zone : string; robot : string; station : string; fout : string; shift : string; aantal_str : string; worker_str : string; --object data_stations : object; data_workers : object; station_object : object; worker_object : object; --table data_kanban : table[string]; tbl_station_failure : table[string, boolean, string, string, string, string, real, string, string, string, string, string, string]; -- table[Name, Active, Start distribution, Start parameters, Stop distribution, Stop parameters, Availability, MTTR, Duration distribution, Duration, Interval, Interval, Failure relates to] tbl_failure_import : table[ string, integer, string]; -- [service, amount, alternitive] tbl_workers : table[object, integer, string, real, real, string, string, string, string, string, string, string, string]; --[worker amount, shift, speed, efficiency, hand, laser, plc, robot, safety, spot, stud, glue]

84 do -- bepalen of de excel bestanden moeten bijgewerkt worden of niet. if .Volvo_car.Models.GA1_1.Update = true then -- is te regelen met de update_exel knop in de GA1_1 --geen code om het naar false te brengen, de true waarde moet gebruikt worden in .volvo_car.Models.GA1_1.init .Volvo_car.tablefiles.data_workers.readExcelFile("Excel sheets\Competentiematrix.xlsx","competentie"); end;

data_workers := .Volvo_car.tablefiles.data_workers; tbl_workers.create; aantal := 0; aantal_a := 0; aantal_b := 0; aantal_n := 0; aantal_we := 0;

-- tabellen: bij elke gebruikte kolom een naam toekennen, zodat ze leesbaar zijn in de weergave als grafiek.

.Volvo_car.tablefiles.WorkerChartTBL[1,0] := "stud"; .Volvo_car.tablefiles.WorkerChartTBL[2,0] := "spot"; .Volvo_car.tablefiles.WorkerChartTBL[3,0] := "hand"; .Volvo_car.tablefiles.WorkerChartTBL[4,0] := "glue"; .Volvo_car.tablefiles.WorkerChartTBL[5,0] := "laser"; .Volvo_car.tablefiles.WorkerChartTBL[6,0] := "robot"; .Volvo_car.tablefiles.WorkerChartTBL[7,0] := "safety"; .Volvo_car.tablefiles.WorkerChartTBL[8,0] := "plc";

.Volvo_car.tablefiles.WorkerChartTotTBL[0,1] := "totaal"; .Volvo_car.tablefiles.WorkerChartTotTBL[1,0] := “stud”; .Volvo_car.tablefiles.WorkerChartTotTBL[2,0] := "spot"; .Volvo_car.tablefiles.WorkerChartTotTBL[3,0] := "hand"; .Volvo_car.tablefiles.WorkerChartTotTBL[4,0] := "glue"; .Volvo_car.tablefiles.WorkerChartTotTBL[5,0] := "laser"; .Volvo_car.tablefiles.WorkerChartTotTBL[6,0] := "robot"; .Volvo_car.tablefiles.WorkerChartTotTBL[7,0] := "safety"; .Volvo_car.tablefiles.WorkerChartTotTBL[8,0] := "plc";

-- workers wissen omdat er bij een nieuwe matrix die minder workers bevat, oude workers overblijven. .volvo_car.resources.workers.deleteObject; local obj: object := .volvo_car.resources.createfolder; obj.name := "workers"; .Volvo_car.MWT.deleteObject; local obje: object := .volvo_car.createfolder; obje.name := "MWT"; -- de gegevens van de competentie matrix aan de workers toekennen, het aantal workers wis afhankelijk van de competentie matrix.

85 -- de namen van de techniekers worden niet gebruikt, ze noemen 'vt_' + hun ploeg naam (A, B, N) + een oplopend cijfer. -- het verband tussen de werkelijke naam en hun programma naam is wel terug te vinden in 'data_workers' in kolom 2 en 6

rij := 1; for local i := 1 to .Volvo_car.tablefiles.data_workers.yDim+1 loop -- yDim = de dimensie van de tabel in de y waarde = aantal rijen (variant op het thema is de xdim)

if (data_workers[5,i] = "actueel" OR data_workers[5,i] = "Actueel") AND (data_workers[4,i] = "ub9" OR data_workers[4,i] = "UB9") then -- filteren op de shift en de aantallen per shift bijhouden if data_workers[3,i] = "A" OR data_workers[3,i] = "a" then shift := "A"; aantal_a := aantal_a +1; aantal :=aantal_a; elseif data_workers[3,i] = "B" OR data_workers[3,i] = "b" then shift := "B"; aantal_b := aantal_b +1; aantal :=aantal_b; elseif data_workers[3,i] = "N" OR data_workers[3,i] = "n" then shift := "N"; aantal_n := aantal_n +1; aantal :=aantal_n; else shift := "WE"; aantal_we := aantal_we +1; aantal :=aantal_we; end;

-- de vaardigheden aan de workers toekennen. aantal_str := num_to_str(aantal); if aantal_str <= .Volvo_car.Models.GA1_1.AantalWorkers then worker_str := "vt_"+shift+"_"+aantal_str; .Volvo_car.tablefiles.data_workers[6,i] := worker_str; .Volvo_car.tablefiles.WorkerChartTBL[0,rij] := worker_str; tbl_workers[1,rij] := .Resources.Worker.createObject(.volvo_car.resources.workers,10,30,worker_str); --worker tbl_workers[2,rij] := 1; --amount tbl_workers[3,rij] := shift; -- shift tbl_workers[4,rij] := (.Volvo_car.Models.GA1_1.wandelsnelheid_in_km_per_h/3.6); --speed m/s tbl_workers[5,rij] := 100; -- efficiency

--nagaan of de vt de competenetie al onder de knie heeft for local j := 13 to 25 loop --het bereik selecteren van de tabellen waarin de benodigde competenties zich bevinden -- de benodigde tabellen raadplegen 16 robot 18 welbolt 19 teamster 21 grippers 22 plc 24 laser 25 veiligheid if str_to_num(data_workers[j,i]) > 0 then if j = 16 then tbl_workers[6,rij] := "robot"; -- vaardigheid: robot

86 elseif j = 18 then tbl_workers[7,rij] := “stud”; -- vaardigheid: stud elseif j = 19 then tbl_workers[8,rij] := "glue"; -- vaardigheid: glue elseif j = 21 then tbl_workers[9,rij] := "hand"; -- vaardigheid: hand elseif j = 22 then tbl_workers[10,rij] := "plc"; -- vaardigheid: plc elseif j = 13 then tbl_workers[11,rij] := "spot"; -- vaardigheid: spot elseif j = 25 then tbl_workers[12,rij] := "safety"; -- vaardigheid: safety end; end; worker_path := ".volvo_car.resources.workers."+worker_str; worker_object := str_to_obj(worker_path); worker_object.OrderCtrl := ref(OrderCtrl);

next; rij := rij+1; end; end; next; tbl_workers.sort("up"); .Volvo_car.Models.GA1_1.Maintenance_UB9.setCreationTable(tbl_workers);

-- voor de layout van table data_workers .Volvo_car.tablefiles.data_workers[13,6] := "spot"; .Volvo_car.tablefiles.data_workers[16,6] := "robot"; .Volvo_car.tablefiles.data_workers[18,6] := “stud”; .Volvo_car.tablefiles.data_workers[19,6] := "glue"; .Volvo_car.tablefiles.data_workers[21,6] := "hand"; .Volvo_car.tablefiles.data_workers[22,6] := "plc"; .Volvo_car.tablefiles.data_workers[25,6] := "safety"; end;

87 MethodGetProfile -- de MethodeGetProfile zorgt voor het ophalen van welke fout er zich in het werkstatoin (singleproc) voordoet en deze specifieke fout in de servicetable van het werkstation steken. -- zo kan er een correcte technieker worden opgeroepen. Deze method krijgt data via RequestCtrl. (IsFailed : boolean; NameProfile:string) is robotnaam : string; fout : string; robotnr : string; data_stations : object; servicetable : table[ string, integer, string]; -- [service, amount, alternative] zone : string; station : string; station_object : object; tabel : object; do data_stations := .Volvo_car.tablefiles.data_stations; print nameProfile; servicetable.create; for local i := 1 to 30 loop -- er zijn een 20 tal verschillende robots, 30 is om een buffer te hebben als er robots bijkomen. for local j := 9 to 15 loop fout := data_stations[j,0]; robotnr := num_to_str(i); robotnaam := "R"+robotnr+fout; -- de naam samen stellen om te kunnnen weten welke fout er opgetreden is. if nameProfile == robotnaam then inspect fout --hand laser plc robot safety spot stud glue when "hand" then servicetable[1,1]:="hand"; when "laser" then servicetable[1,1]:="laser"; when "plc" then servicetable[1,1]:="plc"; when "robot" then servicetable[1,1]:="robot"; when "safety" then servicetable[1,1]:="safety"; when "spot" then servicetable[1,1]:="spot"; when “stud” then servicetable[1,1]:=“stud”; when "glue" then servicetable[1,1]:="glue"; end; servicetable[3,1] := "R"+ robotnr; end; next; next; @.failimp.setservices(servicetable); end;

88 OrderCtrl /*deze orderCtrl zorgt voor: het aanpassen van de MWT tabel, deze tabel is station gebonden. in deze tabel wordt in kolom 1 de meldingstijds van de stronig aan een technieker bijgehouden deze tabel wordt gebruikt om alle wandeltijden naar het bijhorende station bij te houden.

in entranceCtrl wordt de zelfde tabel aangevuld in kolom 2 en 3

daarom wordt kolom 4 (rij 1) gebruikt om de aantal rijen bij te houden. Zo moet dit niet steeds opnieuw bepaald worden.

efficientie van de technieker aanpassen. de efficientie van een technieker is een algemeen overkoppelde waarde. hier wordt bij de technieker de algemeene efficiente steeds aangepast zodat deze overeenkmot met de soort storing dat hij moet oplossen.

*/

(obj : object; -- Importer type : integer) -- Importer type (0=failure importer, 1=setup importer, 2=processing importer, 3=transport importer) is -- variable--

servicetable : table[ string, integer, string]; -- [service, amount, alternative] technieker : string; station : string; controle : string; fout : string; werker : object; tabel : object; chart : integer; chart_tot : integer; do /* de meldings tijd naar de techniekers opslaan de if bepaalt of het werkstation van het type Sxx_xxx is of van het type Sxx_xxx_xx */ if copy(obj_to_str(obj),38,1) = "_" then station := strRcopy(obj_to_str(obj),9); else station := strRcopy(obj_to_str(obj),7); end; tabel :=".volvo_car.MWT.TBL_"+ station; tabel[4,1] := num_to_str(str_to_num(tabel[4,1])+1); --[K,R] -- in tabel[4,1] staat het aantal rijen van die kolom tabel[1,str_to_num(tabel[4,1])] := time_to_str(EventController.simTime);

if type = 0 then

89 servicetable.create; obj.failimp.getservices(servicetable); fout := servicetable[1,1]; technieker := obj_to_str(?); technieker := copy(technieker,30,7); --*.Volvo_car.resources.workers.vt_A_1 controle := strRcopy(technieker,1); if controle = ":" then technieker := copy(technieker,0,7); end; /* in technieker zit nu de naam van de technieker de technieker krijgt een algemeen efficiency factor, dat zorgt er voor dat hij voor elke cometentie die hij kan even goed is. in de onderstaande code wordt zijn effeciente naar het soort reparaties aangepast, op het moment dat hij een specfieke reparatie moet uitvoeren. */ local i := 8; While technieker /= .Volvo_car.tablefiles.data_workers[6,i] loop i := i+2; end; --i is nu de rij van de technieker in de tablefile data_workers local j := 0; if fout = "robot" then j := 16; elseif fout = “stud” then j := 18; elseif fout = "glue" then j := 19; elseif fout = "hand" then j := 21; elseif fout = "plc" then j := 22; elseif fout = "laser" then j := 24; elseif fout = "safety" then j := 25; elseif fout = "spot" then j := 13; end;

werker := ".Volvo_car.resources.workers."+technieker+":1"; werker.efficiency:= str_to_num (.Volvo_car.tablefiles.data_workers[j,i]);

--wegschrijven naar .Volvo_car.tablefiles.WorkerChartTBL i := 1; While technieker /= .Volvo_car.tablefiles.WorkerChartTBL[0,i] loop i := i+1; end;

j := 0; if fout = “stud” then j := 1; elseif fout = "spot" then j := 2; elseif fout = "hand" then j := 3; elseif fout = "glue" then j := 4; elseif fout = "laser" then j := 5; elseif fout = "robot" then j := 6; elseif fout = "safety" then j := 7; elseif fout = "plc" then j := 8;

90 end; chart := str_to_num(.Volvo_car.tablefiles.WorkerChartTBL[j,i]); chart := chart +1; chart_tot := str_to_num(.Volvo_car.tablefiles.WorkerChartTotTBL[j,1]); chart_tot := chart_tot +1; .Volvo_car.tablefiles.WorkerChartTBL[j,i] := num_to_str(chart); .Volvo_car.tablefiles.WorkerChartTotTBL[j,1] := num_to_str(chart_tot);

.Volvo_car.Models.GA1_1.Charts.workerChartfromTBL.inputchannels:=.Volvo_car.tablefiles. WorkerChartTBL.copy({0,0}..{*,*}); -- 'realtime' chart update

.Volvo_car.Models.GA1_1.Charts.workerChartTotfromTBL.inputchannels:=.Volvo_car.tablefil es.WorkerChartTotTBL.copy({0,0}..{*,*}); -- 'realtime' chart update end; end;

91 init /* De init zorgt voor: - Het inlezen van excelbestanden: - breakdowndata.xlsx tabblad : Gegevens_Technomatix_ub9 - UB9.xlsx tabblad : buffers - production_sequence.xlsm tabblad : blad1 - P3_UB9_MAIN FLOW+PA.xlsm tabblad : Pivot Table Results - Gener (2" - P3_UB9_PA FE+FF+RF.xlsm tabblad : Pivot Table Results - Gener (2" - Data uit de 2laaste bestanden uit middelen en samenvoegn met 'breakdowndata' in de tabel: data_buffers - De meetgegevens in de werkstations laden. - kanban gegevens inladen - sling gegevens inladen - buffer gegevens inladen */ is -- variable-- --integer rij : integer; aantal : integer; aantal_a : integer; aantal_b : integer; aantal_n : integer; aantal_we : integer; lengte_rij : integer; komma_getal : integer; --string str_path : string; area : string; zone : string; robot : string; station : string; fout : string; shift : string; aantal_str : string; worker_str : string; --object data_stations : object; data_workers : object; station_object : object; workplace_object : object; worker_obj : object; rij_kolom_rij : object; P3_UB9_MAIN_FLOW_PA : object; P3_UB9_PA_FE_FF_RF : object; --table data_kanban : table[string]; tbl_station_failure : table[string, boolean, string, string, string, string, real, string, string, string, string, string, string]; -- table[Name, Active, Start distribution, Start parameters, Stop distribution, Stop parameters, Availability, MTTR, Duration distribution, Duration, Interval, Interval,

92 Failure relates to] tbl_failure_import : table[ string, integer, string]; -- [service, amount, alternitive] tbl_workers : table[object, integer, string, real, real, string, string, string, string, string, string, string, string]; -- [worker amount , shift, speed, efficiency, hand, laser, plc, robot, safety, spot Stud, glue] tbl_rij_kolom_rij : table[string]; do

data_stations := .Volvo_car.tablefiles.data_stations; P3_UB9_MAIN_FLOW_PA := .Volvo_car.tablefiles.P3_UB9_MAIN_FLOW_PA; P3_UB9_PA_FE_FF_RF := .Volvo_car.tablefiles.P3_UB9_PA_FE_FF_RF; rij_kolom_rij := .Volvo_car.tablefiles.rij_kolom_rij; data_kanban.create; --lege tabel aanmaken

.InformationFlow.TableFile.createobject(.Volvo_car.MWT,10,10,"TBL_UB9"); tbl_station_failure.create; tbl_failure_import.create;

-- input of the tables (excel) + generating kanban table(s)-- if .Volvo_car.Models.GA1_1.Update = true then -- is te regelen met de update_exel knop in de GA1_1 .Volvo_car.Models.GA1_1.Update := false; .Volvo_car.tablefiles.data_stations.readExcelFile("Excel sheets\breakdowndata.xlsx","Gegevens_Technomatix_ub9"); .Volvo_car.tablefiles.data_buffers.readExcelFile("Excel sheets\UB9.xlsx","buffers"); .Volvo_car.tablefiles.production_sequence.readExcelFile("Excel sheets\production_sequence.xlsm"); P3_UB9_MAIN_FLOW_PA.readExcelFile("Excelsheets\P3_UB9_MAIN LOW+PA.xlsm", "Pivot Table Results - Gener (2"); P3_UB9_PA_FE_FF_RF.readExcelFile("Excel sheets\P3_UB9_PA FE+FF+RF.xlsm","Pivot Table Results - Gener (2");

lengte_rij := 0; tbl_rij_kolom_rij.create; --end;

-- mediaan bepalen uit 'P3_UB9_MAIN_FLOW_PA' tov alle beschikbare weken om een waardige procestime te hebben uit de metingen. -- redenering: sorteer alle gegevens oplopend of aflopend en neem er dan de middenste waarde uit. -- het gemiddelde wordt niet gebruikt omdat eventueel uitschieters het gemiddelde te sterk kunnen beïnvloeden.

for local i := 4 to P3_UB9_MAIN_FLOW_PA.yDim loop -- aantal rijen doorzoeken if copy(P3_UB9_MAIN_FLOW_PA[1,i],8,1) = "" then P3_UB9_MAIN_FLOW_PA[1,i] := "S" +

93 copy(P3_UB9_MAIN_FLOW_PA[1,i],3,2) + "_" + copy(P3_UB9_MAIN_FLOW_PA[1,i],5,3); -- notatie zoals ST20010 veranderen naar S20_010 zoals in data_stations end;

for local j := 2 to P3_UB9_MAIN_FLOW_PA.xDim loop -- per rij het aantal kolomen doorzoeken rij_kolom_rij[1,j] := P3_UB9_MAIN_FLOW_PA[j,i]; --[kolom, rij] elke rij wordt naar een kolom getransponeerd, omdat er enkele voor een kolom een functie bestaat om gegevens alfabetisch te rankschikken. next; rij_kolom_rij.sort("down"); -- de nieuwe kolom alfabetisch in tegengestelde zin rangschikken, dit om de lege cellen achteraan te hebben

for local k := 1 to rij_kolom_rij.yDim loop -- de gerangschikte kolom terug in de oorspronkelijk tabel brengen, de gegevens worden dus opnieuw getransponeerd. Nu naar hun oorsprongkelijke rij, maar dan alfabetisch. P3_UB9_MAIN_FLOW_PA[k+2,i] := rij_kolom_rij[1,k]; if rij_kolom_rij[1,k] /= "" then -- ydim functie stopt niet bij de eerste lege cel, hij bevat waardes die tot 800 a 900 kunnen oplopen. bij deze if functie kunnen we het aantal gevulde cellen in de y richting behouden. lengte_rij := lengte_rij + 1; end;

next;

-- 'lengte_rij' bevat de waarde waar de mediaan zich bevindt. de while loop zoekt uit of het een geheel of een komma getal is -- want met een komma getal kan er geen specifieke kolom bepaald worden. lengte_rij := (((lengte_rij - 2)/2)+2)*10; -- de locatie van de mediaan, maal 10 omvan een komma getal een geheel getal maken, een integer kan geen komma's bijhouden en anders moeten we een real komma_getal := lengte_rij; while komma_getal > 5 loop komma_getal := komma_getal -10; end; -- als het een komma is dan wordt er een geheel getal van gemaakt if komma_getal > 5 then lengte_rij := (lengte_rij +5)/10; --delen door 10 om terug op de normale waarde uit te komen else lengte_rij := lengte_rij/10; --delen door 10 om terug op de normale waarde uit te komen end;

P3_UB9_MAIN_FLOW_PA[2,i] := P3_UB9_MAIN_FLOW_PA[lengte_rij,i]; -- de locatie van de mediaan lengte_rij := 0; -- een reset zodat de volgende rij

rij_kolom_rij.delete; -- wis kolom door gebruikte cel te overschrijven door een lege, zodat vorige waardes niet blijven rond slingeren. next;

94

-- ook uit de tabel 'P3_UB9_PA_FE_FF_RF' de mediaan bepalen, net hetzelde als hier boven.

for local i := 3 to P3_UB9_PA_FE_FF_RF.yDim loop -- aantal rijen doorzoeken if copy(P3_UB9_PA_FE_FF_RF[1,i],8,1) = "" then P3_UB9_PA_FE_FF_RF[1,i] := "S" + copy(P3_UB9_PA_FE_FF_RF[1,i],3,2) + "_" + copy(P3_UB9_PA_FE_FF_RF[1,i],5,3); -- notatie zoals ST20010 veranderen naar S20_010 zoals in data_stations end;

for local j := 2 to P3_UB9_PA_FE_FF_RF.xDim loop -- per rij het aantal kolomen doorzoeken rij_kolom_rij[1,j] := P3_UB9_PA_FE_FF_RF[j,i]; --[kolom, rij] elke rij wordt naar een kolom getransponeerd, omdat er enkele voor een kolom een functie bestaat om gegevens alfabetisch te rankschikken. next; rij_kolom_rij.sort("down"); -- de nieuwe kolom alfabetisch in tegengestelde zin rangschikken, dit om de lege cellen achteraan te hebben

for local k := 1 to rij_kolom_rij.yDim loop -- de gerangschikte kolom terug in de oorspronkelijk tabel brengen, de gegevens worden dus opnieuw getransponeerd. Nu naar hun oorsprongkelijke rij, maar dan alfabetisch. P3_UB9_PA_FE_FF_RF[k+2,i] := rij_kolom_rij[1,k]; if rij_kolom_rij[1,k] /= "" then -- ydim functie stopt niet bij de eerste lege cel, hij bevat waardes die tot 800 a 900 kunnen oplopen. bij deze if functie kunnen we het aantal gevulde cellen in de y richting behouden. lengte_rij := lengte_rij + 1; end;

next;

-- 'lengte_rij' bevat de waarde waar de mediaan zich bevindt. de while loop zoekt uit of het een geheel of een komma getal is -- want met een komma getal kan er geen specifieke kolom bepaald worden. lengte_rij := (((lengte_rij - 2)/2)+2)*10; -- de locatie van de mediaan, maal 10 omvan een komma getal een geheel getal maken, een integer kan geen komma's bijhouden en anders moeten we een long komma_getal := lengte_rij; -- van een komma getal een geheel getal maken, een integer kan geen while komma_getal > 5 loop komma_getal := komma_getal -10; end; -- als het een komma is dan wordt er een geheel getal van gemaakt if komma_getal > 5 then lengte_rij := (lengte_rij +5)/10; --delen door 10 om terug op de normale waarde uit te komen else lengte_rij := lengte_rij/10; --delen door 10 om terug op de normale waarde uit te komen end;

95

P3_UB9_PA_FE_FF_RF[2,i] := P3_UB9_PA_FE_FF_RF[lengte_rij,i]; -- de locatie van de mediaan lengte_rij := 0; -- een reset zodat de volgende rij

rij_kolom_rij.delete; -- wis kolom door gebruikte cel te overschrijven door een lege, zodat vorige waardes niet blijven rond slingeren.

next;

-- de gevonden processTime in de tabel data_stations stockeren. -- redenering: doorzoek 3 tabellen naar de overeen komende workstations (tabellen data_stations, P3_UB9_MAIN_FLOW_PA en P3_UB9_PA_FE_FF_RF)

for local i := 1 to data_stations.yDim loop -- doorzoek if data_stations[3,i] /= "" then --[rij,kolom] for local j := 1 to P3_UB9_MAIN_FLOW_PA.yDim loop if P3_UB9_MAIN_FLOW_PA[1,j] = data_stations[3,i] then data_stations[6,i] := str_to_time(P3_UB9_MAIN_FLOW_PA[2,j]); end; next; for local j := 1 to P3_UB9_PA_FE_FF_RF.yDim loop if P3_UB9_PA_FE_FF_RF[1,j] = data_stations[3,i] then data_stations[6,i] := str_to_time(P3_UB9_PA_FE_FF_RF[2,j]); end; next; end; next;

end;

-- processing of data_stations-- (inladen gegevens van tabel 'stations' naar alle werkstations) for local i := 1 to data_stations.yDim+1 loop -- yDim = de dimensie van de tabel in de y waarde = aantal rijen (variant op het thema is de xdim) --area if data_stations[1,i] /= "" then --[rij,kolom] area := data_stations[1,i]; end; --zone if data_stations[2,i] /= "" then --[rij,kolom] zone := data_stations[2,i]; end; --station if data_stations[3,i] /= "" then station := data_stations[3,i];

str_path := ".Volvo_car.Models."+area+"."+zone+"."+station;

96 station_object := str_to_obj(str_path); -- omvormen van string naar object, verwijst naar de functieblokken (de werkstations) met instellingen in het programma station_object.setAttribute("proctime",data_stations[6,i]);

.InformationFlow.TableFile.createobject(.Volvo_car.MWT,10,10,"TBL_"+station);

station_object.failimp.brokerpath := .Volvo_car.Models.GA1_1.Broker; station_object.FailImporterActive := true; station_object.failImp.RequestCtrl:= ref(RequestCtrl); station_object.shiftcalendarobject := .Volvo_car.Models.GA1_1.ShiftCalendar;

tbl_station_failure.delete; tbl_station_failure.create; tbl_failure_import.delete; tbl_failure_import.create; rij := 1;

end; --robot if data_stations[4,i] /= "" then workplace_object := str_to_obj(".Volvo_car.Models."+area+"."+zone+".wp_"+station); workplace_object.entrancectrl := ref(entranceCtrl); for local j := 9 to 15 loop --type fouten uit de excel halen en in een locale tabel steken if data_stations[j,i] /= "0" then robot := data_stations[5,i]; fout := data_stations[j,0]; robot := robot+fout; tbl_station_failure[1,rij] := robot; --Name tbl_station_failure[2,rij] := true; --active tbl_station_failure[3,rij] := "const"; -- Start distribution tbl_station_failure[4,rij] := "0"; --Start parameters tbl_station_failure[5,rij] :="const"; -- Stop distribution tbl_station_failure[6,rij] :="0"; --Stop parameters tbl_station_failure[7,rij] := data_stations[7,i]; --Availability tbl_station_failure[8,rij] := "1,"+data_stations[j,i];--MTTR tbl_station_failure[9,rij] := "";--Duration distribution tbl_station_failure[10,rij] := "";--Duration tbl_station_failure[11,rij] := "";--Interval tbl_station_failure[12,rij] := "";--Interval tbl_station_failure[13,rij] := "operatingtime";--Failure relates to -- failure importer tbl_failure_import[1,rij] := fout; --service tbl_failure_import[2,rij] := 1; --amount tbl_failure_import[3,rij] := ""; --alternative rij := rij+ 1; end; next;

97 end;

if data_stations[3,i+1] /= "" then -- de complete locale tabel van de bovenstaande loop in de bijhorende werkstation steken.

str_path := ".Volvo_car.Models."+area+"."+zone+"."+station; station_object := str_to_obj(str_path); -- omvormen van string naar object, verwijst naar de functieblokken (de werkstations) met instellingen in het programma station_object.failures.settable(tbl_station_failure); station_object.failimp.setservices(tbl_failure_import); end; station_object.failCtrl:=ref(MethodGetProfile);

next;

-- generation data_kanban (table with production sequence for kanban buffer)-- for local i := 1 to .Volvo_car.tablefiles.production_sequence.yDim loop data_kanban[1,2*i-1] := .Volvo_car.tablefiles.production_sequence[3,i]+"_rear_floor"; data_kanban[1,2*i] := .Volvo_car.tablefiles.production_sequence[3,i]+"_front_floor"; next; .Volvo_car.Models.GA1_1.S22_5.KanbanSingleProc.KanbanSequence := data_kanban;

-- executing of the options menu (adjusting capacity of slings and buffers)-- for local i := 1 to .Volvo_car.Models.GA1_1.Slings.yDim loop

str_to_obj(".Volvo_car.Models.GA1_1."+.Volvo_car.Models.GA1_1.Slings[1,i]).Number := str_to_num(.Volvo_car.Models.GA1_1.Slings[2,i]); next;

--buffers in lezen uit excel for local i := 1 to .Volvo_car.Models.GA1_1.buffers.yDim loop

str_to_obj(".Volvo_car.Models.GA1_1."+.Volvo_car.Models.GA1_1.buffers[1,i]).Capacity := str_to_num(.Volvo_car.Models.GA1_1.buffers[2,i]); next; end;

98 Bijgevoegde digitale bestanden

1. Thesis 1.1. In Word 1.2. In PDF 2. Simulation files 2.1. Excel sheets 2.1.1. Breakdowndata.xlsx 2.1.2. Competentiematrix.xlsx 2.1.3. P3_UB9_MAIN FLOW+PA.xlsm 2.1.4. P3_UB9_PA FE+FF+RF.xlsm 2.1.5. production_sequence.xlsm 2.2. UB9.spp 3. Images 3.1. Images UB9

99