OPTIMERING AV RÖRVERKSPLANERING

Transkript

1 Examensarbete 20 poäng D-nivå OPTIMERING AV RÖRVERKSPLANERING Reg.kod: Oru-Te-EXA089-D102/06 Anders From och Tomas Marcusson Magisterprogrammet Datateknik 160 p Örebro vårterminen 2006 Handledare: Lars Karlsson Examinator: Silvia Coradeschi TUBE MILL PLANNING OPTIMIZATION Örebro universitet Örebro University Institutionen för teknik Department of technology Örebro SE Örebro, Sweden

2 Sammanfattning Denna rapport beskriver framtagningen av ett program för automatisk rörverksplanering. Arbetet är förlagt hos företaget OVAKO i Hofors, rörverk fyra och fem. Målet med arbetet var att ta fram en optimeringsmodell för rörverksplaneringen och sedan bygga programmet på modellen. Arbetet görs sedan tidigare mestadels manuellt av erfaren personal med hjälp av ett program som bygger på tidigare tidsstudier. Dessa användes delvis som grund för utvecklingen av modellen. Abstract This report describes the development of a program for automatic tube mill planning. The work has been done at the corporation OVAKO in Hofors, tube mill four and five. The goal of the project was to develop an optimization model for the tube mill planning and then build the program based on the model. Earlier the planning has been done primarily manually by experienced personnel with the aid of a program that was built on earlier time studies. These were partially used as a base for the development of the model. 2(52)

3 Förord Denna rapport är resultatet av ett examensarbete vilket omfattar 20 poäng på Magisterprogrammet i Datateknik vid Örebro Universitet. Arbetet utfördes vid företaget OVAKO i Hofors under våren Vi vill i och med detta tacka Rolf Marcusson för upplägg och hjälp under arbetets gång. Lars Karlsson för hjälp och assistans angående optimeringsmodellen. Rolf Persson, Mats Persson och Per Wickström för assistans och vägledning samt hjälp med tidsstudier och identifiering av parametrar. Ralf Petterson för hjälp att installera oss i bostäderna på Hammarvägen. Vi vill även passa på att tacka OVAKO för hjälp med logi och merkostnader. Slutligen vill vi tacka alla som har visat intresse för vårt examensarbete på något sätt, ingen nämnd ingen glömd. Örebro Anders From Tomas Marcusson 3(52)

4 Innehåll 1 Inledning Kapitelöversikt OVAKO Problem Översikt Projektbeskrivning Etapper Mål Krav på utformningen av systemet Beskrivning Befintliga funktioner Funktioner som ska utvecklas kravlista Tekniker Programmeringsspråket C# Microsoft Access NET-plattformen Studium av det befintliga systemet för rörverkssortering Uppbyggnad Movex ORDA RVP RVP Gränssnitt Tidsstudier Framtagning av prototyp Den teoretiska optimeringsmodellen Introduktion till optimeringslära Tillämpningsområden Optimeringsprocessen Matematisk formulering och problemklassificering Optimeringsmetoder Heuristiska metoder Trädsökningar Egenskaper hos lösningar Det nya systemet Arbetet inleds Problemdefinition Tidsstudier Prototypen färdigställs Valet av optimeringsalgoritm Tester Rörverk 5 införlivas i programmet Förslag till förbättringar Utvärdering Terminologi Referenser Bilaga 1 Manual Optimex (52)

5 1 Inledning 1.1 Kapitelöversikt Kapitel 1: Inledning ger en kort beskrivning av rörverket och vad som görs där. Kapitel 2: Projektbeskrivning ger en beskrivning av projektet. Vilka uppgifter som skulle lösas och de olika etapperna som projektet delades in i. Det ger också en översikt om mål och krav på det nya systemet. Kapitel 3: Tekniker beskriver de tekniker som projektet lutar sig på samt en kort beskrivning av dessa. Kapitel 4: Studium av det befintliga systemet för rörverkssortering beskriver det gamla systemet översiktligt och berättar lite om vad styrkorna och svagheterna är med detta. Kapitel 5: Tidsstudier berättar om hur tidssättningen av de olika momenten gick till. Kapitel 6: Framtagning av prototyp beskriver hur prototypen togs fram och hur den hjälpte projektet på vägen. Kapitel 7: Den teoretiska optimeringsmodellen beskriver den modell som togs fram och som det färdiga systemet bygger på. Kapitel 8: Det nya systemet beskriver det färdiga programmet och hur det kan användas. Det behandlar även en del om olika optimeringsmetoder som av vissa skäl inte kunde användas. Dessutom innehåller kapitlet en del pseudokod och en beskrivning av hur optimeringen implementerats. Kapitel 9: Förslag till förbättringar innehåller som namnet antyder en del förslag till förbättringar. Kapitel 10: Utvärdering innehåller en text som talar om hur mycket av de i förväg uppsatta målen som har uppnåtts och lite om svårigheter under genomförandet av projektet. Kapitel 11: Terminologi beskriver en mängd ord och fraser som kan vara okända för läsaren. Kapitel 12: Referenser innehåller en komplett lista med referenser. 5(52)

6 1.2 OVAKO OVAKO bildades genom en sammanslagning av Ovako Steel AB, Imatra Steel Oy Ab, Fundia Special Bar AB och Fundia Bar & Wire Processing AB och går numera under namnet Oy Ovako ab. OVAKO är en ledande Europeisk producent av långa specialstålprodukter för kullagerindustrin, tunga fordon och automatiseringsindustrin. Produktionen består av lättmetall och kolstål i former av stänger, rör, ringar och förkomponenter. Företaget har 16 produktionsenheter och flera säljföretag i Europa och USA. Nettoförsäljningen under 2004 uppgick till 1.3 Miljarder Euro. Ovako sysselsätter 4600 personer, och den totala stålproduktionen är 2 Miljoner ton. OVAKO i Hofors tillverkar långa ämnen, rör och ringar av stål varav en stor del vidarebearbetas till exempel ringar för kullagerindustrin. Fabriken har omkring 1400 anställda. Rörtillverkningen är en viktig del av OVAKOs verksamhet och de är också världsledande inom ringtillverkning. 1.3 Problem Varje vecka skapas en planeringslista för varje rörverk som anger ordningen för rörtillverkningen. Det finns många faktorer som påverkar denna ordning. Ett rörverk består sammanfattningsvis av en förvärmningsugn, ett hålverk, ett asselverk och ett reducerverk. Förvärmningsugnen värmer upp ämnet som består av en stång. Hålverket gör hål genom att trycka en plugg genom ämnet. Asselverket bestämmer tjockleken på rörets vägg och reducerverket bestämmer rörets ytterdiameter. För olika rör kan flera saker skilja sig, till exempel storlek på ämnet, temperatur och verktyg. I nuläget sorteras rörtyperna delvis maskinellt med hjälp av ett existerande program. Sorteringen blir inte optimal och därför sorteras körordningen om manuellt. Den manuella sorteringen görs idag av mycket erfaren personal och saknar dokumenterade regler. Det är tidsödande att lära upp ny personal att utföra denna sortering. 6(52)

7 1.4 Översikt Nedan visas en översiktlig skiss över hur flödet i rörverket fungerar. Figur 1: Skiss över flödet i ett rörverk. Walking beam furnace - Karusellugnen som hettar upp ämnena till rätt temperatur. Centering - Ett litet hål i centrum av ändarna på ämnet görs för att man ska träffa rätt i nästa steg, hålningen. Piercing Mill - Hålverket, här görs ett hål i ämnet så att det blir ett rör. Assel Mill - Asselverket, här valsas röret till rätt väggtjocklek, det vill säga tjockleken på väggen mellan rörets inner- och ytterdiameter. Sizing Mill - Reducervalsverket, här bestäms rörets ytterdiameter. Rotary sizer - Riktverket, här tillses att röret är runt och inte ovalt. Cooling bed - Svalbädden, här får ämnena ligga och kallna innan nästa steg. Detta är i stora drag vad som görs i rörverk 4 och 5. För rörverk 6 skiljer sig förfarandet något. Där går rören direkt till steget Inductive Intermediate Heating efter asselvalsningen och därefter till Stretch Reducing Mill. Detta rörverk behandlas inte i rapporten. För examensjobbet var det viktigt att bestämma tider för verktygsbyten mellan de olika stegen och skillnaden i uppvärmningstid mellan olika dimensioner och stålsorter. Det var även av vikt att känna till lite om hur tillverkningen gick till och därför tillbringades några timmar i verket ledsagad av handledare som förklarade de olika momenten. 7(52)

8 2 Projektbeskrivning Detta kapitel beskriver uppgiften som skulle lösas på OVAKO rörverk fyra och fem. 2.1 Etapper 1. Dokumentation Dokumentation av alla faktorer som påverkar den tid ett rörverk står stilla för byte av rörtyp. Dessutom ska dessa faktorer tidsättas genom tidsstudier och med hjälp av erfarenheter från OVAKOs personal. 2. Teoretisk modell En teoretisk modell skapas för hur dessa faktorer ska användas för att optimera ett givet antal rörtyper. 3. Prototyp En prototyp skapas som innehåller program för: A. Inmatning av de faktorer och tider som påvisades under punkt ett. B. Tar emot ett givet antal rörtyper med vardera ett specifikt tillverkningssätt avseende verktyg. C. Sorterar tillverkningen i optimal tillverkningsordning med minsta möjliga tid för produktionsstopp mellan rörtyper. D. Presenterar sorteringsordningen med alla rörtyper och använda verktyg i en planeringslista. 4. Utveckling av teoretisk modell Utveckla den teoretiska modellen för hur prototypen kan kompletteras för att ta emot rörtyper som kan ha flera alternativa tillverkningssätt med olika verktyg (i praktiken kan maximalt 10 olika tillverkningssätt per rörtyp bli aktuella). Sorteringsordningen ska dels välja optimal ordning mellan rörtyperna och för varje rörtyp välja det tillverkningssätt som ger minsta möjliga stopptider i rörtillverkningen. 5. Implementering av den teoretiska modellen Då den teoretiska modellen är klar ska ett nytt program göras som bygger på denna modell. 6. Testning av systemet Då den teoretiska modellen har implementerats ska programmet, dess användarvänlighet och funktionalitet testas av utvecklarna och ett antal användare. 8(52)

9 2.2 Mål Målet är att få en teoretiskt optimal rörverksplanering som kan användas istället för nuvarande delvis manuella system. Programmet som bygger på den teoretiska modellen bör kunna användas från de system som används av företaget. 2.3 Krav på utformningen av systemet Beskrivning Framtagningen av systemet och den teoretiska modellen bygger på tidsstudier gjorda på rörverk fyra och fem. Programmet ska utvecklas i Visual Studio i programspråket C# vilket kräver att.net Framework är installerat på systemen det ska köras på Befintliga funktioner Det nuvarande systemet består av ett program som gör en grov sortering av tillverkningsordningen av rörtyperna och därefter görs en manuell optimering. Systemet som används nu heter RVP och är skrivet i COBOL Funktioner som ska utvecklas kravlista Nedan följer en lista på de krav som systemet ska uppfylla. Användaren ska själv kunna ändra parametrar som påverkar sorteringen av rörtyperna. En manual till programmet ska finnas som beskriver vad användaren behöver göra för att köra programmet eller ändra parametrar. Alla tidsparametrar skall sparas till fil och läsas in när programmet startas. Körordern ska ligga i en access-databas och läsas in när programmet startas. Användaren ska själv kunna flytta på ordrar i databasen och sen ha möjlighet att kunna räkna ut ny ställtid. Vid beräkning av körorderordning skall den sorterade körordningen sparas till en access-databas. 9(52)

10 3 Tekniker Detta kapitel beskriver de tekniker som systemet bygger på, C#,.NET Framework och Microsoft Access. 3.1 Programmeringsspråket C# C# (uttalas C-sharp) är ett objektorienterat språk, utvecklat av Microsoft i samband med skapandet av.net-plattformen. Språket bygger på C++ men är influerat av Java. Anders Hejlsberg, skapare av Turbo Pascal och Delphi, var ansvarig för utvecklingen. Fördelar Språket är lätt att lära sig för C++/Javaprogrammerare eftersom syntaxen är snarlik C# kan användas både som kompilerat språk och som språk under ASP.NET C#-kompilatorn är gratis och ingår i en normalinstallation av Microsoft.NET och kräver inga licenser eller utvecklingsverktyg Nackdelar C# exekveras i likhet med Java i en Virtual Machine och kan därför upplevas som långsamt. Särskilt i uppstarten Program skrivna i C# kräver att man har.net Framework installerat 3.2 Microsoft Access Microsoft Access är en databashanterare utvecklad av Microsoft. Access bygger på JETmotorn. JET-motorn är utvecklad för att kunna arbeta med Visual Basic vilket innebär att man får ett lättarbetat gränssnitt mot Visual Studio som är det mest använda utvecklingsverktyget för C#-applikationer. Access har en mängd export- och importfunktioner som ger möjlighet att överföra data från en Access-databas till exempelvis en Microsoft SQL-server eller motsvarande. En nackdel med Access är att det inte lämpar sig för server-klienttillämpningar. 3.3.NET-plattformen Microsoft.NET är utvecklat av Microsoft. Det innebär att man kompilerar programmen till bytekod och kör dem i en virtual machine. Microsoft hade flera avsikter med sin.netplattform, några av dessa är: Kompatibilitet Eftersom så många COM-bibliotek redan har skapats så tillhandahåller.net Framework metoder för att tillåta kompatibilitet mellan redan existerande bibliotek och ny kod. Common Language Runtime I likhet med Javaplattformen kompileras koden till bytekod och körs på en virtuell maskin. Common Language Runtime är Microsofts namn på den virtuella maskinen. Språkoberoende Till skillnad från Javaplattformen stödjer.net-plattformen utveckling i flera språk t.ex. Visual Basic och ASP. Basklassbibliotek Basklassbiblioteket (BCL, Base Class Library) är ett bibliotek som innehåller typer som är tillgängliga för alla språk som använder.net- 10(52)

11 plattformen. Basklassbiblioteket tillhandahåller klasser som innehåller ett antal vanliga funktioner, t.ex. läsning och skrivning till fil, grafikrendering etc. Även om ursprungstanken var att.net skulle vara förbehållet Microsofts operativsystem så är det idag möjligt att köra det på flera andra operativsystem till exempel MacOS och Linux. 11(52)

12 4 Studium av det befintliga systemet för rörverkssortering Detta kapitel beskriver uppbyggnaden av det befintliga systemet och dess komponenter. 4.1 Uppbyggnad RVP Rörverksplanering är ett fristående datasystem som hämtar uppgifter från Movexplaneringssystem om rör som ska tillverkas och hämtar uppgifter från ORDA-systemet om hur röret ska tillverkas Movex Movex är ett affärssystem som säljs av Intentia. Det innehåller produktadministration, anskaffning, orderuppfyllelse, tillverkning, distribution, redovisning och verksamhetsstyrning ORDA Orda är ett system på Ovako vilket är skräddarsytt för rörtillverkning. ORDA hämtar information så som behörighetsregister, kundregister, produktregister och tillverkningsorder (TO) från Movex och lämnar sedan tillbaks information så som registrering av produkt, registrering av TO, sekvensnummer på TO och utskrift av TO. ORDA innehåller delsystem FOR, MUK, MUR och RVP för beräkning och tillverkning av rör, dessa presenteras nedan: FOR - Förfrågan med kundkrav MUK - Tekniska uppgifter kalla rör MUR - Tekniska uppgifter varma rör RVP - Rörverksplanering varma rör Dessa delsystem innehåller tabeller som styr systemen RVP 100 Väljer TO i Movex som ska levereras kommande vecka. o Urval görs från rörverk, leveransdatum och ämnesdimension. Skapar en planeringslista för valt rörverk. Sortering på ämnesdimension, verktyg, ämnesvärmningstemperatur med hjälp av parametrar från MUR170 i ORDA. Uppdaterar Movex med sorteringsordning på TO. Utskrift av planeringslista och kilometerlista (kilometer rör per reducerstol) RVP 110 Manuell omplanering i ordningen av TO genom att ändra radnummer i planeringslistan. Byte till alternativa verktyg via FOR190 i ORDA för att bättre passa med andra rör som ska tillverkas aktuell vecka. Omnumrering av TO i RVP-planeringslista och Movex. Utskrift av planeringslista. 12(52)

13 4.2 Gränssnitt Systemet består av ett program vilket först sorterar körordningen automatiskt, och sedan sorteras planeringslistan om manuellt av erfaren personal. Detta görs genom att logga in och ändra radnummer och byta bland andra tillverkningsförslag i listan. Användaren loggar in i systemet genom att ange användarnamn och lösenord, rättigheten att ändra i planeringslistan är begränsad till sådan personal som innehar den kompetens som krävs för att optimera sorteringen. Figur 2 visar inloggningsfönstret. Figur 2: Inloggning i RVP. Efter inloggning görs ett val i menyn för att komma till rörverksplaneringen enligt figur 3. Även här finns det begränsningar i vad som visas beroende på vilka rättigheter användaren har. Figur 3: Menysystem i RVP. Här kan användaren välja bland olika val, i det här fallet 75, vilket då tar användaren till RVP110 och manuell rörverksplanering, detta visas i figur 4. Sedan får användaren välja vilken planeringslista som ska sorteras. 13(52)

14 Figur 4: Val av planeringslista. När en planeringslista är vald kan användaren ändra sorteringsordning genom att ändra radnumret för vald TO. Ett exempel på hur det kan se ut visas i figur 5. Användaren kan även titta på andra tillverkningsförslag och byta till ett förslag som passar bättre. Figur 5: Planeringslista med möjlighet att ändra ordningen. 14(52)

15 5 Tidsstudier Det befintliga systemet bygger på gamla tidsstudier och vissa av dem är inte längre aktuella. Därför utfördes nya tidsstudier vid rörverk fyra. Stegen redovisas i punktform nedan. Den intresserade läsaren kan gå tillbaka till figur 1 där samtliga dessa steg finns med. Uppvärmning Max tre meter långa rundämnen värms upp i en karusellugn. Hålning Ämnena hålas i ett roterande hålverk med koniska valsar. Mellan valsarna finns en hålningsplugg, Vid dimensionsbyten kan inloppstratt, ledare och ledarhållare behöva bytas. Asselvalsning I asselverket valsas rätt godstjocklek fram mellan tre valsar och en valsdorn. Denna process ger en mycket snäv väggtolerans. Reducervalsning I reducerverket ges rören rätt ytterdiameter genom att valsas ner till sökt dimension genom ett antal valsstolar. Riktvalsning - Innan svalning görs en riktning av röret för att räta ut röret och eventuella böjningar som uppstått under tillverkningen. Svalning På en svalbädd kyls rören ner i temperatur. Via en automatisk utlastning hämtas de valsade rören med grensletruck för vidare förädling. Tidsstudier gjordes på följande moment: Uppvärmning: Uppvärmning av förvärmningsugn Hålverk: Trattbyte Ledarbyte Byte av ledarhållare Pluggstångsbyte Pluggbyte Asselverk: Dornbyte Reducerverk: Byte av reducerverksstolar Riktverk: Ledarbyte Byte av ledarhållare Byte av inloppsränna 15(52)

16 6 Framtagning av prototyp Innan framtagningen av den teoretiska modellen togs en jämförelsemodell fram, vilken sorterar rörtyperna med avseende på kortaste ställtid och kvalitetsaspekter. Modellen är inte teoretiskt optimal men sorterar rörtyperna snarlikt det förfarande som görs idag. Ett program togs fram som sorterar enligt givna parametrar och presenterar en sorterad lista av rörtyper. Sorteringen går till enligt följande: Ämnesdimension Flera ämnesdimensioner kan köras med små eller inga omställ i hålverket. Dessa delades upp i grupper vilka i första hand användes för sorteringen. Anledningen är att man alltid kör från grövre dimension till lägre för att därigenom kunna använda slutstolarna i reducervalsverket från tidigare rörtyp som seriestolar i nästföljande. Detta gör att man minimerar antalet stolar som behöver användas och är en tvingande parameter, det vill säga vi måste ta hänsyn till det även om ett alternativt körsätt skulle visa sig vara snabbare. Anledningen till detta är att det finns endast 24 stolar till rörverk 4 och det finns ca 85 olika valsstorlekar. När en ny valsstorlek kommer in och denna ej finns i någon av de 24 stolarna som används måste någon rivas och sedan byggas om med de nya valsarna. Rörverk 5 är inte lika beroende av det kravet då det där finns 48 stolar, men är en ändå en parameter som måste tas hänsyn till då en körorder innehåller uppemot 80 stolar totalt. Temperaturen Olika stålsorter har olika hårdheter och körs därför i olika ugnstemperaturer. Mellan en del av dessa är omställningstiden ganska kort och dessa sorterades ihop i samma grupp. Slutstolar Stolsbyte är en punkt som tar mycket tid och vid varje byte av slutstolar är det en lång inkörningstid vilket gör att den här punkten kostnadsmässigt hamnade högt upp i sorteringen. Rörtyper med samma slutstolar men olika antal stolar kan köras med korta omställ. Tratt hålverk Tratten används för att styra in ämnet mellan valsarna i hålverket och byts vid olika dimensionsintervall. Ledare hålverk I hålverket där hålet skapas i ämnet går ämnet på en ledare för att på så sätt ledas rätt väg genom hålverket. Denna ledare byts vid olika dimensionsintervall. Ledarhållare hålverk Ledaren i hålverket sitter monterad på ledarhållaren och byts på samma sätt som ledaren vid olika dimensionsintervall. Ledare riktverk Ledaren i riktverket fyller samma funktion som ledaren i hålverket och byts vid olika dimensionsintervall. Ledarehållare riktverk Ledarhållaren i riktverket fyller samma funktion som ledarhållaren i hålverket och byts vid olika dimensionsintervall. Inloppsränna riktverk - Inloppsränna fyller samma funktion som tratten i hålverket och leder in röret i riktverket och byts vid olika dimensionsintervall. 16(52)

17 Pluggstång Pluggstångsbyte görs vid ändring av innerdimension, pluggstångsbytet innebär mycket arbete och tar relativt lång tid jämfört med pluggbyte och därför försöker man att få så få pluggstångsbyten som möjligt. Dorn Dorn bestämmer innerdimensionen och bytet går ganska fort tidsmässigt och är helt automatiserat och är därför en parameter som kommer långt ner på listan. Plugg Plugg byts liksom pluggstång vid olika innerdimensioner, pluggen byts mycket oftare än stången men innebär istället ett väldigt kort stopp och är inte så jobbigt arbetsmässigt. Därför tas det minst hänsyn till denna parameter. Ovanstående gjordes innan tidsstudierna som ett försök att efterlikna det gamla systemet samt för att få en ökad förståelse för vilka problem som fanns. Modellen användes aldrig skarpt och är med bara för att man ska se hur arbetsgången har varit samt att introducera de olika parametrarna. Syftet med jämförelsemodellen var att snabbt förstå problemet, hitta fallgropar, samt att det skulle finnas ett färdigt program som åtminstone fungerade hjälpligt om allt annat skulle misslyckas. Dessutom kändes det bra att ha tidskrävande kodskrivning färdig. Exempel på sådan kod är kopplingarna mellan databaser och programmet. Detta gjorde också att en snabb återkoppling erhölls från personalen med avseende på sorteringen och den allmänna utformningen av programmet. 17(52)

18 7 Den teoretiska optimeringsmodellen Detta kapitel ger en inblick i optimeringslära och dess tillämpningar. 7.1 Introduktion till optimeringslära Området optimeringslära är en gren av den tillämpade matematiken vilken omfattar användningen av matematiska modeller och metoder för att finna bästa handlingsalternativ i olika beslutssituationer. Optimering kommer från det latinska ordet optimus (det bästa). Man kan säga att optimeringslära är läran om att göra något så bra som möjligt. En förutsättning för en optimeringsmodell är att det finns något i problemställningen som kan varieras eller styras, så kallade variabler. Optimeringen går ut på att bestämma bästa möjliga värde på dessa variabler, givet det specificerade målet. Målet uttrycks av en målfunktion vilken ska maximeras eller minimeras, beroende på problemställning. För att kunna använda optimeringsmodeller måste målen och begränsningarna kunna kvantifieras, begränsningarna uttrycks av en mängd bivillkor. Ett antagande är även att antal möjliga lösningar i problemställningen är mycket stort och att det krävs speciella optimeringsalgoritmer för att beräkna vilken lösning som är den bästa. Optimeringslära kan ses som en del av Operations Research vilket omfattar ett flertal områden såsom: statistisk analys, köteori, simulering, systemteori och produktionsekonomi. Alla dessa har utgångspunkten i matematisk analys för att fatta beslut. En stor del av den matematiska teorin inom optimeringslära kommer ursprungligen från de klassiska matematiska områdena. När dessa teorier började användas som beslutsstöd i komplexa planeringsprocesser för drygt ett halvt sekel sedan blev optimeringslära ett eget vetenskapligt område inom den tillämpade matematiken. De första tillämpningarna inom optimeringslära var till en början militära tillämpningar och därför brukar man säga att andra världskriget var startpunkten för optimeringslära. Detta är även förklaringen till namnet OR Research on (military) Operation. Det stora genombrottet kom 1947 när George Dantzig presenterade simplexmetoden. Optimeringslära används idag inom ett stort antal områden, främst tekniska och ekonomiska. Det är ett tvärvetenskapligt område det vill säga man behöver kunskaper i både matematik, datalogi och kunskaper inom ämnesområdet optimeringen är avsedd för. Utvecklingen inom optimeringslära har i stort sett gått hand i hand med utvecklingen inom datorområdet. Optimeringstillämpningar ger ofta upphov till stora datamängder och komplicerade modeller som kräver stor datorkraft. Många problem som tidigare var olösbara har idag fått sin lösning tack vare den ökade prestandan i datorerna men ännu viktigare har algoritmutvecklingen inom optimeringsområdet varit. 7.2 Tillämpningsområden Optimeringslära kan bland annat användas inom följande tillämpningsområden: Produktionsplanering Exempelvis tillverkning av kretskort som ofta tillverkas i ett stort antal varianter och med olika komponenter. Vid tillverkningen kan en maskin 18(52)

19 bara ha ett visst antal komponenter i sitt magasin och vill man byta typ av kretskort behöver man göra ett byte. Ett annat exempel är vid rörtillverkning, som det här examensarbetet går ut på att optimera körordningen för. Där styr en mängd parametrar vilka verktyg och vilken temperatur som ska användas och vid omställningarna tar det en viss tid. Problemet är att bestämma i vilken ordning rören ska tillverkas för att nå en minsta möjlig tillverkningstid. Transport och logistik Exempelvis ruttplanering av lastbilar. Olika transportuppdrag ska kombineras till rutter och varje bil ska tilldelas en rutt. Målet är att minimera transportkostnaderna. Packningsproblem Exempelvis design av lastutrymme. Vid utvecklingen av bilar måste man i designfasen kunna uppskatta hur mycket lastutrymmet på en bilmodell kommer att rymma. Optimeringsproblemet är att beräkna en maximal volym givet lastutrymmets fysiska storlek. Telekommunikation Vid design av telenät utgår man från hur mycket teletrafik det kommer att gå mellan olika noder. Problemet är att bestämma var knutpunkterna ska sitta och vilken kapacitet de ska ha för att kostnaden ska bli så låg som möjligt med garanterad kapacitet. Trafikplanering Vid styrning av trafiksignaler är vanliga frågeställningar vilka intervall man ska ha på röd/grön-faserna, i vilken följd trafiken ska passera en korsning och hur trafiksignalerna ska samordnas med varandra. 7.3 Optimeringsprocessen Optimeringslära och optimeringsmodeller används för att analysera en problemställning och för att lösa ett problem i en given tillämpning. Det brukar i allmänhet kallas en optimeringsprocess eller arbetsgång vilken inkluderar ett antal olika moment. Först och främst handlar det om att identifiera optimeringsproblemet ur problemställningen. Sedan beskiver man problemet matematiskt i form av en optimeringsmodell genom att formulera problemet. Därefter använder man någon optimeringsmetod för att lösa problemet och till sist utvärderas modellen och resultatet. Några av de olika momenten kan ibland utföras parallellt, och beroende på problemställningens storlek, struktur och komplexitet varierar omfattningen av varje moment. 19(52)

20 Verkligt problem Verifiering Identfiering Avgränsning, förenkling Förenklat problem Validering Formulering Optimeringsmodell Optimeringsmetod Lösning Resultat Figur 6: Schematisk bild av optimeringsprocessen. Det verkliga problemet är den problemställning man har från början och som ska analyseras. Detta problem är ofta mycket komplext och det finns alltid parametrar som man inte vill eller ens kan ta med i modellen. Därför förenklar man problemet för att kunna formulera det matematiskt. Det är därför av stor vikt att kunna avgöra vad som är viktigt i det verkliga problemet och att kunna avgöra om problemet ens kan analyseras med en optimeringsmodell. Detta och övriga steg illustreras i figur 6. När problemet har förenklats ska det beskrivas matematiskt som en optimeringsmodell. Denna ska bestå av variabler, eventuella bivillkor och en målfunktion. Modellen ska ge en god lösbarhet och en tillräckligt bra beskrivning av problemet. Man måste också ta i beaktande om de data man kan samla in är tillförlitliga och om man ens kan få tillgång till alla data. Storleken och strukturen på modellen påverkar lösbarheten i högsta grad och är även det en viktig faktor. Som tidigare nämnts har utvecklingen av datorer påverkat hur avancerade problem man kan optimera. Blir modellen för komplicerad måste man skära i den eller utveckla bättre algoritmer. När modellen är färdig används en optimeringsmetod för att lösa problemet. Lösningen utvärderas sedan för att säkerställa att den löser det verkliga problemet på ett tillfredsställande sätt. Det finns dels optimerande och dels heuristiska metoder för optimering [1]. Den optimerande metoden garanterar att det är en optimallösning till modellen och detta går att verifiera. Den heuristiska metoden hittar lösningar som oftast ligger nära det optimala men det är svårt att uppskatta hur nära och det går inte att garantera kvaliteten på lösningen. I det fallet detta examensarbete avser är det många parametrar som inte är exakt samma för varje rörverk och om man skulle ta hänsyn till exakt allt som någonsin kan påverka ordningsföljden så skulle 20(52)

21 modellen bli alltför komplex. Därför kan det bara bli tal om en heuristisk modell förutsatt att den ska gå att använda inom fler än ett av rörverken. 7.4 Matematisk formulering och problemklassificering Generellt kan ett optimeringsproblem formuleras (P) min f (x) då x X T där f (x) är en målfunktion vilken beror av variablerna x = ( x 1... x n ). Mängden X definierar de tillåtna lösningarna i problemet. Vanligtvis uttrycks X med hjälp av bivillkor och en alternativ formulering av (P) är min f (x) då gi ( x) bi, i = 1,..., m där ( x),..., g ( ) är funktioner som beror av x, och b,...,b är givna konstanter. g1 m x 1 m * En lösning x X som minimerar f (x) kallas en optimallösning och brukar betecknas x. Det optimala målfunktionsvärdet betecknas ofta med z * = f ( x * ). Problemet (P) är formulerat som ett minimeringsproblem, men det kan lika gärna formuleras som ett maximeringsproblem. Att maximera z = f ) är ekvivalent med att minimera ( 1 1 x * * 2 = z1 z ( 2 = f 2 x) = f1( x) och man får att z. Genom enkla omskrivningar kan det också uttryckas andra typer av villkor på den generella formen. Man får att och g g ( b 1 x) b1 g1( x) 2 ( x) = b2 g 2 ( x) b2 och g 2 ( x) b2 2 Beroende på hur funktionerna specificeras f, g1,..., g m och på vilka antaganden som görs avseende tillåtna värden på variablerna x kommer det att erhållas olika problemklasser. Problemet (P) är ett linjärprogrammeringsproblem (LP-problem) Om Alla funktioner f, g1,..., g m är linjära funktioner. n Alla variabler är kontinuerliga (kan anta fraktionella värden). d.v.s. x R. Ett LP-problem kan således skrivas på följande allmänna form. min n z = j= 1 c j x j 21(52)

22 n då aij x j= 1 j b, i = 1,..., m x j 0, j = 1,..., n i Problemet (P) är ett ickelinjärt problem om Minst en av funktionerna f g,..., är en ickelinjär funktion., 1 g m n Alla variabler är kontinuerliga, x R. Problemklasser kan definieras olika beroende på funktionernas utseende och problemets struktur. Om bivillkor saknas kallas det obegränsad optimering och om bivillkoren är linjära med en kvadratisk målfunktion kallas det kvadratiska problem. I det fall problemet är formulerat med endast linjära funktioner är det ett linjärt problem. Ett problem där en delmängd av variablerna är definierade som diskreta variabler är ett heltalsproblem. Det är ett nätverksproblem om problemet definieras som ett nätverk uppbyggt av noder och bågar. Ett välkänt och omskrivet nätverksproblem är Handelsresandeproblemet eller på engelska Travelling Salesman Problem. Problemet definieras enligt följande: En handelsresande ska besöka n städer. Varje stad ska besökas exakt en gång och handelsresanden ska bestämma en tur som startar i hemstaden, besöker alla städer, och sedan återkommer till hemstaden. Målet är att minimera den totala åksträckan. Handelsresandeproblemet formuleras matematisk enligt följande: N utgör mängden av alla noder och S är en äkta delmängd av N. Avståndet mellan varje par av noder betecknas ck. Om vägen mellan noderna ingår i rutten så är xk = 1 annars är xk = 0. B betecknar mängden av bågar i nätverket. Låt B j vara mängden av alla bågar som ansluter till nod j och låt B(S) vara mängden av bågar mellan noderna i den äkta delmängden S. Målfunktionen och bivillkoren blir: (P) min f(x) där f(x) = xk ck då x = 2, j N k B j k k B och xk S 1, S N k B och x {0,1}, k B. k Om turen inte ska återvända till startnoden så byts bivillkor 1 ut mot: k B j x 2, j N k och xk = N 1 k B 22(52)

23 I praktiken brukar inte handelsresandeproblemet lösas på ovanstående form, utan som en sökning i en graf. Den väg som har valts kan då representeras som en lista av noder: ( n1, n2, n3,..., nmax ). 7.5 Optimeringsmetoder Heuristiska metoder Nearest neighbour-metoden är en så kallad girighetsbaserad heuristik och är en ren greedyalgoritm. Det är egentligen ingen generell optimeringsmetod men den kan med viss fördel användas för att lösa handelsresandeproblemet. För att förenkla för sig kan man först börja med att se städerna som noder och sträckan mellan städerna som turer. En godtycklig nod väljs som startnod och sedan väljs närmaste nod som inte redan ingår i turen som nästa nod. Detta upprepas sedan tills samtliga noder i turen är inkluderade enligt figur Figur 7: Närmaste-granne-sökning Simulated Annealing [2] [15] är baserat på sättet metallens molekyler kristalliseras under härdning (annealing) och det är därifrån metoden har fått sitt namn. Vid härdning har metallen en hög temperatur initialt och molekylerna är slumpmässigt ordnade. Med sjunkande temperatur blir molekylerna mer och mer ordnade och vid en viss temperatur når de sitt slutliga tillstånd. Man använder sig av en temperaturvariabel T och energivariabler e och e. Metoden går ut på att slumpmässigt byta plats på element och därefter bestämma den nya energin e. Energin ska alltså minimeras. Därefter räknas de ut som e e. Om de är negativ så görs alltid bytet och om de är positiv görs bytet med en sannolikhet som ges av en i förhand bestämd sannolikhetsfunktion. Sammanfattningsvis är Simulated Annealing alltså en lokalsökningsmetod som utför en iterativ förbättring av lösningen. Genom att utgå från en initialt tillåten lösning försöker man på ett systematiskt sätt förändra den lösningen för att om möjligt finna en ny billigare lösning, vilket visas i figur 8. Om en billigare lösning hittas, utgår man istället från denna lösning och 23(52)

24 upprepar proceduren. För att det inte ska bli en rent girig algoritm som exempelvis Nearest Neighbour så accepteras ibland även en sämre lösning. Den bästa lösningen sparas. i j i j l k Figur 8: Lokalt byte enligt Simulated Annealing. l k Trädsökningar I en nearest neighbour-sökning tar man direkt den närmaste noden och kontrollerar sedan inte några alternativa vägar. Det kan alltså hända att det finns billigare vägar om man väljer t.ex. den näst närmaste noden eller någon annan helt godtycklig nod. En trädsökning är just ett sätt att hitta den närmaste vägen genom att testa ett stort antal möjliga vägar. Depth-First-sökning går ut på att gå på djupet direkt, det vill säga: gå så långt som möjligt ner i trädet och sedan backa uppåt för att söka en bättre lösning. Man utgår från rotnoden och går sedan vidare tills en tillåten lösning hittas eller en nod som inte har några undernoder hittas, se figur 9. Siffrorna i noderna anger besöksordningen. Komplexiteten i Depth-First-sökning är lägre än för Breadth-First som beskrivs nedan. Dessutom är den bättre för heuristiska metoder som väljer en förmodat optimal lösning. I stora sökträd kan dock problem uppstå. Eftersom besökta noder måste sparas på en stack så kan minnet ta slut om trädet går ner väldigt djupt Figur 9: Depth First-sökning. Breadth-First-sökning går ut på att testa alla grannoder till rotnoden. Sedan undersöks dessa noders grannoder tills en lösning nås, se figur 10. Även här anger siffrorna i noderna besöksordningen. Denna sökmetod söker alltså igenom samtliga noder i trädet och använder ingen heuristik. Den blir normalt lite långsammare än en heuristisk metod och för verkligt stora träd är metoden nästan oanvändbar på grund av sin höga komplexitet. 24(52)

25 Figur 10: Breadth First-sökning Branch and Bound är en annan trädsökningsmetod. Den går ut på att hitta ett minimum av f(x) över en mängd tillåtna värden på x. Både f och x kan vara godtyckliga. En "branch and bound"-procedur kräver två verktyg. Det ena är en smart metod att täcka den möjliga regionen genom att använda subregioner. Detta kallas för branching eftersom alla subregioner bildar ett sökträd eller "branch and bound tree". Dess noder består av de skapade subregionerna. Det andra verktyget är bounding. Detta är ett sätt att finna övre och undre gränser (bounds) för den optimala lösningen i den tillåtna regionen. Kärnan av tillvägagångssättet är följande: Om den lägre gränsen för subregion A från sökträdet är större än den övre gränsen för någon annan, tidigare undersökt, subregion kan man direkt avfärda A. Denna del av sökningen kallas pruning (klippning). Med andra ord klipps de grenar av trädet av som inte behövs i sökningen. Metoden presenteras i figur 11. Siffrorna i noderna betecknar här kostnaden för att ta sig till noden. Givetvis adderas tidigare besökta noders kostnad. Effektiviteten i metoden beror mycket på algoritmen som används och det finns ingen generell algoritm som fungerar för alla problem. Figur 11: Branch and Bound-sökning. 25(52)

26 7.6 Egenskaper hos lösningar Vid lösning av ett optimeringsproblem kan man hitta en lösning som är en unik optimallösning eller så konstaterar man att det finns alternativa optimallösningar. I vissa fall kan problemet ha en obegränsad lösning eller att en tillåten lösning saknas. Dessutom finns det något som kallas sub-optimala lösningar vilket innebär att lösningen inte kan bevisas vara optimal. Det är oftast denna typ av lösning som nås via heuristiska metoder. Unik optimallösning En unik lösning innebär att det endast finns en optimallösning till problemet. Denna lösning finns alltid i en hörnpunkt i det tillåtna området, se figur 12. Figur 12: Unik optimallösning. Alternativa optimallösningar Alternativa optimallösningar uppkommer då det bästa värdet återfinns i minst två hörnpunkter, se figur 13. Figur 13: Alternativ optimallösning. 26(52)

27 Obegränsad lösning En obegränsad optimallösning inträffar när det tillåtna området är öppet i den riktning som målfunktionen förbättras, se figur 14. I den riktningen kan man då förflytta sig oändligt långt och det optimala funktionsvärdet går mot oändligheten. I det fall detta inträffar i verkligheten är det oftast fel på modellformuleringen eller indata. Figur 14: Obegränsad lösning. Tillåten lösning saknas Detta fall inträffar när bivillkoren är definierade så att ingen punkt uppfyller samtliga bivillkor, se figur 15. Figur 15: Tillåten lösning saknas. 27(52)

28 8 Det nya systemet 8.1 Arbetet inleds Arbetet påbörjades med en introduktion av verket och dess säkerhetsföreskrifter. Denna introduktion är ett krav från företaget för att anställda skall få vistas i verket ensamma. Hela första veckan bestod mestadels av introduktion och genomgång av de olika momenten för att få en större inblick i hur arbetet gick till. 8.2 Problemdefinition Efter forskningar på Internet och samtal med Lars Karlsson identifierades det här problemet som ett handelsresandeproblem (Travelling Salesman Problem). I det här fallet motsvarar alltså ett rör en stad och tiderna för verktygsbyten motsvarar en sträcka till en annan stad. Handelsresandeproblemet är omskrivet både på Internet och i litteratur och beskrivs i kapitel 7. Följande gäller enligt tidigare: N utgör mängden av alla noder. Om vägen mellan noderna ingår i rutten så är x k = 1 annars är xk = 0. B betecknar mängden av bågar i nätverket. Låt B j vara mängden av alla bågar som ansluter till nod j. Följande är nytt för vårt problem: Avståndet mellan varje par av noder betecknas nu istället c k, g då valet av förslag påverkar sträckan. G utgör mängden av alla olika förslag för varje nod och valt förslag betecknas t g. Om förslaget t är valt så är t = 1 annars är t = 0. g Problemet kan nu formuleras matematiskt enligt följande: (P) min f(x) där f(x) = k B j x 2, j N och k g G g k B x k c k, g t g g k B x k = N 1 och g G j t = 1, j N g och xk {0,1}, och t {0,1}, g k B g G 28(52)

29 8.3 Tidsstudier Efter introduktionsveckan påbörjades arbetet med tidsstudier. I och med att dessa till en stor del skulle göras ute i verket tilldelades hjälm och arbetskläder. Hjälm och hörselskydd är ett tvång för att få vistas i verket. Till en början gjordes studierna genom att undersöka de olika momenten och tidsbestämma dessa. En tillverkningsorder kördes dock under en lång period vilket ledde till att det var få byten med lång tid emellan. Detta tillsammans med att produktion körs i skift dygnet runt gjorde att det blev väldigt svårt att tidsätta momenten rättvist under en tvåveckorsperiod. Men då personalen i produktion skriver in alla stopptider och stopporsaker i en databas kunde siffror fås fram för stopp respektive ställ för hela Ett snittvärde togs för varje moment ur dessa tider som sedan jämfördes med verkligheten i verket. Det kontrollerades också med erfaren personal att dessa tider verkade rimliga. De tider som inte verkade vara rätta korrigerades. I och med användandet av denna databas kunde mer rättvisa tider presenteras och en bättre produkt kunde framställas. I det fall tider förändras vid ombyggnation eller liknande kan användaren själv ändra dessa utan att behöva ändra något i koden, se figur 16. Figur 16: Optimex, Ändra flik. 8.4 Prototypen färdigställs Mot slutet av tidsstudierna påbörjades arbetet med en prototyp vars syfte var att efterlikna den sortering som görs idag. I början på projektet lades mycket arbete på delar som senare visade sig överflödiga. Bland annat lades mycket tid och kraft på att programmet skulle kunna hantera manuell inmatning och ändring av ordrar. Detta visade sig senare onödigt för slutprodukten men var väldigt användbart under utvecklingsarbetet då författarna kunde simulera rörtillverkningen med ett valfritt antal tillverkningsordrar. Prototypen satte olika prioriteter på de moment som utförs i verket, till skillnad från slutprodukten som helt och hållet baserar sig på tider för verktygsbyten. 29(52)

30 Prioriteter listas nedan i fallande ordning: Slutstol Ugnstemperatur Pluggstång Dorn Plugg Först och främst sorterades alltså körordningen beroende på slutstol och sedan de övriga punkterna i den mån det går. Denna prototyp fungerade inte tillfredställande. Dels beroende på att kunskapen om produktionen, produkten och dagens sortering ännu var mycket begränsad och dels att här endast togs hänsyn till ett enda tillverkningsförslag. Det skulle även visa sig under projektets gång att det fanns en mängd andra parametrar att ta hänsyn till. Även om denna prototyp inte fungerade bra gav arbetet med den en bättre förståelse och inblick i verksamheten vilket i sin tur ledde till en bättre produkt. 8.5 Valet av optimeringsalgoritm Nästa steg var att börja studera optimeringsteori och utreda hur detta skulle kunna appliceras på det givna problemet. Den enklaste heuristiska optimeringsmetoden är nearest neighbourmodellen. Det innebär i stora drag att man utgår från en "nod", i det här fallet en tillverkningsorder, räknar ut sträckan till övriga noder och väljer den nod som ligger närmast. Sedan upprepas detta steg för övriga noder. Metoden beskrivs i detalj i kapitel 7. I del 2 av utvecklingsfasen användes denna metod för att utföra sorteringen. Under programmeringen av denna fas framgick det att fler tidsparametrar fanns som påverkade körordningen. Dessa införlivades allt eftersom de uppdagades. Tidsparametrar: Stolsbyte 15 min Temperaturskifte i ugnen 15 min Pluggstångsbyte 15 min Pluggbyte 3 min Dornbyte 6 min Byte av tratt i hålverket 3 min Byte av ledarhållare i hålverket 15 min Byte av ledare i hålverket 5 min Sorteringen fungerade bra men för att förbättra lösningen ytterligare fortsatte sökandet efter lämpliga metoder. Första modell att övervägas var heltalsmodellen. Ett problem är ett heltalsproblem om en delmängd av variablerna (minst en) är definierade som diskreta variabler. [1] Detta går i korthet ut på att ställa upp en formel för minsta totala ställtid och bivillkor för parametrar. Det framgick ganska fort att denna metod inte lämpade sig speciellt bra för detta problem då det finns alltför många parametrar, vilket i sin tur betyder ohanterligt många bivillkor. Därför påbörjades forskningar bland de algoritmer som mer specifikt används för att lösa just handelsresandeproblemet. Detta var inte helt trivialt då det inte finns någon generell algoritm för riktigt stora problem. Men efter en del efterforskningar föreföll det som att någon form av trädsökning var en lämplig metod. 30(52)

31 De trädsökningsalgoritmer som undersöktes så som Depth-First, Breadth-First och Branch and Bound (beskrivs i kapitel 7) använde liksom många andra handelsresande-algoritmer en kostnads-/avståndsmatris för att göra sökningen och detta passade problemet bra då det var relativt enkelt att implementera en sådan. Trädsökningsalgoritmer var som tidigare nämnts de första metoderna som på allvar blev påtänkta för detta projekt. Det skulle dock visa sig att det var svårt att implementera dem beroende på det stora antal noder som blev följden av alla olika tillverkningsförslag. Om man tänker sig handelsresandeproblemet i samma situation skulle det innebära att en stad skulle flytta sig på kartan beroende på vilket förslag som väljs, vilket skulle ge ohanterligt stora sökträd. Dessutom måste en algoritm som är tillräckligt effektiv utformas för att inte exekveringstiden ska bli ohanterligt lång och informationen i böcker och på Internet var väldigt bristfällig. Ett alternativ hade varit att nästan enbart jobba med att komma fram till en bra algoritm men högsta prioritet var att se till att få fram en lösning som kunde användas av företaget. Därför lades dessa metoder på hyllan tills vidare. Det vore dock mycket intressant att se hur mycket effektivare lösningen skulle kunna bli med en "branch and bound"-algoritm. En gissning är att det inte blir så mycket bättre än den lösning som presenteras i detta projekt. Dels så är detta sökträd väldigt stort vilket skulle ställa mycket höga krav på algoritmen och dels så verkar en variant av neighbourhood search i kombination med nearest neighbour fungera mycket bra för problemet. Då en produkt kan tillverkas på flera olika sätt och därför har flera olika tillverkningsförslag blev ovanstående metoder alltså svåra att tillämpa. Därför frångicks dessa metoder och istället fortsattes förbättringarna med närmaste-granne-metoden. Indata till algoritmen var alltså tiderna för verktygsbyte mellan olika tillverkningsordrar, maximalt antal stolar som kunde användas, tillverkningsförslag för tillverkningsordrarna och tillverkningsordernumret. Dessa representerades i form av en vektor av den egendefinierade datatypen Tube. Vektorn innehöll samtliga tillverkningsordrar (N) och de olika förslagen för varje tillverkningsorder (G) [Se kapitel 8.2]. De valda förslagen av varje tillverkningsorder kopierades över till en annan vektor som användes som den sorterade körordningen. Denna vektor kördes med en tidsfunktion som räknar ut den totala tiden för verktygsbyten mellan varje element i listan till nästa. Tiden för verktygsbyten mellan två tillverkningsordrar är alltså c k, g. Tidsfunktionen tog naturligtvis ingen hänsyn till den virtuella kostnaden som infördes för att tvångssortera stolarna. I och med att flera olika tillverkningsförslag införlivades kontrollerades även att inga parametrar saknades. Efter samtal med personal presenterades denna kompletta lista över tidsparametrar för rörverk 4: Stolsbyte 15 min Pluggstångsbyte 15 min Pluggbyte 3 min Dornbyte 6 min Byte av tratt i hålverket 3 min Byte av ledarhållare i hålverket 15 min Byte av ledare i hålverket 5 min Temperaturskifte dimensioner ,9 min/grad Temperaturskifte dimensioner ,48 min/grad 31(52)

32 Temperaturskifte dimensioner ,36 min/grad Byte av inloppsränna riktverket 2 min Byte av Ledarhållare riktverket 15 min Byte av Ledare riktverket. 3 min Efter att dessa tider implementerats fungerade sorteringen bättre än innan. Vid granskning utförd av den personal som idag gör den manuella sorteringen visade det sig dock att sorteringen saknade en viktig parameter. Ingen hänsyn togs till att det fanns begränsningar i antalet reducerverksstolar som finns att tillgå. Då en körorder använder sig av mellan 70 och 80 olika stolar och rörverk 4 endast har 24 stolar att tillgå var detta ett problem som behövde ingå i optimeringen. Vidare visade det sig att det fanns en kvalitetsaspekt att ta hänsyn till. Vid varje slutstolsbyte fås ett par rör, så kallade inkörningsrör, som blir skrot på grund av att valsarna måste slitas in. I och med detta är slutstolsbyten mycket "dyra" kvalitetsmässigt. Detta försvårade optimeringen en hel del då det är en tvingande parameter som gör att man inte rakt av kan välja den billigaste vägen tidsmässigt. I dagsläget sorteras körordningen från grövsta dimension till lägre för att på så sätt få bättre kvalitet men även för att kunna fasa ut stolar när de inte kommer användas igen för att då kunna bygga nya till kommande ordrar. Då dessa parametrar (antal stolar, kvalitetsfrågan) skulle införlivas var det nödvändigt att använda en virtuell kostnad då dessa inte kunde tidsättas på ett rättvist sätt. Detta löstes genom att lägga till en parameter vid namn stolsberoende vilken kontrollerar hur många stolar som maximalt används och på så sätt se till att maximalt antal stolar inte överstiger 24. Även kvalitetsfrågan löstes med hjälp av detta stolsberoende då den ser till att sorteringen går från högre dimension till lägre. För att förbättra sorteringen ytterligare gjordes en lösning som ändrar stolsberoendet från 0 till 100 i steg om 1 och gör en närmaste-granne-sortering för varje värde på stolsberoendet. Sedan väljs den snabbaste av de körordningar som uppfyller kriteriet. Kriteriet utgör maximalt antal stolar som får låsas upp simultant under körningen. Detta förbättrade körtiden marginellt då kriteriet kunde nås på flera olika sätt och några av dessa var mer effektiva än andra. Pseudokod för funktionen visas nedan: Förutsättningarna är att man specificerat max antal stolar som får användas samtidigt. Dessutom har man en bästa tid sedan tidigare som man jämför med. För alla stolsberoenden från 0 till 100 testas Nearest Neighbour-funktionen och den snabbaste körordningen som uppfyller kriteriet med max antal uppbundna stolar sparas. for(stolsberoende = 0; stolsberoende <= 100; stolsberoende++) { nearestneighboursort(stolsberoende); if(time < besttime AND antalstolar <= maxantalstolar) använd denna sortering; } Hittills hade enbart närmaste-granne-algoritmen använts. Den föreföll fungera ganska bra för det givna problemet men kan i vissa fall ge mycket icke-optimala lösningar. För att förbättra tiden skulle man behöva testa sig både framåt och bakåt i listan. Detta var svårt att genomföra med de vanligare metoderna eftersom det fanns så många olika tillverkningsförslag att ta hänsyn till. 32(52)