Szakdolgozat. A Szatmári Konzervgyár uborkagyártásának szimulációja és a gyártás optimálása

Miskolci Egyetem Gépészmérnöki és Informatikai Kar Anyagmozgatási és Logisztikai Tanszék Általános Informatikai Tanszék

A Szatmári Konzervgyár uborkagyártásának szimulációja és a gyártás optimálása

Szakdolgozat

Készítette: Habarics Henrietta D7IDRF Mérnök informatikus BSc 4761, Porcsalma, Lehel út 76.

Tartalomjegyzék Tartalomjegyzék ..................................................................................................................... I Bevezetés ............................................................................................................................... 1 1.

Logisztikai rendszer ........................................................................................................ 3 1.2 A logisztikai rendszer tervezésének lépései ................................................................ 4

2.

A Szatmári Konzervgyár ................................................................................................. 6

3.

A szimulációhoz felhasznált technológia ......................................................................... 8 3.1 Enterprise Dynamics ................................................................................................. 8 3.2 Plant Simulation ...................................................................................................... 10 3.2.2 Simtalk ............................................................................................................. 10

4.

Megvalósítás ................................................................................................................. 12 4.1 Lehetőségek az Enterprise Dynamicsban ................................................................. 12 4.2 A szimuláció elkészítésének menete ........................................................................ 13 4.3 Tervezés Plant Simulation-el ................................................................................... 17 4.3.1 Selejtkiválasztás ............................................................................................... 20 4.3.2 SimTalk ............................................................................................................ 23

5.

Optimálás ...................................................................................................................... 25 5.1 .NET, C# ................................................................................................................. 26 5.2 Visual Studio ........................................................................................................... 27 5.3 Random Search algoritmus ...................................................................................... 29

6.

Az optimálás kezdeti lépései.......................................................................................... 31 6.1 Optimálás C# nyelven ............................................................................................. 33 6.1.1 Üzleti logika tervezése ...................................................................................... 35 6.1.2 Üzleti logika megvalósítása .............................................................................. 36

7.

Felhasználói kézikönyv ................................................................................................. 39

8.

További fejlesztési lehetőségek ..................................................................................... 41 8.1 Szimuláció............................................................................................................... 41 8.2 Optimáló program ................................................................................................... 41

Összegzés ............................................................................................................................. 43 Summary .............................................................................................................................. 45 Irodalomjegyzék ................................................................................................................... 47 Mellékletek .......................................................................................................................... 49 I

EREDETISÉGI NYILATKOZAT ........................................................................................ 51

II

Bevezetés Logisztika szakirányos hallgatóként több ízben foglalkozhattam már logisztikai szimulációk elkészítésével. Bármely termék gyártásáról is beszélünk a gyártás megkezdése előtt, illetve után is érdemes szimulációt készíteni, hiszen egy szimuláció elkészítése költséghatékonyabb magánál a gyártásnál, azonban a hiányosságok, illetve megoldatlan problémák hamar kiütköznek, így ezek gyakran a gyártás megkezdése előtt megoldhatóvá

válnak,

illetve

a

gyártás

közben

felmerülő

változhatások

is

zökkenőmentesen integrálhatóak a szimuláció elkészítése után a kész rendszerbe. Szakdolgozatomban a Tyukodi Konzervgyár uborkabefőtt gyártásának szimulációját készítem el, illetve ehhez kapcsolódó optimálási feladatokat is elvégzek a bevétel maximálva. Célom, hogy a dolgozatom kapcsán elkészült programok valódi értéket képviseljenek a gyártási rendszerben. Dolgozatomhoz két szimuláció készül el az Enterprise Dynamics, és PlantSim programokkal. Az optimálást C# nyelven készítem el. A Szatmári Konzervgyár jelenleg Rege márkanevű termékeket gyárt, de régebben Globus, majd előtte Globi termékeket készített. A családom évtizedek óta foglalkozik uborka termelésével, illetve szüleim is sokáig dolgoztak az említett konzervgyárban. Ebből a megfontolásból, és természetesen logisztikai tanulmányaim, és érdeklődési köröm miatt készítem ezen témából a dolgozatomat. Munkámat segítette a Tyukodi Konzervgyár közelsége, és a számomra rendelkezésre bocsátott értékes információk. Emellett konzervgyár weboldalán elérhető, a gyártási rendszert bemutató anyagok is nagy segítséget nyújtottak munkám elkészítésében. Mivel az elmúlt idő alatt legjobban a savanyú uborkagyártást ismerhettem meg, ezért az általam elkészített program ezt hivatott szimulálni.

1

Fontosnak tartom megjegyezni azonban, hogy a munkám nem teljes, hiszen minden termék gyártását nem volt módomban megismerni, így kifejezetten csak az említett termék elkészítésének szimulációját, és gyártásához kapcsolódó optimálást készíthettem el. Ennek oka még, hogy a gyár több mint harminc féle terméket készít, így nem lett volna megvalósítható a gyár teljes termelési, és raktározási folyamatának hiteles ábrázolása.

2

1. Logisztikai rendszer Egy logisztikai rendszer tervezéséhez először is tisztáznunk kell, mit is értünk logisztikai rendszer, illetve logisztika alatt. A "gondolkodni" jelentésű logo görög főnévi igenévből alakult ki a logizomai ige, mely többek között a számolni, kiszámítani, meggondolni, tervezni jelentéseket tartalmazza és hordozza. Ebből alakult ki a logismos főnév és a logistikos melléknév, mely jól számítható, kiszámolható értelmű. A görög városállamokban így Athénban már az ókorban voltak olyan hivatalnokok, akik a városállam vezetésének gazdálkodását ellenőrizték. A logisztika kifejezés a magyar nyelvű szakirodalomban a 60-as és 70-es évtizedben tűnik fel első ízben. Kezdetben döntően az anyagmozgatási folyamatok vizsgálatára alkalmazott elemzési eljárásokat illették ilyen névvel, később fokozott szerepet kapott az anyagmozgatáshoz kapcsolódó elméleti problémák leírása is. Ekkor alakultak ki - döntően német és angol szakirodalmi forrásokra támaszkodva - a logisztika magyarországi definíciói. A logisztika az anyagáramlás

tervezésével,

megvalósításával

és

irányításával

kapcsolatos

tevékenységek rendszerszemléletű vizsgálatát és koordinálását végzi a nyersanyag előállításától (a természettől történő elragadástól) a késztermék felhasználásáig, sőt a hulladékkezelésig terjedő teljes termelési - értékesítési - fogyasztási láncban. [1] A logisztika az alapanyagok, félkész és késztermékek, valamint a kapcsolódó információk származási helyről felhasználási helyre történő hatásos és költséghatékony áramlásának tervezési, irányítási és megvalósítási folyamata, a vevői elvárásoknak történő megfelelés szándékával. Célja a rendszerszemléletű anyaggazdálkodás segítségével a forgóeszköz-gazdálkodás, valamint

közvetve a teljes vállalati

gazdálkodás kedvező hatékonyságának biztosítása. [2] Egy logisztikai rendszernek meghatározott alapelveknek kell eleget tenni. Ezek a logisztikában csak „7 M”-nek emlegetett alapelvek a következőek: 

megfelelő minőség



megfelelő anyag



megfelelő költség



megfelelő helyen



megfelelő mennyiség 3



megfelelő információval ellátva



megfelelő vevőnek álljon rendelkezésre.

A vállalkozás logisztikai tevékenysége szorosan kapcsolódik a nagyobb logisztikai rendszerek működéséhez. Ebből következően indokolt áttekintenünk ezek legfőbb jellemzőit is.[2] [19] [20][22]

1.2 A logisztikai rendszer tervezésének lépései Dolgozatom végtermékeként szimulációkat készítek el. A szimuláció megtervezésében is különböző lépésekre van szükség, először is meg kell határozni, hogy mi az a szimuláció. „A szimuláció egy rendszer leképezése dinamikus folyamataival együtt egy olyan modellben, amellyel kísérletezni lehet. Célja olyan eredmények szerzése, amelyek a valóságban felhasználhatók.”[3] A szimuláció célja az, hogy jobban átlássuk egy rendszer működését, hogy később optimalizálni tudjuk azt. De mit is várunk egy szimulációtól? Egy jó szimuláció által nő a létesítmény, a gépek kihasználtsága, és a teljesítmény. Ezáltal csökken a gyártási idő, a tároló helyek mérete, illetve kevesebb emberi erőforrásra van szükség. Meghatározhatóak a tároló méretek, szállítóeszközök száma, illetve a munkadarab hordozók száma is. Fontos szempont az is, hogy a tervezés során felmerült alternatívák kipróbálhatók, a vezérlési stratégiák optimalizálhatók, így elkerülhetőek

a

tervezési

hibák,

illetve

megőrizhetőek

a

beruházások,

és

megtakaríthatóak a kivitelezésre szánt források. [4] A dolgozatomhoz elkészített szimulációs modellt a hollandiai Incontroll cég által forgalmazott Enterprise Dynamics, és a Plant Simulation(korábban eM-Plant) programokkal készítettem.

Célom,

hogy mindkét

programban elvégezzem a

4

konzervgyár

logisztikai rendszerének

szimulációját,

majd

összehasonlítsam

a

megvalósítás menetét, és lehetőségeit kitérve a programok sajátosságaira. A logisztikai programok tárháza óriási, így nagy feladat volt kiválasztani a munkámhoz leginkább megfelelőt. A szoftverek kiválasztásánál azt biztosan tudtam, hogy két különböző szoftverrel is el szeretném készíteni a szimulációt, az azonban még kérdéses volt, hogy mely szoftvereket válasszam. Tanulmányaim alatt elkészített szimulációkat FlexSim-ben készítettem el, így ez tűnt a legkézenfekvőbb megoldásnak. Ez azonban akadályokba ütközött, hiszen az interneten volt elérhető student verzió, ám az elérhető változatokban csak korlátozott mennyiségű atom volt felvihető a rendszerbe. Tanulmányaim alatt tanáraim alapvetően a PlantSim-et javasolták hasonló feladatok elvégzéséhez, így ez volt az egyik megoldás. A másik választásom azért esett az Enterprise Dynamics-ra, mert az interneten fellelhető kész rendszerek szimulációi alapján messze a legszemléletesebbnek tűnt. Az Enterprise Dynamics nagy népszerűségnek örvendő és kiválóan használható szimulációs program. A külföldi szakirodalmat megvizsgálva arra a következtetésre jutottam, hogy az Enterprise Dynamics kifinomult, rugalmas megoldásokkal, illetve beépített atomokkal rendelkező programjára van szükségem. A választást elősegítették még az interneten található tutorial videók is, amelyekben láthattam, hogy nagy logisztikai rendszerek látványos és összehangolt munkáját is el lehet készíteni ezzel a szoftverrel. Munkámat először a rendszer tervezésével kezdtem, melyet kezdetben papíron, később az Enterprise Dynamics programban folytattam. Nagy segítségemre voltak a SzatmáriKonzervgyár által rendelkezésemre bocsátott anyagok, melyek a gyár működésével, a logisztikai rendszer kivitelezésével, a gépek adataival, elrendezésével, illetve folyamatirányítási,

automatizálási,

minőségbiztosítási,

és

gyártástechnológiai

információkat tartalmaztak.

5

2. A Szatmári Konzervgyár Ez a gyár a szatmári régió egyik központi termelési egysége, és munkát ad az itt élő szakembereknek, illetve a mezőgazdaságban tevékenykedő embereknek. A gyár különböző

területekre

készít

élelmiszeripari

termékeket.

Ezek

többségét

Németországba, vagy Romániába exportálják. A Szatmári Konzervgyárat 1965-ben hozták létre. Az ezredfordulón végrehajtott racionalizálási és fejlesztési program keretében a társaság dinamikus fejlődésnek indult. A feldolgozás, csomagolás, raktározás műszaki színvonala a XXI. század követelményeinek felel meg, ezért a termékek megőrzik az alapanyagok természetes értékeit. [5] A feladatok köre időszakos. A nyári időszakban uborkát, szilvát, málnát, és egyéb idény termékekből készítenek befőtteket, savanyúságokat, majd az ősz közeledtével paprika, kukorica, stb. feldolgozása kezdődik. A Szatmári Konzervgyár Szabolcs-Szatmár-Bereg megyében, Tyukod és Porcsalma között található, területe 176. 951 m2. A gyár építése 1978-ban fejeződött be. Raktárak: a gyárban öt raktár található: segédanyag raktár, sátorraktárak, kéthajós raktár, műszaki raktár, és az egyteres készáruraktár. A segédanyagraktárban segédanyagokat, a sátorcsarnokban segédanyagokat és késztermékeket, a műszaki raktárban műszaki eszközöket, alkatrészeket, a készáruraktárban készárukat tárolnak. A gyár tulajdonában van egy 260 m3-es víztároló, 3db mélyfúrású kút, illetve 2x 120 fm hosszú iparvágány. A termelő berendezések öt nagy feldolgozó részből állnak: kukorica sor, borsó sor, magozott meggy sor, uborka-savanyúság sor, és lé állomás. Az általam vizsgált feldolgozó rész az uborka-savanyúság sor, melynek technológiai folyamata a következő: A bejövő árut konténer ürítőbe helyezik. Ezt követően ventillációs mosás, felhordó, kefés mosás és kézi válogatás következik. A kiválogatott anyagok Niko töltőgépre, tömködőbe, onnan levezésre, zárásra (TO gőzvákuumos

6

üvegzáró), Alpha pántozóra kerül. A kézi leszedést követően egységrakomány képzés történik fóliázással. A berendezések többsége 5 éves, vagy annál fiatalabb. Szállító eszközök az árukat szállítószalagon (mágnesbetétes, három sávos, görgős, Food Lamellás, válogatószalag), elevátorokon, üvegszállító-szalagokon, felhordó szalagokon, szállítópályán szállítják a gyártási folyamatok között. A gyártás kezdetén és végén kisteherautókkal, illetve gőzüzemű targoncákkal történik az áruszállítás. Az egységrakomány-képzés ERK-321 egységrakomány rögzítővel, fóliázóval és ER343-E-F egységrakomány rögzítővel történik. [6]

7

3. A szimulációhoz felhasznált technológia A szimulációt először Enterprise Dynamics-ban, majd PlantSim-ben készítetem el. A PlantSim-ben lévő szimulációhoz készült metódus a PlantSim saját programozási nyelvén a SimTalk-on íródik.

3.1 Enterprise Dynamics Az Enterprise Dynamics egy objektum orientált szoftver környezet, amelyet az Incontroll cég fejlesztett ki. Az Enterprise Dynamicsnak különböző termékei léteznek: ED Logistics, ED Airport, ED Transport, ED Warehouse, ED Educational. Láthatjuk tehát, hogy különböző szoftverek léteznek eltérő rendszerek megvalósításához. Jelen esetben nekem az ED Logistics programra volt szükségem, aminek

student

verziója

ingyenesen

letölthető

az

http://www.incontrolsim.com oldalról.

1. ábra Az Enterprise Dynamics logója[7]

Az Enterprise Dynamics egy szimulációs program, ami folyamatok tervezésére, monitoringjára, modellezésére, szimulációjára, illetve ezek megjelenítésére alkalmas. Egy szimulációs program, és szimulációs nyelv keveréke, tehát szimulátor, ami lehetővé teszi komplex feladatok rugalmas elkészítését, illetve megoldását. Építőelemei az atomok. Mindegyik atom egy négy dimenzióval rendelkező(x, y, z és az idő) objektum. Ennek a koncepciónak az előnye, hogy az atomok által létrehozott valós rendszerek működése pontosan leképezhető. Maga a program csaknem kétszáz előre gyártott atomot tartalmaz, és ezek az atomok különböző feladatokat oldanak meg. Az ED-ben találhatunk egy úgynevezett Modell Layout-ot, tehát modellezés számára használható szerkesztői felületet, amelyen grafikus formában elhelyezhetők a modellhez felhasznált atomok. Az atomok színe, mérete, elhelyezkedése egyedileg megadható, módosítható, ezáltal méretarányos modellek készíthetőek.

8

A következő feladat, meghatározni a modellben áramló áruk, entitások, információk áramlásának irányát. Erre a feladatra az atomok bemeneti és kimeneti pontjait összekötő csatornákat használom.

2. ábra Csatornák az Enterprise Dynamics programban

Az építőelemek jellemzőit párbeszédablakban állíthatjuk be, így meghatározva az atomok funkcionalitását, és a modell viselkedését. Az atomok belső logikája a 4D script nyelven készült, ami az ED saját programozási nyelve, és ezt egy szerkesztő, az Atom Editor segítségével tudjuk megváltoztatni, módosítani, vagy kiegészíteni. Ezáltal új funkciók, és tulajdonságok adhatók az atomokhoz, illetve teljesen új atomok is készíthetőek. A modelleket háromféle üzemmódban tudjuk szimultán futtatni: 2D, 3D és Virtual Reallity. Az ED további előnye még, hogy támogat más alkalmazásokat, így DDE, DLL, ODBC, SQL, Windows Socket, ActiveX kapcsolatokon keresztül valós időben megvalósítható az adatok írása és olvasása külső programokból. Mint említettem ez a verzió hallgatói licenszes, ami ebben az esetben azt jelenti, hogy bár elkészíthetünk egy nagyobb rendszert is, azonban csak meghatározott számú (30) atommal rendelkező szimuláció menthető el. Mivel nem volt lehetőségem a program teljes verzióját megszerezni, ezért ebben az esetben két lehetőséget láttam a dolgozat elkészítésére; a program részleteit elkészíteni, majd ezeket egyenként elmenteni, vagy a 9

program vázát Enterprise Dynamics-ban elkészíteni, ezzel látványos, ámde vázlatos képet adva a teljes rendszerről, majd a teljes, már kibővített rendszer szimulációját Plant Simulationban elkészíteni. [7]

3.2 Plant Simulation A Plant Simulation a Tecnomatix termékcsalád tagja. Alkalmazása a raktározás technikában és a logisztikában lehetővé teszi a dinamikus raktározási és logisztikai műveletek valós szimulációs modelljeinek a gyors létrehozását. Plant Simulation használatával lehetőség nyílik az egyes terv alternatívák karakterisztikájának és kialakításának kiértékelésére még azelőtt, hogy az beépítésre kerülne a valós folyamatokba, ezáltal jobb tervezési döntések hozhatók, illetve a tervezési utómunka is minimalizálható.

3.2.2 Simtalk PlantSimben lehetőség van kis programok, úgynevezett metódusok készítésére is. Ezek hasonlóak az ismert programozási nyelvek (Pascal, C++) metódusaihoz. A PlantSim saját programozási nyelvének neve SimTalk, amely az Eiffel programozási nyelven alapul. Egy metódussal alkalmas: 

objektumok módosítására, esetleg viselkedésük kiterjesztésére,



jellemzők beállítására és lekérdezésére,



a szimuláció alatt bekövetkező eseményekre való reagálásra,



kifejezések futtatására,



új felhasználók számára párbeszédablak létrehozására a modellhez.

Ezáltal hatékonyabbá növelhető a szimuláció hatékonysága és rugalmassága. Emellett implementálhatóvá válnak különböző megközelítések, és a modell teljes körűen testre szabható. 10

Metódust az Információs áram fülön található „M” betű fogd és ejtsd módszerrel való behúzásával hozhatunk létre a modellben. Ekkor megjelenik egy, csak a metódus testét tartalmazó ablak. Fontos megemlíteni, hogy metódus létrehozásakor mindenekelőtt ki kell kapcsolni a forráskód öröklése funkciót. Enélkül nem hozható létre metódus, illetve a metódus létrehozásakor látható metódustestet sem módosítható. A kód a változtatások elfogadása fülre való kattintásra lép érvénybe. A modellt ezután nem szükséges alaphelyzetbe állítani, enélkül is láthatóvá válnak a metódus kimenetei [8] [9].

11

4. Megvalósítás Mint említettem, két lehetőségem volt, az Enterprise Dynamics-ban történő megvalósítást illetően. Az egyik, hogy részleteiben készítem el a szimulációt, a másik, hogy elnagyolt szimulációt készítek, a feleslegesnek tűnő részleteket elhagyva, illetve a lényegre koncentrálva. A második megvalósítási lehetőséget választottam, hiszen úgy gondolom, a vázlatos megoldások minden esetben segítik egy komplex munka kialakítási lehetőségeit, hiszen az elvi megvalósítási problémáknak már itt ki kell ütközniük. Ezért először Enterprise Dynamics-ban készítettem el a szimuláció vázát, majd azt kibővítve elkészítettem a szimulációt PlantSim-ben is. Ebben a fejezetben összehasonlítom a két említett programot, illetve bemutatom bemutatom a bennük elkészített szimulációt, kitérve azok részleteinek kialakítására.

4.1 Lehetőségek az Enterprise Dynamicsban A szimuláció megvalósításánál két nézetet használtam. Az első a Model

Layout,

a

tervezéshez

használható nézet. Itt illeszthetjük be az atomokat Library Tree-ből, ahol címszavak szerint láthatjuk rendezve az atomokat.

Mint

láthatjuk

itt

megvalósításhoz

találjuk

a

szükséges

atomokat, tehát a product-ot, azaz a terméket, a source-t, azaz a forrást, a queue-t, az ezeket összekötő vonalakat, a node-okat. Ezen kívül az

anyagáramláshoz

szükséges

anyagokat, és eszközöket is találunk itt, ilyen például a targonca, raklap,

3. ábra Library Tree

12

szállítószalag, konvejor, stb. A másik nézet, amit használtam a 3D tervező nézet, amelyet a Display, 2D Model view helyen tudunk elérni. Itt már a kész szimulációt láthatjuk 3D nézetben. A szimulációt a Run controll ablakban tudjuk elindítani, a Run gombra kattintva. Ugyanebben az ablakban lehetőségünk van a szimuláció futási sebességének megadására, így gyorsabban áttekinthetővé válik a kész rendszer. Az

anyagáramlás

megvalósításához,

illetve

az

anyagáramlás

irányának

meghatározásához engedélyeznünk kell a csatornákat, amit a Model Layout-ban tudunk megtenni a Channels enabled fül alatt. Ekkor láthatóvá válnak a színes pontok, amelyek összekötésével valósul meg az anyagáramlás.

4.2 A szimuláció elkészítésének menete Ahhoz, hogy az anyagáramlás szimulációja megvalósuljon, szükségünk van egy forrásra, illetve egy termékre, amelyek a forrás kibocsát. Jelen esetben én uborkákat szerettem volna. Mivel uborkák egyértelműen nincsenek előre gyártott modellként az ED-ben ezért ezeket magamnak kellett elkészíteni. Létre kell hoznunk egy terméket (product), amelyet módosítanunk kell. Ez a ProductBaseclass ablakban érhető el. Itt, a visualization fülön láthatjuk a termék 2D-s alakját, megadhatjuk, hogy milyen 3D ikont szeretnénk, illetve ennek a színét is. Jelen esetben én Barrel Horizontal-t válaszottam, illetve zöld színt. Ha a másik, a General fült választjuk, akkor a termék méreteit tudjuk megadni x,y,z koordinátákkal. Ez jelen esetben nekem x=0.5 y= 0.2 z=0.1 Most nézzük meg a részletes folyamatot, amelyet a végleges és teljes szimulációban meg kell valósítanom!

13

4. ábra Az uborkagyártás folyamatábrája [10]

Mint láthatjuk maga a gyártási folyamat tizenkilenc részegységből áll, amelyek mindegyike szükséges a minőség megőrzés és a fogyaszthatóság szempontjából, illetve 14

vannak közöttük higiéniailag szükséges lépések is. Nem szükséges azonban ezek mindegyikét ábrázolni a vázlatos szimulációban, egyes lépések összevonhatóak. Ezt úgy oldottam meg, hogy a szimulációmban egyes gépek több folyamatot is elvégeznek, így megvalósul a folyamat szemléltetése, azonban nem kerül újabb atom a szimulációba. A nyersanyag átvételt, illetve a tárolást nem tartottam szükségesnek elhelyezni a szimulációban, hiszen magához a gyártás folyamatához nem tartozik hozzá, sokkal inkább az előzetes munkálatokhoz, illetve az anyagáram a gyárba történő beáramlásához. A szimuláció a vonalra adás fázistól kezdődik, ahol szállítószalagon mennek az uborkák, majd ezeket egy úgynevezett kefés mosóval ellátott gép tisztítja meg. Ez a folyamat több fázisban megy végbe.

5. ábra Az uborkák útja a szállítószalagon a mosóba

Ezután következik a válogatás, amit kézi munkaerővel végeznek. Szemrevételezik az árút, majd a selejtet kiválogatják, és a továbbiakban növényi hulladékként kezelik. Ezután a már kiválogatott, megtisztított uborkákat üvegbe helyezik, majd befűszerezik, ellenőrzik az üvegeket (hiszen ha elrepedt az üveg széle, vagy valamilyen okból selejt, az nem kerülhet a polcokra). Az üvegeket ez előtt felrakják, illetve meg is tisztítják.

15

Ezt a fázist is összevontam, hiszen nem láttam feltétlenül szükségesnek az üvegek tisztításának, és ellenőrzésének bemutatását. Így a szimulációmban egyazon gép végzi el ezeket a munkálatokat, egészen a zárásig, ahol egy szállítószalagon érkeznek a lapkák, amelyeket egy gép helyez rá az üvegekre. Az üvegekre rákerülnek a lapkák, majd egy gép ellenőrzi, hogy a vákuumzárás megfelelő -e. Ekkor kiszedik a selejteket, majd egységrakományt képeznek az üvegekből, amelyeket egy targonca szállít a raktárba. Sajnos egyes műveleteket, mint a selejtek elszállítása, nem az elhanyagolhatóság, hanem a hallhatói licensz miatt nem tudtam megvalósítani, de a szimuláció teljes verziójába belekerülnek. Mivel befőttes üveg, és lapka sem volt az előre elkészített atomok között, ezért ezeket is magamnak kellett létrehozni.

6. ábra Befőttesüveg és lapka

16

A befőttesüvegeknek az alábbi adatokat adtam meg: barrel vertical x= 0.3 y=0.3 z=0.5 A lapkák adatai:

3D ikon: oildrum x= 1 y=1 z= 0.1

Miután az uborkák üvegbe kerültek, azokat lezárták, és ellenőrizték fel is címkézik őket. Ezt a szimuláció szempontjából kétféleképpen lehet megoldani. Az egyik, hogy textúrázom az üvegeket, a másik, hogy megváltoztatom azok színét, ezzel jelezve, hogy felkerült rájuk a címke. A textúrázás nem bizonyult megfelelő megoldásnak, hiszen nem volt kellően látható az üvegen történt változás, ezért az átszínezést választottam.

4.3 Tervezés Plant Simulation-el A tervezés első lépéseként a Szatmári Konzervgyártól kapott folyamatábrát vizsgáltam meg, majd a felépítést az itt látható atomoktól függően vittem fel a rendszerbe. Mint ahogy a folyamatábrán is látható, a rendszer felépítését két oldalról kell megközelíteni, az egyik az üvegek, a másik a nyersanyag oldala. Ez alapján, illetve a Szatmári Konzervgyár weboldalán található videóanyag alapján kezdtem el felépíteni a rendszert. A nehézséget az okozta, hogy a rendszer vázát először Enterprise Dynamics-ban készítettem el, ezért az itt létrehozott logikai séma alapján indultam el, ez azonban különböző a két programban, tehát kissé eltérő szemléletet igényel. Itt is, akárcsak Enterprise Dynamics-ban kétféle nézetben látható a modell, egy tervező nézetben, ezt PlantSim-ben keretnek, vagy Frame-nek nevezik, és egy 3D-s nézetben, 17

amelyet a nézeten található 3D nézet aktiválása ikon tesz láthatóvá. Ezen felül minden MU-nak van önálló 3D-s nézete, amelyen szerkeszthetőek megjelenési tulajdonságai. Enterprise Dynamics-ban az először végeláthatatlannak tűnő csatornák rengeteg segítséget

nyújtanak,

azonnal

látható

mi

mivel

van

összekötve,

amolyan

elektrotechnikai tanulmányok alapján ismert bemenet-kimenet alapon. Ezzel szemben PlantSim-ben egyszerű összekötő nyilakkal kötjük össze a rendszer részeit. Enterprise Dynamics-ban külön Product-ot kell rendelnünk a forráshoz, amely meghatározza a belőle kiáramló árut. Ezzel szemben FlexSimben a bemenet határozza meg a belőle kiáramló mozgó egységet, az MU-t. Ezek viselkedését magunk határozhatjuk meg. A PlantSim esetében rendelkezésünkre áll néhány alap MU, vagy mi magunk is tervezhetünk ilyet. Mivel az uborka, üvegek nem szokványos MU-k ezért magam kellett megtervezni a számomra szükséges mozgó egységeket. A PlantSim .jt kiterjesztésű 3D-s objektumokat támogat, ezért az interneten fellelhető kész objektumok nagy része nem volt alkalmas számomra. Végső megoldásként magam szerkesztettem az interneten található kész objektumokat. Erre azért volt szükség, mert gyakran sem méretük, sem elhelyezkedésük, sem kiterjesztésük nem volt alkalmas számomra. Ehhez az AUTODESK 3DS Max Design Student verzióját vettem igénybe, ami bár időkorlátos, de ingyenesen letölthető az internetről. A következő MU-kat használtam fel: 

uborkát reprezentáló MU [11],



üveg, lapka nélkül [12],



üveg lapkával [13]

A kezdeti 3D-s objektumokat szerkesztés után importáltam a PlantSim-be a következő módon: duplikáltam a PlantSimben meglévő alapvető MU-k egyikét, majd átneveztem a duplikált MU-t. Ezt követően az osztálykönyvtárban lévő MU-t szerkesztettem 3D-s nézetben. Itt különböző transzformációs műveleteket adhatunk meg, amelyek az eltolás, elforgatás illetve a skálázás. Ezek mindegyikét használtam, hiszen a meglévő modelleknek még szerkesztés után sem volt teljesen megfelelő mérete, illetve elhelyezkedése. Importálás után hozzá kell rendelni az MU-t a bemenethez, ami a

18

bemenet MU kiválasztás fülén végezhető el. Ez után már a kívánt MU lesz a modellen belüli mozgó egység. A rendszert először tervező nézetben készítettem el, majd ezeknek külön szerkesztettem 3D-s tulajdonságait. Mint a folyamatábrán látható, a gyártás tizenkilenc különböző gyártási folyamaton megy át. A nyersanyag átvételtől az egységrakomány képzésig. Ezekhez a szimulációban szállítószalagokat rendeltem, hiszen ez a valóságban is hasonlóképp történik, azonban a valóságban nyilvánvalóan egy egységnek számít maga a művelet, és a műveletek közötti szállítás. Az alábbi képen látható az elkészült Keret.

Fontos, hogy a rendszer részeinek

megfelelő és egyedi neve legyen, azonban nem lehet azonos neve két objektumnak, ezért találóan kell elnevezni a hasonló funkciót betöltő funkciókat is. Fontos még, hogy rövid névvel legyenek ellátva, hiszen egy nagyobb rendszer esetében, ha meg akarjuk jeleníteni a neveket, akkor a hosszú nevek átláthatatlanná teszik a rendszert.

7. ábra A szimuláció 2D-s modellje, a Frame

Ha elkészült a rendszer, az állomásokhoz dolgozók rendelhetőek, ennek kétféle módja van, rendelhető egy dolgozó is az adott állomáshoz, illetve dolgozócsoport is. Én a 19

dolgozócsoportot választottam, hiszen a valóságban sem egy ember koordinálja, illetve végzi a gyártás egyes részeit.

8. ábra A szimuláció 3D-s modellje

4.3.1 Selejtkiválasztás A modell létrehozásakor utolsó lépésként a selejtkiválasztást végeztem el. A folyamatábrán látható, hogy a modellben négy helyen kell selejtkiválasztást eszközölni: 

az üveg oldaláról ki kell válogatni a selejt üvegeket,



a növény oldaláról el kell távolítani a növényi hulladékot,



a zárás részlegen a selejt lapkákat,



illetve a végterméknél a selejt végtermékeket.

Felmerült a kérdés, hogy jelezzem-e a selejt MU-kon, hogy azok valóban selejtek. Végül úgy döntöttem, hogy mivel ezek emberi szemmel nem mindig könnyen látható hibák, és a való életben is gépek ellenőrzik minőségüket, ezért nem szükséges fizikailag látható módon jelezni az MU-k minőségét. A megvalósításnál többféle szempontot figyelembevettem. Kezdetben a legegyszerűbb módon oldottam meg a feladatot, tehát forrást és nyelőt alkalmazva. Így azonban nem

20

volt tökéletesen koordinálható a be - illetve kiáramló anyagmennyiség, tehát ezt a módot el kellett vetnem. Két megoldás maradt a selejtek kiválasztására: 

A feladat megoldható metódussal, amelyben szükség van PlaceBuffer, Quality és egy PartNotOk objektumra, majd a metódus programja az adott egység Quality attribútumát true-ra állítja, ha a PartNotOk állomásra érkezik. Ezután definiálható egy kimenetet, amely a megsemmisítést hivatott reprezentálni, vagy az esetleg javítható termékeket visszaküldhetjük (természetesen ekkor nincs szükség kimenetre) a gyártósor indulási pontjára.



A másik megoldás, ha beillesztünk a rendszerbe egy áramlásvezérlőt. Ez az elem képes kezelni a bemenetére érkező, és további két kimenetén távozó MU-kat.

Jelen esetben a második megoldást választottam, hiszen így százalékos arányban koordinálhatóvá

válik

a

rendszerben

lévő

selejtek

száma.

Megadásakor

meghatározhatóak belépési illetve kilépési stratégiák és felhasználói attribútumok. Belépési stratégiánál a

legrégebbi igény volt

a legmegfelelőbb a gyártás

átláthatóságának szempontjából. Kilépési stratégiánál megadható a stratégia, mi szerint válassza ki a rendszer a hibás elemeket. Ezek különbözőképpen kezelhetőek (ciklikus, véletlen, metódus, kiválasztás, százalék, stb.). A százalékos arányt választottam, mert a gyárak is százalékos arányban kezelik a selejtek számát, így, ha egy termékből esetleg több selejt érkezne, vizuálisan láthatóvá válik, hogy ez mennyire lassítja a rendszer teljesítményét. Az fűszer előkészítés folyamatot megelőzi az üvegek ellenőrzése, tehát itt végre kell hajtani a selejtkiválasztást. A képen látható statisztikában 97% jó üveg, és 3% selejt üveg statisztikája látható. Érzékelhető, hogy a fűszer előkészítő folyamatban a gép nem működik állandóan, hiszen a rendszer csak késleltetve, és lassabban továbbít üvegeket (hiszen felesleges üvegeket küldenünk a gyártósorra, amíg nem kerülhet bele termék). Természetesen, ha a bemenetről érkező üvegek mennyiségét és gyorsaságát növelném, a rendszer ezen része kihasználtabb lenne, azonban később alakulnának torlódások.

21

9. ábra Statisztikai adatok abban az esetben, amikor 97% jó, és 3% selejt van a rendszerben

Látható, hogy a folyamatnál működő gép 45,71%-ban működik. Működése alatt 36 MU haladt át rajta, illetve távozott. Azonban, ha az arányokat megfordítjuk, ezáltal sokkal több selejt kerül a rendszerbe, az az egész gyártási folyamatot lelassítja.

10. ábra Statisztikai adatok abban az esetben, amikor 3% jó és 97% selejt van a rendszerben

Az arányok megfordításánál a gép csak 3.95%-ban működött, és csak egy MU lépett be, illetve távozott az állomásról. Fontos tehát a rendszer megfelelő időzítése, illetve, a selejtek megfelelő kezelése, hiszen ezek lelassítják a gyártás folyamatát, és veszteségessé teszik azt.

22

4.3.2 SimTalk A fenti ábrán látható, hogy az adott gép a szimuláció idejének mekkora arányában volt várakozó illetve dolgozó státuszban, amely úgy kérdezhető le, hogy szimuláció közben megnyitom a modellhez tartozó statisztikákat. Saját statisztika is készíthető a PlantSim saját programozási nyelvén, a SimTalk nyelven.

Jelen esetben az egységrakomány-képzéshez tartozó várakozási idő

folyamatos megjelenítésére készítettem programot. A programot meg kell hívni az adott gép valamely eseményénél, amely a Frame-ben való megnyitás után a Kontrollok ablakban tehető meg. Én az egységrakomány-képző egység kilépési eseményéhez rendeltem hozzá a kód futtatását, amely így minden olyan alkalommal meg fogja hívni az alábbi metódust, amikor az egységből elem távozik.

is tab : table; throughput_log : table; i : integer; do tab.create; throughput_log.create; @.statistics(tab); throughput_log[1, throughput_log.yDim+1] := to_str(tab["waitingTime", 1]); for i := 1 to throughput_log.Ydim loop print throughput_log[1, i]; next; end;

23

11. ábra Statisztikai adatok az a gép várakozási idejéről idő függvényében

A program kimenete a konzolon látható, itt az átlagos várakozási idő figyelhető meg az adott gépre vonatkozóan. Ez azért tér el a fenti Statisztikai adatoktól, mert ezek az adatok fent százalékos arányban és csak a program aktuális állására viszonyítva jelennek meg, itt azonban minden egyes egységrakomány képzés után folyamatosan látható a konzolon az átlagos várakozási idő. A kódban lekérjük és eltároljuk egy táblázat típusú lokális változóban az adott feldolgozóegységre vonatkozó statisztikákat. Ebben minden statisztika benne lesz. Ezután a várakozási időnek megfelelő sort kiszedjük a táblázatból (amely valójában egy asszociatív tömb), és letároljuk egy másik táblázatban. Ezen változó típusát azért táblázatnak választottam meg, hogy a későbbiekben könnyen bővíthessük a kódot, ugyanis jelen implementáció esetén, ha például az átlagos blokkolt állapotban töltött időt is meg szeretnénk jeleníteni, csupán egy sort kellene hozzáadnunk a meglévő kódhoz. A kód hátralevő részében ugyanis ezen saját táblázatunkon szaladunk végig soronként

egy ciklussal, és a sorait

kiírjuk a konzolra.

Az általánosított

implementációnak köszönhetően a metódust a kód módosítása nélkül bármilyen olyan feldolgozóegységre vonatkozóan lefuttathatjuk, amely szolgáltatja az általunk kódban igényelt statisztikai adatokat.

24

5. Optimálás A tervezési folyamatban, mialatt a tervezési fázisból késztermék lesz, rengeteg szempont figyelembevételére szükség van. Ezek gyakran a termékek biztonságos és gazdaságos felhasználásához kötődnek; olykor viszont gyártási. használati, javíthatósági szempontok is előtérbe kerülnek. A tervező – a tervezési szempontok szerint – a legmegbízhatóbb, legkisebb súlyú, legolcsóbban legyártható, stb. terméket kívánja megalkotni. A tervező keresi a tervezési szempontok és a minőségi eljárásoknak olyan együttesét, amely pl.: a legolcsóbb terméket eredményezi amellett, hogy a minőségi elvárások teljesülnek. A tervezési fázisban elvégzett optimálási feladatok mellett nagy jelenősége van a termelési folyamatban elvégzett optimálásnak is, hiszen a legjobban megtervezett alkatrész is úgy értékes, ha azt gazdaságosan sikerül legyártani. [14]

12. ábra Az optimálás logikai struktúrája [14]

25

Olyan gyakorlati életben is felhasználható dolgozatot szeretnék készíteni, ami a gyár számra is hasznos lehet, így elkészítem a gyártási haszon optimálását. Mivel az árak az idő elteltével rohamosan változnak, azt szerettem volna, ha programom időtálló marad, ezért kerültem a beégetett adatokat. Létrehoztam egy XML-t, amely tartalmazza az árakat és feltételeket, így ha új terméket gyártunk, vagy megváltoznak az árak, akkor egy egyszerű XML-t módosítva optimálható a gyártás az új árakkal, vagy feltételekkel. A haszon a bevétel és a kiadás különbsége, tehát rendelkezni kell olyan adatokkal, amelyek ezeket reprezentálják. Ebből a szempontból szerencsés vagyok, hiszen rendelkeztem a rendelkezésre álló anyagok listájával és árával is. A gyártott termékre ún. „felöntőlé” kerül, amely meghatározott recept alapján készül. Ennek hozzávalóit 100l-es nagyságrendben kaptam meg. 100l felöntőléhez szükség van 95l vízre, 2,3l ecetre, 0,15 kg borkőre, 2,5 kg sóra, és 3,5 kg cukorra. A jelenlegi nagykereskedelmi árakkal számolva 100l felöntőlé 1614 Ft-ba kerül, de hogy könnyebben számolhassak vele, ezeket literben adtam meg a programban, így egy liter felöntőlé jelenleg 16,14 Ft-ba kerül. [15]

5.1 .NET, C# A dolgozatomhoz tartozó optimálást C# nyelven készítetem el. Napjainkban egyre elterjedtebb a .NET Framework, amelynek egyik fő nyelve a C#. Maga a .NET platform a Microsoft, Intel, Hewlett Packard és egyéb cégek közreműködésével megfogalmazott CLI implementációja. A CLI: Common Language Infrastructure egy szabályrendszer, ami több részre oszlik: 

CTS: az adatok kezelését, az egymással való interakciót, a memóriában való megjelenést, stb. írja le,



CLS: CLI kompatibilis nyelvekkel kapcsolatos elvárásokat tartalmazza,



VES: a futási környezetet specifikálja, nevezik CLR-nek is. [16]

A .NET nem egy programozási nyelv, hanem egy környezet. Bármely nyelvnek létezhet .NET implementációja. Jelenleg kb. 50 nyelvnek létezik .NET megfelelője. A 26

hagyományos programozási nyelveken megírt programok először úgynevezett natív kódra fordulnak le. Ezzel szemben a .NET először egy köztes nyelvre (MSIL) fordítja le a forráskódot, majd szabványosítás után CIL nyelvű állomány keletkezik belőle. Ez a kód a telepített .NET Frameworknek szóló utasításokat tartalmaz. A programot első futtatáskor egy Just In Time fordító kezeli, lefordítja gépi kódra, amit a processzor már tud kezelni. Első fordításkor egy szerelvény, úgynevezett Assembly keletkezik. Ez egy vagy több fileból is állhat, tipikusan .dll, vagy .exe kiterjesztéssel. A C# fejlesztését először 1999-ben kezdték el. A C# tisztán objektumorientált, általános felhasználású típus biztos nyelv. Tervezésénél a legnagyobb produktivitás elérése volt a cél. Elméletileg platform független, de a legjobb hatékonyságot a Microsoft implementációja biztosítja.[16] Munkámat Visual Studio 2010-ben készítetem, 4.0 Framework alatt. Választásom egyértelmű volt, hiszen tanulmányaim alatt a C# nyelvvel ismerkedtem meg a legjobban.

5.2 Visual Studio A Visual Studio egy a Microsoft által fejlesztett integrált fejlesztőkörnyezet (IDE), amely több (elméletileg bármilyen) programozási nyelvet is támogat, és a végletekig testre szabható. Segítségével különböző programnyelveken fejleszthetünk Windows asztali alkalmazásokat, Windows 8 appokat, Windows Phone mobilalkalmazásokat, webalkalmazásokat, web- és egyéb szolgáltatásokat, Silverlight alkalmazásokat. A Windows 8 appok közzétételét Windows Store integráció segíti, illetve a – szintén Microsoft által fejlesztett – Azure felhőplatformra is közvetlenül a fejlesztéshez használt programból tölthetjük fel a kész alkalmazásunkat, ezen művelet elvégzéséhez nincsen szükség külső, harmadik féltől származó komponensre. Az ASP.NET és egyéb webalkalmazások lokális futtatásához és teszteléséhez a Visual Studio megfelelő webes komponenseinek telepítésekor automatikusan települ egy lebutított, könnyűsúlyú webszerver, illetve igény szerint IIS Expresst is telepíthetünk.

27

Fejlett szövegszerkesztővel rendelkezik, amely rengeteg nyelvet ismer, és a szintaktikának megfelelően színezi a kódot a könnyű átláthatóság kedvéért. A kódkiegészítést az IntelliSense technológia teszi tökéletessé: a programozási nyelv figyelembe vétele nélkül bátran kijelenthetjük, hogy a legjobban testre szabható, legkényelmesebben használható fejlesztői környezetek egyike, amely teljesítményben is maga mögé utasít sok vetélytársat. A szövegszerkesztője az IDE-ktől elvárható funkciók mindegyikével rendelkezik, úgy a kommenteléssel, refaktorálással, definíció megkeresésével, különféle navigációs elemekkel. Rengeteg kiegészítő érhető el hozzá, és igény szerint továbbiak is készíthetők a nyílt API-nak köszönhetően. A kiegészítők segítségével adatbázisműveleteket (pl. két adatbázis-séma összehasonlítását, és az egyikből a másikba történő transzformáció

szkriptjének

legenerálását)

végezhetünk

el

közvetlenül

az

alkalmazásfejlesztéshez használt, megszokott programkörnyezetünkből. A Visual Studio a Microsoft által fejlesztett Team Foundation Server (TFS) verziókövető és work item tracking (WIT) rendszerrel mélyen integrálva van, így a hatékony csapatmunka megvalósításához minden a rendelkezésünkre áll egyetlen programban. Természetesen más verziókezelő rendszerek, pl. a Subversion (SVN) támogatása is megoldott. A hibakeresés egyik legjobb eszköze a Visual Studio. Beállíthatjuk, milyen típusú kivételek esetén szeretnénk, ha a hibakereső értesítene minket, valamint töréspontok beszúrásával a lehető legközelebbről szemlélhetjük, mi is történik valójában alkalmazásunk futása közben. Érdekesség, hogy pl. webalkalmazás-fejlesztés esetén, amennyiben a tesztelést Internet Explorer böngészővel végezzük, a kliensoldali, böngésző által futtatott JavaScript kódot is a Visual Studioba megszokott környezetében és eszközeivel debuggolhatjuk, nem szükséges ehhez a böngésző saját hibakeresőjét használnunk. Az Internet Explorer integrációja ennél sokkal mélyebb szintű: kényelmi funkció, hogy amint a lokálisan futtatott webalkalmazás debuggolását leállítjuk, az azt megjelenítő böngészőlap is automatikusan bezárul, és fordítva. Így nem fordul elő olyan, hogy huzamosabb tesztelés után felhalmozódnak a böngészőnkben az alkalmazás különböző verzióit megjelenítő lapok, amelyeket kézzel vagyunk kénytelenek bezárni minden alkalommal. 28

Bár számtalan programozási nyelvet támogat, elsősorban C, C++ és C#/Visual Basic nyelvű programok fejlesztésére használják. A C# és a Visual Basic a Microsoft által feltalált és gondozott nyelv, amellyel a .NET keretrendszerre írhatunk tetszőleges alkalmazást, amely így szűkebb értelemben platformfüggetlen lesz, és magával hordozza az ily módon történő fordítás és futtatás minden előnyét és hátrányát. Ezen két nyelv elsődleges fejlesztői környezete a Visual Studio. A C és C++ nyelvek már több évtizedes múltra tekintenek vissza. Szerepük azonban korántsem elhanyagolható napjainkban sem: a C gyakorlatilag minden modern programozási nyelv és keretrendszer alapja, illetve a UNIX/Linux operációs rendszerek kernelje is ebben íródott. A C++ széles körben használt még az új projektekben is, hiszen C++ fordító gyakorlatilag bármilyen platformra létezik és készen rendelkezésre áll, a lefordított állományok pedig már natív kódot tartalmaznak, amelyek így jelentősen nagyobb teljesítményt tudnak felmutatni, mint a „divatosabb” nyelvek, mint pl. a Java és a C#. A Visual Studio licenszét egyszer kell csak megvásárolni, használata nem rendszeres díjfizetéshez van kötve, továbbá az újabb verziókra való áttérés általában rendkívül kedvezményes áron megoldható. A Microsoft magáncélú, nem profitorientált használatra bárki számára rendelkezésre bocsát egy funkciókban erősen csökkentett, de kezdő fejlesztők és ismerkedők számára elegendő, Express verziót a mindig aktuális kiadásból, amely ingyenesen letölthető és használható korlátlan ideig. A DreamSpark (korábbi nevén Microsoft Developer Network Academic Alliance, MSDNAA) program keretében felsőoktatás keretében tanuló hallgatók világszerte a Microsoft többi terméke mellett a Visual Studio bizonyos verzióihoz is hozzájuthatnak díjmentesen a hallgatói jogviszony fennállása alatt, amennyiben nem üzleti, hanem a tanulmányaikkal szorosan összefüggő célokra használják azt. [21]

5.3 Random Search algoritmus A Random Search egy sztochasztikus eljárás, tehát olyan eljárás, amely (ál)véletlen számok segítségével generál új próbapontokat. A tiszta véletlen keresés (PRS – Pure Random Search) az egyik leggyakrabban használt sztochasztikus eljárás.

29

A keresési módszerek is pontok halmazával dolgoznak. A halmaz elemeinek strukturált formában való cseréje helyett újabb pontok véletlen pontválasztásból vagy véletlen keresési irány menti egyirányú keresésből keletkeznek. [17] Egyenleges eloszlásban generálunk pontokat egy tartományon, és a legkisebb értékűt eltároljuk, mint a globális minimum pont közelítését. Megmutatható, hogy néhány egyszerű feltevés után y (1) = min{f(x1), …, f(xN)} valószínűségi változó eloszlásfüggvénye F(1) (y)= 1 – (1 – μ(y)N

ahol μ(y) az y-hoz tartozó nívóhalmaz mértéke,

μ(y) = P (f(x) ≤ y. Egy régi

megfigyelés szerint annak valószínűsége, hogy az N+1 húzással jobb pontot találunk, ha már egy húzás volt

, és K újabb pontra ez a valószínűség K/(N+K).

A sztochasztikus folyamatokra jellemző, hogy ha N  ∞, akkor a globális optimumot kapjuk. Ez természetesen csak elméletben lehet megnyugtató, hiszen a valódi cél elérésének valószínűsége nagyban függ a sikerterület méretétől. [14]

30

6. Az optimálás kezdeti lépései A feladat megtervezésénél több igényt is figyelembe vettem, és eszerint választottam meg az algoritmust, ami szerint optimálni szeretném a gyártást. Végül azért választottam a Random Search-öt, mert egyszerű implementálni, és kis problématérre nagy valószínűséggel optimum közeli eredményt ad, viszonylag rövid idő alatt. Szakdolgozatom

mindenképp

ki

szerettem

volna

egészíteni

egy

optimálási

feladatrésszel. Már csak az volt kérdéses, hogy az óriási gyártási rendszer melyik részét optimáljam. Felmerült az eshetőség, mi szerint az üvegméretek optimálása érdekes feladatnak bizonyulhatna, ezek azonban szabványos üvegméretek, amelyeket a gyár évtizedek óta használ, így megkérdőjelezhetővé válhatna a program hasznossága, nem képviselhetne valódi értéket. Hasonló probléma miatt vetettem el azt is, hogy azt optimáljam az uborkák milyen kombinációit érdemes egy méretű üvegbe rakni. Ez azért lenne felesleges, mert egy üvegbe csak egyazon méretű uborkák kerülhetnek. Az uborkák még a gyárba kerülés előtt egy válogatási folyamaton mennek keresztül, ahol méretük szerint osztályozzák. Ugyanazon méretű uborkák kerülnek zsákokba, és ezeket szállítják a gyárba. A termelők így mérlegelés után azonnal tudják, az általuk termelt uborkák méretét és súlyát. Erről mérlegjegyet kapnak, amelyen szerepel az általuk bevitt uborkamennyiség méretenkénti százalékos osztályozása. Én is ilyen mérlegjegyek alapján dolgoztam, hiszen így tudhatom, hogy a gyár milyen méretű uborkákból milyen arányban kapott. Mivel, mint mindenhol, a Szatmári Konzervgyárban is kulcsfontosságú a bevétel, ezért úgy döntöttem az uborkabefőtt gyártás alatt befolyt hasznot szeretném optimálni. Mint minden optimálási feladatot, először a változók, feltételek, és a célfüggvény meghatározásával kezdtem. Mint már említettem az uborkabefőtt gyártás alatt befolyt hasznot szeretném optimálni, ami a gyártás alatt befolyt bevétel és a kiadás különbsége, tehát: Célfüggvény = Bevétel- (felöntőlé ára + uborka ára + befőttesüveg ára + befőttesüvegre kerülő lapka ára+ gyártási költség)

31

A gyártási költség ugyanannyinak tekinthető minden termék esetében, illetve a pontos költségre vonatkozó adataim nem voltak, így ezt elhanyagolhatónak tekintettem. Természetesen a későbbiekben, ha erre szükség van, ez is egyszerűen beilleszthető az XML-be. Mivel szüleim uborkatermeléssel foglalkoznak, illetve a Szatmári Konzervgyár is rengeteg információt bocsátott rendelkezésemre, rendelkeztem az ehhez szükséges adatokkal. Szükségem volt az uborka árára, amely kilogrammban értendő, de méretenként eltérő. A gyár öt különböző méretosztályú uborkát vásárol fel, ám ezekből csak négy méretből készül az általam optimált termék, az ötödik savanyító üzembe kerül. Szükségem volt még az üvegek, egyéb hozzávalók árára, illetve az arányokra, hogyan oszlik el az uborkatermés méretenként. Erre azért van szükség, mert hiába szeretnénk csak kis uborkát gyártani, ha abból terem a legkevesebb, illetve ez évenként is változó lehet, hiszen a termés mindig más. Ezért ez is bekerült az XML-be, így ha arányaiban változnak a termési viszonyok, egyszerűen felvihetőek a változások. Változók: diszkrét változónak tekinthetők az uborka, illetve üvegméretek, emellett további változó a termés százalékos eloszlása. Meg kell határozni feltételeket. Jelen esetben a boltokból, és a gyár által rendelkezésemre bocsátott információkból dolgozhattam. Természetesen vannak más üvegméretek is, de a Szatmári Konzervgyár a következő három fajta üvegbe gyárt savanyú uborkát: 

kis üveg: nettó tömege 460g, töltőtömege 300g,



közepes üveg: nettó tömege 900g, töltőtömege 500g,



nagy üveg: Nettó tömege 5000g, töltőtömege 2900g.

Ezekhez az üvegekhez kapcsolódnak feltételek, hiszen bizonyos üvegbe csak bizonyos méretű uborkát gyártanak. 

Kis üvegbe csak 2 - 5 méretű uborka kerülhet,



közepes üvegbe csak 3 - 6, vagy 5 - 8 méretű,

32



nagy üvegbe csak 6 – 9 méretű.

Ezek fizikai, illetve költséghatékonysági okokkal is magyarázható adatok, hiszen a 6 -9 méretű uborka fizikai méretei alapján nem fér bele a kis üvegbe, de a nagy üvegbe igen. Ezért is olcsóbb, hiszen csak egyféle termék gyártásához használható fel, illetve ebből terem a legtöbb. Ha azonban kis méretű uborkát helyeznénk a nagy méretű üvegbe, az az 5000g nettó tömegű üvegbe 2900g töltősúly helyett sokkal többet eredményezne, hiszen a kis uborka helykitöltése sokkal jobb, illetve ez a legdrágább a frissáruk közül, ezért a gyártás veszteséges lenne. Azt is fontos megjegyezni, hogy a különböző méretű üvegekhez különböző méretű, és árú fedél, úgynevezett lapka tartozik, illetve az üvegek ára is méretenként eltérő. Ezeket is rögzítettem az XML-ben, tehát ár változás esetén csak az XML-t szükséges módosítani.

6.1 Optimálás C# nyelven A feladatot Windows Forms Application-ként valósítottam meg. A futtatásához Microsoft Windows operációs rendszer szükséges, amelyre a .NET framework legalább 4-es verziója telepítve van. A programban többszálú feldolgozást végzek, amelyhez BackgroundWorker-t használtam. A Form-on elhelyeztem egy gombot, amin alapesetben a „Generate” felirat

olvasható,

ha

azonban

megnyomjuk a gombot, elkezdődik a generálás, így a gomb feliratát „Cancel”re

cseréltem.

Ha

generálás

közben

megnyomjuk a „Cancel” gombot, a generálás leáll, a felirat újra „Generate” lesz.

A

generálás

ProgressBar-on

jelzem

alatti

haladást

(amelyen

a

13. ábra Az optimáló program főképernyője

33

BackgroundWorker által jelentett százalék látható). Ehhez először regisztrálni kell a BackgroundWorker példány eseménykezelőit a megfelelő eseményekhez:

-

DoWork: ezt a metódust szeretnénk a háttérben lefuttatni, ez tehát maga a generálás,

-

RunWorkerCompleted: ez a metódus hívódik meg a főszálon a háttérszálon futtatott kód futásának befejeződésekor, ezt az eredmény megjelenítésére használjuk,

-

ProgressChanged:

akkor

használhatjuk

ezt

az

eseményt,

ha

a

BackgroundWorker példány WorkerReportsProgress tulajdonsága igaz értékű, ide egy olyan metódust kell regisztrálnunk, amely megkapja a háttérszáltól a százalékos haladás mértékét, majd azt megjeleníti a felhasználói felületen. Én ehhez egy ProgressBar vezérlőt használtam. A haladás jelzését is nekem kellett megvalósítani a háttérszálon futtatott metóduson belül. Ezeket a regisztrációkat az alkalmazás betöltődésekor végzem el. Majd a gombra kattintás után vizsgálnom kell, hogy fut-e már generálás. Ha fut, leállítom, az isGenerationPending flaget hamisra állítom (hiszen befejeződik a generálás) megváltoztatom a gomb feliratát, illetve a ProgressBar értékét kinullázom. Ha nem fut generálás, az isGenerationPending flaget igazra állítom, hiszen most kezdődik a generálás. A gomb feliratát lecserélem „Cancel”-re, majd elindítom a generálást. A generálást, vagyis a háttérszál munkáját ténylegesen a BackgroundWorker példány RunWorkerAsync() metódusának meghívásával indítom el. Jelen feladatban azért volt célszerű háttérszálon végezni a generálást, mert az a felhasználó szempontjából mérhető ideig (percekig, vagy megfelelő értékek esetén akár órákig, napokig is) tart. Ha a főszálon végezném ezt a hosszú számítássort, az operációs rendszer néhány másodperc után azt jelezné számomra, hogy az alkalmazás nem válaszol, ami a felhasználóban azt a téves gondolatot ébresztheti, hogy „lefagyott”, ami a generálás eredménytelen, erőszakos megszakításához vezethet. Továbbá ebből fakadóan a generálás gombbal történő leállítását sem lehetne megvalósítani, ha mindent a főszálon futtatnánk. Így a főszálnak megmarad az alkalmazás grafikus felületének megjelenítése, kezelése, 34

megfelelő események vizsgálata, a háttérszálon pedig a hosszadalmas számításokat végezzük. Így interaktívabbá válik a programunk, mivel egy ProgressBar segítségével folyamatosan tájékoztatjuk a felhasználót, hogy a generálás még fut a háttérben. Ha pedig ő ezt meg szeretné szakítani, mert például előre nem látható okokból le kell állítania a gépét, vagy rájött, hogy rossz adatokat adott meg az XML konfigurációs állományban, ezt elegánsan és magától értetődően megteheti a „Cancel” feliratú gombra kattintva. A generálás befejezése után meg kell jelenítenem a generálás eredményét. Először meg kell vizsgálnom, hogy befejeződött-e a generálás, tehát ha az eredmény nem null vagy üres String (!String.IsNullOrEmpty(result)). Ekkor először szintén visszaállítom az isGenerationPending flaget hamisra, illetve a gomb feliratát is megváltoztatom, hogy a program a későbbiekben képes legyen további generálásokat futtatni anélkül, hogy be kelljen zárni és újra el kelljen indítani azt. Ezután egy MessageBox-ban megjelenítem a generálás eredményét. Végül az eredményt üres Stringre állítom, hiszen újra megnyomhatom a „Generate” gombot, ezáltal újra generálhatok, amely generálás eredménye nem kell, hogy megegyezzen a most kapott eredménnyel – a konfigurációs állomány ugyanis megváltozhatott időközben.

Ha a felhasználó megszakítja a futást, értesülnie kell, hogy ez ténylegesen megtörtént. Ezt ugyancsak egy MessageBox-ban teszem meg. Majd újra ki kell nulláznom a ProgressBar értékét, hiszen azóta nem reportolhatott még a BackgroundWorker. 14. ábra Az optimáló program értesítése megszakítás esetén

6.1.1 Üzleti logika tervezése Az XML-ben lévő adatoknak külön logikai osztályban hoztam létre getterrel és setterrel ellátott property-ket.

35

Az üzleti logikai kitalálásánál a legfontosabb szempont, hogy valóban mit is szeretnék optimálni. A nyereséget szeretném, ám ennek többféle aspektusa lehet. A program egy korábbi változatában azt vizsgáltam, mely uborkát érdemes, mely üvegbe gyártani, és egy üveg uborka legyártása után mennyi haszon keletkezik. Az értékek megfelelőek voltak, azonban ezek diszkrét értékek, és így nem valódi optimálás. Új változót kellett felvinnem a rendszerbe. Olyan változóra esett a választásom, amely az uborkák méretbeli eloszlását tartalmazza. Ezáltal sokkal komplexebb nyereségbeli kérdések merülnek fel, amelyeket érdemes vizsgálni. A gyár tudja, hogy mennyi üveg savanyúságot szeretne gyártani összesen. Tudja annak az eloszlását is, hogy mely méretű uborkákból mennyi érkezett be a gyárba, hiszen ez az adat nyilvánvalóan minden évben rendelkezésre áll, miután a beszállítók mindegyikétől beérkezett az áru. Tudja, hogy az üvegméretek feltételek is. Ezáltal optimálható, hogy az eloszlás szerint mely méretű uborkából mennyi üveggel érdemes gyártani, illetve ha ezek legyártásra kerülnek, mennyi lesz a gyár teljes haszna. A legyártani kívánt üvegek száma eltérő lehet, illetve gyártási időszakonként is eltér, hiszen a nyár végével kevesebb nyersanyagból kevesebb késztermék állítható elő. Ezért az XML-ben lévő TotalQuantity elem értékeként megadható, hogy hány üveg uborkát szeretnénk gyártani összesen. A programkódot régiókba szerveztem, hogy így átláthatóvá tegyem a forráskód részeit.

6.1.2 Üzleti logika megvalósítása Az üzleti logika megvalósításához adott mennyiséghez le kell generálnom egy véletlenszerű eloszlást. Ki kell számolnom minden használható üvegméret-uborkaméret kombinációt, illetve meg kell határozni az így befolyt hasznot. A haszon az adott méretkombináció piaci készterméke egységárának és az adott mennyiségű és minőségű uborka, üveg, felöntőlé, lapka összköltségének a különbsége.

36

foreach (var kvp in currentGeneration) { foreach (var pickleSize in kvp.Value) { value += (pickleSize.Key.NetValues.Single(ps => ps.PickleWeight == kvp.Key.PickleWeight).Value (kvp.Key.FullPrice + kvp.Key.LiquidContent * rootNode.LiquidContentUnitPrice + pickleSize.Key.Price * kvp.Key.PickleWeight)) * pickleSize.Value; // }

A random search lényege, hogy generálok véletlen számokat, amelyek megfelelnek az általam támasztott követelményeknek (üvegméret-uborkaméret kombináció), majd vizsgálom, hogy az így kapott haszon nagyobb-e, mint az eddigi maximális haszon. Ha nagyobb, eltárolom maximálisként, majd ezt folytatom a következő véletlen értékkombinációval, ha azzal nagyobb volt a hasznom ő lesz az új maximális, ha nem, veszem a következő véletlen számot és ezt folytatom egészen az XML-ben meghatározott iterációszámig. Le kell kérnem hányféle méretű uborkát helyezhetek az üvegbe: IList actualPickleSizes = x.LowerBoundary >= jar.MinPickleSize jar.MaxPickleSize).ToList();

rootNode.PickleSizes.Where(x && x.UpperBoundary

=> <=

Majd ezeket összeszámolom. Később le kell kérnem az ehhez tartozó uborkaméretmennyiség értékpárokat. Végül meg kell határozni, hogy melyik üvegméret-uborkaméret kombinációból mennyit gyártson le a gyár. Fontos, hogy az XML-ben meg kell határozni egy mennyiséget, amennyit gyártani akarunk. A program meghatároz egy értéket az első méretű üvegre, így aztán a második és harmadik méretre már csak az összmennyiség és az eddigi mennyiség különbsége használható fel. Az utolsó méretnél a fennmaradó teljes mennyiséget felhasználjuk. Így sosem generálódik olyan kombináció, amely a célmennyiségnél több vagy kevesebb üveg legyártását eredményezné.

37

15. ábra Az optimáló program által meghatározott optimális gyártási mennyiség

38

7. Felhasználói kézikönyv A program használata minimális informatikai tudást igényel.

Ha nincs feltelepítve

számítógépére a .NET keretrendszer 4.0-s vagy annál újabb verziója, telepítse fel, ez ugyanis szükséges a program futtatásához! Nyissa

meg

a

programhoz

tartozó

uborka.xml

állományt

tetszőleges

szövegszerkesztővel (Notepad++ ajánlott). Az xml-ben található TotalQuantity elemben megadható, hogy mennyi üveg uborkát szeretne gyártani összesen. A PickleWeight-nél található az üveg töltősúlya, a Price-nál megadhatja az üveg darabárát, a TopPrice-nál pedig az üveghez tartozó lapkaárat. A MinPickleSize és MaxPickleSize elemekben megadható cm-ben, hogy mekkora méretű uborkák vannak (2-5, 3-8, stb.). A LowerBoundary és UpperBoundary elemekben megadható az, hogy mekkora méretű uborkák kerülhetnek az adott üvegbe. A LiquidContentben megadható, hogy hány liter felöntőlé kerül az üvegbe. A Value pedig azt

határozza meg,

hogy mennyibe

kerül az adott

méretű uborka

kilogrammonkénti ára. A Percentage résznél meg tudjuk adni, hogy az adott méretű uborkának hány százalékos a termési aránya. Erre azért van szükség, mert a program ez alapján számítja ki, hogy melyik méretű uborka-üveg kombinációból hány üveggel gyárthat le úgy, hogy az adott terméssel az kivitelezhető legyen. Az XML állomány megfelelő szerkesztése után mentsük el a fájlt, majd indítsuk el a programot az Uborka.exe fájllal! Ha nem jelenik meg a programfelület, az XML fájl nem található, nem olvasható a program számára, nem felel meg az XML szintaktikának, vagy a program számára meghatározott formátumnak. Ha megjelent a felület, a „Generate” gombbal indíthatjuk el az optimalizálási folyamatot, amelynek előrehaladását a programablak alsó részében egy sáv jelez. A generálás futásának végén egy felugró ablakban jelennek meg az optimalizálás eredményei.

39

Amennyiben más értékekkel szeretnénk futtatni az optimalizálást, nem szükséges kilépni a programból, elegendő csupán az XML fájlt módosítani és menteni, majd ismét a „Generate” feliratú gombra kattintani az új értékek figyelembe vételével történő generálás megkezdéséhez.

40

8. További fejlesztési lehetőségek Az alábbiakban a dolgozatomhoz tartozó további fejlesztési lehetőségeket adom meg külön vizsgálva a dolgozathoz elkészült szimulációkat, és az optimálást.

8.1 Szimuláció A szimuláció arra hivatott, hogy új rendszer tervezésekor átlássuk az esetleges nehézségeket, megoldatlan problémákat, vagy meglévő rendszernél kiküszöböljük a hiányosságokat; átláthatóbbá, gördülékenyebbé tegyük a rendszert. Jelen esetben a rendszer gyártásának gyorsaságát a selejtek száma lassíthatja le óriási mértékben. A selejt termékeket természetesen nem lehet egykönnyen minimálni, de bevezethető az anyagok előzetes ellenőrzése, hogy csak közel hibátlan üvegek és lapkák kerülhessenek be a gyártósorra. Természetesen a további hibákat elkerülendő a jelenlegi ellenőrzésekre is szükség van, de abban az esetben, ha nagy a selejtszám, a gyártósor egy része kihasználatlan lesz. Emellett a gyártósor folyamatos üzemelésénél rengeteg késztermék keletkezik, amelyet a pakolórobotok csak torlódással tudnak a raktárba helyezni. Több pakolórobottal, esetleg robotokkal és targoncákkal gyorsabban bekerülnének az áruk a raktárba, ezáltal kevesebb lenne a torlódás. A valóságban fizikai okokból természetesen nem egykönnyen, de a PlantSimben elkészített szimulációban növelhető lenne a raktár mérete (Enterprise Dynamics-ban korlátlan méretű raktár áll rendelkezésre).

8.2 Optimáló program Optimáló programom kiegészíthető becslések készítésére is alkalmas lehetne, ha az uborkák termésének eloszlását több évre, és külön havi bontásban vizsgálnánk, ezáltal megbecsülhető lenne hónapokkal előtte, hogy miből mennyi üveggel kell gyártanunk. Emellett felvihetőek az XML-be a gyártási költségek is, akár (ha ez eltérő volna) termékenként külön, így a gyártás során keletkezett nyereség pontosan meghatározható lenne. Ez nyilvánvalóan komplex feladat, hiszen az energia ára változik, emellett a gépek elromolhatnak, az pedig veszteségesebbé teszi a gyártást. Azonban a legtöbb 41

nagy gyár esetén statisztikai elemzések által rendelkezésre állnak olyan költségadatok, amelyek a gépek amortizációjával, korszerűsítésével, karbantartásával, üzemeltetésével és véletlen meghibásodásával kapcsolatos költségeket is mind magukban foglalják. A program kiegészíthető továbbá készletgazdálkodási feltételekkel is, hiszen adódhat olyan eset, hogy a program meghatározza valamely üvegméret-uborkaméret kombinációt, ám a vártnál kevesebb érkezik valamely üveg- vagy uborkaméretből. Fontos megemlíteni, hogy abban az esetben, ha a gyár új terméket kíván gyártani, esetleg valamely termék gyártása megszűnik vagy átalakul, ezek a változások a programba illetve az XML-be minimális befektetéssel átvihetők. Az alkalmazás kiegészíthető továbbá a többi, a gyár által készített termék gyártásának optimálásával, ezáltal az üzem egészének gyártási terve könnyebben megtervezhetővé válhat.

42

Összegzés Szakdolgozatomban a lakóhelyem közelében található Szatmári Konzervgyár savanyú uborka gyártásának szimulációját hozom létre, illetve egy ehhez kapcsolódó optimálást végzek el a nyereség tekintetében. A szimuláció elkészítéséhez első lépésben vázlatot készítettem a gyártól kapott információk és a gyár weboldalán található gyártási videó alapján. A vázlatot implementáltam Enterprise Dynamics-ban, ahol elkészült a szimuláció 2D-s és 3D-s változata is. Itt a program által adott keretek között szerkesztettem a szimulációba beépülő atomokat (uborka, lapka, üvegek). Ezt követően a gyár által kapott folyamatábra, gyártástechnológiai és logisztikai információk alapján kibővítettem a vázlatot, és PlantSim-ben elkészítettem a gyár uborkabefőtt gyártásának szimulációját, amelyben a mozgó elemek már önálló 3D-s objektumok. A szimuláció ezen részéhez is készült 2D-s változat is. A vázlat selejtkiválasztással is bővült, amelyben százalékos arányban megadható, hogy különkülön mennyi legyen a selejtszázaléka a felhasználandó termékeknek. Ezzel nyomon követhető százalékban romlik a gépek kihasználtsága a selejtszázalék növelésével. Munkám során összehasonlítottam a két használt logisztikai tervezőprogramot, meghatároztam a köztük rejlő hasonlóságokat és különbségeket. A dolgozat részét képezi még egy általam írt optimáló program, amely meghatározza, hogy az adott termésből mely méretű uborkákból mely méretű üvegekbe mennyit érdemes gyártani, és azt is, hogy mekkora lesz az így befolyt haszon. A programhoz használt

algoritmus

a

véletlen

keresés

(random

search),

amely

egyszerű

megvalósíthatósága és viszonylag gyors konvergenciája miatt nagy népszerűségnek örvend a keresési eljárások között. A bemenő paramétereket egy XML-ben helyeztem el, így az árak, a gyártani kívánt mennyiség vagy a termési viszonyok változásakor elegendő ezt módosítani, majd az

43

optimalizálás újra elvégezhető az új értékekkel az alkalmazás újrafordítása vagy a kódjának módosítása nélkül.

44

Summary In my thesis I write about the simulation of the sour cucumber production in the cannery of Szatmár, which lies near my hometown and I’m making a related optimization from the point of the profits.

As first step for making the simulation I made an outline on the basis of the information that I received from the manufacturer and the video of the manufacturing process. I implemented the outline in Enterprise Dynamics, where the simulation was made in 2D and 3D. Here I designed the simulation incorporated atoms with the help of the program (cucumber, jar, flan).

After this I extended the outline following the information I got from the factory about logistics and production technology and I made a simulation of the factory’s canned cucumber production, in that the moving elements are independent 3D objects. A 2D version was made as well for this part.

The outline was expanded with waste product selection, in that it can be input how much the percentage of the waste products of the products to be used separately should be. So, if the amount of the wasted products grows, it can be traced in what kind of percentage the utilization of the machines deteriorates. During my work I compared two logistics planning software’s. I defined their similarities and differences.

Part of my thesis is an optimization program that I wrote, that defines how much should be produced from which cucumber size for which jar size, and how big the profits from it will be. The algorithm that was used for the program is random search, that on account of it’s easy feasibility and relatively fast convergence is highly appreciated among the search methods.

I placed the input parameters into XML, so by the prices, the desired production amount or by the crop relation changes, it’s enough to alter this. So the optimization can be 45

performed again with the new values without having to alter the application or to having to recompile it.

46

Irodalomjegyzék [1]Webkorridor, A logisztika fogalma: http://www.webkorridor.hu/logisztikafogalma.htm [10] Szatmári Konzervgyár, A savanyú uborkagyártás folyamatábrája

[11] Zimmerman Dominikus, Cucumber 3D Model: http://archive3d.net/?a=download&id=ca0db412

[12] pholubz4, A jar with no lid: http://www.turbosquid.com/3d-models/jar-3ds-free/180667

[13] Andrei Egorov, Olives 3D Model: http://archive3d.net/?a=download&do=get&id=8cf963f9 [14] Erdősné Sélley Csilla, Gyurecz György, Janik József, Körtélyesi Gábor, Mérnöki Optimalizáció: http://www.tankonyvtar.hu/hu/tartalom/tamop425/0029_2A_Mernoki_optimalas_HU/a datok.html [15]Dr. Kardos Ernő, Dr. Szenes Endréné, Konzervipari zsebkönyv, Mezőgazdasági Kiadó, 1972 [16] Reiter István, C# jegyzet: http://devportal.hu/content/CSharpjegyzet.aspx [17], G.-Tóth Boglárka, Globális Optimalizáció: http://www.math.bme.hu/~bog/GlobOpt/globopt_hun.pdf [19 ] Prof. Dr. Knoll Imre, Bóna Krisztián, Logisztika I: http://hallgato.griffkft.hu/dokumentumok2/log_i_szocio_log_ver.pdf

47

[2] Pénzügy Sziget, Határozza meg a logisztikai rendszer fogalmát: http://penzugysziget.hu/index.php?option=com_content&view=article&id=1591%3A17 atetel&catid=254&Itemid=378 [20]Webkorridor, A logisztikai tevékenység szintjei - logisztikai rendszerek: http://www.webkorridor.hu/logrend.htm

[21] Wikipedia, Microsoft Visual Studio: http://en.wikipedia.org/wiki/Microsoft_Visual_Studio [3] Molnár Zsolt Kézzel vagy géppel? Optimalicáljuk a gyártást: http://www.slideshare.net/leancenter/optimalizljuk-a-gyrtst [4]Földesi Péter, Logisztika I-II: http://vili.pmmf.hu/portal/documents/19217/19797/Logisztika_I-II.pdf [5 ]Szatmári Konzervgyár Kft., Bemutatkozás: http://www.regeweb.hu/rolunk/bemutatkozas/ [6] Szatmári Konzervgyár Kft. – A Szatmári Konzervgyár Kft. eszközeinek vagyonértékelése

[7] Incontrolsim, Enterprise Dynamics: http://www.incontrolsim.com

[8] Graphit, eM-Plant alapok

[9] Steffen Bangsow, Manufacturing Simulation with Plant Simulation and Simtalk, Springer, 2010

[22]Wikipedia, Logisztika: http://hu.wikipedia.org/wiki/Logisztika A webcímek utoljára ellenőrizve: 2014. 04.30

48

Mellékletek A CD melléklet tartalma:  doc:      

szakdolgozat.docx, szakdolgozat.pdf, osszefoglalo.docx, osszefoglalo.pdf, summary.docx, summary.pdf.

 Src:                            

szimulacio_ed.bak, szimulacio_ed.mod, szimulacio_ps.bak, szimulacio_ps.spp, Uborka.sln, Uborka.csproj, RootXMLNode.cs, Program.cs, PickleSize.cs, Pickle.cs, NetValue.cs, MainForm.resx, MainForm.Designer.cs, MainForm.cs, Jar.cs, Settings.settings, Settings.Designer.cs, Resources.resx, Resources.Designer.cs, AssemblyInfo.cs, Uborka.Properties.Resources.resources, Uborka.pdb, Uborka.MainForm.resources, Uborka.exe, Uborka.csprojResolveAssemblyReference.cache, Uborka.csproj.GenerateResource.Cache, Uborka.csproj.FileListAbsolute.txt, DesignTimeResolveAssemblyReferencesInput.cache, 49

     

DesignTimeResolveAssemblyReferences.cache, uborka.xml, Uborka.vshost.exe.manifest, Uborka.vshost.exe, Uborka.pdb, Uborka.exe.

50

EREDETISÉGI NYILATKOZAT Alulírott

Habarics

Henrietta

Neptun-kód

D7IDRF

a

Miskolci

Egyetem

Gépészmérnöki és Informatikai Karának végzős mérnök informatikus szakos hallgatója ezennel büntetőjogi és fegyelmi felelősségem tudatában nyilatkozom és aláírásommal igazolom, hogy …………………………………………………………………………………………… … című szakdolgozatom/diplomatervem saját, önálló munkám; az abban hivatkozott szakirodalom felhasználása a forráskezelés szabályai szerint történt. Tudomásul veszem, hogy szakdolgozat esetén plágiumnak számít: -

szószerinti idézet közlése idézőjel és hivatkozás megjelölése nélkül;

-

tartalmi idézet hivatkozás megjelölése nélkül;

-

más publikált gondolatainak saját gondolatként való feltüntetése.

Alulírott kijelentem, hogy a plágium fogalmát megismertem, és tudomásul veszem, hogy plágium esetén szakdolgozatom visszautasításra kerül.

Miskolc,.............év ………………..hó ………..nap

…….……………………………….… Hallgató

51