Jämförelser av påverkan på nyckeltal vid olika
aggregerings nivåer inom produktionsbaserad
flödessimulering.
Comparison of KPI impact for different model
aggregation levels in production flow
simulation.
Examensarbete inom huvudområdet Produktionsteknik
Grundnivå: 15 Högskolepoäng Vårtermin 2018
Ricard Dahlin
Isabelle Hovbjer
Handledare: Amos Ng
Examinator: Tehseen Aslam
i
ÄKTHETSINTYG
Denna rapport skriven av Isabelle Hovbjer och Rickard Dahlin inlämnas till Högskolan i Skövde, för högskolexamination inom produktionsteknik.
Med detta intygas att lånat material i denna rapport, är tydligt identifierat och allt övrigt är skrivit och formulerat av oss personligen.
ii
FÖRORD
Detta examensarbete på Högskolan i Skövde är den slutliga uppgiften i produktionsteknikerprogrammet som är på 120 högskolepoäng. Arbetet som innefattar att bygga en simuleringsmodell av ett bearbetningsflöde är på 15 högskolepoäng.
Ett stort tack till Jacob Bernedixen som varit engagerade i examensarbetet och alltid bistått med experthjälp när problem uppkommit med modellerandet.
Vi vill även tacka vår handledare Amos Ng och examinator Tehseen Aslam för all hjälp och som gjort att detta uppdrag varit möjligt.
Skövde, 2018
Isabelle Hovbjer och Rickard Dahlin
iii
SAMMANFATTNING
Den här studien är genomförd på en tillverkningsindustri. Fabrikens verksamhet inkluderar avdelningar för montering, bearbetning, materialhantering, underhåll och teknisk support m.m. Huvudsyftet med denna studie var att bygga en simuleringsmodell över ett bearbetningsflöde med hjälp av den uppdaterade mjukvaran FACTS. Att genomföra optimering på operationsobjekt (OP) med hjälp av SCORE, jämföra och utvärdera resultat för nyckeltalen TH, LT, WIP mot befintliga modeller samt att minska totala antalet objekt med 10 % jämfört med ursprunglig FACTS modell definierades som mål för studien. Produktvariant Y användes uteslutande under denna simuleringsstudie. I projektet användes PDCA som problemlösningsmetod vilket är ett hjälpmedel för att ge struktur åt förbättringsarbeten. Bank simuleringssteg har använts som riktlinjer i genomförandefasen. Processdata för tillgänglighet, cykeltid och MTTR insamlades från befintliga modeller i FACTS och Plant Simulation. Efter lämpliga data var insamlad skapades en grundmodell byggd för att efterlikna det verkliga fysiska systemet och befintliga modellers layout. Det nya resursobjektet användes för att modellera portalsystemen och tid för ladda/lossa produkter placerades i operationsobjekt för transport. Efter färdigställande av grundmodellen verifierades och validerades denna samt lämplig simuleringshorisont för experiment fastställdes.
För att beräkna antalet nödvändiga replikationer för ett trovärdigt resultat användes tillhandahållen Excel tabell från Högskolan i Skövde. Experiment för nyckeltal och optimering med SCORE utfördes och resultaten jämfördes mot befintliga modeller för att kunna utvärdera eventuella skillnader och dess orsaker. Resultaten visade på närmast likvärdiga siffror för TH men differenser på ca 10–15 % fanns för LT och WIP i ny modell för dessa nyckeltal. SCORE påvisade vissa skillnader i de primära flaskhalsarna men generellt var placeringen av flödesbegränsningar lokaliserade till produktionens avslutande del. Antal objekt i ny FACTS modell blev 327 i jämförelse med 351 i befintlig. Det fanns ett antal olika faktorer som kan ha haft påverkan på det slutgiltiga resultatet. Skillnader i inhämtade processdata och avsaknad av ladda/lossatider i befintlig FACTS modell var faktorer som gjorde systemjämförelser mellan modeller svåranalyserade. Vidare studier krävs för mer grundlig analys av orsaker till differenser i LT och WIP mellan de olika modellerna. Det satta målet för minskat antal objekt med 10 % uppnåddes inte utan objektantal minskade med enbart 6,8 %. Enligt författarna åstadkoms dock en förenklad förståelse för produkternas flöde genom tillverkningsprocessen.
iv
ABSTRACT
This study was conducted in a manufacturing plant. The plant includes assembly-, machining-, materiel handling-, maintenance- and technical support departments.
The main purpose of this study was to create a simulation model of a machining line using the updated software version of FACTS. To implement optimization of the operational objects using SCORE, to compare and evaluate KPI results for TH, LT and WIP against existing models and reduce the total number of objects with 10 % compared to original FACTS model were defined as targets for this project. Studies was conducted using only the product variant Y. PDCA was used as a method for problem solving and to give some structure for the implemented improvements.
Guidelines from Banks simulation steps were utilized in the implementation phase of this study. Process data for availability, cykel time and MTTR were collected from existing FACTS and Plant Simulation models. After finishing the necessary data collecting a basic model which mimicked the real physical system was created. The new resource object was used to model the gantry systems och time for loading/unloading were added to the operational objects used for transportation.
When the basic model was completed a verification and validation phase were conducted and suitable values for simulation horizon and warm-up time was decided.
An Excel chart provided by the University of Skövde was used to calculate the number of replications needed for a credible experiment result. SCORE and KPI experiments were performed and the results was compared with existing models to detect any reasons for abnormalities. The results for the new FACTS model showed an almost similar value for TH but there were differences of approximately 10-15 % for LT and WIP. Analysis of SCORE results showed some differences in the primary bottlenecks but in general the most significant flow restrictions were located in the end part of the production flow. The total number of objects in the new FACTS model was 327 compared to 351 in the existing FACTS model. There were several factors that could have affected the end results of the experiments. Differences in used process data and the lack of process times for loading/unloading of products in existing FACTS model were all factors that made a correct system comparison and analysis more difficult to transact. Further studies need to be conducted to analys causes of the abnormalities between the different models regarding LT och WIP. The target of reducing the total number of objects in new FACTS model with 10 % was not achieved. Object numbers only decreased with 6,8 % but according to the authors a more simplified understanding of how the products flow in the manufacturing process was achieved.
v
FIKTIVA PRODUKTIONSSIFFROR
Verkliga värden och befintliga data har använts under examensarbetet. Efter sekretessönskemål från företaget har fiktiva siffror lagts till i rapporten.
vi
INNEHÅLLSFÖRTECKNING
ÄKTHETSINTYG ... i
FÖRORD ...ii
SAMMANFATTNING ... iii
ABSTRACT ... iv
FIKTIVA PRODUKTIONSSIFFROR ... v
INNEHÅLLSFÖRTECKNING ... vi
FIGURFÖRTECKING ... ix
TABELLFÖRTECKNING ... x
BEGREPPSFÖRKLARING ... xi
1. INTRODUKTION ... 1
1.1 INLEDNING ... 1
1.2 BAKGRUND ... 1
1.3 SYFTE ... 1
1.4 PROBLEMDEFINITION ... 2
1.5 MÅL ... 2
1.6 AVGRÄNSNINGAR OCH FÖRENKLINGAR ... 2
1.7 HÅLLBAR UTVECKLING... 2
2 TEORETISKT RAMVERK ... 3
2.1 SYSTEMSTUDIER OCH MODELLERING ... 3
2.2 SIMULERINGSVARIANTER ... 4
2.2.1 DISKRET HÄNDELSESTYRD SIMULERING ... 4
2.2.2 KONTINUERLIG SIMULERING ... 5
2.3 LÄMPLIGA TILLÄMPNINGSOMRÅDEN FÖR SIMULERING ... 6
2.4 OLÄMPLIGA TILLÄMPNINGSOMRÅDEN FÖR SIMULERING ... 6
2.5 KONCEPTUELL MODELLERING ... 6
2.6 MODELL VERIFIERING OCH VALIDERING ... 7
2.6.1 VERIFIERING AV MODELL ... 7
2.6.2 VALIDERING AV MODELL ... 8
2.7 STEADY STATE OCH REPLICATION ANALYS ... 8
2.8 FLASKHALSANALYS ... 9
2.9 FACTS ... 10
2.10 PLANT SIMULATION ... 10
2.11 SCORE ... 10
2.12 BANKS SIMULERINGSSTEG ... 11
3 METOD ... 14
3.1 METODIK OCH METODVAL ... 14
3.2 PROJEKTPLANERING ... 16
3.3 PROCESSKÄNNEDOM ... 16
vii
3.4 KONCEPTUELL MODELLERING ... 16
3.5 DATAINSAMLING ... 17
3.6 SKAPA BASMODELL FACTS ... 17
3.7 VERIFIERING OCH VALIDERING... 17
3.8 SIMULERINGSEXPERIMENT ... 17
3.9 RESULTATANALYS ... 17
3.10 PRESENTATION OCH ÖVERLÄMNING AV MODELL ... 17
4. NULÄGESBESKRIVNING ... 17
4.1 FYSISKT SYSTEM ... 17
4.2 PORTAL OCH TRANSPORTSYSTEM ... 18
4.3 SIMULERINGSMODELL FACTS ... 19
4.4 SIMULERINGSMODELL FACTS PORTALSYSTEM ... 21
4.5 SIMULERINGSMODELL PLANT SIMULATION ... 21
5. GENOMFÖRANDE ... 22
5.1 PROJEKTPLANERING ... 22
5.2 PROCESSKÄNNEDOM ... 22
5.3 KONCEPTUELL MODELLERING: ... 23
5.4 DATAINSAMLING ... 23
5.5 BYGGNATION BASMODELL FACTS 3.0 ... 23
5.6 MODELLERING PORTALSYSTEM FACTS 3.0 ... 24
5.6.1 PLACERING AV LADDA/LOSSATID I MODELL ... 26
5.7 VERIFIERING OCH VALIDERING... 26
5.8 STEADY STATE OCH SIMULERINGSHORISONT ... 26
5.9 ANTAL REPLIKATIONER FÖR TROVÄRDIGT RESULTAT ... 28
6. RESULTAT ... 28
6.1 RESULTAT SCORE ... 28
6.1.1 SCORE BEFINTLIG FACTS MODELL ... 28
6.1.2 SCORE NY FACTS MODELL ... 29
6.2 RESULTAT NYCKELTAL (KPI) ... 30
6.2.1 KPI BEFINTLIG FACTS MODELL ... 31
6.2.2 KPI PLANT SIMULATION MODELL ... 31
6.2.3 KPI NY FACTS MODELL ... 31
6.3 RESULTAT ANTAL OBJEKT ... 32
7. DISKUSSION ... 33
7.1 FORTSATT ARBETE ... 34
7.1.1 SKILLNADER I RESULTAT FÖR NYCKELTAL LT OCH WIP ... 34
7.1.2 GENOMFÖRA SIMULERINGSEXPERIMENT FÖR VARIANT Y ... 34
viii
7.1.3 SCORE JÄMFÖRELSE MED PLANT SIMULATION MODELL ... 34
7.1.4 ANPASSA NY FACTS MODELL EFTER UTVALD BEFINTLIG MODELL ... 34
8. SLUTSATS ... 35
9. REFERENSER ... 35
10. BILAGOR ... 38
BILAGA 1. GANTT SCHEMA FÖR PROJEKT ... 38
BILAGA 2. FUNKTIONSBESKRIVNING ... 39
BILAGA 3. REPLIKATIONSANALYS ... 41
ix
FIGURFÖRTECKING
Figur 1. Alternativ vid systemstudier och experiment. Egen tolkning från (Banks, et al., 2005) ... Fel!
Bokmärket är inte definierat.
Figur 2. Diskret händelsestyrt system, egen tolkning från (Banks, et al., 2005) .. Fel! Bokmärket är inte definierat.
Figur 3. Kontinuerligt system, egen tolkning från (Banks, et al., 2005) ... Fel! Bokmärket är inte definierat.
Figur 4. Steady state graf för total WIP ... Fel! Bokmärket är inte definierat.
Figur 5. Stegmetodik vid simuleringsstudie, egen tolkning från Banks, et al., (2005) . Fel! Bokmärket är inte definierat.
Figur 6. PDCA-cykeln, fritt tolkad av Isabelle Hovbjer & Rickard Dahlin. ... Fel! Bokmärket är inte definierat.
Figur 7. Projektkarta med PDCA och Banks simuleringssteg ... Fel! Bokmärket är inte definierat.
Figur 8. Övergripande bild på hela bearbetningsflödet... Fel! Bokmärket är inte definierat.
Figur 9. Egen illustration av de tre olika transportsekvenserna. ... 19 Figur 10. Exempel från modell av innesluten process med flera delmoment. ... Fel! Bokmärket är inte definierat.
Figur 11. Fleroperationsmaskin OP268_1 modellerad med buffertobjekt. ... Fel! Bokmärket är inte definierat.
Figur 12. Exempel modellerat portalsystem OP_20 ... Fel! Bokmärket är inte definierat.
Figur 13. Utvald del från Plant Simulation modell... Fel! Bokmärket är inte definierat.2 Figur 14. Transportavstånd för åkvagn som servar flera maskiner. .. Fel! Bokmärket är inte definierat.
Figur 15. Färdigställd simuleringsmodell i FACTS 3.0.3 ... Fel! Bokmärket är inte definierat.
Figur 16. Menybild från fliken Resource i öppnat resursobjekt. ... Fel! Bokmärket är inte definierat.
Figur 17. Menybild från fliken Resource i öppnat operationsobjekt. Fel! Bokmärket är inte definierat.7 Figur 18. Färdig-modellerat portalsystem OP_50_70 ... Fel! Bokmärket är inte definierat.
Figur 19. Kurva som visar medelvärdet för TH per timma. ... Fel! Bokmärket är inte definierat.
Figur 20. Kurva som visar medelvärdet för Total WIP. ... Fel! Bokmärket är inte definierat.
Figur 21. Plotter-diagram från SCORE för TH (maxTP) och förbättringar (minimp). .... Fel! Bokmärket är inte definierat.
Figur 22. Diagram från SCORE vilket visar flaskhalsoperationer. ... Fel! Bokmärket är inte definierat.
Figur 23. Plotter-diagram från SCORE för TH (maxTP) och förbättringar (minimp). .... Fel! Bokmärket är inte definierat.3
Figur 24. Diagram från SCORE vilket visar flaskhalsoperationer. ... Fel! Bokmärket är inte definierat.
x
TABELLFÖRTECKNING
Tabell 1. Antal objekt av respektive variant och totalt antal objekt Fel! Bokmärket är inte definierat.0 Tabell 2. Medelvärde/standardavvikelse för TH, LT och WIP i befintlig FACTS modell. .. Fel! Bokmärket är inte definierat.
Tabell 3. Medelvärde/standardavvikelse för TH, LT och WIP i PLANT SIMULATION modell. ... Fel!
Bokmärket är inte definierat.
Tabell 4. Medelvärde/standardavvikelse för TH, LT och WIP i ny FACTS modell (singlepart). ... Fel!
Bokmärket är inte definierat.
Tabell 5. Medelvärde/standardavvikelse för TH, LT och WIP i ny FACTS modell (doublepart). ... Fel!
Bokmärket är inte definierat.
Tabell 6. Antal objekt i ny FACTS modell (doublepart). ... Fel! Bokmärket är inte definierat.
xi
BEGREPPSFÖRKLARING
Skills: Färdigheten för vald funktion i meny för resursobjekt
IRC: Interactive Run Controller, hjälpmedel för att hitta fel i logiken och avlusa modellen
Tertiär flaskhals: Flaskhals i ett system som inte är primär eller sekundär utan kommer i tredje hand PIA: Produkter i arbete, antalet produkter som för tillfället finns i produktionsflödet
MDT: Mean down Time, Medeltiden ett system inte är operationellt Portalsystem: Transportsystem för produkter mellan operationer
1
1. INTRODUKTION
I detta kapitel förklaras examensarbetets syfte, mål, bakgrund samt vilka avgränsningar som uppgiften omfattar. Kapitel 1.7 innehåller fakta och reflektioner kring hållbar utveckling.
1.1 INLEDNING
För att upprätthålla sin konkurrenskraft och få en effektiv produktion måste företag idag jobba hårt med att effektivisera sina processer och utveckla nya metoder.
Begränsningar som påverkar flödets kapacitet behöver också arbetas bort. Att identifiera och lokalisera dessa hinder kan vara en svår sak (Bernedixen, et al., 2015).
Nutida produktionssystem är ofta stora och mycket komplexa, när ett sådant system inte fungerar optimalt är det svårt att hitta rotorsak till dålig prestanda. Ett kostnadseffektivt sätt att genomföra experiment på komplexa system kan vara att använda flödesbaserad simulering. Modellering kan utföras på redan existerande system eller för att testa framtida system. (Law 2007).
Enligt Banks (2005) är definitionen av en simulering en efterhärmning av beteendet för en fysisk process eller ett fysiskt system över tid. Simuleringar kan genomföras med hjälp av datorer eller för hand där en artificiell beskrivning och historik över systemet eller processen skapas. Denna artificiella historik studeras sedan under experiment för att finna slutsatser som kan härledas till det utvalda verkliga systemets driftsegenskaper (Banks, 1998). Simulering kan användas som problemlösningsmetod för många fysiska problem och anses av Banks (1998) vara oumbärligt.
Per definition kan ett system anses vara en samling enheter eller objekt, exempelvis maskiner eller operatörer som interagerar tillsammans mot ett gemensamt mål.
Studier kan genomföras på ett komplett system, exempelvis en hel produktionsfabrik eller på utvalda delar av fabriken som en specifik produktionslina. (Law, 2007)
1.2 BAKGRUND
Studien genomfördes på en tillverkningsindustri. Produktionen innehåller avsnitt för grov- och finbearbetning samt inkluderar områden för invändig och utvändig montering, materialhantering och diverse supportavdelningar. Organisationen innefattar bland annat produktionstekniker, beredare och simuleringsingenjörer.
funktionalitet. Företaget har en ambition att vara ledande kring användandet av simuleringsmjukvaran FACTS vid flödesexperiment och optimeringar. I föregående utgåva av FACTS fanns ett antal systembegränsningar för effektiv modellering av portalsystem, transportsystem eller manuella operationer. Vid portalsystemsmodellering krävdes en stor kvantitet av objekt för att uppnå rätt funktionalitet. En uppdaterad utgåva FACTS 3.0 har nu introducerats och företaget önskar utvärdera och jämföra den nya funktionaliteten med redan befintlig modell från tidigare utgåva av FACTS och en mer detaljerad Plant Simulation modell.
1.3 SYFTE
Det huvudsakliga syftet är att bygga en simuleringsmodell innefattande resursobjektet över ett utvalt bearbetningsflöde. Vidare skall projektet utvärdera resursobjektets (Resources) funktionalitet för portalsystemsmodellering vid genomförande av simuleringsexperiment i mjukvaran FACTS 3.0. Resultat från simuleringsexperiment på nyckeltalen TH (Throughput), LT (Ledtid) och WIP (Work In Process) skall utvärderas och jämföras med redan existerande modeller.
2
Flaskhalsdetekteringen och optimering kommer att ske på processtid och tillgänglighet med hjälp av Simulation-based COnstraint REmoval (SCORE).
1.4 PROBLEMDEFINITION
Följande frågeställningar i studien har identifierats och kommer utredas under arbetets gång.
Uppnår modellen med resursobjektet likvärdiga resultat jämförbara med befintliga FACTS och Plant Simulation modeller.
Minskar antal objekt i modellen vid användande av resursobjekt (Resource).
1.5 MÅL
Följande mål definierades för studien.
Genomföra optimering på operationsobjekt (OP) med hjälp av SCORE.
Jämföra och utvärdera resultat för nyckeltalen TH, LT, WIP mot befintliga FACTS och Plant Simulation modeller.
Minska totala antalet objekt med 10 % jämfört med befintlig FACTS modell.
1.6 AVGRÄNSNINGAR OCH FÖRENKLINGAR
Studien kommer avgränsa sig till endast en del av ett bearbetningsflöde. Befintliga processtider från föregående modeller kommer användas och inga nya tidsstudier kommer utföras. Ingen intern eller extern materialhantering kommer inkluderas i simuleringsmodellen. Alla producerade produkter i flödet är kvalitetsriktigt tillverkade. Övriga avgränsningar och förenklingar som uppkommer under studiens gång kommer inkluderas i den konceptuella modellen och beskrivs utförligare i kap.5.3.
1.7 HÅLLBAR UTVECKLING
Att uppnå en hållbar utveckling kan tyckas vara en omöjlig uppgift. Vissa delar av världen lever i överflöd och förbrukar resurser i sådan utsträckning att ett sådant samhälle inte är hållbart i längden. Samtidigt som människor i andra delar av värden knappt har resurser för att de grundläggande behoven tillgodoses. Det krävs en anpassning och sparsamhet av resurser i hela världen. Samtidigt som de tillgängliga resurser som nu finns tillvaratas och vårdas för att uppnå en hållbar utveckling. För att utvecklingen i samhället ska övergå till att vara hållbart fordras att människor har förmåga att värdera frågor som rör användningen av naturresurser långsiktigt.
(Persson & Persson, 2015)
Det finns ingen lösning för hur arbetet med att uppnå en hållbar utveckling ska gå till.
Definitionen av hållbar utveckling fastslogs av Brundtlandkommissionen 1987 och lyder:
”En hållbar utveckling är en utveckling som tillfredsställer dagens behov utan att äventyra förutsättning för kommande generationers möjligheter att tillfredsställa sina behov”.
Ett steg i rätt riktning är att hela världen börjar praktisera kretsloppsprincipen. Vagga till vagga är ett tankesystem som utvecklats av Michael Brungart och William McDonough. Enligt detta tankesätt står naturen och dess processer som modell för den mänskliga konsumtionen. Material står för en cirkelformig ekonomi som blir till näring åt jorden eller industrin som aldrig förstörs utan återanvänds. (Brungart &
McDonough, 2002)
3 Hållbar utveckling rör tre olika dimensioner:
Social hållbarhet, behandlar strävan efter ett samhälle där grundläggande mänskliga rättigheter uppfylls.
Miljömässig hållbarhet, handlar om att hushålla med resurser långt in i framtiden.
Ekonomisk hållbarhet innebär att alla ska ha råd att tillgodose sina grundläggande behov i förhållande till jordens begränsade resurser. En ekonomisk tillväxt som inte medför ogynnsamma konsekvenser för den ekologiska eller sociala hållbarheten. (Persson & Persson, 2015)
Simuleringar har inom tillverkningsindustrin blivit ett allt vanligare verktyg.
Möjligheten att planera, utveckla och optimera befintliga eller framtida system utan att påverkan på miljö eller människa blir så stor, är en fördel med simuleringsmodeller. Att testa nya koncept kan vara både energi- och resurskrävande samt ta lång tid. Med en simulering sparas både på material och den energi det hade krävts vid uppbyggande och drift. Genom att analysera de resultat som erhålls vid simuleringsexperiment kan identifiering av flaskhalsar och överkapacitet ske. Detta leder till att maskiner inte står på tomgång, mindre omarbetningar, färre defekter och mindre transporter. (Banks, et al., 2005)
Enligt en artikel i SvD påverkar IT-sektorn miljön lika mycket som flygindustrin och det är elförbrukningen som är den stora boven. Datorer blir allt kraftfullare och drar mycket el. Mycket energi hade sparats om energisparfunktioner använts mer eller att utrustning stängs av när den inte nyttjas (Olsson, 2008). Men konsumenter måste även börja fundera på vad det är för energikälla som används. Grön el är producerad av förnybara energikällor som vattenkraft, vindkraft och solenergi. Positiva effekter av att använda dessa källor kan vara att utsläpp av växthusgaser från fossila bränslen minskar, mindre luftföroreningar och att användningen av begränsade resurser minskar. (Klimatrådgivningen, 2017)
”Den värld vi skapat, som resultat av vårt tänkande hittills, har problem som inte kan lösas genom att tänka på det sätt vi tänkte när vi åstadkom dem.” (Albert Einstein)
2 TEORETISKT RAMVERK
I detta kapitel kommer tillämplig teoretiskt ramverk att skildras, detta för att ge en ökad förståelse för vad simulering innebär. Diskret händelsestyrd simulering kommer skildras men även kontinuerligsimulering kommer beskrivas kortfattat. Det teoretiska ramverket innefattar även fakta om när simulering är tillämpningsbart eller inte. För att erhålla en tydlig struktur vid genomförandet av simuleringsprojektet beskrivs metodiken, Banks simuleringssteg.
2.1 SYSTEMSTUDIER OCH MODELLERING
System kategoriseras i diskreta och kontinuerliga, där diskreta innebär system vid vilka variabeltillstånden vid separata tidpunkter förändras omedelbart. Kontinuerliga innebär system där variabler förändras kontinuerligt i relation till tiden. Exempel på diskreta system kan vara banker, fabriker och snabbmatsrestauranger där antal kunder eller upptagna servitriser kan vara systemvariabler. Kontinuerliga system kan vara ett flygplans resa genom luften där position och hastighet är viktiga variabler som ändras kontinuerligt under tidens gång. (Law, 2007)
Ett antal variabler som fungerande maskiner, processtider, aktiva operatörer eller stopptid definieras för att beskriva systemets tillstånd vid en specifik tidpunkt. För att kunna studera hur beteendet hos ett system förändras över tid kan en
4
simuleringsmodell utvecklas. Det finns också andra alternativ vid systemstudier och experiment vilket figur 1 nedan visar.
Figur 1. Alternativ vid systemstudier och experiment.
Egen tolkning från (Banks, et al., 2005)
Experiment kan utföras på det verkliga systemet, vilket dock ofta leder till stor påverkan för processen eller kunden. Förslagsvis genomförs experiment med hjälp av en simuleringsmodell. (Law, 2007)
Modellen innefattar ett antal bestämda antaganden baserade på det fysiska systemets driftsegenskaper eller driftsantaganden. Förmodandena är gjorda för det framtida ännu icke existerande system som skall utvärderas (Banks, et al., 2005).
Antaganden i modellen uttrycks ofta i form av matematiska eller logiska förhållanden. I enklare modellkoncept kan exakt information kring systemets prestanda uppnås med enbart matematiska metoder som exempelvis sannolikhetsteorier eller algebraiska metoder. Detta benämns ofta som analytiska lösningar (Law, 2007). De flesta moderna fysiska system är dock väldigt komplexa vilket gör att lösningar med enbart matematiska metoder blir omöjliga. I de fall komplexa system skall studeras används numerisk databaserad simulering för att under en bestämd tid efterlikna systemets beteende. Den genererade datan som framkommer under simuleringstiden används sedan för att mäta systemets prestanda. (Banks, et al., 2005)
2.2 SIMULERINGSVARIANTER
En simulering är en efterliknelse av ett fysiskt system och dess beteende. Vid simuleringsexperiment kan en modell användas för att studera systemets förändringar över tid. Olika parametrar kan förändras, testas och utvärderas utan att skapa driftstörningar och påverka prestandan för det verkliga systemet (Banks, et al., 2005). Enligt Law (2007) finns det många olika varianter av simulering som kan användas exempelvis diskret händelsestyrd, komtinuerlig, Monte Carlo och kombinerad diskret-kontinuerlig. Val av lämplig variant baseras på komplexiteten hos systemet och problemet som skall lösas (Banks, et al., 2005).
2.2.1 DISKRET HÄNDELSESTYRD SIMULERING
Diskret händelsestyrd simulering har blivit ett väsentligt verktyg som används omfattande i det dagliga livet inom många olika områden där mjukvara nyttjas (Lee, Jia & Chen 2013; Zimmermann 2008). Exempel på områden som tillämpar denna simulering är tillverkning, transport, materialförsörjningskedjor, finanssystem och
5
hälsovårdssystem m.fl. (Lee, et al., 2013). Enligt Law (2007) kan diskret händelsestyrd simulering används när komplexa system skall modelleras och utvärderas. Utveckling och förändring över tid hos systemmodellen beskrivs med hjälp av diskreta tillstånd, styrda händelser och analyseras med numeriska metoder. Vidare menar Law (2007) att i en diskret händelsestyrd simulering förändras variablerna för systemets tillstånd enbart vid ett kvantifierbart antal tillfällen över tid. Förändringar av systemets befinnande sker ögonblickligen och triggas av styrda händelser under simuleringstiden. Händelser kan exempelvis vara att en detalj lagras eller lämnar en buffert, en kund kliver in i en affär, en inlagd patient skrivs ut från ett sjukhus.
Händelser påverkar ofta men inte alltid systemets tillstånd (Law, 2007). Vid de tidpunkter som förändringar av tillståndsvariabler och händelser inträffar loggas data av systemet. Systemet loggar data vid tidpunkten för när varje ny händelse inträffar men inte för tiden som passerar där emellan eftersom inga systemförändringar då sker (Banks, et al., 2005). Figur 2 illustrerar antal detaljer i en buffert och hur tillståndet förändras över tid i ett diskret system.
Figur 2: Diskret händelsestyrt system, egen tolkning från (Banks, et al., 2005)
2.2.2 KONTINUERLIG SIMULERING
I ett kontinuerligt system förändras tillståndsvariablerna kontinuerligt över tid. I modeller av kontinuerliga system används differentialekvationer för att visa förändringsförhållandet mellan tillståndsvariabler och tid. Ett välanvänt exempel inom litteraturen för att beskriva ett kontinuerligt system är den biologiska ”rovdjur- bytesdjur” (predator-prey) även kallad ”parasit-värd” (parasite-host) modellen (Law 2007, s.70–71). Denna modell beskriver förhållandet mellan populationen bytesdjur och rovdjur. Större mängd bytesdjur genererar en ökad population rovdjur, mindre mängd resulterar i en minskad population av rovdjur proportionerligt över tid. Andra exempel på kontinuerliga system kan vara hur vattennivån i en damm varierar över tid (Banks 2005, s.12). Kontinuerlig simulering är motsatsen till diskret simulering eftersom värden loggas över tid även när inga specifika händelser inträffar. Figur 3 visar exempel på förändringar i vattenmängd (tillståndsvariabel) i en swimmingpool över tid. Poolen fylls inledningsvis på vid uppstart till önskad volym. Under drift förändras mängden vatten p.g.a. avdunstning, läckage eller regnväder.
6
Figur 3: Kontinuerligt system, egen tolkning från (Banks, et al., 2005)
2.3 LÄMPLIGA TILLÄMPNINGSOMRÅDEN FÖR SIMULERING
Simulering kan anses vara ett lämpligt verktyg om något av följande kritierier uppfylls:
Simulering möjliggör att med hjälp av experiment analysera hela eller delar av ett komplext system. Mycket kunskap förvärvas genom att skapa en simuleringsmodell, under datainsamlingen kan frågor identifieras som leder till förbättringar vilket kan vara av värde för det fysiska systemet.
Genom att ändra olika indatavariabler och observera resultaten av utdata, kan värdefull kännedom erhållas av vilka variabler som är mer viktiga och hur dessa samverkar med varandra.
Under designfasen vid nya produktionssystem kan simulering förbereda för olika senarion.
Simuleringar möjliggör att personal kan utbildas utan att verksamheten påverkas, vilket medför mindre kostnader. (Banks, et al., 2005)
2.4 OLÄMPLIGA TILLÄMPNINGSOMRÅDEN FÖR SIMULERING
Följande exempel beskriver när inte simuleringar kan anses som lämpligt verktyg:
Simuleringar bör inte användas om problemet kan lösas genom matematiska formler.
När kostnaderna av en simulering överstiger förtjänsterna eller om det är enklare att genomföra experiment direkt på den fysiska verksamheten.
Simuleringar avråds att använda om inga tidsstudier eller data finns tillgänglig och bör undvikas om resurser eller tid saknas.
Vissa manuella utföranden är extremt komplexa att efterlikna och av den orsaken är inte simulering att föredra. (Banks, et al., 2005)
2.5 KONCEPTUELL MODELLERING
Det svåraste med att bygga upp simuleringsmodeller är att bestämma vad modellen ska bestå av. Konstruktören måste förstå det system som ska efterliknas för att kunna erhålla en lämplig simuleringsmodell. (Robinson, et al., 2008)
Konceptuell modellering är en teoretisk konstruktion av en simuleringsmodell som byggts upp ifrån ett verkligt system eller för att testa ett framtida system.
7
Det önskvärda när en modell ska byggas vore att konstruera modellen så detaljerad som möjligt för att få realistiska värden. Detta kan göras om den som bygger modellen har full förståelse för det verkliga systemet och en uppsjö av tid. Fast finns begränsad kunskap och lite tid är detta inte sannolikt. Därför är det av största vikt att redan på designstadiet bestämma vad som ska modelleras och vad som inte ska modelleras. Tankeskapelsen går ut på att hitta de nödvändigaste delarna för att kunna bygga en förenklad representation av det verkliga systemet i en simuleringsmodell. (Robinson, et al., 2008)
Konsten att erhålla en begreppsmässig modell är att finna korrekta förenklingar, det vill säga att bortse från det oväsentliga. Eftersom alla modeller är förenklingar av ett verkligt system, innefattar alla simuleringsmodeller abstrakt modellering. Även den mest komplexa och detaljerade simuleringen gör olika hypoteser om det verkliga systemet och väljer att bortse från vissa detaljer.
Det är viktigt att känna till målsättningarna, indata och utdata för att bygga den konceptuella modellen. Modellen är skapad för ett specifikt syfte och utan kunskap om syftet är det omöjligt att skapa en bra förenkling. (Robinson, et al., 2008) Robinson, Brooks, Kotiadis & Lee förklarar ytterligare antaganden och förenklingar i ett konferensblad från 2008: Antaganden görs endera när det finns osäkerheter eller övertygelser om hur det verkliga systemet ser ut. Förenklingar görs i modellen för att möjliggöra snabbare modellutveckling, för att modellen ska vara enklare att använda, och lättare att förstå. Antaganden är med andra ord en begränsning av vetskap eller teorier, medan förenklingar är en önskan om att skapa enkla modeller.
2.6 MODELL VERIFIERING OCH VALIDERING
Verifiering av en simuleringsmodell kan enligt Banks (1998) liknas vid en modelltransformering där en ny form för modellen antas som planerat med en tillfredställande noggrannhetsnivå. Verifieringsfasen säkerställer att modellen byggs på rätt sätt enligt beskrivningen för den konceptuella modellen (Law, 2007). I valideringsfasen säkerställs att modellen har rätt funktionalitet. Validering kan beskrivas som en process där modellen utvärderas i relation till studiens utvalda parametrar för att avgöra om den är en sanningsenlig representation av det fysiska systemet. Följande kan beskrivas som generella riktlinjer för valideringsprocessen:
Komplexiteten av ett system avgör svårighetsgraden för valideringsprocessen.
Att validera ett befintligt system är enklare jämfört med om processen skall utföras på ett framtida system som ännu inte existerar. (Law, 2007)
En absolut modellvalidering kan inte uppnås och är inte önskvärt.
Simuleringsmodellen av ett komplext system är oavsett spenderad tid för modellbyggnation alltid en uppskattning av det verkliga systemet. Att uppnå en hög tillförlitlighetsgrad är ofta kostnadskrävande och leder inte alltid till högre förståelse för systemet. (Law, 2007)
Varje gång en ny funktionalitet skall appliceras till simuleringsmodellen ska en ny valideringsprocess utföras. (Law, 2007)
2.6.1 VERIFIERING AV MODELL
Vid genomförande av verifieringsprocessen säkerställs att modellen är byggd på ett sätt som efterliknar det avbildade fysiska systemet. Är rätt antagande och förenklingar gjorda, används rätt data värden och parametrar och innehåller modellen önskad systemstruktur är vanliga frågeställningar vid verifiering. (Banks, et al., 2005)
8
Vid verifiering av en simuleringsmodell kan sunt förnuft användas och Banks, Carson, Nelson & Nicol (2005) och Law (2007) ger följande förslag på punkter som kan undersökas vid verifieringsprocessen av en simuleringsmodell.
Börja med att skapa en enklare basmodell som är mindre komplex.
Låt annan person med expertkunskap kring simuleringsmjukvara kontrollera modellen.
Testa olika inställningar för indata parametrar och kontrollera sedan att resultat på utgående dataparametrar är rimliga. Analys av utdata används för nya inställningsalternativ för indata (iterativ process).
Om animeringar vid modellsimulering används skall det säkerställas att dessa liknar det verkliga systemet.
Att hitta fel i logiken och avlusa modellen med hjälp av Interactive Run Controller (IRC).
Gör modellen självdokumenterande genom precisa variabeldefinitioner och systembeskrivningar.
2.6.2 VALIDERING AV MODELL
Validering används vid kalibrering av modellen där resultaten på utdata från utförda simuleringsexperiment utgör basen för analysen. Enligt Banks, Carson, Nelson & Nicol (2005) finns en trestegs-process som kan följas vid utförande av validering.
1. Bygga en modell med hög trovärdighet hos användaren Modellerarens mål är att bygga en modell som efterliknar det verkliga systemet och framstår som vettig enligt personer med hög systemkännedom (användare). Att involvera den framtida användaren i konstruktions- och valideringsarbete gör att trovärdigheten och förståelsen för modellen ökar.
2. Validera modellantaganden Validering av modellantaganden är viktig och användaren bör involveras i detta steg. Modellantagande delas vanligen in i två generella klasser vilka är strukturella- och dataantaganden. Strukturella innebär antaganden kring exempelvis flödets utformning eller antal operationer/stationer som inkluderats/exkluderats i modellen. Dataantaganden innefattar antaganden kring dataparametrar exempelvis buffertstorlekar, processtider, tillgänglighet, produkter i arbete eller genomloppstid.
3. Validering av ingående och utgående data Det slutgiltiga valideringssteget för en simuleringsmodell. I detta steg valideras processen för omvandling av ingående data till någon form av utgående prestandaresultat från simuleringsexperiment i modellen. Resultaten av utgående data från modellen bör jämföras med prestandaresultat från det fysiska systemet för att bedöma om de är rimliga. Olika värden för ingående data kan implementeras i modellen för att se hur de påverkar beteendet och resultatet vid simulering. För att höja trovärdigheten hos användaren bör datavalideringsprocessen fokusera på de huvudsakliga dataparametrar som användare/kunden efterfrågat.
2.7 STEADY STATE OCH REPLICATION ANALYS
En simulering är ett system som körs under mycket lång tid. Simuleringen startar på simuleringstid noll under inledande villkor som bestämts av analytikern och som sedan körs under en fördefinierad tidsperiod. (Law, 2007) En steady state analys innebär att ta reda på hur lång tid det tar för en simuleringsmodell att infinna sig i ett stabilt läge. Simuleringen delas upp i två faser, uppvärmningsfasen och stabilt läge fasen. Datainsamlingen startar inte för ens simuleringen passerat tiden för uppvärmningsfasen. Law (2007) framhåller att ett verkligt system inte har ett stabilt läge fas eftersom egenskaperna förändras över tid.
9
För att bestämma uppvärmningstiden finns olika metoder men den mest använda är Welch metod. Med Welch metod körs simuleringen med en lång simuleringshorisont och med fem till tio replikationer. Under simuleringen mäts utdata med varierande intervall, insamlade data sammanställs och utvärderas. Ett medel av de olika parametrarna plottas ut i en graf och när dessa börjar stabiliseras och kurvan planar ut har modellen uppnått ett stabilt läge. (Law, 2007) Exempel på en steady state graf för Total WIP visas i figur 4. Blå ringen i figuren symboliseras tidpunkten när grafens värde börjar plana ut.
Figur 4. Steady state graf för total WIP
En bra design av simulerings-replikationer möjliggör att den mest statistiska informationen erhålls för minsta beräkningskostnad. I första hand strävas efter att minimera antalet replikationer men ändå få tillförlitlig statistik. För att resultaten som simuleringsmodellen ger ska bli tillförlitliga behöver flera upprepningar genomföras. Men hur många replikationer som behöver genomföras beror på vilken konfidensnivå och felmarginal som önskas. (Law, 2007)
2.8 FLASKHALSANALYS
Företag idag måste ständigt arbeta med att erhålla en effektiv produktion för att upprätthålla sin konkurrenskraft. Det som vanligtvis begränsar kapaciteten är flaskhalsar, för att hitta och göra något åt dessa flaskhalsar krävs ofta stora insatser.
(Bernedixen, et al., 2015)
Flaskhalsar definieras av Roser, Masaru & Minoru (2002) som ett tillstånd i ett produktionssystem som har störst effekt på att sakta ned eller stoppa hela systemet, i ett ögonblick eller under en längre tid. För att förbättra produktionens genomströmning är det av intresse att finna dessa flaskhalsar. (Roser, et al., 2002) Ett produktionssystem definieras av Goldratt (1984) som en serie av processer, beroende av varandra, länkas samman till en kedja och som arbetar mot ett gemensamt mål. Den svagaste länken är det som begränsar systemet (Goldratt, 1984). Då vissa moment eller bearbetningar har högre cykeltid än processen innan och efter uppstår flaskhalsar. Om buffertar är begränsade eller inte finns alls behöver momenten med kortare cykeltid vänta. Produktionen bör inte ha en takt tid som understiger något moments cykeltid. (Bicheno, 2006)
10
Alla produktionssystem är begränsade av minst en flaskhals. Det kan vara ett dominerande hinder som kommer framstå som flaskhals merendels under en analys eller tillfälliga hinder som växlar under tid (Pehrsson, 2013). Ordspråket ” en kedja är inte starkare än dess svagaste länk” kan även användas som synonym till en produktionslina. Systemet kan jämföras med kedjan som inte är bättre än den svagaste punkten. Att lägga resurser på de maskiner som inte är problemet kommer inte förbättra systemet. Det är när prestandan ökar på den svagaste maskinen som hela produktionslinan blir mer effektiv. (Krajewski, et al., 2002)
En maskin kan bli en begränsning på grund av exempel ett maskinfel. Med anledning av det kan ett system därför under längre perioder inte bara ha en primär flaskhals utan även sekundära och tertiära flaskhalsar. Det vill säga maskiner som är tillfälliga flaskhalsar men i mindre utsträckning än den primära flaskhalsen. Tillfälliga eller kortvariga flaskhalsar är maskiner som hindrar systemets prestanda under en kort period. Långsiktiga flaskhalsar är maskiner som begränsar under lång tid och dominerar alla andra maskiner i systemet. (Thajudeen & Hidayath, 2016)
Är det bara en maskin som begränsar systemet är det enda flaskhalsen. Maskinen med den längsta aktiva perioden är en tillfällig flaskhals och två begränsningar som följer varandra betraktas som korta skiftande flaskhalsar. Resultaten från en skiftande flaskhalsanalys presenteras genom att mjukvaran anger den totala tiden i procent som maskinen varit en enda flaskhals och skiftande flaskhals. (Pehrsson, 2013)
2.9 FACTS
FACTS Analyzer är en mjukvara som används för simulering och optimering av produktionsflöden. Mjukvaran stödjer fabriksdesign vid ombyggnad av fabrikskoncept eller under konceptuell design fas. FACTS Analyzer ger även en allmän insikt och kunskap om tillverknings och produktionskontroll. (evoma, 2018) Fördelarna med att använda FACTS Analyzer jämfört med andra kommersiella simuleringsprodukter för produktionssystem är att det går snabbt att bygga modeller, ingen programmering krävs och verktygen är lätta att lära och använda.
Inbyggnadsfunktioner för att identifiera flaskhalsar och rekommendationer för vilka parametrar som bör förbättras sker automatiskt. FACTS Analyzer stödjer också flera objektiva optimeringar vilket medför att beslutsfattaren kan välja en lösning som passar bäst vid förbättringar av produktionssystemet. (Pehrsson, 2013) Processtid, tillgänglighet, MTTR, buffertkapacitet och tider för transportörer är minimum för indata i FACTS Analyzer. Mjukvaran har ett begränsat antal standardobjekt för DES detta för en enklare och snabbare modellering. Ett antal objekt som kontrollerar Pulskodsmodulering, PCM (Pulse-code modulation) finns också, dessa tillåter modellering av komplexare system utan att kunskap i programmering krävs. (Thour, 2014)
2.10 PLANT SIMULATION
Plant Simulation är en mjukvara som används vid byggande av simuleringsmodeller.
Med hjälp av denna mjukvara kan befintliga eller inte existerande produktionssystem analyseras, visualiseras och optimeras. Med detta verktyg kan mycket komplexa system konstrueras, vilket kräver stor kunskap hos konstruktören. (Bangsow, 2016)
2.11 SCORE
En metod som kan hjälpa tillverkande företag att identifiera sina produktionsbegränsningar kan vara att introducera SCORE. (Bernedixen, et al., 2015)
11
En flaskhalsanalys ger en anvisning om vilka arbetsstationer som kräver förbättringsinsatser. För att råda bot på några av problemen med flaskhalsdetektering utvecklades metoden SCORE. Dess huvudsakliga uppgift är att optimera systemets genomströmning och hitta de flaskhalsar som måste elimineras för att förbättra systemets prestanda. (Pehrsson, 2013) Med SCORE metoden är syftet att hitta den flaskhals som ger den bästa förbättringen för en produktionslina.
Genom att ändra vissa av systemets parametrar som exempelvis cykeltid, tillgänglighet och stilleståndstid (MDT: mean down time). Samtidigt som antalet av ändrade parametrar minimeras, maximeras genomströmningen av systemet.
Lösningar med det som kräver minst systemändringar och ger den mest fördelaktiga genomströmningsförbättringen kommer att detekteras. Den flaskhals som uppträder oftast som lösning är den som bör förbättras först. (Pehrsson, 2013) Flaskhalsarna kan hittas genom att observera optimeringsresultaten, den med högst frekvens är sannolikt det som begränsar systemet mest. Den parametern med den näst högsta frekvensen är troligtvis sekundär och följaktligen kan flera flaskhalsar i systemet detekteras och rangordnas. Det är också möjligt att använda andra nyckeltal såsom ledtid och PIA (produkter i arbete). Eftersom olika typer av hinder ingår i optimeringen, kommer det att vara möjligt att inte bara upptäcka var förbättringar ska ske, utan också vilken typ av förbättring som krävs för att förbättra prestandan för hela systemet. (Pehrsson, 2013)
2.12 BANKS SIMULERINGSSTEG
För att få en tydlig struktur vid genomförandet av ett simuleringsprojekt kan en
”steg-för-steg” metodik användas. Banks, Carson, Nelson & Nicol (2005) ger riktlinjer för en steg-metodik som delar upp det övergripande arbetet i mindre beståndsdelar.
Detta gör projektet mer lättöverskådligt, enklare att planera och följa upp. Vidare anser författarna att denna stegmetodik vägleder vid simuleringsstudier på ett grundligt och sunt sätt. Figur 5 illustrerar dessa riktlinjer enligt Banks, Carson, Nelson
& Nicol (2005).
12
Problemformulering
Sätta mål och övergripande projektplan.
Konceptuell
modellering Datainsamling
Modell översättning
Verifiering
Validering
Utforma experiment
Simuleringskörning och analys
Fler simuleringskörningar
Implementation Nej
Ja Nej
Nej
Ja
Ja Ja
Nej
Dokumentation
Figur 5: Stegmetodik vid simuleringsstudie, egen tolkning från Banks, et al., (2005) Riktlinjerna delas in i olika steg vilka beskrivs nedan.
1. Problemformulering. En problemformulering bör vara det inledande steget i ett simuleringsprojekt. Denna behöver vara väl formulerad och tydligt beskriva problemet för att undvika missförstånd under projektets gång. Gemensam
13
förståelse och samtycke för problemformuleringen är särskilt viktig i de fall formuleringen skapats av modellbyggaren och inte tillhandahållits av problemägaren. Under projektets gång kan problemformuleringen behöva justeras och skrivas om vilket inte visas i figur 4.
2. Sätta mål och övergripande projektplan Baserat på problembeskrivningen formuleras de frågeställningar och mål som skall besvaras under simuleringsstudien vilket i sin tur styr metodvalet för problemlösningen. Beslut tas gällande om simulering är det bäst lämpade verktyget för detta problem eller om det kan lösas med någon annan metod eller verktyg. En övergripande projektplan skapas sedan i de fall simulering framkommit som bästa metodval.
Projektplanen bör inkludera ett antal parametrar:
Redogörelse för alternativa system att betrakta.
Metodbeskrivning för effektivitetsmätning av dessa alternativa system.
Antal involverade personer i projektet.
Studiens kostnad.
Antal dagar som krävs för att färdigställa respektive steg i studien.
3. Konceptuell modellering Kan definieras som en utförligt detaljerad beskrivning av hur ett system fungerar och är organiserat (Lunds Tekniska Högskola, 2013).
Inom konceptuell modellering finns det ett antal riktlinjer som kan följas för att uppnå en framgångsrik modellbyggnation. Att starta med byggnation av en enkel grundmodell som innehåller enbart de väsentligaste karaktärsdragen från systemet är att föredra. Denna modell kan sedan utvecklas och göras mer komplex beroende på behov och problemets natur. Att göra modellen mer komplex än vad som krävs för att uppfylla studiens syfte leder enbart till extra kostnader för projektet. Modellen behöver inte ha alla objekt från det verkliga systemet modellerade (ett till ett förhållande) utan övergripande karaktärsdrag räcker ofta vid studier. Att involvera modellanvändaren i konceptskede ger också högre tillförlitlighet och bättre kvalité på den slutgiltiga modellen.
4. Datainsamling En stor del av den använda tiden i ett simuleringsprojekt går åt till datainsamling där information kring olika modellparametrar inhämtas. Vilken data som behöver samlas in dikteras av projektets frågeställningar och målsättningar. Väntetider, servicetider och processtider är vanliga exempel på data som används vid simuleringsstudier. Datahistorik kan också användas för att validera simuleringsmodellen i ett senare skede.
5. Modell översättning Många moderna system är ofta komplexa vilket kräver en mängd beräkningar och lagringsutrymme vid modellering. För att kunna ta hjälp av datorisering vid modelleringsprocessen krävs att modellen översätts till ett läsbart format för datorn. Översättningen kallas ofta för programmering där programmet innehåller logisk kod för styrning av modellens beteende. Inom modellering av tillverknings, eller materialhanteringsflöden används ofta simuleringsmjukvara som är särskilt anpassat för dessa behov men andra typer av simuleringsspråk förekommer också.
6. Verifiering När modellens program förberetts behöver en verifiering verkställas.
Verifieringen säkerställer att modellen uppfyller rätt funktionalitet och efterliknar beskrivningen för den konceptuella modellen på ett önskvärt sätt.
Program och kod genomgår en avlusningsprocess (debugging) där eventuella fel i logiken upptäcks och åtgärdas. I komplexa modeller krävs ofta en lång och tidskrävande avlusningsprocess vilket gör att en uppdelning av modellen i mindre bitar kan rekommenderas.
7. Validering Detta är en upprepande process (iterativ) där modellens beteende jämförs och kalibreras mot det verkliga systemet. Eventuella avvikelser som
14
upptäcks mellan modell och fysiskt system analyseras och används för att ytterligare förbättra modellen tills en önskvärd noggrannhet erhållits. Validering anses av Banks (2005) vara den mest kritiska fasen i stegprocessen eftersom felaktig validering kan leda till implementering av kostsamma eller farliga lösningar.
8. Utforma experiment Vid utformning av simuleringsexperiment bestäms de ingående parametrar som ska följas upp under körningen. Längden på simuleringens uppvärmningstid och antal använda replikationer bestäms också i detta läge. Efter analys av genomfört experiment kan en justering av ingående parametrar i experimentutformningen behöva göras innan nya körningar utförs.
9. Simuleringskörning och analys Simuleringskörning genomförs med bestämd modellkonfiguration och resultatet analyseras. Resultatet från körningen ger en uppfattning om nuvarande konfigurations prestanda.
10. Fler simuleringskörningar Efter att ett bestämt antal simuleringar genomförts analyseras modellresultaten för att klarlägga om tillförlitligheten och standardavvikelser är på en tillfredställande nivå. Bedöms resultaten inte vara tillförlitliga behövs fler simuleringar genomföras och en experimentdesign för dessa utformas.
11. Dokumentation och rapportering Att skapa en tydlig dokumentation är en viktig del i ett simuleringsprojekt av flera olika anledningar. Om programmet ska återanvändas i framtiden behöver dokumentation finnas för att förstå programstruktur och funktionalitet. Dokumentation effektiviserar också tidsförloppet vid modifiering av programmet och skapar förståelse för relationen mellan ingående och utgående dataparametrar. Frekvent rapportering under projektets gång minimerar risken för feltolkningar och missförstånd kan upptäckas och korrigeras i ett tidigt stadie. Rapportering ökar också chanserna för ett lyckat slutfört projekt och gör det enklare att följa projektets tidsfrister.
12. Implementation Är det slutgiltiga steget i ett simuleringsprojekt. Hur framgångsrik implementationsfasen för systemet blir baseras på hur grundligt och lyckosamt de föregående stegen genomförts. En grundligt genomförd studie med korrekt data och en god kommunikation med modellanvändaren under projektets lopp skapar goda förutsättningar för en lyckad implementation.
3 METOD
Detta kapitel inkluderar strukturen, planeringen och utvald metod som använts vid projektstudien och modelleringsfasen. Datainsamlingstekniker som använts i studien kommer att presenteras.
3.1 METODIK OCH METODVAL
Som övergripande metodikval för denna studie/projekt har Banks simuleringssteg valts som lämpliga riktlinjer. Studiens generella planering, genomförande och struktur kommer till viss del kunna härledas till dessa riktlinjer.
Problemlösningsmetod som valts i detta projekt är PDCA, som är en problemlösningsmetod för att driva och strukturera förbättringsarbete. Metoden delas in i fyra faser och är en engelsk förkortning av plan, do, check och act som på svenska kan översättas till att planera, genomföra, kontrollera och agera. Varje fas har sina metoder och verktyg som projektgrupper kan använda för ett effektivt förbättringsarbete. (Bicheno, et al., 2011) PDCA cykeln illustreras i figur 6.
15
Figur 6: PDCA-cykeln, fritt tolkad av Isabelle Hovbjer & Rickard Dahlin.
1. Planera (PLAN)
I planeringsfasen identifieras viktiga parametrar, fakta samlas in, analyser kring vad som kan vara problemet utförs och sedan föreslås en eller flera lösningar.
2. Genomföra (DO)
I fas två fattas beslut och sedan genomför den bästa lösningen, här samlas även mätvärden in.
3. Kontrollera (CHECK)
Under denna fas samlas data in och utvärderas. Analyser om förändringen var en förbättring görs och om lösningen är tillfredsställande fortskrid till agerafasen, om inte åter till planeringsstadiet. Följ upp och föreslå åtgärder så att lösningen har förutsättningar för att bli varaktig.
4. Agera (ACT)
I agerafasen implementeras och standardiseras lösningen och förändringen införs som en ny standard. För att processer ständigt ska förbättringars krävs det att nya problem identifieras.
Figur 7 visar en projektkarta över de fyra stegen i PDCA cykeln och hur studiens planering- och genomförandefaser enligt Banks riktlinjer är kopplade till dessa. Det inledande steget i en studie är en problemdefinition vilken inkluderas i projektkartan men kommer inte beskrivas eftersom den redan finns formulerad i kap.1.4.
16
Figur 7: Projektkarta med PDCA och Banks simuleringssteg
3.2 PROJEKTPLANERING
Inledningsvis ska en planering göras för att skapa förståelse för projektets omfattning och komplexitet. Ett Gantt schema har skapats där relevanta milstolpar placeras in och specifika slutdatum planeras. Gantt schemat finns bifogat i bilaga 1. Projektets övergripande mål presenteras i kap. 1.5.
3.3 PROCESSKÄNNEDOM
För att få en ökad processkännedom ska studiebesök ske på företaget där specifikt bearbetningsflöde studeras. Kritiska moment i processen ska fotograferas och filmas för att frambringa en ökad kunskap kring flödet och underlätta vid konstruerandet av simuleringsmodellen. Befintligt Plant Simulation och FACTS modell ska erhållas för att understödja projektstudien.
3.4 KONCEPTUELL MODELLERING
För att bestämma omfattningen av studien och komplexitet hos modellen kommer en konceptuell eller begreppsmässig beskrivning att utföras. Den konceptuella modellen kommer inkludera avgränsningar, förenklingar och de antaganden som kommer göras gällande modellstruktur, data eller beteende.
17
3.5 DATAINSAMLING
Datainsamling från befintligt FACTS och Plant simulation modell kommer genomföras och relevant data för studien kommer återanvändas i ny modell.
3.6 SKAPA BASMODELL FACTS
En basmodell kommer att byggas i FACTS 3.0 som får bli grunden för de simuleringsexperiment som sedan ska genomföras. Det nya resursobjektet (Resources) skall användas för att återskapa portalsystemens funktionalitet i modellen.
3.7 VERIFIERING OCH VALIDERING
För att kontrollera att modellen uppfyller ställda krav byggs delar av modellen ihop för att testköras och analyseras innan de sätts samman till det hela systemet. För att säkerställa att modellen fullgör behoven kommer validering ske med handledare.
3.8 SIMULERINGSEXPERIMENT
Simuleringsexperiment ska designas och experiment planeras genomföras med hjälp av SCORE, där nyckeltalen tillgänglighet och cykeltider kommer vara fokusområde
3.9 RESULTATANALYS
Resultaten av de simuleringsexperiment som genomförts kommer att jämföras med resultat från äldre utgåva av FACTS och resultat från Plant Simulation som kommer erhållas från handledare på företaget.
3.10 PRESENTATION OCH ÖVERLÄMNING AV MODELL
Den slutgiltiga modellen med resultat kommer presenteras på ett simuleringsforum hos företaget.
4. NULÄGESBESKRIVNING
Nulägesbeskrivning redogör kortfattat för hur det befintliga fysiska systemet ser ut som helhet och hur produkttransporter genomförs med hjälp av portalsystem (Gantry robotar). En beskrivning av befintlig FACTS modell med portalsystemsmodellering och Plant Simulation ges också i detta stycke.
4.1 FYSISKT SYSTEM
Det fysiska systemet som skall efterliknas i simuleringsmodellen är ett bearbetningsflöde med mestadels avverkande bearbetning. För närvarande i flödet bearbetas fyra olika produktvarianter. Bearbetningsflödet är uppdelat i tre olika huvudavsnitt en grov-, fin- och slutdel och flödet startar vid operation (OP) 10 och slutar vid färdigvarulagret efter OP 335. I grovdelen bearbetas kärnämnet grovt och där utförs det mesta av den avverkande bearbetningen. Området grovdel inkluderar alla operationer från OP 10 till OP 90. Findelen innefattar operationer från OP180 till OP 165 lager och slutdelen operationer mellan OP 267 till Färdiglager.
Bearbetningsflödet innehåller också operationer där Statistical Process Control (SPC) eller på svenska Statistisk Process Kontroll (SPS) utförs för att upptäcka avvikelser hos produkten och/eller processen. SPC operationer finns både i utförande som inbyggda automatiska i maskinen och manuellt utförda av operatörer. En mer utförlig funktionsbeskrivning på respektive operation visas i bilaga 2.
18
Fleroperationsmaskiner som beskrivs i bilagan utför flera olika funktioner i samma maskin, exempelvis: borrning, fräsning och gängning. Figur 8 visar en övergripande bild av det totala bearbetningsflödet inkluderat alla delar. Blå prick visar starten av bearbetningsflödet och gul prick visar var flödet slutar. Streckade linjer har också lagts till för att enklare förstå hur produkten förflyttas i flödet
Figur 8: Övergripande bild på hela bearbetningsflödet.
4.2 PORTAL OCH TRANSPORTSYSTEM
För att transportera produkter (block/mellandel) mellan olika operationer används takhängda eller markbundna transportbandssystem (conveyor), portalsystem med Gantry robotar och på vissa ställen ledade robotar. Portalsystemen ombesörjer för transporter i flödet. Portalsystem har en eller flera åkvagnar som rör sig längst styrskenan och styrs av elektriska signaler från styrenheter även kallade PLC (Programmable Logic Controller). Hur transporterna utförs skiljer sig åt mellan olika portalsystem. Det finns tre olika varianter av transportsekvenser programmerade för flödets portalsystem. De flesta åkvagnar i flödet har dubbla platser för att lasta/lossa block eller mellandel. Dessa används till att förflytta produkter två och två mellan maskiner eller att lasta/lossa en produkt åt gången.
Texten nedan beskriver de olika transportsekvenserna och Figur 9 illustrerar de tre olika sekvensernas rörelsemönster. De horisontella streckade blå pilarna symboliserar åkvagnens rörelsemönster längst styrskenan. De vertikala blå pilarna symboliserar rörelsen för ladda/lossa processen.
Transportsekvens 1. I denna cykel utgår åkvagnen ifrån sin utgångsposition (pos.1) som ofta är nära positionerad till maskinen där produkten skall hämtas. När produkten är färdigbearbetad i maskin 1 transporterar sig åkvagnen dit längst
19
styrskenan och intar lastaposition (Load) (pos.2). Produkten lastas på åkvagnen vertikalt ur maskinen och när lasta processen är genomförd transporterar sig åkvagnen till maskin 2 där den intar lossaposition (Unload) (pos.3). Produkten lossas från åkvagn vertikalt till maskin och vagnen återgår sedan till ursprungsposition (pos.1) i väntan på ny färdigbearbetad produkt från maskin 1.
Transportsekvens 2. Här utgår åkvagnen från sin ursprungsposition (pos.1). När en produkt är klar i maskin 1 transporterar sig åkvagnen för att lasta produkten (Load) (pos.2). Vagnen transporterar sedan produkten till maskin 2 där den lossas (Unload) (pos.3). Vagnen står kvar vid maskin 2 (pos.3) och lastar på en färdigbearbetad produkt (Load) som sedan transporterar och lossas (Unload) i maskin 3 (pos.4).
Därefter återgår åkvagnen till ursprungspositionen vid maskin 1 (pos.1).
Transportsekvens 3. Här utgår åkvagnen från sin ursprungsposition (pos.1). När en produkt begärt lastning från lastabuffertplatsen (pos.2) transporterar sig åkvagnen dit för att lasta produkten (Load). Vagnen transporterar sedan produkten till maskin 1 där den lossas (Unload) (pos.3). Vagnen står kvar vid maskin 1 (pos.3) och lastar på en färdigbearbetad produkt (Load) som sedan transporterar och lossas vid lossabuffertplats (pos.4). Därefter återgår åkvagnen till ursprungspositionen vid maskin 1 (pos.1).
Figur 9: Egen illustration av de tre olika transportsekvenserna.
Sekvens 3 används när lasta- och lossabuffertplatser ligger nära varandra geografiskt och när en åkvagn ska serva flera maskiner.
4.3 SIMULERINGSMODELL FACTS
Det finns två befintliga simuleringsmodeller över bearbetningsflödet som i nuläget huvudsakligen används. En modell är skapad i mjukvaran Plant Simulation och är mer komplex och detaljerad samtidigt som den andra är gjord i en äldre version av FACTS
20
och har lägre komplexitet. I denna studie kommer huvudfokus att ligga på jämförelser med befintlig FACTS modell gällande layout av flöde och antal objekt.
Plant Simulation modellen kommer att användas för datainsamling av tider för portaltransporter och jämförelser i SCORE resultat.
Befintlig FACTS modell startar på OP10 och slutar vid färdigvarulager efter OP335 precis som det fysiska systemet. Modellen inbegriper objekt för råvarupåfyllning (Source), bearbetningsoperationer, SPC operationer, buffertar, lager (Stores), portalsystem (Assembly, Disassembly & Source), montering (Assembly), demontering (Disassembly), taktstyrning och kundleverans (Sink).
Processer som inte inkluderas i modellen är materialpåfyllning med truck, justeringsstationer, läckagetester och maskinoperatörer.
Tabell 1 visar antalet OP-, SPC-, Buffert-, Assembly-, Disassembly-, Source-, Sink-, Store- och Takt objekt som finns i FACTS modellen och även det totala antalet objekt sammanlagt.
Tabell 1. Antal objekt av respektive variant och totalt antal objekt ANTAL OBJEKT PER SORT STYCKEN
Operationer 96
SPC operationer 19
Buffertar 151
Assembly 31
Disassembly 30
Source 14
Sink 1
Store 6
Takt 3
Totalt antal objekt: 351
Vid modellering av exempelvis kyltunnlar eller andra inneslutna operationer där många delprocesser innefattas har ett operationsobjekt använts för varje delmoment av processen vilket visas i figur 10. Ett taktobjekt styr takttiden för varje delprocess och tillgänglighetsgraden för processen som helhet har placerats i objektet OP272.
Figur 10: Exempel från modell av innesluten process med flera delmoment.
Buffertobjekt har använts för att modellera produkttransporter på takhängda- eller golvbundna transportband och även för fleroperationsmaskiner har detta objekt använts för att visa de olika delprocesserna inne i maskinen. Exempel på modellering av fleroperationsmaskin med hjälp av buffertobjekt visas i Figur 11. De tre buffertobjekten på bilden motsvarar tre olika positioner inne i maskinen på OP268_1.
