• No results found

Kapitlet beskriver planeringsfasen och tillvägagångssättet för att få kännedom om processen. Det beskriver även den konceptuella modellen, var indata är hämtad och arbetsgången för byggandet av simuleringsmodellen.

5.1 PROJEKTPLANERING

Till att börja med genomfördes ett möte med handledare från företaget där viktiga datum och relevanta milstolpar planerades in. Föreläsningar som introducerade examensarbetet ligger också till grund för planeringen. Ett Gantt schema skapades för att få en uppskattning av projektets omfattning och komplexitet. Gantt schemat se bilaga 1.

5.2 PROCESSKÄNNEDOM

För att få en ökad processkännedom gav produktionstekniker en introduktion på projektområdet med en rundvandring. Flera studiebesök har utförts på företaget där specificerat bearbetningsflöde studeras. Aktuella moment i processen har fotograferats och filmats för att erhålla behövlig kunskap kring flödet för byggandet av simuleringsmodellen. Produktionsdata som processtider, tillgänglighet, buffertkapacitet och MTTR har hämtats från befintlig Plant Simulation- och FACTS modell.

23

5.3 KONCEPTUELL MODELLERING:

Den konceptuella modellen som skapades innefattade ett antal olika avgränsningar, antaganden och förenklingar kring modellstruktur och dataparametrar. Följande bestämdes:

 Inga processer för intern/extern materialpåfyllnad (manuell påfyllning med truck) kommer inkluderas i simuleringsmodellen.

 Inga processer för omarbete eller läckagetest kommer inkluderas.

 Antaganden görs att maskinoperatörer alltid finns på plats för att sköta maskinparken varpå inga stopp på grund av personalbrist kommer uppstå under simulering. Ingen väntetid på operatör vid reparation/återställning av maskin kommer mätas som enskild parameter under simulering. Reparation och väntetid på operatör är inkluderat i maskinens tillgänglighetsvärde.

 Vid manuella SPC operationer antas operatören vara på plats för att påbörja kontroll/mätning av produkten omedelbart. Ingen väntetid inkluderas.

 Alla produkter som produceras i flödet är 100 % kvalitetsriktiga varpå inget flöde för omarbete eller kassationer kommer modelleras.

 Använd ingående processdata (cykeltid, tillgänglighet m.fl.) från befintliga Plant Simulation och FACTS modeller är relevant, rimlig och validerad varpå inga nya tidsstudier behöver genomföras.

5.4 DATAINSAMLING

Data för cykeltider hos operationer, SPC, ladda/lossatider för portalsystem, buffertar och lager har mestadels hämtats ifrån befintlig FACTS modell och återanvänts i den nya modellen. Transporttider för portalens åkvagnar har inte inkluderats i ny modell eftersom dessa inte markant påverkar processtiden eller genomloppstiden för produkten. I de fall råämnen laddas i maskinen två och två har processtider från Plant Simulation modellen använts där parallelloperationer utnyttjats.

5.5 BYGGNATION BASMODELL FACTS 3.0

I samförstånd med handledare på Högskolan i Skövde skapades simuleringsmodellen med hjälp av mjukvaran FACTS. Den senaste utgåvan FACTS Analyzer 3.0.3 användes vid byggnationen. Eftersom det huvudsakliga syftet med studien var att utvärdera funktionalitet för det nya resursobjektet i FACTS 3.0.3 var detta ett självklart val.

Mjukvaran FACTS används av företagets tekniker i det dagliga arbetet när modellering skall genomföras. Modellen är byggd för att efterlikna det verkliga fysiska systemets- och befintliga modellers layout. Vissa kompromisser fick dock göras i FACTS modell eftersom mjukvaran saknar viss funktionalitet jämtemot Plant Simulation. Layoututformningen och objektval är gjord för att underlätta förståelsen för produktens flöde genom tillverkningsprocessen, efterlikna verkligheten och skapa en jämförelsebas mot existerande FACTS och Plant Simulation modeller. Färdigställd simuleringsmodell visas i Figur 15. Grön cirkel visar flödets startpunkt för produkten och röd cirkel visar flödets slut.

24

Figur 15: Färdigställd simuleringsmodell i FACTS 3.0.5

5.6 MODELLERING PORTALSYSTEM FACTS 3.0

Vid modellering av portalsystem i FACTS 3.0 användes det nya resursobjektet (Resources). Resursobjektet gör det möjligt att modellera rörelsemönster för olika åkvagnar i ett portalsystem eller montörer-/operatörers rörelser och effektivitetsgrad vid manuellt arbete. När fliken ”Resources” öppnas i resursobjektet framkommer en meny enligt figur 16 nedan. I detta exempel för portalsystem OP50-70 har två aktiva resurser skapats och två ”Skills” med benämning ”Transport Portal” och ”Transport Klar” har kopplats till dessa. En skill kan beskrivas som egenskapen/färdigheten hos en resurs. Det finns standardiserade skills att välja på i resursobjektet men i detta fall har egna skills skapats gällande transport. De aktiva resurserna har namngetts till

”Akvagn_1” och ”Akvagn_2”. Menyn ”Amount” styr hur många resurser med detta namn och skillval som skall finnas i detta resursobjekt. ”Execution factor” bestämmer effektivitetsgraden hos resursen. Ett motsvarar 100 %, 0,8 motsvarar 80 % effektivitet. I de modellerade portalsystem i ny modell valdes 100 % effektivitet hos alla åkvagnar.

25

Figur 16: Menybild från fliken Resource i öppnat resursobjekt.

Efter att önskat antal skills och aktiva resurser valts kopplades resursobjektet ihop med ett antal operationsobjekt (OP) benämnda ”Transport_3, Transport_4, Transport_5”. Dessa operationsobjekt skall motsvara lasta/lossa processen för en åkvagn. För att slutföra kopplingen mellan resursobjektet och operationsobjekten

”Transport_3” var önskad skill tvungen att väljas och aktiveras i ”Resources” fliken hos OP objektet vilket visas i figur 17.

Figur 17: Menybild från fliken Resource i öppnat operationsobjekt.

Samma process upprepades sedan för ”Transport_4” och ”Transport_5” för att slutföra sammankopplingen med resursobjektet.

Denna process som beskrivits gällande skapande av resurser och skills i resursobjekt och sammankoppling med OP objekt användes vid modelleringen av alla portalsystem i modellen.

Figur 18 nedan visar hur det slutgiltiga resultatet för portalsystemsmodelleringen ser ut för ”Portalsyst_OP50_70”. Detta portalsystem innehåller två åkvagnar som transporterar produkter till och från ”OP58” och ”OP60”. Resursobjektet är anslutet till tre OP transportobjekt ”Transport_3, Transport_4, Transport_5” (blå pilar) och tre MaxWIP objekt har placerats ut för att förhindra att någon produkt blir stående på transportobjekten innan ”OP58” och ”OP60” är klara med sina cykler.

Följande beskriver kort flödet för en produkt genom operationer som illustreras i figur 16. Produkten kommer in till buffert ”OP50_Utbana” och väntar där på transport till ”OP58”. När ”OP58” är tom skickar resursobjektet ut en åkvagn till

”Transport_3” där den lastar produkten från ”OP50_Utbana”. Produkten transporteras vidare till ”OP58” där den lossas för att sedan börja bearbetas. Efter bearbetningscykeln i ”OP58” är klar och ”OP60” är tom skickar återigen resursobjektet en åkvagn till ”Transport_4” där produkten lastas för vidare transport framåt till ”OP60”. Samma process upprepas igen och om inte buffert ”OP70_Inbana”

är full skickar resursobjektet en åkvagn till ”Transport_5” för att lasta produkten för vidare transport framåt till ”OP70_Inbana”. MaxWIP objekten ”MaxOP58, MaxOP60, MaxOP70_Inbana” ombesörjer för att inga produkttransporter genomförs om MaxWIP nivån för framförvarande operation eller buffert är uppnådd.

26

Figur 18: Färdig-modellerat portalsystem OP_50_70

5.6.1 PLACERING AV LADDA/LOSSATID I MODELL

För att underlätta i framtida optimeringsarbete kring ladda/lossa tider valdes följande placering av tider i modellobjekten.

Tider för laddning/lossning av produkter placerades i processtiden för operationsobjekt namngivna ”Transport_xx” enligt figur 18.

Portalsystemen i bearbetningsflödet utför ofta transportaktiviteter parallellt med maskinens pågående arbetscykel d.v.s. att portalens åkvagn förflyttar sig längst styrskenan medan maskinens bearbetningscykel fortfarande genomförs. På grund av begränsningar i FACTS mjukvara och svårigheter att få relevant data på hur mycket dessa parallella transportaktiviteter påverkade produktens flöde så valdes att inte inkludera detta i ny FACTS modell.

5.7 VERIFIERING OCH VALIDERING

Under verifieringsfasen av modellen har tidigare beskrivna riktlinjer enligt Banks (2005) följts. En förenklad grundmodell skapades inledningsvis med förenklad portalsystemsstruktur. Strukturen på portalsystemen i modellen diskuterades med handledare på högskolan och utvecklare av FACTS mjukvaran för att finna det bästa och mest effektiva sättet att modellera portalsystem på med hjälp av nya resursobjektet. Modellens funktionalitet säkerställdes också stegvis där flödets olika delar (fin, grov & slutdel) avlusades separat innan de sammanställdes till ett stort gemensamt flöde.

Under valideringsfasen genomfördes experiment för att få fram prestandaresultat från modellen. Resultaten för främst TH värde visade på en avvikelse från befintliga modellers resultat vilket ledde till att modellens portalsystem och struktur fick planeras och byggas om. Efter genomförda förändringar genomfördes nya experiment där mer likvärdiga resultat uppnåddes. Den slutgiltiga modellen verifierades och validerades i samarbete med handledare på Högskolan i Skövde.

5.8 STEADY STATE OCH SIMULERINGSHORISONT

För att säkerställa en lämplig uppvärmningstid för simuleringsmodellen genomfördes experiment i FACTS där följande inställningar användes:

27 Simuleringshorisont 48 dagar Loggningsintervall 60 min Antal replikationer 10 st

Resultaten för WIP och TH värdet analyserades sedan och en uppvärmningstid på ca 180 h kunde anses lämplig (se figur 19 & 20). Resultatet för TH och WIP inkluderar produktvariant Y och Y_2x1 (container). Eftersom modellens prestandaresultat slutligen skulle jämföras med befintliga modeller valdes samma simuleringshorisont och uppvärmningstid som dessa. Simuleringshorisont på 48 dagar och uppvärmningstid på 8 dagar (192 h).

Figur 19: Kurva som visar medelvärdet för TH per timma.

Figur 20: Kurva som visar medelvärdet för Total WIP.

28

5.9 ANTAL REPLIKATIONER FÖR TROVÄRDIGT RESULTAT

För att få en indikation på graden av modellens stabilitet behövde en replikations analys (Replication analysis) göras. För att underlätta detta analysarbete användes en Excel tabell som tillhandahållits av Högskolan i Skövde. I denna tabell matades värden in för medeltalen TH per timma, LT och WIP och dessa värdens standardavvikelser efter 10 använda replikationer med ett konfidens intervall på 95 respektive 98 % (Se bilaga 3). Resultaten enligt tabellen visar på att modellen har hög stabilitet för TH, LT och WIP vilket gjorde att 10 replikationer användes för att få trovärdiga resultat.

Related documents