Microsoft Word - Jarzynka.doc

Spis tre ci

Cel pracy

Wst p teoretyczny

2.1.

Definicja podstawowych poj

2.2.

Odmierzanie czasu w systemie symulacyjnym

2.3.

Rodzaje symulacji cyfrowej

2.4.

rodowiska programowania

2.5.

Etapy tworzenia systemu symulacyjnego

2.5.1.

Ogólny schemat tworzenia systemu symulacyjnego

2.5.2.

Projektowanie i implementacja

2.5.3.

Weryfikacja i walidacja systemu symulacyjnego

2.5.4.

Metody walidacji systemu symulacyjnego

2.5.5.

Bł dy w procesie weryfikacji i walidacji

2.5.6.

Weryfikacja i walidacja w procesie tworzenia

modelu symulacyjnego

2.5.7.

Techniki przydatne w fazie weryfikacji i walidacji

2.6.

Cele, zalety i wady symulacji

Opracowanie i implementacja systemu symulacyjnego

3.1.

Przedsi biorstwo wielobran owe "HET- MARK"

3.1.1.

Struktura firmy "HET - MARK". Działy i ich zadania

3.1.2.

Proces produkcji

3.2.

Model koncepcyjny

3.2.1.

Modelowane obiekty

3.2.2.

Schemat działania modelu

3.3.

Wymagania funkcjonalne i niefunkcjonalne

3.3.1.

Wymagania funkcjonalne

3.3.2.

Wymagania niefunkcjonalne

3.4.

Projektowanie systemu symulacyjnego

3.5.

Implementacja systemu symulacyjnego

3.5.1.

Generator liczb losowych

Prowadzenie eksperymentów symulacyjnych

4.1.

Schemat prowadzenia eksperymentów

4.2.

Walidacja systemu symulacyjnego

4.2.1.

Przygotowanie danych wej ciowych

4.2.2.

Schemat procesu walidacji

4.2.3.

Eksperymenty walidacyjne i ocena poprawno ci modelu

Wnioski

Literatura

Politechnika Cz stochowska

1. Wst p

Symulacja procesów produkcyjnych, organizacyjnych i cz sto ekonomicznych

jest pot niejszym narz dziem dla prognozowania w gospodarce jak na mikropoziomie

(przedsi biorstwo, zakład), tak i na makropoziomie (region, a nawet pa stwo). Główn

zalet symulacji jest mo liwo uwzgl dnienia realnych procesów w warunkach

niezb dnej niepewno ci wyra aj cej si w nieokre lono ci parametrów tych systemów.

Przy tym niepewno zwykle traktowana jest w sensie nosowo ci i formalizowana

matematycznie za pomoc teorii prawdopodobie stwa. Głównym narz dziem

zapewnienia w modelu tej losowo ci jest tak zwana metoda jest tzw. metoda Monte

Carlo. Warto odnotowa , e w literaturze naukowej cz sto terminy „symulacja” i

„metoda Monte Carlo” rozpatrywane s jako synonimy.

Wa n cech odró ni c symulacj od innych podej do modelowania

matematycznego jest to, e wyniki symulacji nie zawsze odpowiadaj naszym

intuicyjnym przedstawieniom o rozwoju zdarze , opartym na istotnej dla procesów

my lenia zasadzi ekstrapolacji. Ta cecha jest jedn z głównych zalet symulacji,

poniewa pozwala maksymalnie przybli y model symulacyjny do zachowania si

systemu rzeczywistego.

Dzi w pa stwach rozwini tych symulacja jest podstawowym elementem

procesu projektowania nowych przedsi biorstw, systemów melioracyjnych, pól

naftowych. Istniej nawet przykłady udanej symulacji rozwoju sytuacji politycznej.

Podej cie symulacyjne jest podstaw informatycznej restrukturyzacji

przedsi biorstw. Przy tym wyodr bniono dwa główne etapy: restrukturyzacja odwrotna,

restrukturyzacja bezpo rednia. Na pierwszym etapie (restrukturyzacj odwrotna)

budowany jest model symulacyjny przedsi biorstwa w tym stanie, w jakim ona istnieje.

Taki model symulacyjny pozwala na wykrywanie w skich gardeł procesu

produkcyjnego oraz administracyjnych powi za , pozwala na optymalizacj (

najcz ciej wielokryterialnych) pozwalaj c wyczerpa wszystkie mo liwo ci

ulepszenia działalno ci przedsi biorstwa w ramach jego istniej cej struktury,

technologii i koncepcji zarz dzania. Po wyczerpaniu tych mo liwo ci firma dla

utrzymania si na rynku powinna wprowadzi zmiany rewolucyjne, tzn.

restrukturyzacj . Na tym etapie (restrukturyzacja bezpo rednia) buduje si model

symulacyjny przyszłego zakładu o zupełnie nowej strukturze. Przy tym u ywanie

symulacji pozwala na projektowanie nowego przedsi biorstwa ju w formie

odpowiadaj cej poj ciom o optymalno ci na aktualnym etapie. Dobrym przykładem

takiego zintegrowanego systemu wspomagania restrukturyzacji na podstawie symulacji

jest kompleks programowy ReSink, skutecznie u ywany w całym szeregu projektów,

np. w restrukturyzacji jednego z najwi kszych lotnisk Europy Szeriemietiewa

(Moskwa).

Najcz ciej przedmiotem symulacji jest proces produkcji wyrobu, a dokładniej

ilo wykonanych elementów w zadanym przedziale czasowym, b d , patrz c z innej

strony, czas wyprodukowania okre lonej ilo ci elementów. I w jednym i w drugim

przypadku celem jest okre lenie zdolno ci produkcyjnej zaprojektowanej linii.

Okre lenie czasu pracy daje w wyniku ilo wyprodukowanych elementów, jak mo na

uzyska w czasie, np. jednej zmiany, natomiast zadanie ilo ci elementów do

wyprodukowania daje przybli on odpowied na pytanie, ile czasu zajmie

Politechnika Cz stochowska

wyprodukowanie danej partii (wykonanie danego zamówienia) przydanych nakładach

w sprz cie i ludziach.

Symulacja wymaga podania przez u ytkownika ró norodnych danych

wej ciowych opisuj cych rzeczywisty b d planowany stan rzeczy. Przy badaniu

poprawno ci wyników generowanych przez program, nale y zbada rzeczywisty proces

produkcji tak pod wzgl dem u ytych maszyn i ludzi, jak i pod wzgl dem czasów

potrzebnych do wykonania detalu. Oto główne grupy parametrów istotnych w przebiegu

symulacji:

ilo maszyn i urz dze

czasy jednostkowe wykonania elementu na danym stanowisku

prawdopodobie stwo wyst pienia nadzwyczajnej przerwy w pracy (awaria

maszyny, brak niezb dnych cz ci lub surowców itp.)

przybli one czasy przerw w produkcji (pobranie surowca, ustawienie

parametrów obróbki itp.)

Organizacja pracy w P.W. "HET - MARK" znacz co ró ni si od organizacji

pracy na zasadzie ogólnie przyj tej linii produkcyjnej. Dlatego te celowe wydaje si

dodanie takich parametrów dotycz cych czasu pracy, jak:

czas trwania zmiany

czas trwania przerwy mi dzyzmianowej

cz stotliwo przekazywania detali do dalszej obróbki

Niektóre z podanych parametrów s zale ne od projektanta linii, podlegaj

ograniczeniom zwi zanym z zapleczem produkcyjnym. Mo na zmienia je dowolnie, a

odpowiedzi systemu symulacyjnego powinny by zgodne z wynikami działania systemu

rzeczywistego Inne natomiast s ci le zwi zane z parametrami technicznymi maszyn,

mo liwo ciami ludzi, czy wreszcie z przypadkiem. Te parametry musz by dokładnie

zbadane, gdy jakakolwiek dowolno w ich okre laniu mogłaby spowodowa du e

rozbie no ci pomi dzy wynikiem symulacji a systemem rzeczywistym zbudowanym w

oparciu o t symulacj .

Proces produkcji wyrobów jednego rodzaju jest stosunkowo nieskomplikowany,

dlatego zebranie potrzebnych danych, mimo e pracochłonne i trudne, nie jest procesem

skomplikowanym. Prawidłowo zrobiony system symulacyjny na tym poziomie ł czy w

sobie nast puj ce cechy:

mo e by u yty do krótkookresowego planowania gospodarki materiałowej

pozwala zrozumie i odpowiednio opisa zdarzenia na poziomie

wytwarzania pojedynczego elementu, a nawet pojedynczej czynno ci na

okre lonym stanowisku pracy

pozwala zaplanowa czas wykonania partii wyrobów i tym samym

proponowa kontrahentom bardziej atrakcyjne terminy wykonania

zamówie

pozwala znale tzw. w skie gardła, czyli miejsca w procesie produkcyjnym

o najmniejszej efektywno ci, powoduj ce spadek wydajno ci całej linii

produkcyjnej danego elementu

jest bardzo dobrym punktem wyj cia do stworzenia systemu symuluj cego

działanie całej hali produkcyjnej z dowoln ilo ci rodzajów elementów,

efektywnym przydzielaniem zasobów firmy do procesu produkcji

Politechnika Cz stochowska

konkretnego wyrobu, czy minimalizacj kosztów produkcji poprzez jak

najefektywniejsze wykorzystanie zasobów

Jak wida , ten poziom abstrakcji jest zarówno mo liwy do wykorzystania przez

pracowników firmy, daj c im jednocze nie szersze spojrzenie na elementarne

czynno ci, jak równie ma du e perspektywy rozwojowe, dzi ki którym staje si

bardziej atrakcyjny dla pracowników wy szych szczebli organizacyjnych.

Głównym celem niniejszej pracy jest opracowanie systemu informatycznego,

którego główn cz ci jest kompleks programowy pozwalaj cy na półautomatyczne

generowane modeli symulacyjnych procesów produkcyjnych w warunkach niepewno ci

probabilistycznej.

Celem szczegółowym jest opracowanie modelu symulacyjnego i jego adaptacja

do warunków działalno ci Przedsi biorstwa Wielobran owego "HET - MARK"

(Cz stochowa) i wymogów jego kierownictwa, oraz wdra anie opracowanego systemu

na danym przedsi biorstwie.

Politechnika Cz stochowska

2. Metodologiczne podstawy symulacji procesów produkcyjnych

2.1 Definicja podstawowych poj

Termin symulacji (w uj ciu modelowania procesów produkcyjnych,

organizacyjnych bez uwzgl dnienia szczegółów procesów fizycznych, chemicznych,

mechanicznych itp.) obejmuje zagadnienia imitacji, b d na ladowania , podczas gdy

modelowaniem okre la si tworzenie obiektów reprezentuj cych rzeczywi cie istniej ce

obiekty. Symulacja jest imitacj operacji i zmian zachodz cych w systemie b d w

procesie. Zachowanie systemu i tego jak zmienia si on w czasie mo e by

rozpatrywana i poznawana za pomoc modelu symulacyjnego [5].

Symulacja cyfrowa jest algorytmiczn metod prowadzenia eksperymentów na

modelach dynamicznych istniej cych lub projektowanych systemów. Eksperymenty te

s przeprowadzane za pomoc maszyn cyfrowych. Pierwsze prace na tym polu

rozpocz to w 1960r. Pierwsze systemy symulacyjne powstawały na u ytek armii

(ATLAS)[16]. System rozumie nale y jako zbiór powi zanych ze sob obiektów .

Ka dy z nich charakteryzuje si własnymi, odpowiadaj cymi mu atrybutami. Je li

ka demu z tych atrybutów przyporz dkowana jest jedna zmienna, której zakres warto ci

odpowiada warto ciom przez niego przyjmowanym, to system mo e by opisany

zbiorem zmiennych. Wtedy ka da sensowna kombinacja warto ci zmiennych

odpowiada pewnemu, okre lonemu stanowi systemu. Zmian stanu systemu zatem

symuluje si zmian warto ci odpowiednich zmiennych. Przechodzenie systemu ze

stanu do stanu zgodnie z okre lonymi zasadami jest zatem symulacj , czyli

imitowaniem zachowania si systemu w czasie.

Zmiany stanu systemu mog mie charakter ci gły, czyli zmienna symuluj ca

dany stan mo e przyjmowa warto ci rzeczywiste z zadanego przedziału. Mog mie

równie charakter dyskretny, tzn. mog zachodzi w sposób skokowy. Zmian stanu

systemu nazwa mo na zdarzeniem.

Działania zazwyczaj rozpoczynaj i ko cz zdarzenia. Działanie mo na

zdefiniowa jako niepodzieln , elementarn na przyj tym poziomie abstrakcji i

szczegółowo ci operacj , któr obiekt wykonuje, lub jest poddawany w czasie.

Procesem jest uporz dkowany w czasie zbiór zdarze dotycz cych danego

obiektu. Cz sto zaobserwowa mo na interakcj procesów, czyli ich wzajemny wpływ

na siebie nawzajem, okre laj c warunki wyst pienia poszczególnych zdarze .

Zdarzenie mo na okre li jako bezpo rednio zale ne od czasu, je eli do jego

zaistnienia w procesie wystarczaj ce jest wskazanie odpowiedniego punktu na osi

czasu. Natomiast zdarzenia, których wyst pienie jest zwi zane z osi gni ciem przez

system wyró nionego stanu lub stanów, nazywane s zdarzeniami warunkowymi.

W dalszej cz ci przedstawione b d poj cia i metody tworzenia systemów

symulacji dyskretnej. Ten wła nie model symulacji został przyj ty jako wła ciwy dla

odpowiedniego przedstawienia sposobu działania procesu produkcyjnego w P. W.

"HET - MARK". Wyja nieniu dlaczego dokonano takiego wła nie wyboru po wi cony

zostanie jeden z kolejnych rozdziałów.

Politechnika Cz stochowska

2.2 Odmierzanie czasu w systemie symulacyjnym

Wła ciwe przeprowadzenie przebiegu procesu w symulowanym systemie

wymaga wprowadzenia swego rodzaju zegara systemowego [11]. Jest to specjalna

dedykowana zmienna spełniaj ca role czasu symulacyjnego, którego warto

pocz tkow zwykle ustala si na 0.

Najcz ciej stosowane s dwie metody odliczania czasu symulacyjnego.

Pierwsza z nich opiera si na stałym przyro cie warto ci zmiennej czasu symulacyjnego

t. Nast pnie sprawdza si mo liwo ci wyst pienia poszczególnych zdarze w chwili t

+ t. Technika ta nazywa si technik stałego kroku. Jest ona łatwa w realizacji. Trudno

j jednak efektywnie zaimplementowa w symulacji systemów, w których odst py

czasu mi dzy poszczególnymi zdarzeniami maj charakter losowy. Poza tym, trudno z

jednej strony dobra odpowiedni krok symulacji t tak, aby momenty wszystkich

zdarze były mo liwie dobrze odwzorowane, inaczej, aby dobrana była odpowiednia

rozdzielczo osi czasu. Z drugiej strony zbyt du a rozdzielczo , a wi c małe t

sprawi, e system b dzie powolny i mało wydajny. Mo na j z powodzeniem stosowa

do symulowania systemów, w których zdarzenia zwi zane s głównie z interakcj

mi dzy niezale nymi wobec siebie obiektami, przy czym cz stotliwo zachodzenia

tych interakcji ma charakter losowy.

Drug metod odmierzania czasu systemowego jest metoda oparta na koncepcji

nast pnego zdarzenia. Głównym zało eniem tej metody jest spostrze enie, e pomi dzy

kolejnymi zdarzeniami, stan systemu nie ulega zmianie i z tego wzgl du przyrost

zmiennej opisuj cej czas symulacyjny nie jest stały, lecz jest ustalany na podstawie

momentu kolejnego zdarzenia i aktualnego czasu symulacji. Innymi słowy, w chwili

wyst pienia zdarzenia nast puje przesuni cie zegara symulacyjnego do chwili

kolejnego zdarzenia, a wi c do momentu, w którym mo liwe b d dalsze zmiany stanu

systemu. Metoda ta daje bardziej efektywne wyniki w postaci mniejszego

zapotrzebowania na czas pracy systemu komputerowego. Jest jednak trudniejsza w

implementacji. Głównym tego powodem jest mo liwo wyst pienia zgłoszenia na

dwóch ró nych obiektach. Nale y wtedy zwróci szczególna uwag na prawidłowe

obsłu enie obydwu zgłosze zdarzenia, uwzgl dni ewentualne interakcje pomi dzy

obiektami, które je wywołały i w prawidłowy sposób okre li aktualny stan całego

systemu [1].

Poni ej przedstawiony przykład ma na celu zaprezentowanie ró nic przy

odmierzaniu czasu w obydwu podej ciach. Ma on na celu zaprezentowanie, a nie

porównanie pod jakimkolwiek wzgl dem u ytkowym, tych podej . S bowiem

dziedziny w których nie da si zastosowa metody stałego t, w innych za

przypadkach zastosowanie techniki kolejnego zdarzenia b dzie nieopłacalne.

W systemie działaj trzy obiekty: A B i C. Ka dy z nich niezale nie od innych

co pewien czas wywołuje zdarzenie, na które ma zareagowa system, np. zwi kszy

licznik wywołanych zdarze danego obiektu. Czasy wywołania kolejnych zdarze , to

odpowiednio:

A: co 5 sekund

B: co 7 sekund

C: co 4 sekundy

Czasy startu dla wszystkich obiektów równe s 0 (t

= 0).

Przyrost warto ci zmiennej zegarowej w podej ciu stałego kroku t = 1 sekunda

Jedna podziałka na osi czasu odpowiada jednej sekundzie czasu symulacyjnego

Politechnika Cz stochowska

Dla porz dku wspomnie nale y te o innych sposobach podej cia do problemu

symulacji komputerowej. Maj one zastosowanie w ró nych dziedzinach. Zapoznanie

si z nimi na pewno poszerzy horyzonty i da nowe spojrzenie na ró ne zjawiska.

Metoda Monte Carlo

Bodaj e najstarszym podej ciem do tematu symulacji cyfrowej jest metoda

Monte Carlo. Jest to statyczna technika symulacji, w której upływ czasu nie jest brany

pod uwag . Metoda swoj nazw wzi ła od hrabiego Montgomery'ego de Carlo,

włoskiego hazardzisty. Monte Carlo wykorzystuje liczby losowe i losowe zdarzenia,

gdzie upływ czasu ma znaczenie pomijalnie małe. To podej cie jest wykorzystywane do

modelowania zjawisk probabilistycznych, których charakterystyki s niezmienne w

czasie. Metoda ta była wykorzystywana w czasie II Wojny wiatowej do

rozwi zywania problemów zwi zanych z tworzeniem broni atomowej. Mo e ona by

równie wykorzystywana do rozwi zywania nie probabilistycznych problemów za

pomoc technik probabilistycznych.

Metoda ustalonej trasy (ang. trace-driven)

W tej metodzie trasa jest zdefiniowana jako uporz dkowany w czasie zbiór

zdarze zebranych z realnie istniej cego systemu, b d wygenerowany przez program

komputerowy. Podej cie to jest cz sto wykorzystywane w algorytmach przewidywania

zjawisk

rodowiskowych, zapobiegania zakleszczeniu, stronicowania, czy

wykorzystania pami ci wirtualnej. U ycie trasy jako danych wej ciowych daje lepsz

dokładno uzyskanych wyników. Ró ne typy zestawów przej u ytych w symulacji

zale od rodzaju systemu, który poddawany jest analizie. Mog to by dane dotycz ce

temperatury, ci nienia, wysoko ci, jak równie dane dotycz ce adresów wej cia -

wyj cia, modele pami ci podr cznej, czy podsystemu.

Politechnika Cz stochowska

2.3 Rodzaje symulacji cyfrowej

Symulacja cyfrowa jest dziedzin szybko rozwijaj c si , na której polu

przeprowadzane s liczne do wiadczenia i eksperymenty. Stosowana jest równie do

rozwi zywania bardzo ró norodnych problemów: od spraw zwi zanych z reakcjami

j drowymi do testowania strategii wojskowych, od kwestii zarz dzania ryzykiem po

rozbudowane modele przedsi biorstw przemysłowych. Z tych wła nie wzgl dów

podej cia do tematu symulacji mog bardzo ró ni si mi dzy sob , w zale no ci od

zastosowania. Przyj to zatem pewne podziały za pomoc których mo na symulacj

sklasyfikowa . Nie s to jednak sztywne granice. Bardzo liczne s przykłady ł czenia

ró nych technik dla jak najlepszego odwzorowania modelowanego systemu.

Model statyczny (system statyczny) jest to podej cie, w którym pomini ty

zostaje upływ czasu. Innymi słowy, w procesie symulacji pomini ta zostaje o czasu.

Ten model stosowa mo na w systemach niezale nych od czasu. Wiele stochastycznych

problemów programowania mo na sformułowa jako problem optymalizacji warto ci

funkcji. Bardzo cz sto funkcji tej nie mo na obliczy dokładnie, mo liwa jest tylko jej

aproksymacja. Do rozwi zywania takich wła nie problemów bardzo cz sto

wykorzystuje si metod Monte Carlo, która wła nie opiera si na modelu statycznym.

W praktyce okazuje si , e jest ona jedynym sensownym sposobem na aproksymowanie

zadanej funkcji [20].

Modelowanie dynamiczne jest to podej cie, w którym uwzgl dniony jest upływ

czasu. Od niego uzale nione s zdarzenia zachodz ce w systemie. Upływ czasu mo e

mie charakter ci gły, czyli zmienna reprezentuj ca czas mo e przyjmowa wszystkie

warto ci rzeczywiste z danego zakresu, b d dyskretny. Symulacja dyskretna (ang.

Diskrete - Event Simulation) jest bardzo cz sto stosowana do symulacji procesów

produkcyjnych. W ich przebiegu główna rol odgrywa bowiem czas.

Zmienna deterministyczna (model deterministyczny) jest to zmienna stała o

warto ci znanej w ka dym momencie symulacji. Nie przyjmuje ona warto ci losowych,

jedynie dokładnie ustalone liczby. Je eli wszystkie dane wej ciowe systemu maj

charakter deterministyczny (nielosowy) wtedy cały system mo na nazwa

deterministycznym, gdy dane wyj ciowe symulacji równie nie b d miały charakteru

losowego. Takie podej cie do niektórych danych jest uzasadnione. Czasami pewne

działania maj stały czas realizacji, np. obróbka na maszynach zautomatyzowanych. To

podej cie nie zdaje zazwyczaj egzaminu, je eli rzeczywiste czasy wykonania maj

charakter losowy. Jego zalet jest fakt, i dla pewnych danych wej ciowych system w

odpowiedzi wygeneruje zawsze takie same dane wyj ciowe. Nieprawidłowe jest w

takim przypadku u ycie warto ci redniej kilku czasów niezale nych realizacji zadania,

gdy mo e to wprowadzi bł dy b d ce wynikiem zbyt du ych uproszcze danych

wej ciowych.

Aby to unaoczni mo na posłu y si prostym przykładem. Załó my, e firma

produkuj ca elementy w ci gu godzinnego cyklu produkcyjnego jest w stanie

wyprodukowa od 6 do 10 sztuk. Zaniedbuj c faktyczn wydajno mo na byłoby

przyj , e firma rednio produkuje 8 szt/h(sztuk na godzin ). (10+6)/2 = 8 i powstaje

zmienna deterministyczna. St d wniosek, e firma produkuje 64 elementy w ci gu 8 -

godzinnej zmiany. Je eli natomiast spojrze na faktyczne wydajno ci firmy

Politechnika Cz stochowska

(przykładowe dane w tabeli u dołu) od razu widoczna jest niezgodno mi dzy

systemem symulacyjnym a rzeczywisto ci .

GODZINY 1. ZMIANA 2. ZMIANA 3. ZMIANA 4. ZMIANA 5. ZMIANA 6. ZMIANA
1

REDNIO

SZT/H

7,625

8,25

7,5

7,75

W CI GU

ZMIANY

Tab. 1 Przykładowe dane

Jak wida , zazwyczaj podczas zmiany wytwarzanych jest mniej ni 64 sztuk. Opieraj c

si wi c na warto ci redniej uzyskanie rzeczywistych wyników jest co najmniej

niepewne. Przyj cie natomiast warto ci redniej ze wszystkich danych o wydajno ci,

równej 7,708333, wi e si z pewnym problemem: czy zaokr gli j do 8 i zgodzi si

na zaistnienie opisanych wcze niej bł dów, czy te przyj - całkowicie niezgodnie z

rzeczywisto ci - e mog by wyprodukowane cz ci dziesi tne. Ani jedno, ani drugie

rozwi zanie nie jest dobre, gdy oba generuj bł dy tego samego rodzaju.

W takich przypadkach u y nale y modelu stochastycznego. Zmienne w tym

podej ciu nie s ju reprezentowane jako liczby, lecz jako pewnego rodzaju przedziały.

Zmienne stochastyczne mog przyjmowa warto ci z tych przedziałów z zadanym

prawdopodobie stwem. Prawdopodobie stwo to mo e mie posta normaln , stał dla

całego przedziału, albo dan funkcj odwzorowuj c b d aproksymuj c rzeczywisty

rozkład warto ci przyjmowanych przez t warto . Przy tym podej ciu odpowied

systemu na pewne dane wej ciowe mo e by niejednakowe dla ró nych uruchomie

symulacji. Dlatego konieczne jest wykonanie wielu niezale nych od siebie powtórze

symulacji dla jednakowych danych wej ciowych. Nale y je traktowa jako

prawdopodobne odpowiedzi systemu. Na tej podstawie za pomoc metod

statystycznych mo na udzieli odpowiedzi na pytanie: jaka jest odpowied systemu na

dane wej ciowe [21]. Zazwyczaj u ywa si do tego celu warto ci redniej i odchylenia

standardowego lub metod graficznych, np. histogramów.

Poł czenie danych wej ciowych stochastycznych i deterministycznych daje w

wyniku zawsze system stochastyczny. Je eli cho jedna (znacz ca) zmienna jest

zdefiniowana jako pewien przedział, to wynik symulacji zawsze b dzie w postaci

przedziału o pewnej funkcji okre laj cej prawdopodobie stwo (stałej lub nie). W ten

sposób tworzona jest wi kszo systemów symulacyjnych. Istnieje jednak pewne

niebezpiecze stwo. Nale y bardzo uwa nie i dokładnie przeanalizowa system oraz,

je li to mo liwe, skonsultowa si z ekspertami, które z danych wej ciowych mo na

traktowa jako deterministyczne, a które koniecznie nale y zaimplementowa jako

stochastyczne. le przeprowadzona na tym poziomie analiza mo e by powodem

pó niejszych rozbie no ci pomi dzy systemem rzeczywistym a symulacj . Z jednej

Politechnika Cz stochowska

strony, niewła ciwie zdefiniowana warto deterministyczna, której warto ci w

rzeczywisto ci maj charakter losowy, zredukuje rozpi to przedziału, w którym

wyst puj dane wyj ciowe. Nie b dzie to jednak lepsze przybli enie wyników, lecz

zignorowanie pewnych stanów, których wyst pienie jest realne w rzeczywisto ci.

Mo na byłoby wi c stwierdzi , e najbezpieczniej jest zadeklarowa wszystkie

zmienne jako stochastyczne. Jednak e zmienna, która w rzeczywisto ci nie przyjmuje

zró nicowanych warto ci, lub ró nice te s mniejsze ni zało ona skala symulacji, czyli

pomijalnie małe, wtedy mamy do czynienia z sytuacj odwrotn . Nie do , e przedział

warto ci mo liwych na wyj ciu nienaturalnie si zwi kszy, to jeszcze cały proces

symulacyjny mo e ulec zafałszowaniu. Ponadto nie mo na ustali przedziału

mo liwych do wyst pienia warto ci liczby deterministycznej, a narzucenie takowych

niejako odgórnie, np. 5% warto ci zmiennej, jest bł dem tego samego typu, co

potraktowanie warto ci stochastycznej jak deterministyczna i narzucenie jej warto ci

redniej. Bł dy te powinny wypłyn na etapie weryfikacji i walidacji (ang. Verification

and Validation V&V) systemu symulacyjnego. Wtedy jednak b d one trudne do

wykrycia, a ich poprawienie mo e okaza si bardzo pracochłonne. Trudno w

odszukaniu takich bł dów wynika głównie z tej przyczyny, e s one zawarte w samym

opisie systemu, a wi c powstały w pocz tkowej fazie jego tworzenia. Wydaje si wi c

oczywiste, e weryfikacja i walidacja systemu rozpocz ta na samym pocz tku

tworzenia systemu pozwoli znale bł dy szybciej i obni y koszty poprawek. Mimo to

V&V nie jest brana pod uwag , dopóki projekt nie jest gotowy lub prawie gotowy [16].

cel symulacji

czas

Rys.2.3 Czas pracy nad projektem w zale no ci od rozpocz cia weryfikacji i

walidacji

2.4 rodowiska programowania

Mówi c o rodzajach systemów symulacji cyfrowej nie sposób nie wspomnie o

narz dziach do ich tworzenia. To od nich zale y kształt i działanie symulacji, a ich

nieprawidłowy dobór mo e bardzo skomplikowa prac nad systemem [11]. Narz dzia

te, podobnie jak cała dziedzina nauki podlegały przemianom. Przemiany te były

spowodowane zapotrzebowaniem na systemy symuluj ce dany dział działalno ci

ludzkiej. Nie mo na zapomnie , e motorem rozwoju symulacji było jej komercyjne

wykorzystanie. To wi zało si z potrzeb dopasowania narz dzi zarówno do potrzeb

twórców systemów symulacyjnych - elastyczno ci i prostot tworzenia, jak i potrzeb

wczesne,

małe korekty

pó niejsze,

du e korekty

CEL

SYMULACJI

Politechnika Cz stochowska

u ytkowników - przejrzysty interfejs , intuicyjna obsługa i precyzyjne, dokładne i

przejrzyste przedstawienie wyników symulacji. Mimo, i mo liwe jest tworzenie

systemów symulacyjnych w j zykach ogólnego zastosowania , np. C++ czy PASCAL

[6], to wi kszo tworzona jest za pomoc komercyjnych narz dzi. Dwa

najpopularniejsze kryteria ich doboru to

elastyczno modelowania, czyli mo liwo modelowania jakiegokolwiek

systemu niezale nie od jego skomplikowania, czy nietypowo ci;

łatwo u ytkowania

S dwa podstawowe typy oprogramowania symulacyjnego dla produkcji.

Pierwszym z nich s j zyki symulacyjne. S to pakiety software'owe, które ze swej

natury s ogólnego zastosowania. To, do czego zostan wykorzystane zale y tylko od

programisty. Nie s one dedykowane do konkretnego rodzaju systemów. Tradycyjnie

programowanie rozumiane jest jako pisanie kodu ródłowego symulacji przez

programist , jednak ostatnio zauwa y mo na silny trend do wykorzystywania

podej cia graficznego tworzenia modelu. Przykładami tego typu j zyków

symulacyjnych mog by m.in.: Arena, AweSim!, GPSS/H, Extend, Micro Saint,

MODSIM III, SES/workbench, SIMPLE++, SIMSCRIPT II 5, SIMUL8, czy SLX [6].

Najwi ksz zalet dobrego j zyka symulacyjnego jest jego elastyczno . Wad

natomiast jest konieczno ekspertyzy programistycznej [6], tzn. sprawdzenie nie tylko

budowy symulacji pod wzgl dem zgodno ci z systemem rzeczywistym, ale równie

składni j zyka. Mog bowiem wyst pi bł dy logiczne na poziomie samej

implementacji. Powstała równie grupa j zyków symulacyjnych zorientowanych

produkcyjnie (ang. Manufacturing - Oriented Simulation Language). Konstrukcje

modelowania s w nich zorientowane na systemy produkcyjne i gospodarki

materiałowej. Do tej grupy nale takie j zyki jak AutoMod i Quest [6].

W ci gu ostatnich dziesi ciu lat wyst piło znacz ce zainteresowanie dla

programów symulacyjnych, które byłyby proste w u yciu. Chodziło o zmniejszenie

ilo ci kodu niezb dnego do stworzenia działaj cej symulacji. Odpowiedzi na to

zapotrzebowanie były symulatory zorientowane produkcyjnie (ang. Manufacturing -

Oriented Simulator). Były to pakiety zaprojektowane do modelowania procesów

produkcyjnych dla pewnych klas systemów. Ten rodzaj oprogramowania ma dwie

wa ne cechy. Po pierwsze, zorientowany jest on na modelowanie systemów

produkcyjnych, po drugie, do stworzenia działaj cej symulacji nie potrzeba wcale, lub

potrzeba niewiele, kodu programowego. Model symulacyjny budowany jest za pomoc

klikni myszki b d metod przeci gnij - i - upu i poprzez wypełnianie okien

dialogowych. Tak wi c zało enia zostały osi gni te. Za cen elastyczno ci systemów

nadano im prostot obsługi. Programami nale cymi do tej klasy s m.in.

FACTOR/AIM, ProModel, Taylor II i WITNESS [6].Główn ich zaleta jest to, e gdy

u ytkownik dobierze narz dzie spełniaj ce wymogi jego systemu (rzeczywistego), to

czas tworzenia symulacji maleje w sposób znacz cy. Twórcy tego typu systemów

wprowadzili pewne mo liwo ci programowania w swoich produktach

mo liwo wprowadzenia konstrukcji programowalnych (ustalanie warto ci

zmiennych globalnych, ustalanie zasad działania instrukcji warunkowych) w

pewnych okre lonych punktach procesu budowy modelu

mo liwo wywołania zewn trznych funkcji napisanych w j zykach

ogólnego zastosowania w pewnych okre lonych punktach procesu budowy

modelu

Politechnika Cz stochowska

W ostatnich latach podział na j zyki programowania i symulatory uległ zatarciu.

W j zykach programowania symulacji zacz to na szerok skal u ywa graficznych

metod budowy modelu w celu ułatwienia procesu tworzenia. W symulatorach natomiast

wprowadza zacz to mo liwo ci dodawania kodu dla zwi kszenia ich elastyczno ci.

Podział jednak istnieje na pakiety symulacyjne ogólnego zastosowania (ang. Global -

Purpose Simulation Package) i pakiety symulacyjne zorientowane aplikacyjnie (ang.

Applications - Oriented Simulation Package) [8].

2.5 Etapy tworzenia systemu symulacyjnego

Termin symulacji oznacza imitacj operacji przeprowadzanych w systemie

rzeczywistym w czasie. Symulacja wi e generacj sztucznie wytworzonej historii

systemu i obserwacji tej historii dla wyci gni cia wniosków dotycz cych

charakterystyk operacji przeprowadzanych w rzeczywistym systemie, który

reprezentuje. Symulacja jest niezast pion metod rozwi zywania problemów

zwi zanych z wieloma dziedzinami ycia. Jest ona u ywana do opisywania i analizy

zachowa systemu, odpowiedzi na pytanie "co by było, gdyby?" dotycz cych tego

systemu. Pomocna jest tak e przy projektowaniu rzeczywistego systemu. Zarówno

bowiem systemy istniej ce, jak i dopiero projektowane mog by przedstawiane i

analizowane za pomoc symulacji [9].

Wybieraj c metod symulacji do rozwi zania danego problemu nale y pami ta ,

e opracowanie i uruchomienie systemu symulacyjnego nie jest w cale zaj ciem

prostym. Jest ono czasochłonne, a czasami i kosztowne. Ponadto nie ma adnych

gwarancji, e czas i koszty wło one w przygotowanie systemu zwróc si w postaci

warto ciowych i wiarygodnych wyników. Tworzenie modeli symulacyjnych wymaga

do wiadczenia z powodu braku ogólnych prawideł formalizuj cych proces

konstruowania symulatorów. Nie istniej wreszcie metody pozwalaj ce na łatwe

oszacowanie wyników bada symulacyjnych gdy nie mo na ich porówna z wynikami

bada eksperymentalnych lub analitycznych [1] . Je eli problem da si rozwi za za

pomoc technik analitycznych to t wła nie drog nale y wybra jako prostsz , bardziej

wiarygodn i zazwyczaj szybsz i ta sz .

Ze wzgl du na mnogo zastosowa i podej do tematu symulacji, jak równie

na bogaty zestaw narz dzi do jej wykonania, nie mo na jednoznacznie odpowiedzie na

pytanie, jak wykona system symulacyjny. Jednak e zostały opracowane modele i

procedury, które s pomocne w jej tworzeniu. Dotycz one systemów dyskretnych.

Ka dy projekt systemu symulacyjnego, aby działa poprawnie, powinien przej pewne

etapy tworzenia. Pomini cie której z nich mo e mie zgubne skutki na efekty

eksperymentu symulacyjnego.

Oczywi cie, schemat oparty na tych etapach, jest tylko szkicem do wła ciwej

pracy. Jego uszczegółowienie zale e b dzie od rodzaju systemu rzeczywistego, który

ma by symulowany. W tym rozdziale szerszej analizie podane zostan sprawy

zwi zane z budowaniem systemów symuluj cych procesy wytwarzania, gdy jest to

tematem całej niniejszej pracy.

Zostan tu równie przedstawione przykłady tak tworzenia, jak równie

zastosowania symulacji do rozwi zywania rzeczywistych problemów. Wiele

przykładów znale mo na na stronie brytyjskiej firmy

www.lanner.com

. Firma ta

specjalizuje si w tworzeniu narz dzi symulacyjnych i wykonywania eksperymentów

symulacyjnych. W ród jej klientów znajduj si m.in. Motorolla, Michelin, Nissan czy

Politechnika Cz stochowska

Hewlett - Packard . Wiele naukowo opracowanych sposobów u ycia symulacji w

ró nych dziedzinach znajduje si na stronach Winter Simulation Conference o adresie

www.informs-cs.org

. Wszystkie przykłady dotyczyły b d zagadnie zwi zanych z

produkcj lub pokrewnych. Istniej równie prace z innych dziedzin, np. wojskowo ci

[10], których do wiadczenia równie mog okaza si pomocne.

2.5.1 Ogólny schemat tworzenia modelu symulacyjnego

Przedstawiony plan projektowania i tworzenia systemów symulacyjnych. Jest on

godny uwagi przynajmniej z kilku wzgl dów. Po pierwsze jest to schemat prosty i

szczegółowy, b d cy dobrym punktem wyj cia do rozpocz cia prac nad własnym

modelem symulacyjnym. Po drugie, cenne wskazówki w nim zawarte mog wzbogaci

i ułatwi prac , W ko cu po trzecie, warto pozna go, aby mie gł bsz perspektyw na

sposób, w jaki rozwijały si systemy symulacyjne. Na tej podstawie powstały obecne

schematy tworzenia systemów symulacyjnych. W swojej ksi ce [1] autor Jerzy Tyszer

podaje nast puj cy plan przygotowania i eksploatacji modelu symulacyjnego:

Okre lenie systemu

Sformułowanie modelu

Przygotowanie danych

Zaprogramowanie modelu

Ocen adekwatno ci modelu

Planowanie strategiczne eksperymentów symulacyjnych

Planowanie taktyczne eksperymentów symulacyjnych

Prowadzenie wła ciwych eksperymentów

Interpretacja uzyskanych wyników

Dokumentowanie

Schemat ten jest nadal powielany w wielu pracach i podej ciach, np. w [9].

Poszczególne etapy powinny by wykonywane w podanej kolejno ci. Poni ej

zamieszczony został krótki opis zaczerpni ty z [1] ka dego z etapów.

Okre lenie systemu - sformułowanie problemu oraz okre lenie celu

modelowania. Zazwyczaj system b d cy przedmiotem modelowania i symulacji,

jest podsystemem wi kszego, bardziej zło onego systemu, którego obiekty w

wi kszym lub mniejszym stopniu wpływaj na badany system. Projektant musi

okre li wyra ne granice pomi dzy badanym systemem a jego rodowiskiem,

oddzieli istotne relacje wi

ce obiekty systemu ze wiatem zewn trznym od

relacji nieistotnych o znaczeniu pomijalnym. Musi równie okre li cel stawiany

przed symulacj . W ko cu nale y dokona wyboru parametrów i zmiennych

systemu oraz ustali miary jego skuteczno ci. Miary te mog przyjmowa posta

współczynników, wielko ci skalarnych, wektorów, funkcji prawdopodobie stwa

itp.

Sformułowanie modelu - ilo ciowa i jako ciowa reprezentacja jego struktury

statycznej i dynamicznej. Model pozwala wyrazi wpływ czynników istotnych z

punktu widzenia prowadzonych bada na zachowanie si systemu.

Podstawowym problemem na tym etapie jest dobór stopnia szczegółowo ci

modelu do postawionego celu. modelowania. Wi ksza liczba szczegółów czyni

model bardziej podobnym do rzeczywistego systemu. Wzbogacanie modelu

atrakcyjnymi detalami, które nie wnosz nic istotnego z punktu widzenia celu

symulacji, powoduje nieproporcjonalny wzrost trudno ci w implementacji i

Politechnika Cz stochowska

weryfikacji modelu. Selekcj wła ciwego poziomu szczegółowo ci ułatwia

modularna struktura modelu, w której wymiana pewnych elementów jest prosta i

nie wymaga przeprojektowania cało ci. "Wprowadzanie zmian mo e mie

charakter post powania iteracyjnego, polegaj cego na konstruowaniu modeli o

coraz wi kszym stopniu zło ono ci. Proces jest kontynuowany a do otrzymania

modelu najbardziej adekwatnego do badanego systemu. Brak formalnych metod

tworzenia modeli symulacyjnych sprawia jednak, e ten etap bada jest raczej

sztuk i wymaga du ego do wiadczenia" [1].

Przygotowanie danych - przygotowanie danych wej ciowych dla systemu

symulacyjnego na podstawie istniej cego systemu rzeczywistego. Bardzo

rzadko dane te s ustalane tylko na podstawie rozwa a teoretycznych.

Zazwyczaj pozostaj one w cisłym zwi zku z danymi empirycznymi. Jak

wynika z do wiadcze w konstruowaniu takich systemów, tylko niewielka cz

pozyskanej empirycznie informacji okazuje si odpowiednia do rozwi zania

postawionego problemu. Informacji tej mo na u y jak danych bezpo rednich

lub jako podstaw do okre lenia teoretycznych i empirycznych rozkładów

prawdopodobie stwa, według których generowane maj by liczby

pseudolosowe. U ycie wył cznie danych nieprzetworzonych w praktyce daje

jedynie mo liwo symulowania przeszło ci. Jakkolwiek ułatwiaj one

weryfikacj modelu, nie zawsze pozwalaj na pełne wykorzystanie mo liwo ci

dobrze zaimplementowanego systemu. Dane, które maja posłu y do symulacji

działania projektowanego systemu rzeczywistego zazwyczaj okre la si na

odstawie znajomo ci systemów ju istniej cych, podobnych do projektowanego.

Zaprogramowane modelu - zaimplementowanie modelu symulacyjnego w

wybranym j zyku lub stworzenie go za pomoc dost pnego pakietu

symulacyjnego zorientowanego aplikacyjnie [6][8]. Wybór konkretnego

narz dzia jest zazwyczaj podyktowany dost pno ci i kosztem odpowiedniego

oprogramowania, umiej tno ciami programisty i charakterem rozwi zywanego

problemu. Mo na równie do tego celu u y j zyków ogólnego przeznaczenia,

jednak wówczas przygotowanie programu symulacyjnego jest cz sto najbardziej

czasochłonnym fragmentem całego procesu tworzenia modelu symulacji.

Ocena adekwatno ci modelu - porównanie procesów symulowanych z

działaniem systemu rzeczywistego. Wykonanie takiego eksperymentu wymaga

ustalenia pewnych kryteriów umo liwiaj cych sklasyfikowanie systemu jako

poprawny lub niepoprawny. Jednoznaczne rozstrzygni cie tego problemu nie

jest zazwyczaj mo liwe, cho by z powodu trudno ci w doborze kryteriów

oceny. Wsz dzie tam, gdzie to mo liwe pierwszym krokiem walidacji systemu

jest porównanie działania symulacji z reakcj systemu rzeczywistego przy

identycznych danych wej ciowych. Innymi podstawowymi metodami oceny

realno ci modeli symulacyjnych to :

sprawdzenie, czy model nie generuje absurdalnych wyników dla typowych

danych

sprawdzenie, czy uzyskane wyniki maja interpretacj w systemie

rzeczywistym

obserwacja pracuj cego modelu przez osoby nie zwi zane z jego

opracowaniem

prze ledzenie w odwrotnym kierunku toku rozumowania przyj tego podczas

opracowania modelu.

Taktyczne i strategiczne planowanie eksperymentów symulacyjnych - plany

eksperymentów symulacyjnych obejmuj ce zestawy oraz warto ci parametrów

Politechnika Cz stochowska

modelu, dla których ma by wykonana symulacja. S to parametry zarówno

wej ciowe, jak i wyj ciowe oraz stałe opisuj ce sam proces. Prawidłowy układ

eksperymentów zapewni ma otrzymanie jak najwi kszej ilo ci informacji przy

minimalnych nakładach obliczeniowych. Na ka dy eksperyment wpływaj

ró nego rodzaju czynniki, takie jak warunki pocz tkowe i ko cowe, momenty

gromadzenia danych. W fazie planowania taktycznego nale y tak rozwi za

problem doboru powy szych parametrów, aby model w mo liwie krótkim czasie

osi gn ł zamierzony tryb pracy, oraz aby rozrzut uzyskiwanych wyników wokół

warto ci rednich był minimalny. Wła ciwe obliczenia symulacyjne warto

poprzedzi obserwacj przebiegów kontrolnych. Ich zadaniem jest okre lenie

wpływu zmian warto ci danych wej ciowych na stopie czuło ci

otrzymywanych wyników. Na jej podstawie mo na jeszcze dokona korekty tak

planu eksperymentów, jak i postaci danych wej ciowych.

Dokumentacja - Przygotowanie odpowiedniej dokumentacji opisuj cej

zastosowanie oraz sposób tworzenia modelu symulacyjnego. Dokumentacja taka

powinna zawiera nast puj ce cz ci:

krótk charakterystyk analizowanego systemu z wyszczególnieniem

wa nych obiektów oraz wi

cych je relacji

sformułowanie zakresu i celu bada symulacyjnych

projekt modelu symulacyjnego oraz tabulogram programu z krótkim opisem

struktur danych i podstawowych segmentów programu plan eksperymentów

wykaz danych wej ciowych u ywanych w poszczególnych przebiegach

analiz i ocen uzyskanych rezultatów

wnioski wynikaj ce z uzyskanych bada

zalecenia dla potencjalnych u ytkowników symulatora

wskazówki dotycz ce ewentualnej rozbudowy modelu

Zazwyczaj w literaturze znale bardzo podobne schematy. Dowodzi to dobrze

opracowanej metodologii i wiarygodno ci tego schematu. Niekiedy proponowane jest

jednoczesne przeprowadzanie ró nych faz, zastosowanie modelowania przyrostowego,

prowadzenie fazy weryfikacji i walidacji równolegle od rozpocz cia prac nad

projektem. Jest to nieco inne podej cie od przedstawionego powy ej. W miar

mo liwo ci przedstawione zostan równie ró ne warianty tej techniki projektowania

modeli symulacyjnych, wynikaj ce z ró norodno ci zastosowa .

Zaprezentowany przez B. Saudona [5] plan definiowania i zbierania danych

dotycz cych modelu symulacyjnego obejmuje cztery nast puj ce kroki:

Sformułowanie problemu i planowanie - ta faza obejmuje zdefiniowanie

problemu, okre lenie zasobów niezb dnych w pracy nad symulacja oraz

samego działania symulacji, analiz systemu i danych. Definicja problemu

obejmuje okre lenie celów symulacji, oszacowanie dost pnego przedziału

czasu, zrozumienie działania systemu rzeczywistego i okre lenie punktu

widzenia jego przedstawienia, oraz stworzenie planu opracowania danych

wyj ciowych i ich analizy. Jednym z głównych zada tej fazy jest okre lenie

granic systemu, który ma by symulowany, oraz zasad jego powi zania ze

wiatem zewn trznym.

Abstrakcja systemu - model jest abstrakcj systemu rzeczywistego. Modele

cz sto opisywane s w ten sam sposób, w jaki maj by przedstawione

uzyskane wyniki. Opis zazwyczaj przyjmuje form diagramu prezentuj cego

sprz towe i programowe zasoby systemu i ich powi zania. Wzbogacony on

Politechnika Cz stochowska

jest opisem mo liwych operacji i odno nikami obja niaj cymi działanie

systemu. Stosowane s te , zwłaszcza przy du ych systemach, diagramy

wielopoziomowe i notacje w pseudokodzie, obja niaj ce wa niejsze

elementy systemu. Dla przedstawienia abstrakcji systemu mo na u y

techniki dekompozycji, jak równie techniki syntezy. W podej ciu syntezy,

wykonuje si kilka etapów, na ka dym z nich tworz c wy szy poziom

abstrakcji. Po osi gni ciu po danego poziomu, nale y dokona analizy

wszystkich składników i oceni ich wpływ na efekt ko cowy. Podej cie

dekompozycyjne jest odwrotne do syntezy. Badany model na pocz tku

rozwa a przedstawiany jest jako cało . Jest on nast pnie rozpatrywany

jako rozł czne podsystemy. Ta czynno jest powtarzana a do osi gni cia

oczekiwanego poziomu abstrakcji. Zaletami tego podej cia jest prostota w

okre leniu mechanizmów przyczynowo - skutkowych i ich weryfikacji.

Okre lenie niezb dnych zasobów - okre lenie zasobów takich, jak pieni dze,

personel, czas i specjalistyczny sprz t. Okre lenie tych potrzeb oszcz dzi

kłopotów w nast pnych fazach budowy modelu. Brak tych zasobów mo e

doprowadzi do konieczno ci zmiany podej cia do modelowanego systemu.

Analiza systemu - gruntowne przeanalizowanie systemu, zaznajomienie si

twórców systemu symulacyjnego z wszystkimi detalami zwi zanymi z

przebiegiem procesu rzeczywistego. Dobrze równie poprze badania

empiryczne zaczerpni tymi z literatury fachowej ródłami dotycz cymi

rozwi zywaniu podobnych problemów. Nale y bowiem pami ta , e

"Problem dobrze zdefiniowany to problem w połowie rozwi zany".

Politechnika Cz stochowska

NIE

Rys. 2.4 Ogólny schemat planowania i tworzenia systemu symulacyjnego

Okre lenie systemu

Sformułowanie modelu

Przygotowanie danych

Budowa modelu

Zaprogramowanie modelu

Weryfikacja

TAK

Walidacja

Planowanie

eksperymentów

Przeprowadzenie

eksperymentów i

interpretacja wyników

Wi cej

danych?

TAK

NIE

Implementacja

Politechnika Cz stochowska

2.5.2 Projektowanie i implementacja

W schemacie (Rys. 2.4) wprowadzono faz programowania modelu [9]. Podczas

niej nie jest tworzony wła ciwy - operacyjny model symulacyjny, lecz jego prototyp.

Dalsze prace weryfikacyjne s prowadzone na tym wła nie modelu systemu

symulacyjnego. U podstaw tego podej cia le y proste, zazwyczaj wła ciwe zało enie

trzech elementów niezb dnych do stworzenia systemu symulacyjnego. Pierwszym

elementem jest rzeczywisty system, b d cy obiektem symulacji wraz ze wszystkimi

jego zasobami, operacjami, funkcjami i zale no ciami ł cz cymi go ze wiatem

zewn trznym. Drugim elementem jest u ytkownik systemu. Jest on ekspertem w

sprawach dotycz cych modelowanego systemu i nie ma adnego do wiadczenia na polu

tworzenia modeli symulacyjnych. Trzecim jest projektant systemów symulacyjnych.

Spełnia on rol eksperta w dziedzinie modeli symulacyjnych, nie posiada adnej wiedzy

o systemie rzeczywistym [12]. Jako modelu symulacyjnego zale y wi c w tym

schemacie od trzech czynników:

u ytkownik bardzo dobrze zna system rzeczywisty i potrafi sformułowa

swoje oczekiwania co do korzy ci, jakich oczekuje po u yciu symulacji

projektant ma do wiadczenie w dziedzinie tworzenia symulacji i potrafi

wyja ni sposób jej działania u ytkownikowi

u ytkownik i projektant potrafi ze sob współpracowa i wymienia

merytoryczne uwagi dotycz ce mo liwo ci, oczekiwa i sposobu prezentacji

symulacji i jej wyników

Rys. 2.5. Model współpracy przy tworzeniu systemu symulacyjnego

Prototyp powinien spełnia pewne warunki, aby czas po wi cony na jego

opracowanie nie był czasem straconym. Do najwa niejszych cech odró niaj cych

prototyp od modelu operacyjnego [12] nale :

krótki czas implementacji

jak najmniejszy rozmiar

RZECZYWISTY

SYSTEM

PROJEKTANT

MODELU SYMULACYJNEGO

Model symulacji

U YTKOWNIK

MODELU SYMULACYJNEGO

Wyobra enie

systemu

Politechnika Cz stochowska

mo na w łatwy i przyst pny sposób opisa u ytkownikowi jego działanie

u ywany jest przez krótki okres czasu do rozwi zywania nagl cych

problemów, lub jako podstawa dla bardziej skomplikowanego systemu

stabilno pracy

standardowy interfejs u ytkownika

mo liwo definiowania modelu przez u ytkownika

dokładna dokumentacja prototypu w celu umo liwienia innym programistom

jego ewentualne rozwini cie.

Zalet u ycia prototypu jest łatwo jego weryfikacji i dokonania zmian. Poza

tym, przy zastosowaniach komercyjnych, łatwiej jest opisa i wytłumaczy

u ytkownikowi - zleceniodawcy schemat i podej cie do symulowanego systemu. Z

drugiej strony, to u ytkownik, jako osoba odpowiedzialna za decyzje podj te na

podstawie symulacji, oraz jako strona znaj ca symulowany system rzeczywisty, musi

przekaza twórcy modelu swoj wizj działania systemu rzeczywistego [12]. Dzi ki

prototypowi, dyskusja nad modelem operacyjnym nie musi toczy si "w powietrzu".

Ka da ze stron ma mo liwo weryfikacji własnego spojrzenia na symulowany system,

jak równie mo e lepiej zrozumie wizj systemu drugiej strony. Jest to chyba

najwa niejsza zaleta wprowadzenia prototypu.

Tworzenie prototypu mo e równie doprowadzi do zarzucenia projektu

symulacji. Dzieje si tak zazwyczaj z dwóch powodów:

u ytkownik stwierdza, e symulacja nie b dzie dobr metod rozwi zania

jego problemów

prototyp modelu jest wystarczaj cy dla u ytkownika i jego dalsze

uszczegóławianie i rozbudowa dadz niewspółmiernie małe korzy ci do

poniesionych kosztów

W tym przypadku prototyp równie spełnia swoje zadanie, gdy chroni przed

niepotrzebnym wzrostem kosztów.

Mo na oczywi cie zrezygnowa z prototypu i podczas fazy programowania

modelu tworzy wła ciwy model. Istnieje pewne ryzyko, e je eli u ytkownik zmieni

zdanie na temat funkcji czy sposobu działania pewnej cz ci systemu, przysporzy to

mnóstwo pracy projektantowi modelu. Poza tym trudniej jest wyja ni u ytkownikowi

działanie modelu ni na przykładzie prototypu. To podej cie ma te i dobre strony.

Je eli u ytkownik b dzie ci le współpracował z projektantem, a projektant b dzie

potrafił w przyst pny sposób wyja ni mu schemat działania modelu, to u ytkownik

otrzyma narz dzie, którego budow zna i ma zaufanie do generowanych przez nie

wyników.

Podczas prac nad implementowaniem systemu, którego ramy nie s dokładnie

okre lone proponowana jest technika stosowania małych kroków [12]. Ma to miejsce

wtedy, gdy u ytkownik nie okre li szczegółowo ci modelu. W takim wypadku

dodawanie niewielkich cz ci do systemu i weryfikacja cało ci z potrzebami odbiorcy

minimalizuje ilo pracy wło onej w "ostatni krok", który mo e zosta odrzucony przez

u ytkownika jako nieistotny dla całego modelu z rozpatrywanego punktu widzenia.

Wła nie zbyt du a ilo detali jest cz stym bł dem wyst puj cym podczas

projektowania i implementacji modelu symulacyjnego. Cz sto nie mo na stwierdzi ,

czy dany detal jest istotny czy nie, zanim nie sprawdzi si jego wpływu na cało

symulacji. Dlatego lepiej jest tworzy systemy proste, a nast pnie uszczegóławia je

cały czas sprawdzaj c czy system działa poprawnie, ni pewn cz

modelu rozwija i

Politechnika Cz stochowska

uszczegóławia zgodnie z przyj tym projektem, zaniedbuj c w tym czasie pozostałe

elementy modelu. Warto te poprosi o współprac osob niezwi zan z projektem i

referowa jej 2 - 3 razy w tygodniu przebieg prac nad projektem. Zazwyczaj nie

zajmuje to wi cej ni 15 minut. Nawet je eli słuchacz nie zadaje pyta i nie krytykuje

projektu, sam projektant z tych rozmów mo e wyci gn wiele wniosków pomocnych

w dalszej pracy [13].

Praca nad implementacj modelu symulacyjnego mo e mie ró n posta . Mo e

by prowadzona jako wst pne opracowanie prototypu, a dopiero na jego podstawie

stworzenie wła ciwego, operacyjnego modelu. Mo e te mie charakter programowania

przyrostowego i wzrostu szczegółowo ci systemu a do osi gni cia po danego przez

u ytkownika stopnia. Mo liwe jest te , przy małych projektach, tworzenie systemu

tylko na podstawie dokumentacji i jego weryfikacja ju po zako czeniu pracy. W ko cu

mo na równie zastosowa model programowania odkrywczego, przy mgli cie

przedstawionych zało eniach co do budowy, zasad działania i celu symulacji. Ten

sposób mo e si sprawdzi jednak jedynie przy konstruowaniu symulacji w celach

dydaktycznych. Nawet przy symulowaniu małych systemów rzeczywistych to podej cie

doprowadzi do fiaska całego przedsi wzi cia, gdy brak b dzie mo liwo ci dyskusji z

u ytkownikiem, weryfikacji (nieistniej cego) modelu.

2.5.3 Weryfikacja i walidacja systemu symulacyjnego

Weryfikacja modelu polega na porównaniu zaimplementowanego modelu z

modelem zaprojektowanym. Obejmuje ona zarówno skonfrontowanie programu z

zało eniami, jakie postawił projektant, jak i jego wizj systemu. W tej fazie

sprawdzeniu podlega równie sam kod ródłowy programu, przeprowadzany jest

debugging i usuwane s bł dy zarówno wynikaj ce ze składni j zyka, jak i

nieprawidłowej, z punktu widzenia logicznego, implementacji systemu. Poprawne

przeprowadzenie czynno ci zwi zanych z weryfikacj ma zapewni :

zgodno systemu symulacyjnego z zało eniami projektanta na poziomie

kodu ródłowego i dokumentacji technicznej

działanie systemu zgodnie z wizj projektanta na poziomie logiki i zało e

systemu, zgodnych z projektem modelu symulacyjnego

brak bł dów składniowych i logicznych w aplikacji

logiczn spójno systemu

bezawaryjne działanie systemu symulacyjnego

stabilne rodowisko pracy

Weryfikacja powinna by przeprowadzana po ka dej zmianie w systemie

symulacyjnym. Dodanie jakiego , pozornie mało znacz cego, elementu, mo e wpłyn

na poprawno działania całego programu. Cz stym bł dem jest jej rozpocz cie dopiero

w trakcie ko cowych prac nad modelem. W tym stadium system jest ju zazwyczaj

bardzo rozbudowany i znalezienie ewentualnych bł dów jest zadaniem trudnym i

pracochłonnym. Szczególnie trudne do poprawienia, a czasem i znalezienia, s bł dy

logiczne. Program kompiluje si poprawnie, działa stabilnie, lecz w wyniku daje bł dne

wyniki. Czasami zało enia symulacji nie s spełniane, lub spełniane s tylko w

okre lonych warunkach. Wtedy wykrycie bł dów jest kłopotliwe, wymaga weryfikacji

całego programu, cz sto nie daj c pewno ci, e sposób, w jaki system został

naprawiony nie wygenerował innych, z reguły mniejszych i trudniej zauwa alnych

bł dów. Rozpocz cie weryfikacji na samym pocz tku prac nad systemem w znacznym

stopniu redukuje ogólny czas potrzebny do usuni cia bł dów. O wiele pro ciej jest

Politechnika Cz stochowska

sprawdzi cz

systemu i okre li , czy działa poprawnie, czy nie. Cz

ta mo e zosta

uznana z działaj c poprawnie dopóki nie zostan poczynione zmiany w niej, lub w

elementach, które maj jakikolwiek wpływ na jej działanie. Z tego wynikaj dwie

przesłanki do budowy i projektowania systemów symulacyjnych:

implementacj rozpocz od najcz ciej u ywanych i najmniejszych

elementów systemu, np. tworz c symulacj sklepu, rozpocz od stworzenia

klasy towaru

je eli zachodzi potrzeba wprowadzenia zmian w takim elemencie, sprawdzi

jej wpływ na cało systemu symulacyjnego, a nast pnie przej do dalszych

prac

Walidacja jest to proces wyznaczania stopnia, w jakim model jest wiernym

odzwierciedleniem rzeczywistego systemu z przyj tego punktu widzenia [16]. Ma na

celu okre lenie, czy symulacja daje wiarygodne wyniki, w zało onym stopniu zgodne z

odpowiedziami rzeczywistego systemu na takie same dane wej ciowe. O ile dzi ki

weryfikacji projektant uzyskuje informacje o zgodno ci systemu symulacyjnego z jego

zało eniami, o tyle walidacja weryfikuje zgodno jego wizji z realnym wiatem. Obie

te fazy wzajemnie si uzupełniaj i jako takie czasami przedstawiane s wspólnie jako

faza oceny adekwatno ci modelu [1].

2.5.4 Metody walidacji systemu

Cz sto stosowana jest subiektywna weryfikacja i walidacja modelu.

Przeprowadzana jest ona przez zespół pracuj cy nad tworzeniem systemu

symulacyjnego. Kwalifikacja modelu jako daj cego dobre wyniki podejmowana jest na

podstawie testów przy u yciu danych z systemu rzeczywistego oraz wygenerowanych

przez symulator. Nie jest to jednak podej cie daj ce pewno o adekwatno ci wyników,

gdy nie bierze pod uwag działania systemu w warunkach skrajnych, dla których nie

ma potwierdzonych danych. Nie daje wi c pełnego obrazu rzeczywistego systemu.

Inn metod jest tzw. niezale na weryfikacja i walidacja (ang. Independent

Verification And Validation IV&V)[15]. Zgodnie z ni wykorzystuje si trzeci

niezale n grup ludzi, niezwi zan ani z projektantami, ani z u ytkownikami systemu.

To ta grupa ma za zadanie zdecydowa , czy model jest adekwatny do systemu

rzeczywistego, czy te nie. Podej cie to cz sto stosuje si w przypadku systemów

bardzo obszernych, nad których stworzeniem pracowała du a grupa ludzi, lub gdy

poniesiono znaczne nakłady na ich opracowanie. Sposób ten podnosi wiarygodno

modelu. Niezb dne jest jednak, aby zespół walidacyjny posiadał zarówno wiedz o

systemie, jak i o celach którym ma słu y symulacja. To od jego oceny b dzie zale ało,

czy system zostanie uznany za narz dzie odpowiednie do rozwi zania problemu.

Istniej dwa podej cia do procesu walidacji. Pierwsze opiera si na równoległej pracy

zespołu walidacyjnego z projektantami systemu i bie cej ocenie adekwatno ci modelu.

Drugie zakłada walidacj i weryfikacj systemu symulacyjnego po zako czeniu nad

nim prac. To podej cie jest jednak dro sze i bardziej czasochłonne od pierwszego [15].

Dlatego zalecane jest podej cie równoległej walidacji podczas całego procesu

powstawania modelu symulacyjnego.

Politechnika Cz stochowska

cel symulacji

czas

Rys.2.6 Weryfikacja i walidacja prowadzona równolegle z pracami nad

projektem

Je eli istnieje mo liwo , walidacja systemu powinna by wsparta przez

rozmowy z u ytkownikiem systemu (Rys. 2.5). Jest on najlepszym ródłem informacji o

systemie, jego działaniu i zasobach. Maj c przez długi czas styczno z systemem

rzeczywistym, ekspert cz sto potrafi odpowiedzie na pytania o zachowaniu systemu w

warunkach skrajnych, ekstremalnych. Cz sto mo e wytkn ra ce bł dy, których

podstaw jest niezrozumienie rzeczywistego systemu, które s przyczyn generowania

przez symulacj złych wyników. Nie nale y traktowa tego jako pora ki, lecz jako

pracy nad modelem [14]. Poza tym bardzo istotn kwesti jest osobiste

zaanga owanie u ytkownika w proces tworzenia systemu [14]. Je eli b dzie miał on

wra enie współtworzenia modelu, b dzie ch tniej współpracował z projektantem, co na

pewno korzystnie wpłynie na jako i wiarygodno symulacji.

Kolejnym sposobem walidacji systemu jest metoda punktowanego modelu. Za

ka d cz

pracy systemu przyznawane s subiektywnie ustalane punkty. Nast pnie

punkty te s sumowane i na tej podstawie okre lana jest przydatno systemu. Je eli

system uzyska wi cej punktów ni pewna, z góry ustalona warto graniczna, to jest on

uwa any z adekwatny, w przeciwnym razie wymaga on jeszcze poprawek. Nie jest to

metoda daj ca wysok wiarygodno . Mo e ona prowadzi do licznych nieporozumie

i bł dów, dlatego jest niech tnie stosowana w praktyce.Za najwa niejsze wady i

zagro enia tego podej cia uwa a si :

sumowanie punktów cz stkowych mo e prowadzi do zatajenia defektów,

które nale ałoby poprawi

subiektywno podej cia ma form zawoalowan i dlatego mo e by ono

mylnie traktowane jako obiektywne

ustalenie granicy punktów zaliczenia testu walidacyjnego jest zazwyczaj

subiektywne

w ten sposób ustalony poziom punktów mo e powodowa zbytni , niczym

nieuzasadnion , wiarygodno dla systemu lub by podstaw do twierdzenia

o wy szo ci jednego systemu nad innym

CEL

SYMULACJI

Politechnika Cz stochowska

Rys.2.7 Systematyka modelu Weryfikacji, Walidacji i Akredytacji

Rozbudowanym modelem jest akredytacja wyników po przeprowadzeniu

weryfikacji i walidacji (ang. Verification, Validation and Accreditation VV&A)[16].

Model ten jest stosowany przy rozpatrywaniu systemów wojskowych. Akredytacja jest

to oficjalne wydanie certyfikatu potwierdzaj cego przydatno danego modelu

symulacyjnego do wykorzystania w ci le okre lonym celu. Przedstawiona powy ej

systematyka (Rys.2.7) ma równie zastosowanie w innych modelach weryfikacji i

walidacji. Niektóre z wymienionych w niej elementów mog lub musz by pomini te

ze wzgl du na brak danych, czy niedost pno wymaganych zasobów. Nie zawsze

bowiem jest mo liwo skorzystania z wiedzy eksperta, czy brak jest danych

historycznych dotycz cych pracy systemu rzeczywistego. Je eli chodzi jednak o

Weryfikacja, Walidacja i Akredytacja

Weryfikacja

podstaw logicznych i

matematycznych

implementacji w

programie

danych

Walidacja

danych

ocena

empiryczna

ocena

teoretyczna

u ywaj c danych

historycznych

u ywaj c oceny

danych z testów

u ywaj c danych

laboratoryjnych

ocena

analityczna

ocena

probabilistyczna

za pomoc

kryteriów

ekonomicznych

ocena

porównawcza

opinia eksperta

porównanie z

doktryn

do innych modeli

Akredytacja

certyfikat danych

tymczasowa dla

aplikacji

jako cz

planu

analizy

Politechnika Cz stochowska

weryfikacj , to nale y przeprowadzi analiz systemu pod ka dym z wymienionych

punktów widzenia. Jest ona zawsze mo liwa, a przeprowadzenie jej w sposób dokładny

i krytyczny w znacznym stopniu upro ci prac nad walidacj systemu i zmniejszy ilo

bł dów. Weryfikacj z natury rzeczy przeprowadza powinien zespół projektantów

systemu. O ile bowiem walidacj cz ciowo lub w cało ci mo e zaj si u ytkownik

lub zespół niezale ny, o tyle zlecanie weryfikacji oddzielnemu zespołowi jest

niecelowe. Po pierwsze, weryfikator musi zna narz dzie lub j zyk programowania, w

którym stworzono model symulacyjny. S to cechy charakteryzuj ce twórców systemu.

Po drugie, czas po wi cony na wtajemniczenie zespołu weryfikacyjnego w zagadnienia

zwi zane zarówno z problemem postawionym przed symulacj , jak i z modelem

logicznym, na jakim si symulacja opiera, bardzo wydłu yłby czas tworzenia systemu.

Celowe za to wydaje si wyznaczenie zespołu programistów - twórców modelu,

odpowiedzialnego za prowadzenie weryfikacji w trakcie prowadzenia prac.

Do znanym narz dziem do walidacji programów zwi zanych nie tylko z

symulacj , ale głównie znanym z zastosowa w sztucznej inteligencji, jest test Turinga

[22]. Polega on na badaniu odpowiedzi systemu rzeczywistego i systemu cyfrowego.

Je eli osoba, b d grupa osób pełni ca rol s dziego, nie jest w stanie jednoznacznie

stwierdzi , która z odpowiedzi pochodzi od maszyny, test uwa a si za zaliczony. Ten

test wykorzystuje si np. do badania inteligentnych systemów dialogowych. je eli

"s dzia" nie jest w stanie okre li , czy rozmawia z maszyn czy z człowiekiem, oznacza

to zaliczenie testu. Dla programów symulacyjnych test ten polega na porównaniu

wyników symulacji i systemu rzeczywistego. Mo e on by wykorzystywany

samodzielnie, lub jako jedno z narz dzi walidacyjnych.

Aby mo liwe było dogł bne przeprowadzenie weryfikacji i walidacji systemu

podczas działania, konieczne jest zapewnienie mo liwo ci obserwowania danych.

Obserwowanie oznacza równie mo liwo zbierania danych. Dane te nast pnie

porównuje si z danymi rzeczywistymi dla ustalenia, czy model symulacyjny jest

dostatecznie dokładny. Je eli nie jest to mo liwe dla wi kszej liczby powtórze ,

niemo liwe staje si równie stworzenie modelu o wysokiej wiarygodno ci wyników

[15]. Obserwacji powinny podlega nie tylko dane wyj ciowe. O ile to mo liwe

obserwacji i porównaniu podlega powinny równie przebiegi zmienno ci stanów

poszczególnych obiektów w systemie. To podej cie prowadzi cz sto do wzrostu

obserwowanych danych. Ma to na celu udowodnienie poprawno ci modelu lub

wykryciu wad. Nawet je eli nie ma odpowiednich danych rzeczywistych koniecznych

dla porówna , zebrane dane symulacji zaowocuj łatwiejszym wykryciem bł dów i

niestabilnych miejsc systemu symulacyjnego.

Porówna mo na dokona na kilka sposobów. Zazwyczaj stosowane s trzy

podej cia: u ycie graficznej prezentacji systemu rzeczywistego i modelu symulacyjnego

do podj cia subiektywnych decyzji, ustalenie przedziałów ufno ci i formalizowanych

testów hipotetycznych. Zalecane s dwa ostatnie podej cia, poniewa one daj

obiektywn ocen systemu [15]. Jednak e cz sto w praktyce nie jest mo liwe ich

u ycie. Powodem mo e by trudno w przedstawieniu danych metodami

statystycznymi, lub niewielka ilo danych rzeczywistych powoduj ca, e wyniki

operacji statystycznych na nich przeprowadzonych odwzorowuj jedynie cz ciowo

zachowanie systemu, przez co nie maj praktycznego zastosowania. Przykładem mo e

by przedział ufno ci utworzony na podstawie danych rzeczywistych, którego

szeroko nie pozwala na zastosowanie go w praktyce [15]. W takich przypadkach

oprze si nale y na prezentacji graficznej. Pomimo subiektywnego charakteru tej

Politechnika Cz stochowska

oceny, jest ona do cz sto wykorzystywana, nawet w projektach bardzo zło onych.

Przykładem mo e by system COMAND opracowany na zlecenie Defence Science and

Technology Laboratory przez CORDA Ltd. Jest to symulator kampanii powietrzno -

morskich. Do walidacji systemu posłu yły dane dotycz ce bitwy o Falklandy z 1982

roku. Uznano, e kluczowymi danymi, jakie powinny by zgodne w rzeczywisto ci i w

wyniku symulacji b d :

ilo zniszczonych okr tów wojennych i statków

straty lotnictwa

ilo zniszczonych łodzi podwodnych

rozkład strat ze wzgl du na typ uzbrojenia i przyczyn zniszczenia

Wykonano 160 niezale nych eksperymentów symulacyjnych i na tej podstawie

opracowano wnioski [10].

Jak wida , w tym przykładzie u yto tylko jednego zestawu danych ródłowych.

Walidacji systemu dokonano na podstawie wykresów graficznych, na których

zaznaczono dane rzeczywiste, oraz przedział, dla którego prawdopodobie stwo danych

wyj ciowych symulacji wynosiło powy ej 95%. Wykresy wygenerowano dla ka dej z

wcze niej wymienionych grup danych, osobno dla ka dej strony konfliktu.

2.5.5 Bł dy w procesie weryfikacji i walidacji

Nale y pami ta o bardzo istotnej kwestii. aden model nie został nigdy

zweryfikowany w 100%. Nie ma mo liwo ci aby przeprowadzi całkowit walidacj

systemu symulacyjnego. Ka dy model jest tylko reprezentacj systemu rzeczywistego i

jego zachowania s w najlepszym wypadku aproksymacj rzeczywistego działania.

Posługuj c si przykładem, nie mo na powiedzie , e model domu wykonany w pewnej

skali, nawet 1:1, posiada wszelkie cechy budynku rzeczywistego. Przeciwnie,

prezentuje on jedynie pewne aspekty budynku w przybli eniu, na jakie godzi si

projektant modelu i jego u ytkownik. Jak powiedział znany statystyk George Box:

"Wszystkie modele s bł dne. Niektóre s u yteczne" [17]. Pami taj c o pierwszym,

nale y stara si spełni warunek drugi. Nie jest to zadanie łatwe. Nie mo na bowiem

ostatecznie stwierdzi , kiedy model osi gn ł odpowiedni stopie adekwatno ci, jest

stabilny i pozbawiony bł dów logicznych, kiedy mo na zako czy prac .

Przez model, który przeszedł weryfikacj i walidacj rozumie nale y model

poddany serii operacji maj cych na celu uszczegółowienie go do poziomu, na jakim

b dzie mógł sprosta postawionym przed nim zadaniom. Wiarygodno modelu zale y

od zaufania, jakie ma do niego u ytkownik. Proces weryfikacji i walidacji ma na celu

doprowadzi do tego poziomu wiarygodno ci.

Bł dy popełniane w czasie prac nad systemem symulacyjnym mo na podzieli

na kilka grup. Wiedz c, gdzie zazwyczaj zdarzaj si usterki, łatwiej mo na je znale i

poprawi . Poni ej zamieszczony zostanie podział bł dów i krótka charakterystyka

ka dej z grup [17]

bł dy w zarz dzaniu projektem - zwi zane s z niewła ciwym

przedstawieniem rzeczywistego systemu na samym pocz tku tworzenia i

projektowania modelu. Wynikaj głównie z tego, e nie uwzgl dniono zasad

pracy pewnej cz ci systemu. Mog by łatwo wykryte, ale ich usuni cie,

szczególnie w ko cowej fazie tworzenia projektu, mo e by czasochłonne i

kosztowne

bł dne dane i bł dne modelowanie danych - bł dne dane to dane wej ciowe

zawieraj ce bł dy, bł dny sposób przedstawienia danych lub ich

niekompletno . Bł dne modelowanie danych rozumie nale y jako

Politechnika Cz stochowska

niewła ciwe ich u ycie w modelu, np. okre lenie zmiennej losowej na

podstawie niewła ciwych danych. Głównymi ródłami bł dnych danych s :

dost pno jedynie danych sumarycznych, podczas gdy konieczne s dane

jednostkowe

dost pno jedynie danych pogrupowanych, kiedy potrzebne s dane

jednostkowe

nie s okre lone powody, od których zale ne s warto ci dost pnych danych

uogólnione dane procentowe, np. wiadomo, e wykorzystanie maszyn

wynosi 94%, nie wiadomo nic na temat czasów napraw oraz czasów

awarii poszczególnych jednostek

dost pno

jedynie

danych

odpowiadaj cych

wyj ciu

systemu

symulacyjnego

Głównymi ródłami bł dnego modelu danych s :

u ywanie warto ci redniej, kiedy w rzeczywisto ci jest to warto losowa

u ywanie warto ci redniej, gdy w rzeczywisto ci jest ona zale na od

pewnego atrybutu, np. ró ne czasy wykonania ró nych typów cz ci

u ywanie warto ci losowych z powodu ró nych warto ci rzeczywistych,

podczas gdy te ró nice maj pewien znany powód

niewła ciwe modelowanie prawdopodobie stwa awarii maszyny

niewła ciwe u ycie niezale no ci statystycznej obiektów, które w

rzeczywisto ci s ze sob powi zane

bł dy logiczne modelowania - bł dy zwi zane z projektowaniem i

implementacj systemu w j zyku programowania, lub za pomoc innych

narz dzi do tworzenia modeli symulacyjnych. Niektóre z tych bł dów mog

by uzale nione wła nie od wykorzystywanego narz dzia, lub wyst powa

cz sto w danej klasie, np. bł dne indeksowanie jest głównym powodem

bł dów obliczeniowych w j zykach symulacyjnych ogólnego stosowania [17].

Podnosi to wymagania w stosunku do projektanta i programisty, co do

znajomo ci wykorzystywanego oprogramowania. Bł dy w zarz dzaniu

projektem s przyczyn wielu bł dów logicznych. Szerszym i zazwyczaj

niedostrzeganym powodem bł dów logicznych jest niedbale przeprowadzony

proces projektowania systemu, lub jego cz ci. Wiele współczesnych j zyków

symulacyjnych umo liwia du elastyczno w je eli chodzi o sposób

modelowania. Umo liwia to dokładniejsze zamodelowanie systemu, stawia

jednak przed projektantem du e wymagania. Prawd jest równie , e proste

sposoby tworzenia systemu symulacyjnego, prezentowane na małych

systemach, mog by trudne do wykorzystania ich w tworzeniu modeli

wi kszych, bardziej rozbudowanych systemów.

bł dy w prowadzeniu eksperymentów - wyst puj w czasie przeprowadzania

eksperymentów symulacyjnych. Nale do nich:

zignorowanie analizy statystycznej

zbyt mała ilo powtórze symulacji

bł dne ustalenie stanu przej ciowego symulacji

bł dne ustalenie przedziałów ufno ci

Politechnika Cz stochowska

2.5.6 Weryfikacja i walidacja w procesie tworzenia modelu symulacyjnego

Celem tego rozdziału jest przedstawienie procesu tworzenia modelu

symulacyjnego z punktu widzenia prowadzenie czynno ci weryfikacyjnych i

walidacyjnych. Wcze niej przedstawione zostały procesy implementacji cało ci

systemu. Teraz zostanie dokładnie opisane miejsce i cel testowania systemu

symulacyjnego. Dogł bne zaprezentowanie tematu oceny adekwatno ci modelu

odzwierciedla wag , jak dla działania całego systemu ma ten etap jego tworzenia.

Jedynie jako projektowania systemu oraz jego weryfikacji i walidacji jest w cało ci

zale na od projektanta systemu. Nie mo na do nich zastosowa adnych narz dzi, a

ostateczna ocena systemu zawsze jest przeprowadzana przez człowieka. Jest wi c

bardziej podatna na bł dy spowodowane ludzkimi ułomno ciami. Przyzwyczajenia i

sposób pracy ka dego człowieka s unikalne i dlatego ka dy model symulacyjny b dzie

si ró nił od innego. Aby osi gn sukces w postaci poprawnie działaj cego systemu

symulacyjnego, adekwatnego do systemu rzeczywistego nale y prac sw traktowa

bardzo powa nie. Na poni szym diagramie (rys. 2.8) zobrazowano proces tworzenia

modelu symulacyjnego, z wyszczególnieniem prac nad jego weryfikacja i walidacj .

Ukazuje on równie jak wa n i wszechobecn rol zadania te powinny gra w procesie

budowy modelu.

Rys. 2.8 Weryfikacja i walidacja w procesie tworzenia systemu symulacyjnego

SYSTEM

RZECZYWISTY

MODEL

KOMPUTEROWY

MODEL

KONCEPCYJNY

Walidacja

danych

Programowanie i

implementacja

Eksperymenty

Analiza i

modelowanie

Weryfikacja modelu

komputerowego

Walidacja

operacyjna

Walidacja modelu

koncepcyjnego

Politechnika Cz stochowska

Wyja nienie poj u ytych na rys.2.8:

System rzeczywisty - system, pomysł, zjawisko, czy czynno , która ma by

symulowana, istniej ca w realnym wiecie

Model koncepcyjny - matematyczna, logiczna i słowna reprezentacja

systemu rzeczywistego, stworzona na podstawie przeprowadzonego studium

problemu

Model komputerowy - model koncepcyjny zaimplementowany w j zyku

programowania, działaj cy na systemie komputerowym; program

symulacyjny

Eksperymenty - seria do wiadcze przeprowadzonych na systemie

symulacyjnym

Walidacja danych - sprawdzenie, czy dane niezb dne do budowy, oceny i

przetestowania modelu, oraz przeprowadzenia eksperymentów dla

rozwi zania problemu, s odpowiednie, poprawne i wystarczaj ce

Walidacja modelu koncepcyjnego - ustalenie, czy teorie i zało enia b d ce

podstaw stworzenia modelu koncepcyjnego s poprawne i czy reprezentacja

systemu rzeczywistego jest logiczna i wła ciwa ze wzgl du na postawiony

problem

Weryfikacja modelu komputerowego - zapewnienie, e implementacja

modelu koncepcyjnego jest poprawna

Walidacja operacyjna - rozstrzygni cie, czy dane wyj ciowe modelu

symulacyjnego s wystarczaj co dokładne dla okre lonego celu, do jakiego

jest on tworzony

Schemat ten ma na celu uzmysłowienie czytelnikowi, jak wa n rzecz jest

weryfikacja i walidacja. Jak wida , jest ona obecna niemal e w ka dej fazie tworzenia

systemu. Harmonijny i symetryczny charakter grafu równie jest nieprzypadkowy.

Pokazuje on, e walidacja musi by przeprowadzana równie dokładnie i starannie

zarówno je eli chodzi o projekt, jak i ko cowy, działaj cy system symulacyjny.

Dla zorganizowania pracy nad adekwatno ci systemu warto posłu y si

prostym schematem przedstawionym w pracy [17]:

wst pne sprawdzenie danych wyj ciowych i okre lenie, czy mogłyby one

wyst pi w rzeczywisto ci

niezale ne uruchomienia symulacji dla jak najwi kszego i jak najbardziej

zró nicowanego zbioru danych wej ciowych w ramach fazy eksperymentu

(ang. Stress Test). Nale y zbada kształtowanie si wyników poszczególnych

przebiegów, przy zmianie niektórych parametrów wej ciowych. Nale y zna

przynajmniej kierunek tych zmian, cho znajomo ich nat enia mo e by

bardzo po yteczna. Szczególn uwag nale y zwróci na te przebiegi, w

wynikiem których s warto ci odbiegaj ce od trendów lub przewidywa

je eli istniej dane pozwalaj ce na odwzorowanie systemu rzeczywistego,

mo liwa jest naukowa walidacja, przy spełnieniu kilku warunków:

zebra dane wej ciowe i odpowiadaj ce im odpowiedzi systemu w

pewnym okresie czasu

uruchomi model symulacyjny podaj c te dane jako wej ciowe

porówna odpowied modelu symulacyjnego z odpowiedzi systemu

rzeczywistego na przestrzeni czasu

je eli dost pny jest jeden zestaw danych rzeczywistych, okre li ich

zgodno z odpowiedzi symulacji. Je eli jest wi cej zestawów danych

Politechnika Cz stochowska

ródłowych, nale y u y metod statystycznych, takich jak przedziały

ufno ci, dla ustalenia ró nic mi dzy tymi systemami

2.5.7 Techniki przydatne w fazie walidacji i weryfikacji

Zaprezentowane tutaj techniki mog okaza si przydatne podczas weryfikacji i

walidacji symulatorów systemów rzeczywistych. Zaczerpni te zostały one z [17].

wymusza nietypowe zachowania i warunki skrajne w celu zbadania

odpowiedzi na nie systemu

zidentyfikowa warto ci zmiennych wyj ciowych wskazuj ce na bł dne

działanie modelu, lub jego podejrzane zachowanie

zidentyfikowa wewn trzne stany modelu wskazuj ce na jego bł dne

działanie. Zastosowa mo na instrukcj warunkow if w podejrzanych

miejscach programu i kontrolowa je w logach lub raportach

wykona jak najwi ksz ilo przebiegów próbnych przed wykonaniem

wła ciwych eksperymentów. Bada kierunek i nat enie zmian warto ci

wyj ciowych spowodowanych zmianami na wej ciu

mie na wzgl dzie mo liwo wyst powania nieoczekiwanych przerw w

pracy człowieka w rzeczywistym systemie i ich wpływ na cało systemu

u ywa wykresów czasowych w celu przedstawienia post pów w pracy we

wszystkich wa niejszych cz ciach systemu symulacyjnego. Sprawdza

ilo wchodz cych i wychodz cych z nich elementów aby mie pewno , e

nie "gin "

u ywa animacji w celu przedstawienia działania modelu. Jest to bardzo

dobre narz dzie do weryfikacji zachowa modelu

2.6 Cele, zalety i wady symulacji

Podsumowuj c wst p teoretyczny dotycz cy modeli symulacyjnych, warto

zwróci uwag na to, jakim celom mog one słu y , jakie s ich zalety oraz wady.

Symulacja nie jest bowiem narz dziem uniwersalnym. Nie da si za jej pomoc

rozwi za wszystkich problemów. Nale y równie zwróci uwag na koszty tworzenia

modelu symulacyjnego. Istniej bowiem metody ta sze i dokładniejsze. Wykorzystanie

w takim przypadku podej cia symulacyjnego byłoby bł dem.

Głównymi celami, jakie stawia si przed badaniami symulacyjnymi na modelach

systemów rzeczywistych s :

wyznaczanie ilo ciowych charakterystyk pracy systemu w okre lonych

warunkach i przy okre lonych regułach

zbadanie zmian charakterystyk systemu pod wpływem zmian reguł i

warunków pracy

Badania symulacyjne ułatwiaj równie zrozumienie funkcjonowania systemu

rzeczywistego i umo liwiaj identyfikacj tych zasobów, których wykorzystanie, b d

poprawienie charakterystyk, poprawiłoby działanie całego systemu. Jest to jak gdyby

uboczny skutek prowadzenia bada , one same s nastawione zazwyczaj na rozwi zanie

pewnego problemu, nie za na zrozumienie zasad działania systemu.

S przypadki, w których najlepszym rozwi zaniem jest przeprowadzenie

symulacji. Do takich przypadków nale :

Politechnika Cz stochowska

sytuacje, w których inne sposoby rozwi zywania problemu zostały

odrzucone lub uznane za nie gwarantuj ce osi gni cia zadowalaj cych

rezultatów

sytuacje, w których sam proces modelowania mo e dostarczy

interesuj cych informacji na temat procesów zachodz cych w systemie

Poza wcze niej wymienionymi, istnieje wiele korzy ci z wykorzystania

narz dzia jakim jest symulacja komputerowa. Jednymi z najwa niejszych s :

działanie i zachowanie si systemów mo e by obserwowane i symulowane

zarówno w rzeczywistych jak i hipotetycznych warunkach, w drodze doboru

odpowiednich parametrów modelu i rodowiska otaczaj cego ten e model.

W tych wypadkach gwarantuje to uzyskanie wyników znacznie bardziej

realnych, ni za pomoc rozwi za analitycznych

badania symulacyjne mog wspomaga podejmowanie decyzji dotycz cych

budowy przyszłych systemów podczas fazy ich opracowania. Nie jest

wówczas konieczna budowa prototypu w celu poznania wła ciwo ci

projektowanego systemu. Model symulacyjny który wyka e nieprzydatno

modelu do zało onych celów jest mniej kosztowny ni system rzeczywisty,

który nie działałby poprawnie

ka dy eksperyment symulacyjny mo na powtórzy w tych samych

warunkach, lub wykona przy parametrach systemu zmieniaj cych si w

sposób nieosi galny w warunkach naturalnych. To powoduje, e łatwo

mo na zapewni kontrol wyników po rednich oraz przebiegu wybranych

procesów

czas potrzebny na przeprowadzenie symulacji jest o kilka rz dów wielko ci

mniejszy, ni czas potrzebny na przeprowadzenie podobnych bada czy

obserwacji w naturze

Symulacja komputerowa posiada równie wady. Wynikaj one z ró nych

przyczyn. W czasie prac nad modelem symulacyjnym mog da zna o sobie

praktycznie podczas wszystkich faz jego tworzenia, w niektórych przypadkach

prowadz c nawet do zarzucenia przedsi wzi cia. Jako najwa niejsze wady i problemy

zwi zane z symulacj wymieni mo na:

nie ma adnej pewno ci, e stworzony model b dzie działał poprawnie i da

wła ciwe rezultaty

nie istniej adne metody weryfikacyjne, które mogłyby zapewni o

powodzeniu projektu

nie istniej adne modele i ramy słu ce do budowy modeli symulacyjnych.

Ka dy z nich jest wi c inny, mo e by obci ony innymi rodzajami bł dów

porównanie dwóch modeli opisuj cych ten sam system rzeczywisty jest

bardzo problematyczne i zazwyczaj nie mo na jednoznacznie stwierdzi ,

który system lepiej odwzorowuje stan rzeczywisty

Politechnika Cz stochowska

3. Opracowanie i implementacja systemu symulacyjnego

3.1 Przedsi biorstwo Wielobran owe "HET - MARK"

P.W. "HET-MARK" jest redniej wielko ci zakładem przemysłowym. Powstało

1 lipca 1989r. na bazie Zakładu lusarskiego produkuj cego m.in. sprz t w dkarski i

okucia drzwiowe. Do 1998r. zajmowało si głównie hurtowym handlem wyrobami

hutniczymi. Obecnie zatrudnia około 40 pracowników, ł cznie z pracownikami

ksi gowo ci, kadr i logistyki. Główn działalno ci firmy jest produkcja drobnych

elementów metalowych dla przemysłu motoryzacyjnego, takich jak tulejki, podkładki,

trzpienie itp. elementy metalowe, jakie mo na uzyska w wyniku toczenia, frezowanie,

gwintowania, nawiercania itp. operacji tokarskich. Asortyment wyrobów jest szeroki i

zró nicowany, zale ny od zamówie jakie dostaje firma od zleceniodawców. Od nich

zale parametry fizyczne wyrobu, takie jak kształt, wielko , rodzaj i gatunek surowca

do produkcji, jak równie parametry jako ciowe, czyli dopuszczalna niezgodno z

wymiarami, jako surowca, itp. Zazwyczaj jednak wymagania co do jako ci wyrobów

s wysokie, firma "HET-MARK" wprowadziła maszyny i urz dzenia automatyczne,

daj ce wi ksz dokładno i powtarzalno wymiarów, jak równie zatrudnia

fachowców do obsługi tych e maszyn. Wprowadzono równie procedury zwi zane z

produkcj i kontrol jako ci. Firma "HET-MARK" posiada certyfikat TÜV

potwierdzaj cy zgodno Systemu Zapewniania Jako ci z norm EN ISO 9002. Koszty

jego uzyskania zwracaj si obecnie w postaci wzrostu konkurencyjno ci firmy na

rynku, oraz budow zaufania klientów co do jako ci oferowanych wyrobów.

Asortyment wyrobów proponowanych przez firm "HET - MARK" mo na

ogólnie podzieli na dwie grupy:

detale wytwarzane metod przeróbki plastycznej na zimno na prasach

hydraulicznych

detale wytwarzane na automatach tokarskich metoda obróbki skrawaniem.

Ze wzgl du na wysokie wymagania odbiorców co do jako ci wyrobu, w firmie

"HET-MARK" du wag przywi zuje si do zapewnienia wysokiej jako ci wyrobu

ko cowego. Kontrol jako ci przeprowadza si na ka dym poziomie procesu produkcji,

od kontroli surowca, poprzez kontrol i autokontrol na stanowiskach pracy, do

zatwierdzenia jako ci wyrobu ko cowego. Jak ju wspomniano czynno ci te s

wykonywane zgodnie z norm ISO 9002, jak równie mog by uszczegółowiane na

yczenie odbiorcy.

Główna produkcja odbywa si na hali produkcyjnej. Surowcem s pr ty

metalowe o zró nicowanych rednicach. W pierwszej fazie pr t poddawany jest

obróbce na automatach tokarskich. Nast pne fazy obróbki s dokonywane na

maszynach tokarskich r cznie.

3.1.1 Struktura firmy „HET-MARK”. Działy i ich zadania

Struktura organizacji firmy "HET-MARK" nie jest zbyt rozbudowana, zawiera

jedynie elementy niezb dne do pracy przedsi biorstwa. Charakter czysto produkcyjny

oraz stosunkowo niewielka liczba zatrudnionych pracowników odbija si równie na

charakterze działów i ich zadaniach. Zostan one pokrótce omówione, aby da obraz

charakteru firmy i jej priorytetów.

Politechnika Cz stochowska

Dział kontroli

Jest to dział odpowiedzialny za kontrol jako ci surowców oraz produktów. W jego

skład wchodz kierownik kontroli jako ci oraz dwóch kontrolerów. Zadaniem

kontrolerów jest sprawdzanie jako ci wyrobów gotowych, jak równie tzw. kontrole

lotne na stanowiskach pracy, czy pracownik nie wytwarza wadliwych detali. Kontrole

lotne s przeprowadzane niesystematycznie, ich celem jest uzupełnienie autokontroli na

stanowiskach pracy.

Kontrola jako ci przeprowadzana jest według ustalonych norm. Ka dy wyrób ma

odr bne instrukcje kontroli i autokontroli okre lone dla ka dej fazy produkcji.

Kierownik kontroli jako ci sprawdza ka d parti detali gotowych. Je eli wykryje

braki, kontrolerzy sprawdzaj cał zakwestionowan parti sztuka po sztuce. Zwi zane

jest to z dbało ci firmy o odbiorców oraz zmniejszeniem ryzyka wysyłki wadliwych

produktów do klienta.

Zadaniem działu kontroli jako ci jest równie przygotowywanie wiadectw jako ci

wymaganych przez odbiorców. Kontroluj równie jako surowca przeznaczonego do

produkcji pod wzgl dem zarówno jego zgodno ci z zał czon dokumentacj , jak i pod

wzgl dem przydatno ci do produkcji bior c pod uwag :

uszkodzenia mechaniczne,

zabrudzenia powierzchni, które mogłyby wpłyn na proces obróbki na

maszynach, czy nawet spowodowa ich uszkodzenie,

wady powierzchni,

korozj powierzchni,

prostolinijno pr tów, jej brak mógłby spowodowa nieprawidłowe działanie

maszyn prowadz ce do produkcji wadliwych elementów, czy nawet

zakleszczenia si surowca (pr ta) w maszynie

Na hali produkcyjnej znajduje si stanowisko komputerowe przystosowane do

sprawdzania parametrów detali. Dane te s nast pnie wykorzystywane jako podstawa

do statystycznego systemu kontroli jako ci. Słu y do tego program VISP PC

współpracuj cy z suwmiark elektroniczn o rozdzielczo ci maksymalnej 0,01 lub

0,001 mm. Program oblicza redni warto mierzon , redni odchyłk oraz parametry

zdolno ciowe CP i CPK. Parametry te s podstaw do wystawienia wiadectwa jako ci

dla danej partii produktów.

Pełnomocnik do spraw zarz dzania jako ci

Firma HET-MARK posiada certyfikat EN ISO-9002. Obowi zkiem pełnomocnika

do spraw zarz dzania jako ci jest dopilnowanie, aby wszelkie procedury produkcji i

kontroli jako ci były z ni zgodne. Opracowuje instrukcje i procedury:

technologiczne dla stanowisk produkcyjnych

autokontroli

kontroli

post powania z wyrobami niezgodnymi (wadliwymi)

inne wymagane przez ISO-9002 i/lub klienta

Jego zadaniem jest równie sprawdzanie procedur kontroli, przestrzegania tych

procedur, poprawno wystawionych certyfikatów. Obowi zki te pokrywaj si

cz ciowo z obowi zkami kierownika kontroli jako ci. Kierownik kontroli jako ci

trzyma piecz nad jako ci wyrobu, pełnomocnik do spraw zarz dzania jako ci

przygotowuje materiały i instrukcje, oraz nadzoruje prac działu kontroli jako ci pod

wzgl dem zgodno ci z normami ISO. Oba te działy współpracuj i uzupełniaj si

wzajemnie.

Politechnika Cz stochowska

Dział produkcji

Jest to najwi kszy dział firmy "HET-MARK", b d cy jedynym elementem

generuj cym dochody. Proces przetwarzania od surowca do wyrobu gotowego b dzie

wła nie przedmiotem symulacji. W tym miejscu opisana zostanie struktura działu,

natomiast schemat działania opisany b dzie szerzej w dalszej cz ci.

Nad cało ci produkcji panuje dyrektor. Nadzoruje on zarówno stan załogi i

maszyn, jak równie prac działu kontroli jako ci, terminy umów itp. Stał kontrol

produkcji oraz stanu załogi zajmuj si brygadzi ci.

Produkcja odbywa si na dwóch halach produkcyjnych. Jedna z nich jest niewielka,

znajduje si na niej kilka (ok. 2-3 ) maszyn, pracuje tam 2-4 pracowników. Wytwarzane

s tam proste detale metod obróbki plastycznej na zimno ,które nie wymagaj ci głej

kontroli jako ci. Druga hala produkcyjna jest o wiele wi ksza i tam wła nie odbywa si

główna produkcja metod obróbki skrawaniem. Znajduje si na niej kilkana cie

obrabiarek, uruchamianych w zale no ci od potrzeb produkcyjnych. Tu wa nie znajduje

si dział kontroli jako ci.

Na hali jest majster zajmuj cy si ustawianiem, poprawianiem i zatwierdzaniem

ustawie maszyn do produkcji danego detalu. Poza nim maszynami zajmuj si

operatorzy maszyn. Ka dy z nich ma pod swoj piecz około pi ciu maszyn. Do ich

obowi zków nale y zapewnienie ci głej i bezawaryjnej pracy maszyn; sprawdzaj

poprawno parametrów produkcji, stopie zu ycia no y i innych narz dzi cieraj cych

si , dostarczanie surowców z magazynu, odstawianie gotowych elementów do

wła ciwej strefy kontroli.

Osobn grup stanowi pracownicy dokonuj cy ko cowej obróbki r cznej detali.

W wi kszo ci przypadków polega ona na nawiercaniu otworów, frezowaniu kraw dzi,

gwintowaniu itp. Ich praca nie ma charakteru linii produkcyjnej, w nielicznych tylko

przypadkach jeden detal wymaga 2 – 3 operacji (np. frezowania i gwintowania), lecz

detale nie s na bie co podawane do kolejnego stanowiska. Surowiec pobierany jest ze

strefy produkcji w toku, a odnoszony do strefy kontroli. Taki sam proces jest

realizowany na mniejszej hali.

Kierownik gospodarki magazynowej

Jest on odpowiedzialny za całokształt gospodarki surowcami i detalami gotowymi.

Zarz dza magazynem surowców, zezwala na pobranie przez operatorów maszyn

surowców do produkcji, dba o wystarczaj c ilo surowców pokrywaj c

zapotrzebowanie wynikaj ce z zamówie . W razie wykrycia niedoboru danego

surowca, informuje o tym dział organizacji, a ten zamawia potrzebny surowiec. Pod

jego piecz znajduj si równie strefy przej ciowe na hali produkcyjnej. Kontroluje on

ilo elementów do dalszego przetworzenia tak, aby nie było przerw w produkcji. Dba

równie o to, aby ilo detali gotowych była zgodna z zamówieniami.

Dział organizacji

Jest to dział zajmuj cy si sprawami okołoprodukcyjnymi. Nale do nich:

zamawianie surowców do produkcji, kontakty z klientami dotycz ce ilo ci zamówie ,

wymaga co do produktów i norm które musz spełnia , strefa logistyki,

przeprowadzanie audytów oraz ksi gowo .

Politechnika Cz stochowska

3.1.2 Proces produkcji

Celem tego rozdziału jest przedstawienie struktury organizacji produkcji w

firmie "HET - MARK" i dogł bna jej analiza. Przedstawione tu dane i wiadomo ci

zostały zebrane za zgod i przy współpracy z kierownictwem P.W. "HET - MARK".

Wiadomo ci te s kluczowe dla analizy systemu, a nast pnie zaprojektowania systemu

symulacyjnego. Organizacja produkcji jest bowiem zło ona w wi kszym stopniu ni

organizacja na zasadzie linii produkcyjnej i jej analiza bez pomocy do wiadczonych

pracowników firmy byłaby zadaniem trudnym, czasochłonnym, a jej wyniki

najprawdopodobniej byłyby niezgodne ze stanem rzeczywistym.

a) obróbka półproduktu na automatach tokarskich

przeniesienie wyrobu do strefy kontroli

kontrola jako ciowa i przeniesienie wyrobu do strefy wyrobów gotowych,

wzgl dnie do strefy produkcji w toku, sk d pobierane s jak w p.1

ewentualna obróbka r czna wyrobów i odesłanie do strefy kontroli

Ze wzgl du na to, e w jednym czasie mo e by wytwarzane wiele typów wyrobów,

etapy produkcji dla ró nych partii zachodz w tym samym czasie, niezale nie jedna od

drugiej.

STREFY

ELEMENTY DO

KONTROLI

ODBIORU

PRODUKCJI

Rys. 3.1 Schemat cyklu produkcyjnego

AUTOMATY TOKARSKIE

Politechnika Cz stochowska

Ad. a)

Na hali produkcyjnej znajduje si ponad 30 maszyn do obróbki rur i pr tów stalowych.

S one uruchamiane i ustawiane według potrzeb produkcji. Czas obróbki materiału

przez maszyn jest stały a sama obróbka nie wymaga ingerencji człowieka. Ze wzgl du

na wysokie wymagania jako ciowe co do wyrobu ko cowego konieczny jest nadzór

ludzi nad prac i parametrami maszyn. Zazwyczaj na 5 maszyn przypada jeden

pracownik obsługi. Jego zadaniem jest sprawdzenie poprawno ci nastawów, ich

korekcja b d wprowadzanie nowych, dbanie o dobry stan cz ci zu ywaj cych si (np.

no e), oddawanie wyrobów do strefy kontroli oraz zaopatrywanie maszyn w surowiec.

W chwili, gdy która z maszyn ulegnie awarii, opiekuj cy si ni pracownik dokonuje

niezb dnych czynno ci, natomiast pozostałe 4 maszyny b d ce pod jego nadzorem

przechodz chwilowo pod piecz pozostałych pracowników.

Ad. c)

Kontrola jako ci przeprowadzana jest r cznie według procedur ustalanych dla ka dego

wyrobu b d półproduktu. Po kontroli ka da partia towaru jest opisywana i przenoszona

do odpowiedniej strefy. Tam główny inspektor kontroli jako ci dokonuje wyrywkowej

kontroli i w przypadku wykrycia defektu oddaje cała parti do sprawdzenia element po

elemencie. Kontrola jako ci przeprowadzana jest po ka dej fazie obróbki, która

prowadzi do wyra nej zmiany kształtu wyrobu. Innymi słowy, po ka dej bardziej

"inwazyjnej" fazie obróbki dana partia wyrobu musi zosta poddana kontroli jako ci.

Ad. d)

Niektóre wyroby wymagaj nawiercenia, gwintowania b d frezowania kraw dzi

otworów. Te czynno ci wykonywane s przez ludzi. Nie maj one charakteru linii

produkcyjne i zabieraj niewiele czasu.

Jak ju wspomniano, proces technologiczny wykonania danego detalu składa si

z od jednej do kilku faz obróbki skrawaniem. Ich ilo jest okre lona przez instrukcje

technologiczne, odr bne dla ka dego rodzaju wyrobu. Wszystkie jednak procesy maj

pewne cechy wspólne, a mianowicie:

pierwsza operacja odbywa si na automatach tokarskich

kolejne operacje odbywaj si na nie zautomatyzowanych stanowiskach

pracy

Czasy przetwarzania detalu bardzo ró ni si w obu tych grupach. Ró nice

mi dzy nimi pojawiaj si te w samych procedurach organizacji pracy. Dlatego te w

dalszej cz ci pracy poj ciem stanowiska pracy okre lane b d zarówno nie

zautomatyzowane stanowiska pracy (stanowiska tokarskie), jak i automaty tokarskie. W

ten sposób unikn mo na b dzie wielu nieporozumie .

Bardzo wa n rol w cyklu produkcyjnym odgrywa równie kontrola jako ci. W

firmie "HET - MARK" stosowane s trzy formy kontroli jako ci:

autokontrola jako ci na stanowisku pracy, nie wpływa ona jednak znacz co

na czas przetwarzania detalu

kontrola lotna wykonywana sporadycznie przez kierownika działu kontroli

jako ci, równie nie ma wpływu na czas przetwarzania detalu

kontrola mi dzy fazami obróbki. Jest podstawow kontrol dla zachowania

jako ci i poniek d mo e mie wpływ na czas wykonania partii materiału

Politechnika Cz stochowska

Zrozumienie przesyłania wyrobów gotowych jednej fazy obróbki jako surowiec

dla nast pnej fazy ma kluczowe znaczenie dla zrozumienia całego systemu

symulacyjnego. Ró ni si on bowiem znacznie od systemu liniowego.

W systemie liniowym wyroby przekazywane s ci gle (na ile oczywi cie

pozwala wydajno ) z maszyny poprzedniej na nast pn . ewentualnej kontroli jako ci

poddawane s dopiero wyroby ko cowe. Aby zastosowa jednak ten schemat musz

by spełnione pewne wymogi, a mianowicie:

gabaryty stanowisk pracy musz pozwala na w miar ergonomiczne ich

ustawienie na hali

wydajno poszczególnych faz produkcji powinna by zbli ona

poszczególne automaty powinny wykazywa si mał podatno ci na awarie

w procesie technologicznym wyeliminowa nale ałoby fazy wymuszaj ce

cz st regeneracj urz dze

W firmie "HET - MARK" trzeba było odst pi od modelu liniowego z kilku

przyczyn. Przede wszystkim, wydajno pierwszej fazy obróbki na automatach

tokarskich jest przynajmniej 2 - 3 krotnie ni sza ni na kolejnych fazach obróbki. Poza

tym, gabaryty automatów tokarskich s do du e. W ko cu wreszcie urz dzenia

stosowane do obróbki skrawaniem wymagaj do cz stej wymiany cz ci roboczych

takich jak no e czy wiertła. Z tych powodów w firmie wprowadzono inny schemat

produkcji opieraj cy si na systemie zmianowym.

Jedna zmiana trwa 8 godzin, przy czym automaty tokarskie pracuj przez 7

godzin, a godzina po wi cana jest na ostrzenie i wymian narz dzi, konserwacj i

nastawianie parametrów obróbki. Pracownicy na stanowiskach nie zautomatyzowanych

pracuj pełne 8 godzin.

Jedna partia materiału do dalszej obróbki to detale wykonane przez automat

tokarski w ci gu całej zmiany. Przy wydajno ci ok. 55 - 85 szt/h (sztuk na godzin ),

daje to ok. 390 - 600 sztuk w ci gu zmiany. Wszystkie detale partii składowane s w

osobnym pojemniku. Taka partia jest opisywana i poddawana kontroli jako ci. Po

kontroli jako ci detale mog zosta poddane dalszej obróbce.

Automaty tokarskie maj te pewn niekorzystn cech , a mianowicie cz sto

ulegaj niewielkim awariom, spowodowanym chocia by przez wadliwy surowiec, czy

zły stan narz dzi tokarskich. Oczywi cie ma to wpływ na wydajno w ci gu zmiany, a

zatem i na wielko partii.

Surowcem dla tej fazy obróbki s metalowe pr ty pobierane z magazynu.

Pobranie i zało enie surowca w automacie zajmuje pracownikowi od 3 do 5 minut.

Jeden pr t wystarcza na ok. 50 - 60 minut pracy automatu. Wyrobem jest zazwyczaj

element metalowy o długo ci kilku - kilkunastu centymetrów .

Politechnika Cz stochowska

przepływ detali

przepływ pojemników

Rys. 3.2 Schemat przepływu detali na stanowiskach automatów tokarskich

Na stanowiskach tokarskich praca twa 8 godzin. Wydajno obróbki jest o wiele

wi ksza ni na automatach i waha si w granicach od 250 do 700 szt./h. łatwo mo na

wi c zauwa y , e dla zapewnienia ci głej pracy stanowiska tokarskiego przez 8

godzin, automat musi pracowa kilka dni. Dlatego te wa n rzecz jest planowanie

produkcji dla ci głej pracy stanowisk tokarskich, gdy przestawianie ich kilka razy

dziennie dla obróbki ró nych rodzajów detali jest nieefektywne.

Detale po obróbce na stanowiskach s poddawane mi dzyfazowej kontroli

jako ci w przypadku, gdy ze wzgl du na jej charakter istnieje prawdopodobie stwo

wyst pienia wadliwych wyrobów. Okre lone jest to w stosownych instrukcjach

kontroli. Je eli nie ma konieczno ci przeprowadzenia kontroli jako ci, detale we

wcze niej opisanych partiach mog zosta poddane dalszej obróbce, b d , je li taki jest

cykl technologiczny, trafiaj do strefy wyrobów gotowych.

Praktyka dowiodła, e ze wzgl dów ergonomicznych wydajniejszy jest

nast puj cy system: pracownik pobiera z pojemnika kilka detali i przetwarza je na

urz dzeniu tokarskim, a nast pnie wkłada do pojemnika z detalami obrobionymi.

Wydaje si , e gdyby miał on pobiera ka dy detal osobno, wpłyn łoby to negatywnie

na jego wydajno .

MAGAZYN

pr t

metalowy

AUTOMAT

TOKARSKI

pojemnik

wyj ciowy

O
C

Politechnika Cz stochowska

Rys.3.3 Schemat przepływu detali na stanowiskach tokarskich

Na hali produkcyjnej znajduj si trzy strefy,

strefa wyrobów gotowych

strefa produkcji w toku

strefa kontroli jako ci

W strefie wyrobów gotowych składowane s pojemniki z detalami po przej ciu

wszystkich faz obróbki. Poddawane s one ostatecznej kontroli jako ci wyrobów

gotowych i po odpowiednim opisaniu przenoszone s do magazynu.

Do strefy produkcji w toku trafiaj pojemniki z detalami, które przeszły ju

kontrol jako ci, lecz wymagaj jeszcze obróbki. St d wła nie pobierane s surowce dla

stanowisk tokarskich.

Do strefy kontroli jako ci przenoszone s pojemniki z detalami które, według

instrukcji, wymagaj kontroli jako ci. Upowa nione osoby dokonuj kontroli,

wprowadzaj dane do komputerowego systemu wspomagaj cego kontrol jako ci VISP

PC. Po przeprowadzeniu kontroli pojemniki przenoszone s do strefy produkcji w toku,

a stamt d mog by pobrane do dalszej obróbki.

Ka dy z pojemników jest szczegółowo opisany Opis obejmuje numer

ewidencyjny elementu, ilo sztuk w partii, dat wykonania partii, odbyte kontrole

jako ci i ich wyniki. Te dane pozwalaj na szybszy przepływ detali i maj

fundamentalne znaczenie dla zachowania jako ci wyrobów.

Kolejn grup pracowników s kontrolerzy jako ci. Pobieraj oni pojemniki z

detalami ze strefy kontroli jako ci i po dokonaniu kontroli przenosz do strefy produkcji

w toku. Dokonuj oni równie kontroli jako ci wyrobów gotowych, jednak ta operacja

STANOWISKO

TOKARSKIE

pojemnik

wyj ciowy

O
C

pojemnik

wyj ciowy

O
C

Politechnika Cz stochowska

wykracza ju poza ramy organizacji produkcji, a wi c nie b dzie szerzej opisywana. Nie

ma ona wpływu na przebieg cyklu produkcyjnego.

Do obowi zków kontrolerów jako ci nale y równie przeprowadzanie tzw.

kontroli lotnych, tzn. sprawdzanie poprawno ci wykonania detali na stanowiskach

pracy. S one wykonywane sporadycznie (kilka razy dziennie) i maj na celu jak

najszybsze ujawnienie wady detalu. Wady te mog by spowodowane przez

nieprawidłowe działanie automatów i urz dze tokarskich, jak równie przez bł dy

ludzi. Kontrole lotne pozwalaj na szybkie ustalenie miejsca powstawania braków, oraz

usuni cie wadliwych detali z dalszego cyklu produkcyjnego.

Rys.3.4 Schemat pracy kontrolera jako ci

Okołoprodukcyjne działy i struktury firmy takie jak dział kadr, dział gospodarki

magazynowej, czy transportu nie b d tu opisywane. Ze wzgl du na to, e system

symulacyjny zajmuje si cyklami produkcyjnymi na do niskim poziomi, tzw.

mikrosymulacj [19], działania tych struktur uzna mo na za niezwi zane z tematem

pracy, a ich ewentualne wprowadzenie wprowadziłoby tylko chaos w cykl działania

symulacji. Co wi cej, mogłoby doprowadzi do jej wadliwej pracy, a otrzymane wyniki

byłyby niewiarygodne.

Wpływ na to ma fakt, e dostawy surowców maj charakter nieregularny. Ze

swej natury nie mog by przewidziane co do godziny, a ich wpływ na cykl

produkcyjny jest niewielki. Dodatkowo fakt, i symulowany obszar produkcji jest

niewielki, symulowanie dostaw surowców, czy wysyłki produktów byłoby niezgodne ze

skal zało onego projektu.

Te działania uwzgl dni mo na w kolejnych wersjach systemu symulacyjnego,

rozbudowanych do skali pracy całej hali produkcyjnej, ł cznie z gospodark

magazynow i systemem logistycznym.

Dla celów tej pracy wa ne s takie elementy procesu produkcyjnego, które maj

bezpo redni wpływ na czasy wykonania zada w obr bie linii technologicznej dla

jednego, zadanego rodzaju produkowanych detali. Pomijane s natomiast elementy

maj ce wpływ na cało produkcji zakładu. Uzasadnione jest to tym, e niespełnienie

potrzeb wy szego rz du (np. dostaw surowców, powa na awaria maszyny i jej serwis,

absencja pracownika) powoduj zmian lub wstrzymanie operacji ni szego rz du, które

po kontroli

przed

kontrol

KONTROLER

JAKO CI

pojemnik z

detalami do

kontroli

jako ci

STREFA

PRODUKCJI

W TOKU

O
C

STREFA

WYROBÓW

GOTOWYCH

Politechnika Cz stochowska

to symulowa ma system. Nie mo na natomiast przyjmowa , i zdarzenia te b d

mogły modyfikowa cykl produkcyjny na ni szym szczeblu, gdy takie zało enie

nakładałoby obowi zek zaimplementowania w systemie zdarze losowych

wyst puj cych bardzo rzadko. Przykładowo, cz stotliwo i czas usuni cia drobnych

awarii automatu tokarskiego nie wymagaj cych serwisowania mo na sensownie

zaimplementowa w symulacji obejmuj cej kilka b d kilkana cie zmian. Natomiast

awaria urz dzenia na stanowisku tokarskim wyst puj cy raz, dwa razy w miesi cu jest

ju zdarzeniem zbyt rzadkim i nieprzewidywalnym , by mo na było sensownie je

zamodelowa na tym poziomie abstrakcji.

3.2 Model koncepcyjny

Zakres bada symulacyjnych obejmuje produkcj jednego okre lonego rodzaju

elementów. Produkcja odbywa si na okre lonym przez u ytkownika zbiorze maszyn i

z udziałem okre lonej liczby pracowników zajmuj cych si kontrol jako ci.

3.2.1 Modelowane obiekty

Omówione zostan szczegółowo poszczególne elementy, jakie bior udział w

modelu symulacyjnym, wraz z zadaniami, jakie maj spełnia w systemie.

element - opis detali, jakie maj zosta otrzymane w wyniku pracy

zaprojektowanego systemu. Jest to jak gdyby instrukcja technologiczna,

zawieraj ca:

ilo faz, jakie musi przej ka dy detal

miejsca w procesie, kiedy ma by przeprowadzana kontrola jako ci

czas przeprowadzania kontroli jako ci

czas obróbki w poszczególnych fazach przetwarzania

strefa mi dzyprodukcyjna - miejsce, w którym składane s pojemniki

przeznaczone do poszczególnych celów. W rzeczywistym zakładzie s trzy

strefy:

strefa kontroli jako ci - trafiaj tu pojemniki z detalami, które musz by

poddane kontroli jako ci

strefa wyrobów gotowych - składowane s tu pojemniki z wyrobami

gotowymi, które przeszły ju wszystkie fazy obróbki

strefa produkcji w toku - trafiaj tutaj pojemniki z wyrobami

przeznaczonymi do dalszej obróbki, które ju przeszły kontrol jako ci,

lub jej nie wymagały

automat tokarski - maszyna, której zadaniem jest pierwsza faza obróbki.

Obróbka wykonywana jest automatycznie, czasy obróbki pojedynczego

elementu s stałe. Po niej detale powinny zosta poddane kontroli jako ci.

Na wej cie maszyny podawany jest pr t metalowy. Detale po obróbce

składowane s w pojemniku wyj ciowym. Zakłada si , e automat nie mo e

pracowa , je eli nie ma którego z nich. Wymiany pr ta na wej ciu dokonuje

człowiek, jej czas jest warto ci losow . Automaty mog ulega awariom. W

modelu uwzgl dniono jedynie drobne usterki, które mo na usun na terenie

firmy i wzywanie ekipy serwisuj cej nie jest konieczne. Decyzj t podj to,

gdy powa niejsze awarie nie s cz ste, a czas potrzebny na ich usuni cie

nie jest adekwatny do skali symulacji. Długo czasu awarii, jak równie

prawdopodobie stwo jej wyst pienia, ma charakter losowy. Wspomniano

ju wcze niej, e automaty tokarskie pracuj przez 7 godzin podczas 8 -

Politechnika Cz stochowska

godzinnej zmiany, po tym czasie pojemnik z przetworzonym surowcem

mo e by poddany dalszej obróbce. W modelu przyj to mo liwo

okre lenia innego czasu trwania zmiany, jak równie cz stsze przekazywanie

wyrobów. Charakterystyczne dla automatu tokarskiego warto ci to:

czas wymiany surowca

czas obróbki pojedynczego detalu

prawdopodobie stwo wyst pienia awarii

czas awarii

czas pracy automatu podczas jednej zmiany

cz stotliwo oddawania pojemnika z detalami po obróbce

Czynno ci, jakie wykonuje automat tokarski:

pobranie pr ta metalowego (surowca)

obróbka poszczególnych detali a do wyczerpania surowca

wymiana pojemnika wyj ciowego na pusty

naprawa maszyny w razie awarii

stanowisko tokarskie - na tym stanowisku detale, które przeszły pierwsz

faz obróbki poddawane s kolejnym według instrukcji technologicznej. Po

obróbce detale mog by poddane kontroli jako ci wyrobu, jednak zale y to

od operacji, jakim poddany został detal. Stanowiska tokarskie nie ulegaj

awarii. Pracuj przez cał zmian bez przerwy. Tak jak na automatach

tokarskich, do pracy niezb dne s pojemniki z surowcem i na wyrób, jednak

na wej ciu znajduje si nie pr t, lecz pojemnik z detalami z poprzedniej fazy

obróbki. Stanowisko tokarskie opisuj nast puj ce warto ci:

czas wymiany kontenera wej ciowego

czas obróbki pojedynczego detalu

ilo pobranych do obróbki detali

Czynno ci, jakie wykonywane s na stanowisku tokarskim:

pobranie pojemnika z surowcem (detalami)

obróbka poszczególnych elementów

wymiana pojemnika wyj ciowego na pusty

wymiana pojemnika wej ciowego na pełny

kontroler jako ci wyrobów - zajmuje si sprawdzeniem jako ci wyrobów. W

modelu nie została uwzgl dniona kontrola tzw. lotna, gdy nie ma ona

wpływu na czas produkcji, jedynie na jako , która nie została uwzgl dniona

w tym modelu symulacyjnym. Kontroler jako ci pobiera pojemniki ze strefy

kontroli jako ci, dokonuje kontroli jako ci i odkłada je do strefy produkcji w

toku. Wyst pienie wadliwych detali i zwi zane z tym operacje nie jest

symulowane. Warto ci opisuj ce stanowisko kontrolera jako ci produkcji to:

czas przeprowadzania kontroli jako ci partii

Czynno ci wykonywane na tym stanowisku:

pobranie pojemnika do kontroli

kontrola jako ci

przeniesienie skontrolowanego pojemnika do odpowiedniej strefy

pojemnik - jest to obiekt przechowuj cy i grupuj cy detale podczas działania

systemu. Mo e by na wej ciu maszyny, wtedy detale s z niego pobierane,

mo e by na wyj ciu, wtedy detale s do niego składowane. W modelu pr ty

metalowe równie s pojemnikami, z tym, e po wyczerpaniu surowca nie s

one odstawiane do strefy mi dzyprodukcyjnej jako puste, lecz usuwane.

Pojemnik nie wykonuje adnych czynno ci, mo e on zmienia swój stan na

skutek operacji innych obiektów systemu. Charakteryzuje si warto ciami:

Politechnika Cz stochowska

ilo detali

maksymalna ilo detali

symbol detalu jaki zawiera

czy detale powinny przej kontrol jako ci

linia produkcyjna - zbiór obiektów, poł czonych według pewnych zasad,

którego celem jest wyprodukowanie detali o okre lonych wła ciwo ciach. W

modelu linia produkcyjna zarz dza wszystkimi wy ej wymienionymi

grupami obiektów, nadzoruje ich prac i współdziałanie, ustala reguły

działania modelu. Jest odpowiedzialna za prawidłowy przebieg symulacji.

Opisuj j nast puj ce warto ci:

aktualny czas symulacji

identyfikator produkowanego elementu

ilo maszyn przeznaczonych do ka dej z faz obróbki

ilo kontrolerów jako ci

ilo pojemników

ilo pr tów metalowych (surowca)

czas działania symulacji (warunki zako czenia symulacji)

Linia produkcyjna jest elementem, który scala wszystkie pojedyncze obiekty

w jeden. Mo na j porówna do powierzchni hali produkcyjnej na której

stoj maszyny, urz dzenia i pracownicy skierowani do pracy przy produkcji

zadanego detalu.

3.2.2 Schemat działania modelu

Działanie symulacji opiera si ma modelu symulacji dyskretnej. Czas

systemowy zmienia si zgodnie z zasad nast pnego zdarzenia. Przyj to, e najmniejsz

jednostk czasu jest 1 sekunda. Wprowadzanie wi kszej dokładno ci uznano za

niecelowe ze wzgl du na czas trwania całej symulacji - przynajmniej 8 godzin, oraz

czasy wykonywania poszczególnych operacji. Poza tym eksperymentalne ustalenie

warto ci z wi ksz dokładno ci byłoby trudne. Nast pna zaleta jest znaczne

zwi kszenie przejrzysto ci modelu.

Odmierzaniem czasu systemowego, jak równie nadzorowaniem wszystkich

operacji zachodz cych w systemie zajmuje si linia produkcyjna.

W momencie rozpocz cia symulacji czas systemowy ustalany jest na zero.

Sprawdzany jest stan wszystkich elementów systemu. Obiekty, które mog wykona

operacje, przeprowadzaj je, zwracaj c czas zako czenia operacji. Nast pnie wybierany

jest najwcze niejszy czas zako czenia operacji i zegar systemowy jest przestawiany do

tego momentu. W kolejnej fazie odpytywane s znów wszystkie obiekty modelu, bez

wzgl du na to, czy s w trakcie wykonywania operacji, czy nie. Metoda ta została

zastosowana ze wzgl du na to, e nie zakłóca pracy elementów systemu, które ju

wykonuj działania, a daje lepsz kontrol nad obiektami oczekuj cymi na okre lone

zdarzenie w systemie, które pozwoli na rozpocz cie przez nie prac . Przykładem mo e

by stanowisko tokarskie oczekuj ce na pojawienie si w strefie produkcji w toku

pojemnika z detalami o identyfikatorze zgodnym z jego identyfikatorem surowca.

Jej zalet jest równie mo liwo dokładniejszego monitorowania stanu

zarówno systemu jako cało ci, jak równie poszczególnych jego cz ci w ka dym

momencie procesu symulacji. Jest to bardzo przydatne podczas weryfikacji i walidacji

systemu [17].

Politechnika Cz stochowska

Linia produkcyjna jest równie wła cicielem wszystkich obiektów

symulowanego systemu. Dane dotycz ce poszczególnych elementów przechowywane

s w specjalnie do tego przeznaczonych zmiennych. Mimo, e powoduje to dublowanie

danych, pozwala jednak na ich zachowanie w przypadku modyfikacji struktury linii,

upraszcza archiwizacj i wczytywanie danych oraz tworzenie logicznej struktury linii.

Przez logiczn struktur linii nale y rozumie powi zanie poszczególnych obiektów

mi dzy sob , nadanie im warto ci pocz tkowych i ustalenie warunku ko cz cego

symulacj . Nakłady na pami s minimalne w porównaniu z zyskami, jakie dzi ki

temu si osi ga. Poni ej zapisany został w pseudokodzie ogólny schemat tworzenia i

pracy systemu symulacyjnego.

czas_trwania_symulacji := t;

czas_symulacji := 0;

Twórz_Lini _Produkcyjn ;

Pobierz_Dane;

Twórz_Logiczn _Struktur _Linii;

while not Warunki_Ko cowe do

BEGIN

najbli sze_zdarzenie := INF;

zdarzenie_obiektu := 0;

FOR ka dy_obiekt DO

BEGIN

zdarzenie_obiektu :=

obiekt.KrokSymulacji(czas_symu

lacji);

IF najbli sze_zdarzenie > zdarzenie_obiektu THEN

najbli sze_zdarzenie=zdarzenie_obiektu;

END;

czas_symulacji := najbli sze_zdarzenie;

END;

W toku rozmów z przedstawicielami firmy "HET - MARK" opracowano model

logiczny systemu, powi zania mi dzy jego elementami, oraz kluczowe dane zarówno

wej ciowe jak i opisuj ce efekty pracy modelowanego systemu. Zrobiono równie

pewne zało enia co do działania modelu oraz reprezentacji pewnych zdarze , jakie maj

miejsce w rzeczywisto ci, mianowicie:

nie symulowanie awarii wymagaj cych obsługi serwisowej

nie symulowanie awarii na stanowiskach lusarskich

deterministyczny czas wykonania pojedynczego detalu zarówno na

automatach, jak i stanowiskach lusarskich

automatyczne zako czenie napraw automatów w momencie rozpocz cia

przerwy mi dzyzmianowej

zakłada si , e zawsze jest niezaj ty mechanik, który mo e od razu zaj

si usuni ciem usterki maszyny

kontrolerzy jako ci zawsze znajduj si na hali produkcyjnej i nie trzeba

symulowa ich nieobecno ci b d chwilowej niemo no ci kontroli

materiału

kontrola jako ci wyrobów gotowych, jako nie wpływaj ca na cykl

produkcyjny, nie jest przeprowadzana

czas wymiany surowca zawiera jeden czas jednostkowy obróbki detalu

Politechnika Cz stochowska

3.3 Wymagania funkcjonalne i niefunkcjonalne

Mimo i interfejs u ytkownika nie jest integraln cz ci systemu

symulacyjnego i system ten mo e działa bez jego udziału, jest on najbardziej

namacalnym dowodem na poprawno działania systemu i jego zgodno z

zało eniami. Interfejs u ytkownika mo e by bez przeszkód zmieniony i rozbudowany

bez ingerencji w samo "j dro" symulacyjne. Autor miał na celu stworzenie tylko

przykładowego programu pokazuj cego mo liwo ci i zastosowania zaprojektowanego

systemu. Przedstawione poni ej wymagania funkcjonalne zostały sprecyzowane w toku

rozmów z przedstawicielami firmy "HET - MARK", jak równie przez autora, w celu

ułatwienia pracy nad modelem symulacyjnym i uproszczeniu jego weryfikacji

i walidacji.

3.3.1 Wymagania funkcjonalne

Poni szy wykres prezentuje wymagania funkcjonalne co do interfejsu. Model

systemu przedstawiony został wcze niej. Interfejs u ytkownika jest przejrzysty i

czytelny. Ograniczono si do najbardziej niezb dnych funkcji prezentowania wyników

symulacji, oraz zbierania wyników jej działania.

Zarz dzanie systemem symulacyjnym

Plik

Nowy

Edycja elementu

Edycja faz produkcji

Edycja awaryjno ci maszyn

Edycja pojemników

Edycja kontroli jako ci

Edycja cyklu zmianowego

Edycja czasu trwania oraz rodzaju symulacji

Tworzenie kontroli jako ci

Politechnika Cz stochowska

Tworzenie linii produkcyjnej

Graficzna prezentacja linii produkcyjnej

Otwórz

Tworzenie kontroli jako ci

Tworzenie linii produkcyjnej

Graficzna prezentacja linii produkcyjnej

Zapis

Zapis danych dotycz cych linii produkcyjnej

Edycja

Edycja faz produkcji

Edycja pojemników

Edycja awaryjno ci maszyn

Tworzenie linii produkcyjnej

Edycja kontroli jako ci

Tworzenie kontroli jako ci

Edycja cyklu zmianowego

Edycja czasu trwania oraz rodzaju symulacji

Politechnika Cz stochowska

Edycja danych unikalnych dla poszczególnych stanowisk

Widok

Raport

Wy wietlenie danych dotycz cych pracy obiektów

w trakcie symulacji

Ustalenie liczby przebiegów

Prezentacja danych dotycz cych pracy obiektów

Prezentacja rednich warto ci danych dla wszystkich

przebiegów

Ustawienie rodzaju symulacji

Symulacja z prezentacj graficzn

Prezentacja danych dotycz cych pracy obiektów

Symulacja bez prezentacji graficznej

Wykonanie okre lonej ilo ci przebiegów

Generowanie danych statystycznych

Opcje

Rozpocz cie symulacji

Ustalenie ilo ci przebiegów

Zako czenie symulacji

Zapis danych statystycznych do pliku

Politechnika Cz stochowska

3.3.2 Wymagania niefunkcjonalne

Wymagania niefunkcjonalne postawione przez u ytkownika dotyczyły głównie

interfejsu oraz formatu danych statystycznych generowanych przez symulator i były to:

estetyczna i przejrzysta prezentacja graficzna struktury linii produkcyjnej

i jej elementów w trakcie trwania eksperymentu symulacyjnego

mo liwo obróbki wygenerowanych danych statystycznych za pomoc

arkusza kalkulacyjnego

dane statystyczne zapisane w pliku tekstowym w taki sposób, by mo na

było z nich skorzysta bezpo rednio

mo liwie szybkie generowanie danych statystycznych z du ej ilo ci prób

bez konieczno ci obsługi programu przez człowieka

Wymagania te zostały uwzgl dnione przy projektowaniu i implementacji

interfejsu. Po przestawieniu ich przedstawicielowi firmy "HET - MARK" interfejs

został zaakceptowany jako funkcjonalny i zgodny z wymaganiami u ytkownika.

3.4 Projektowanie systemu symulacyjnego

Pokrótce omówiona zostanie struktura klas wchodz cych w skład samego

"j dra" symulacji. Budowa interfejsu u ytkownika nie jest istotna dla działania

symulatora. Zostan przedstawione podstawowe klasy wraz z ich polami oraz

metodami, oraz powi zania mi dzy nimi. Klasy odwzorowuj elementy systemu

wyró nione w modelu koncepcyjnym, b d cym efektem modelowania. Projektowanie

modelu symulacyjnego było procesem dynamicznym, model ten ulegał zmianom, jakie

wi zały si z usuwaniem bł dów logicznych. Dlatego przedstawione zostan jedynie te

elementy, które maja kluczowy wpływ na działanie systemu.

Klasa CElement - klasa odpowiedzialna za przechowywanie informacji dotycz cych

elementu, jaki jest produkowany na zaprojektowanej linii produkcyjnej. Jej pola to:

eleme_id - identyfikator (nazwa) elementu

nStages - ilo faz potrzebnych do wykonania elementu

avg_times - tablica przechowuj ca czasy wykonania pojedynczego

elementu na danej fazie

Ustawienie pr dko ci pracy symulacji

Ustalenie liczby przebiegów

Opracowanie warto ci statystycznych

Zapis wyników do pliku

Zbieranie danych statystycznych

Politechnika Cz stochowska

Klasa CContainer - klasa reprezentuj ca pojemniki na detale. Reprezentuje równie

surowiec w postaci pr tów metalowych. Opisuj j nast puj ce dane:

elem_id - identyfikator aktualnie przechowywanego elementu. W

praktyce jest to numer fazy obróbki, jakiej zostały poddane elementy w

nim si znajduj ce

count - ilo detali znajduj cych si w pojemniku

base_container - flaga oznaczaj ca, czy pojemnik ma by traktowany jak

metalowy pr t, czy jak zwykły pojemnik

quality_control - flaga oznaczaj ca, czy detale znajduj ce si w tym

pojemniku maj zosta poddane kontroli jako ci, czy nie

quality_control_time - czas trwania ewentualnej kontroli jako ci

Funkcje składowe klasy CContainer:

CreateContainer - nadawanie warto ci pocz tkowych pojemnikowi

SetQualityControl - ustawienie danych dotycz cych kontroli jako ci

CreateBase - nadawanie pojemnikowi warto ci pocz tkowych i nadanie

mu funkcji surowca - metalowego pr ta

GetSource - pobranie detalu z pojemnika

PutElement - wło enie do pojemnika detalu

Klasa CStage jest klas podstawow dla dwu klas: CMachine oraz CHandWork.

Reprezentuje ona dowolne stanowisko pracy: automat tokarski i stanowisko tokarskie.

Nie istniej adne obiekty tej klasy. Przechowuje ona jednak dane wymagane zarówno

przez jedna jak i drug klas pochodn . Jest to podyktowane tym, e obiekty tych klas

tworzone s dynamicznie. Gdyby która z nich miała inn struktur pól ni klasa

rodzica, to zarz dzanie tymi obiektami byłoby utrudnione. Zostan wymienione

elementy wspólne dla obu klas, a dla danych wykorzystywanych tylko przez jedna z

nich b d stosowne adnotacje.

Pola wspólne dla obu klas dziedzicz cych z klasy CStage:

name - nazwa stanowiska pracy

cont_in - wska nik do pojemnika z surowcem

cont_ount - wska nik do pojemnika z detalami gotowymi

time - aktualny czas symulacji

avg_time - czas obróbki pojedynczego detalu

next_event - bezwzgl dny czas wyst pienia kolejnego zdarzenia na tym

stanowisku

state stan stanowiska - czy mo e obrabia elementy, czy nie

in_id - umowny identyfikator pojemnika z surowcem

out_id - umowny identyfikator pojemnika z wyrobem gotowym

start_time - czas rozpocz cia pracy

statistic - dane statystyczne zbierane podczas pracy symulacji

input_triangle - czas wymiany pojemnika z surowcem w postaci

przedziału

output_triangle - czas wymiany pojemnika z detalami gotowymi w

postaci przedziału

ro_type, ri_type - rodzaje rozkładów zmiennych losowych czasów

wymiany pojemników

Dane wykorzystywane przez klas CMachine reprezentuj c automaty tokarskie:

Politechnika Cz stochowska

shift - czas trwania cyklu zapełniania kontenera wyj ciowego

shift_end - czas zako czenia aktualnego cyklu

act_shift - numer aktualnego cyklu

pause_time - czas trwania przerwy mi dzyzmianowej

damage_probability - prawdopodobie stwo wyst pienia awarii

damage_time - czas usuwania awarii w formie przedziałowej

rd_type - rodzaj rozkładu zmiennych losowych czasów usuwania awarii

Dane wykorzystywane przez klas CHandWork reprezentuj c stanowiska tokarskie:

- n_taking - ilo elementów pobieranych jednocze nie przez pracownika

Wa niejsze funkcje wchodz ce w skład klasy CStage (dost pne w obydwu klasach

pochodnych):

StartingPos - nadawanie parametrom stanowiska warto ci pocz tkowych

SimulationStep - krok symulacji

ProceedWithSource - obróbka detalu

DamageOccured - sprawdzenie czy wyst piła awaria

SetState - ustalanie stanu w jakim jest stanowisko

PutOutContainer, TakeOutContainer - odkładanie b d pobieranie

pojemnika z detalami gotowymi

PutInContainer, TakeInContainer - odkładanie b d pobieranie

pojemnika z surowcem

ActivateOutContainer, ActivateInContainer - sprawdzanie, czy pobrane

kontenery s prawidłowe i ich ustawienie na wła ciwej pozycji

ChangingOutput, ChangingInput - aktywacja wymienionych

pojemników

RandomizeDamageTime, RangomizeInput, RandomizeOutput -

generowanie danych losowych zgodnie z przyj tym rozkładem

Klasa CZone - klasa reprezentuj ca strefy mi dzyprodukcyjne. zarz dza znajduj cymi

si w niej pojemnikami. Do niej odwołuj si pozostałe obiekty w celu pobrania,

wymiany b d oddania pojemnika. Zmienne składowe tej klasy to:

cont - tablica wska ników do pojemników znajduj cych si w danej

strefie

c_count - aktualna ilo pojemników w strefie

max_count - maksymalna ilo pojemników - rozmiar tablicy

wska ników

Najwa niejsze funkcje składowe klasy to:

PutContainer - wło enie pojemnika do strefy

TakeContainer - pobranie pojemnika ze strefy

TakeControlContainer - pobranie kontenera do kontroli jako ci

GetBaseCount - zwraca ilo pr tów metalowych

GetFullCount - zwraca ilo pojemników zawieraj cych detale

GetEmptyCount - zwraca ilo pojemników nie zawieraj cych detali

GetElementCount - zwraca ilo wszystkich detali znajduj cych si w

pojemnikach strefy

Politechnika Cz stochowska

Klasa CQualityControler reprezentuje pracowników odpowiedzialnych za kontrol

jako ci. W systemie reprezentowani s oni w ograniczonym zakresie, gdy w systemie

rzeczywistym ich obowi zki wykraczaj poza zakres, jaki obejmuje model

symulacyjny. Przyj to wi c na u ytek modelu, e kontroler ma zawsze czas na kontrol

jako ci wyrobów danego typu, natomiast czas tej kontroli mo e by ustalany dowolnie,

a zmienna opisuj ca go mo e mie dowoln g sto . Poza tym przyj to, e czas kontroli

jako ci nie jest zale ny od kontrolera, lecz od detalu, jaki ma kontrolowa . Dane

opisuj ce klas CQualityControler to:

container - wska nik do aktualnie sprawdzanego pojemnika

time - aktualny czas symulacji

next_event - moment nast pnego zdarzenia

state - stan w jakim jest kontroler jako ci

tested_element - ilo sprawdzonych detali

control_time - czas kontroli aktualnie sprawdzanego pojemnika

Funkcje wchodz ce w skład tej klasy:

StartingPos - ustawianiekontrolera w stan pocz tkowy

SimulationStep - pojedynczy krok symulacji

TakeContainer - pobranie pojemnika do kontroli jako ci

PutContainer - odło enie pojemnika po przeprowadzeniu kontroli jako ci

Klasa CProductionLine reprezentuje cał struktur logiczn i fizyczn cyklu

produkcyjnego. Jest wła cicielem wszystkich obiektów wchodz cych w skład modelu

symulacyjnego. Koordynuje wszelkie zdarzenia, jakie maj miejsce podczas pracy

modelu. Interfejs u ytkownika komunikuje si tylko i wył cznie z obiektem tego typu.

Równie poszczególne obiekty wchodz ce w skład modelu symulacyjnego podczas

aktywacji pobieraj z obiektu typu CProductionLine dane pocz tkowe. Dane

charakteryzuj ce obiekty tej klasy:

element - obiekt typu CElement

zone - obiekt typu CZone reprezentuj cy stref produkcji w toku

out_zone - obiekt typu CZone reprezentuj cy stref wyrobów gotowych

control_zone - obiekt typu CZone reprezentuj cy stref kontroli jako ci

container - tablica obiektów typu CContainer - wszystkie istniej ce

fizycznie w systemie pojemniki

stage - dwuwymiarowa tablica obiektów CStage - wszystkie istniej ce w

systemie automaty i stanowiska tokarskie

c_count - ilo pojemników

base_count - ilo surowca - pr tów metalowych

base_max - ilo detali, jak mo na wyprodukowa z jednego

metalowego pr ta

n_stages - ł czna ilo stanowisk i automatów tokarskich

triangle_input_times - tablica czasów wymiany pojemników z surowcem

triangle_output_times - tablica czasów wymiany pojemników z

wyrobami gotowymi

s_count - tablica ilo ci stanowisk dla ka dej fazy produkcji

time - aktualny czas symulacji

sim_time - czas trwania symulacji

n_taking - ilo pobieranych elementów przez CHandWork

controler - tablica obiektów CQualityControler kontrolerów jako ci

controler_count - ilosc kontrolerow jakosci

pause - flaga oznaczaj ca zako czenie symulacji

Politechnika Cz stochowska

quality_control - tablica flag kontroli jako ci po ka dej fazie

quality_triangle - tablica czasów kontroli jako ci po ka dej fazie

rq_type, rd_type, shift_time, pause_time, n_shifts, damage_probability,

damage_time - dane dotycz ce klasy CStage, maj ce takie samo jak tam

znaczenie.

Funkcje klasy CProductionLine:

CreateProductionLine - tworzy logiczn struktur linii produkcyjnej

CreateQualityControl - tworzy struktur kontroli jako ci

SimulationStep - pojedynczy krok symulacji, wykonanie wszystkich

zdarze , jakie zaszły w danym momencie czasu

StartingPos - ustawienie wszystkich obiektów modelu w ich stanach

pocz tkowych

RandomizeQualityControlTime - generowanie warto ci losowej czasu

kontroli jako ci zgodnie z wybran g sto ci zmiennej losowej

LoadLineFromFile - wczytanie z pliku danych dotycz cych całej

struktury linii

SaveLineToFile - zapis do pliku danych dotycz cych całej struktury linii

Dodatkow klas jest klasa CTriangle, której obiekty przechowuj dane na temat

liczb zapisanych w postaci przedziałów z wyró nionym rodkiem ci ko ci.

Wykorzystywane s one przy generowaniu liczb losowych. Elementami tej klasy s :

min - warto minimalna, lewy kraniec przedziału losowego

avg - warto rednia, rodek ci ko ci przedziału

max - warto maksymalna,. prawy kraniec przedziału losowania

Funkcje klasy CTriangle:

GetRandomParabolicValue - zwraca warto zmiennej losowej o

g sto ci parabolicznej

GetRandomLinearValue - zwraca warto zmiennej losowej o g sto ci

liniowej (stałej)

GetRandomTriangleValue - zwraca warto zmiennej losowej o g sto ci

trójk tnej

3.5 Implementacja systemu symulacyjnego

Po opracowaniu wst pnego modelu koncepcyjnego, zidentyfikowaniu

elementów maj cych istotne znaczenie dla przebiegu rzeczywistego procesu

produkcyjnego, oraz po zrobieniu wy ej wymienionych zało e , przyst piono do

implementacji modelu symulacyjnego. Jako rodowisko programowania wybrano

Microsoft Visual Studio C++ 6. Wyboru tego dokonano ze wzgl du na kilka

czynników. Przede wszystkim decydowały umiej tno ci i do wiadczenie autora w

programowaniu w j zyku C++ oraz zgodno tego rodowiska ze specyfikacj tego

j zyka oraz jego stabilno . Wa n spraw była te bogata pomoc w postaci MS

Developer Network. Brak podobnej pozycji niejednokrotnie bardzo utrudnia prac w

innych rodowiskach, takich jak np. Borland C++ Builder.

Przy tworzeniu systemu symulacyjnego u yto model kaskadowy z

prototypowaniem [18]. Model ten jest cz sto polecany w literaturze, jako daj cy du e

korzy ci przy współpracy z u ytkownikiem ko cowym systemu. Ewentualne bł dy

wynikłe podczas budowania modelu koncepcyjnego s stosunkowo łatwe do wykrycia a

Politechnika Cz stochowska

ich usuni cie zazwyczaj nie nastr cza wielkich trudno ci. Podej cie to okazało si

słuszne, gdy po prezentacji prototypu przedstawiciel firmy wytkn ł powa ne

uchybienia w strukturze logicznej modelu. Po ich usuni ciu prototyp zaprezentowano

ponownie. Został on oceniony jako adekwatna reprezentacja systemu rzeczywistego i

został wykorzystany jako podstawa do stworzenia systemu symulacyjnego.

Prototyp obejmował wszystkie elementy modelu koncepcyjnego. Interfejs

u ytkownika był bardzo ubogi. Nie został równie zaimplementowany aden generator

liczb losowych, w zwi zku z czym prototyp był modelem deterministycznym.

Upraszczało to jednak bardzo weryfikacj szkieletu modelu, pozwoliło na łatwe

znalezienie bł dów w implementacji. Gdyby symulator od pocz tku dawał warto ci

losowe, identyfikacja du ej liczby z nich byłaby bardzo trudna, b d wr cz niemo liwa.

Po zaakceptowaniu struktury logicznej rozpocz to prace nad wła ciwym

systemem. Prototyp stał si jego podstaw , jednak dodane zostały do niego liczne

funkcje. Przede wszystkim dodano generator zmiennych losowych o zadanej g sto ci.

Ulepszono i rozbudowano interfejs u ytkownika, opieraj c go na technologii

widok - dokument (ang. View - Document). W technologii tej wszelkie dane

przechowywane s w obiekcie klasy CDocument, natomiast klasa CView zarz dza

wy wietlaniem, prezentacj danych i komunikacj z u ytkownikiem. Poniewa do

jednego dokumentu podł czy mo na wiele widoków, łatwo mo na rozbudowa

aplikacje, dodaj c okna pokazuj ce działanie symulacji z ró nych punktów widzenia.

Wprowadzanie danych i modyfikacja parametrów odbywa si głównie poprzez okna

dialogowe, które ł cz si bezpo rednio z dokumentem i na bie co modyfikuj

odpowiednie dane.

Prezentacja graficzna symulacji mo e si odbywa w dwóch trybach:

animacyjnym i schematycznym. Przechodzenie pomi dzy nimi odbywa si poprzez

podwójne klikni cie w dowolnym miejscu obszaru roboczego aplikacji.

Pierwszy z nich prezentuje symulacj za pomoc animowanych obrazów

(Rys. 3.5). Pozwala zrozumie proces produkcyjny i sam budow linii. Wy wietlane

obrazy s wzorowane na faktycznym wygl dzie poszczególnych obiektów w systemie

rzeczywistym.

W trybie schematycznym (Rys. 3.6) linia produkcyjna rysowana jest za pomoc

bloków reprezentuj cych poszczególne obiekty modelu. Ten tryb pozwala na ledzenie

niektórych danych dotycz cych procesu produkcji - stopnia zapełnienia pojemników,

zaj to ci poszczególnych stanowisk, czy czasu oczekiwania na kolejne zdarzenie na

poszczególnych stanowiskach. Elementy s rozmieszczone w tych samych miejscach,

jak w trybie animacyjnym. Tryb schematyczny sam w sobie nie jest zbyt przejrzysty,

lecz w poł czeniu z trybem animacyjnym pozwala na zrozumienie struktury linii, oraz

na ledzenie jej parametrów.

Politechnika Cz stochowska

3.5.1 Generator liczb losowych

Niektóre z danych w systemie rzeczywistym maj charakter losowy. S to

zazwyczaj operacje przeprowadzane przez człowieka, b d przy jego udziale. Mo na do

nich zaliczy :

czas wymiany pojemników

czas przeprowadzania operacji kontroli jako ci

czas usuwania usterki

Wszystkie te czynno ci modelowane s za pomoc przedziałów liczb. Mo liwe jest

równie okre lenie redniej, najcz ciej spotykanej w rzeczywisto ci, warto ci. Do

bada wydajno ci zalecane jest jednak stosowanie zmiennej o stałej g sto ci f(x)=const.

W celach porównawczych zastosowano równie zmienne funkcji g sto ci trójk tnej i

parabolicznej. Sposoby generowania warto ci losowych z ich zakresu zostan

przedstawione poni ej.

Rozbudowanie mo liwo ci symulacji pod wzgl dem ró norodno ci zmiennych

losowych jest łatwe i bezpieczne. Nie wymaga ingerencji w samo j dro symulacji.

Konieczne jest jedynie dodanie wymaganej funkcjonalno ci do klasy CTriangle, oraz

wykorzystanie jej w odpowiednich funkcjach pozostałych klas.

Zmienna o stałej g sto ci - generowana jest z zadanego przedziału

<min, max> przy u yciu narz dzi standardowych - generatora liczb c++.

Przy generowaniu warto ci losowych tego typu nie jest brana warto

parametru CTriangle::avg. Przykładowy wykres prezentuje rozkład ilo ci

wyst pie poszczególnych liczb z zakresu <1, 100> w 1.000.000 prób

Rozkład zmiennej losowej o stałej

g sto ci

9500

9600

9700

9800

9900

10000

10100

10200

10300

ilo trafie

lic

Zmienna losowa o stałej g sto ci

9500

9600

9700

9800

9900

10000

10100

10200

10300

liczba

ilo

Politechnika Cz stochowska

Zmienna losowa o rozkładzie trójk tnym - funkcja g sto ci tej zmiennej ma

kształt trójk ta , którego wierzchołek znajduje si w punkcie CTriangle::avg,

mo liwe jest wi c okre lenie najcz ciej wyst puj cej warto ci z zadanego

przedziału <min, max> nie b d cej jego rodkiem. Odpowiada to

werbalnemu sformułowaniu przedziału, np. "warto ci wyst puj w

przedziale od 1 do 10, ale najcz ciej w okolicach 3". Wtedy mo na

przedstawi to jako trójk t o warto ciach min = 1, max = 10, avg = 3.

Algorytm otrzymywania zmiennej losowej o rozkładzie trójk tnym jest

nast puj cy:

rzutowa rodek ci ko ci avg na przedział <0,1>

min

max

min

−

avg

wylosowa liczb u o rozkładzie jednostajnym z przedziału <0,1>

obliczy warto zmiennej r o rozkładzie trójk tnym

avg

min)

(max

min)

(

min

−

dla a < u

)

(

min)

(max

)

(max

max

avg

−

dla a > u

r = avg

dla a = u

Zmienna losowa o rozkładzie

trójk tnym

5000

10000

15000

20000

25000

liczba

ilo

rednia = 20
rednia = 50
rednia = 75

Politechnika Cz stochowska

Zmienna losowa o rozkładzie parabolicznym - funkcja g sto ci ma kształt

odwróconej paraboli. Do generowania tego rodzaju zmiennych u yto

algorytmu opartego na metodzie eliminacji [1]. Została ona zaproponowana

przez von Neumanna w 1951 roku w nast puj cym kształcie: Niech zmienna

losowa X ma funkcj g sto ci prawdopodobie stwa f(x) okre lon na

przedziale (a, b) i równ zeru poza nim. Niech tak e f(x) b dzie ograniczona
pewn stał 0 < c <

:. Algorytm generowania liczby liczby losowej X o

rozkładzie danym funkcj f(x) jest nast puj cy:

wyznaczy par liczb losowych (r

, r

) tak , e r

jest liczb losow o

rozkładzie równomiernym na przedziale (a, b), r

za jest liczb losow o

rozkładzie równomiernym na przedziale (0, c). Przyjmujemy ponadto, e

i r

s warto ciami dwóch niezale nych zmiennych losowych R

i R

je eli f(r

)

, jako wynik nale y przyj r

; w przeciwnym razie nale y

przej do kroku pierwszego [1].

Metody eliminacji u ywa si do generowania liczb losowych o rozkładzie

normalnym N(0,1).

W prezentowanym przykładzie funkcja f(x) = -x

+1, warto r

jest

losowana na przedziale <0, 2> a nast pnie rzutowana na przedział

<min, max>, natomiast r

na przedziale <0, 1>. Przykładowy wykres

prezentuje g sto zmiennej losowej na przedziale <1, 100> przy 1.000.000

prób.

W oparciu o t metod generowana jest równie zmienna cosinusoidalna, której
funkcja g sto ci ma kształt f(x) = cos

(x) dla 0

≤ x ≤

Zmienna losowa o rozkładzie

parabolicznym

5000

10000

15000

20000

liczba

ilo

Politechnika Cz stochowska

4. Prowadzenie eksperymentów symulacyjnych

W tej cz ci pracy przedstawione b d procedury, jakie zostały zastosowane w

prowadzeniu eksperymentów symulacyjnych, oceny ich wyników, oraz porównanie

wyników z prac systemu rzeczywistego.

Zbieranie danych statystycznych z kilkuset prób byłoby bardzo kłopotliwe i

czasochłonne, je eli miałoby by prowadzone przy udziale człowieka nadzoruj cego

ka dy z przebiegów symulacji. Prezentacja graficzna symulacji zabiera bowiem

znacznie wi cej czasu, ni potrzeba go na same obliczenia zwi zane z procesem

produkcyjnym. Z drugiej strony, nie mo na pozwoli na to, aby system działał

niekontrolowany, gdy zaufanie u ytkownika do niego byłoby niewielkie. Dlatego te

przy opracowywaniu interfejsu stworzono schemat niweluj cy w pewnym stopniu te

problemy. Ułatwia i przyspiesza on w znacznym stopniu zbieranie danych,

umo liwiaj c jednocze nie wizualn ocen działania zaprojektowanej linii.

4.1 Schemat prowadzenia eksperymentów

Zaproponowany schemat zbudowany jest w oparciu o trzy rodzaje prowadzenia

symulacji: graficzny, wst pny i statystyczny.

Pierwszy z nich, symulacja graficzna, oferuje prowadzenie symulacji z

prezentacj graficzn , tak wi c cały proces jest pod kontrol u ytkownika. Dzi ki

niemu mo na równie okre li , w którym miejscu wyst puj tzw. "w skie gardła", które

ujemnie wpływaj na wydajno zaprojektowanej struktury. Mo na te okre li

moment czasowy wyst powania przestojów spowodowanych np. brakiem surowca,

b d zbyt wolnym działaniem kontroli jako ci. W ka dym momencie mo na te

obejrze dane dotycz ce poszczególnych stanowisk, takie jak wydajno , czasy

przestojów, czy ilo wykonanych do tej pory elementów. Nie mo na jednak

automatycznie zbiera danych statystycznych dotycz cych kilku przebiegów tego typu.

Słu y on bowiem tylko do okre lenia poprawno ci modelowanej struktury.

Drugi rodzaj przeprowadzania symulacji to prowadzenie kilku eksperymentów

bez prezentacji graficznej okre lony mianem symulacji wst pnej. Po ka dym przebiegu

dane dotycz ce zarówno całej linii jak i poszczególnych jej elementów s mo liwe do

przejrzenia. Po wykonaniu wszystkich zaplanowanych przebiegów, dane rednie s

prezentowane u ytkownikowi. Kontrola nad symulacj nie jest tak du a jak w

poprzednim podej ciu, jednak cały proces odbywa si o wiele szybciej, a dane

generowane po ka dym przebiegu pozwalaj oceni poprawno pod wzgl dem

ekonomicznym zaprojektowanej linii. Jest to najszybszy z zaprojektowanych, sposób na

przeprowadzenie eksperymentu symulacyjnego. Danych przez niego generowanych

równie nie mo na przechowywa . Jego celem jest szybkie przeprowadzenie 5 - 20

przebiegów symulacji, by na tej podstawie wyci gn wnioski co do sposobu działania

struktury. Tak mała ilo przebiegów pozwala bowiem tylko na zgrubn ocen linii.

Trzeci, ostatni rodzaj prowadzenia eksperymentu symulacyjnego jest

zaprojektowany w celu zbierania danych statystycznych i dogł bnej oceny wydajno ci

zaprojektowanej struktury. Jest to symulacja statystyczna. Podobnie jak w poprzednim

podej ciu, nie ma prezentacji graficznej podczas prowadzenia pojedynczej próby

symulacyjnej. Nie s równie podawane wyniki ko cowe poszczególnych prób. W

zamian za to czas potrzebny na przeprowadzenie jednej próby symulacji jest

najmniejszy, a cały proces zbierania danych statystycznych nie wymaga udziału

człowieka. Mo liwe jest wi c przeprowadzenie 500 - 1000 prób, których wyniki

Politechnika Cz stochowska

zapisywane s do pliku. Ten proces trwa najdłu ej, jednak daje pełne spektrum

wyników, jakie mo liwe s do osi gni cia przy u yciu zaprojektowanego schematu.

Dane statystyczne, zebrane w wyniku jego działania mo na nast pnie przetwarza w

arkuszu kalkulacyjnym. Generowane s równie histogramy wydajno ci całej linii oraz

czasów produkcji zadanej partii materiału.

W oparciu o te rodzaje prowadzenia eksperymentów symulacyjnych

opracowano sposób tworzenia, oceny i zbierania danych dotycz cych zaprojektowanej

linii produkcyjnej. Składa si on z nast puj cych kroków:

Zaprojektowa struktur linii produkcyjnej

Przeprowadzi symulacj wst pn

Dokona oceny symulacji wst pnej. Je eli niektóre z parametrów

wyj ciowych symulacji budz w tpliwo ci, przeprowadzi symulacj

graficzn

Je eli ocena linii produkcyjnej, dokonana na podstawie kroków b) i c),

wypadła pozytywnie, przeprowadzi symulacj statystyczn . W przeciwnym

razie powróci do kroku a)

Dokona analizy uzyskanych danych statystycznych

Podstaw do prowadzenia analizy statystycznej s generowane przez system

symulacyjny histogramy. Przedstawiaj one rozkład wyst pie poszczególnych

warto ci w całym spektrum mo liwych wyników - od warto ci minimalnej do

maksymalnej uzyskanych w danym eksperymencie - podzielonych na 9 równych cz ci.

Na tej podstawie mo na skonstruowa funkcj g sto ci. Jednak aby miała ona kształt

zbli ony do funkcji Gaussa, nale y zaplanowa du ilo powtórze podczas symulacji

statystycznej. Poni sze wykresy prezentuj kształt funkcji g sto ci dla ró nych ilo ci

wykonanych eksperymentów dla tej samej struktury linii produkcyjnej.

Kształt funkci g sto ci dla ró nej ilo ci prób

0,2

0,4

0,6

0,8

1,2

100

250

500

1000

Politechnika Cz stochowska

Oczywisty jest fakt, e dla wi kszej ilo ci powtórze wynik jest najbardziej

prawdopodobny, a mniejsza ilo prób daje wynik jedynie przybli ony. Pami ta tak e

nale y, e zmienia si zakres, w jakim wyst puj rozwi zania, szeroko przedziału od

minimum do maksimum zwi ksza si wraz ze wzrostem ilo ci prób. Warto te zwróci

uwag na fakt, e warto rednia w cale nie musi znajdowa si w przedziale, dla

którego funkcja g sto ci przyjmuje najwi ksze warto ci.

4.2 Walidacja systemu symulacyjnego

W materiałach naukowych bardzo du a waga przywi zywana jest do weryfikacji

i walidacji systemu symulacyjnego. O ile weryfikacja jest zadaniem czysto

informatycznym, polega bowiem na znajdywaniu i usuwaniu bł dów logicznych i

składniowych w samym kodzie programu, o tyle walidacja jest zadaniem trudniejszym,

gdy wymaga współdziałania wielu osób, cz sto zajmuj cych si dziedzinami, które nie

maj ze sob nic wspólnego. Walidacj rozpocz nale y ju w pierwszych fazach

modelowania, podczas tworzenia modelu koncepcyjnego. Nast pnie, podczas procesu

tworzenia systemu, nale y kontrolowa post py prac, aby ich wynik nie odbiegał od

przyj tego modelu. Wreszcie w ko cowej fazie cały system musi zosta przetestowany.

Wyniki wygenerowane przez system symulacyjny nale y porówna z wynikami

systemu rzeczywistego. Dopiero po sprawdzeniu i zaakceptowaniu stopnia zgodno ci

obydwu z nich, system mo e zosta uznany za działaj cy poprawnie i wdro ony do

wła ciwej pracy.

Walidacja ka dego systemu mo e mie inny charakter i przebiega w inny

sposób. Zale ne to jest od wielu czynników, mi dzy innymi od dost pno ci danych

historycznych pochodz cych z symulowanego systemu, mo liwo ci wykorzystania

wiedzy eksperta, czy od zało onego stopnia wiarygodno ci, jaki symulacja musi

spełnia .

W procesie walidacji modelu symulacyjnego oparto si na danych rzeczywistych

pochodz cych z P.W. "HET - MARK". Walidacja przeprowadzona była w oparciu o

nast puj ce ródła:

dane historyczne dotycz ce ilo ci wyprodukowanych elementów

wydajno ci dla poszczególnych faz obróbki zapisane w kartach

technologicznych

warto ci rzeczywiste

wiedz eksperck

Walidacja przeprowadzona w oparciu o te ródła daje cało ciowy obraz

produkcji oraz zapewnia wiarygodno systemu na poziomie akceptowalnym przez

przedstawicieli firmy "HET - MARK".

4.2.1 Przygotowanie danych wej ciowych

Przy ocenie adekwatno ci systemu bardzo wa na była ocena modelu przez

eksperta, oraz jego rady co do kształtu zarówno całego programu, jak i poszczególnych

danych. Bardzo wa na była równie ekspercka ocena danych generowanych przez

symulator.

Wydajno ci pobrane z kart technologicznych s to ilo ci wyprodukowanych

sztuk na godzin . Za rad eksperta zostały one za obowi zuj ce dla stanowisk

tokarskich i na tej podstawie wprowadzane do systemu. Dla automatów tokarskich

zmierzone zostały czasy rzeczywiste wyprodukowania pojedynczego elementu. Czasy

Politechnika Cz stochowska

wymiany surowca, trwania przerw zwi zanych z usuwaniem usterek, czy kontrol

jako ci zostały ustalone w formie przedziałowej po rozmowach z kierownictwem, jak

równie z pracownikami firmy i zaakceptowane przez eksperta. Zdecydowano si na to

ze wzgl du na czasochłonno wykonania pomiarów rzeczywistych czasów tych

czynno ci, jak równie ich problematyczn wiarygodno .

4.2.2 Schemat procesu walidacji

Jako podstaw prac walidacyjnych przyj to porównanie wydajno ci automatów

tokarskich. Nie ma bowiem adnych danych dotycz cych czasów wyprodukowania

partii detali. Istnieje jedynie dokumentacja dotycz ca wydajno ci automatów tokarskich

obejmuj ca ilo wyprodukowanych sztuk w ci gu jednej zmiany oraz czasy produkcji

pojedynczych elementów. Po konsultacji z przedstawicielem firmy ustalono, e da to

wystarczaj cy stopie wiarygodno ci. Przyj to równie , e nie wszystkie dane

rzeczywiste b d brane pod uwag . Postanowiono odrzuci wyniki z cykli

produkcyjnych, podczas których wyst piły rzadko spotykane przestoje produkcji. Ich

powodem mógł by np. rozładunek materiału, powa na awaria maszyny, czy brak

surowca.

Po weryfikacji danych dotycz cych systemu rzeczywistego przyst piono do

przeprowadzenia eksperymentów symulacyjnych. Ka dy z nich obejmował :

okre lenie danych rzeczywistych dotycz cych wydajno ci produkcji

danego typu elementu

okre lenie danych dotycz cych rzeczywistych parametrów produkcji

zbudowanie adekwatnego modelu za pomoc systemu symulacyjnego i

jego wst pna ocena

przeprowadzenie ustalonej liczby przebiegów symulacji i zebranie

danych statystycznych

porównanie wyników uzyskanych dzi ki symulacji z wynikami systemu

rzeczywistego

Wymienione czynno ci przeprowadzono dla kilku ró nych rodzajów elementów.

Dodatkowo przeprowadzono testy linii produkcyjnej zło onej z czterech faz. Ich

wyniki były ocenione przez eksperta oraz porównane z uproszczonym modelem

systemu.

4.2.3 Eksperymenty walidacyjne i ocena poprawno ci modelu

Testy wydajno ci linii produkcyjnej zostały przeprowadzone zgodnie ze

schematem zaproponowanym w punkcie 4.1. Linia została zaprojektowana zgodnie z

instrukcjami technologicznymi dotycz cymi pewnego detalu. Dla fazy pierwszej czas

jednostkowy obróbki detalu został zmierzony w systemie rzeczywistym, dla

pozostałych faz czasy te zostały ustalone na podstawie instrukcji i w porozumieniu z

ekspertem. Czasy wymiany pojemników oraz trwania kontroli jako ci zostały ustalone

po rozmowach z pracownikami firmy. Dane dotycz ce wydajno ci zostały pobrane z

instrukcji technologicznych. Nale y jednak zwróci uwag na fakt, i wydajno dla

pierwszej fazy (65 szt/h) jest o wiele ni sza od wydajno ci, jak mo na obliczy dziel c

jedn godzin przez jednostkowy czas produkcji detalu; wtedy wydajno równa jest

ok. 100 szt./h. W rzeczywisto ci wydajno ta waha si w granicach około 80 szt./h.

Zbiór danych wej ciowych, jak równie dane dotycz ce wydajno ci, przedstawia tabela

4.1.

Politechnika Cz stochowska

Faza

Ilo

czas

wymiana

zwot wyr.

kontrola rozpocz cie wydajno

stanowisk jednostkowy

surowca

gotowych

jako ci

pracy

[szt.]

[s]

[h]

[szt/h]

90 - 150

600 - 900

45 - 85

90 - 150

brak

570

45 - 85

90 - 150

300 - 600

250

45 - 85

90 - 150

brak

700

Tabela 4.1 dane wej ciowe dla symulowanej linii produkcyjnej

Dla innych parametrów przyj to nast puj ce warto ci:

czas usuwania usterki: 10 - 20 minut

ilo pr tów metalowych: 1000 szt.

ilo detali z jednego pr ta: 35 szt.

ilo kontrolerów jako ci: 1

czas pracy: 10 zmian = 80 godzin

Za pomoc uproszczonego modelu uwzgl dniaj cego jedynie wydajno ci

poszczególnych maszyn przyj to, i ilo gotowych detali waha si powinna w

granicach od 4560 do 5600 sztuk.

Eksperyment symulacyjny składał si ze 100 niezale nych powtórze . Oto

wyniki rednie wydajno ci dla poszczególnych stanowisk, oraz histogram prezentuj cy

rozkład ilo ci wyprodukowanych elementów.

Faza Przedział

rednia

wydajno ci wydajno

[szt/h]

75 - 81

579 - 581

579

253 - 254

253

691 - 696

693

Tabela 4.2 Wydajno ci maszyn wygenerowane przez system symulacyjny

Histogram wydajno ci linii produkcyjnej

0,2

0,4

0,6

0,8

1,2

ilo elementów

Politechnika Cz stochowska

Wyniki eksperymentu zostały ocenione przez eksperta jako bardzo

prawdopodobne. Rzeczywista wydajno maszyn prowadz cych pierwsz faz obróbki

została porównana z wydajno ci otrzyman przez symulator i równie uznana za

poprawn . Jedyn ró nic był rozrzut wydajno ci maszyn w stosunku do ich

wydajno ci rzeczywistych. Spowodowane to było przez pomini cie w symulacji

pewnych czynników, o których mowa była wcze niej. Jednak wynik eksperymentu

wypadł zadowalaj co w oczach przedstawicieli firmy.

Jak ju wspomniano, ocena zaprojektowanej linii miała charakter hipotetyczny,

poniewa w rzeczywisto ci nie ma danych dotycz cych czasu wyprodukowania partii

materiału. Dlatego przy rozstrzyganiu o adekwatno ci wyników tej symulacji główn

rol grał głos eksperta.

Dla porównania przeprowadzono eksperyment symulacyjny, w którym

wszystkie stanowiska pracy rozpoczynały prac w tym samym czasie (czas rozpocz cia

pracy = 0). Do wykonywania obróbki w fazie trzeciej przeznaczone były dwa

stanowiska. Statystyki dotycz ce drugiego stanowiska - mniej wykorzystanego -

przedstawione s w nawiasach. Wyniki tego eksperymentu przedstawia poni sza tabela.

Faza

Przedział

rednia

wydajno ci

wydajno

[szt/h]

75 - 81

235 - 243

239

161 - 167 (82 - 87)

163 (85)

247 - 257

252

Tabela 4.3 Wydajno ci maszyn wygenerowane przez system symulacyjny

Jak wida w tym rozwi zaniu udało si wyprodukowa o wiele wi cej detali

gotowych, jednak wykorzystanie stanowisk tokarski znacznie spadło. Tego typu

schematu raczej nie wykorzystuje si w rzeczywisto ci.

Histogram wydajno ci linii produkcyjnej

0,2

0,4

0,6

0,8

1,2

ilo elementów

Politechnika Cz stochowska

O wiele wa niejszy i bardziej obiektywny test opierał si na porównaniu

wyników generowanych przez symulator ze zbiorem wyników rzeczywistej wydajno ci

maszyn wykonuj cych pierwsz faz obróbki. Mimo ograniczonego obszaru, test ten

nale y uzna za wi

cy, gdy wi ksz cz

obróbki partii materiału zajmuje wła nie

ta faza. Wynika to chocia by ze wzgl du na wydajno ci poszczególnych faz zapisane w

instrukcjach technologicznych. Poza tym czas wymiany surowca jest najdłu szy w

pierwszej fazie. Na wydajno ujemnie wpłyn mog równie ró nego rodzaju usterki,

czy awarie automatów.

Czas trwania jednej zmiany równy 10 godzin został tak ustalony w systemie

symulacyjnym, gdy podczas zbierania danych rzeczywistych tyle wła nie trwał czas

pracy automatów tokarskich.

Równie w tym do wiadczeniu czasy wymiany surowca i usuwania usterek oraz

prawdopodobie stwo ich wyst pienia ustalono z ekspertem po rozmowach z

pracownikami firmy.

wymiana metalowego pr ta: 60 - 240 sekund + czas obróbki jednego

elementu

oddanie pojemnika z detalami gotowymi: 90 - 180 sekund

usuwanie usterek: 10 - 20 minut

czas trwania jednej zmiany 10 godzin

czas przerwy mi dzyzmianowej: 1 godzina

Tabel 4.4 prezentuje rzeczywiste wydajno ci wyra one w ilo ci wyprodukowanych

elementów ka dego z badanych rodzajów detali. W przypadku detalu 56 w czasie

pierwszych czterech zmian pracowały dwa automaty, a nast pnie uruchomiony został

trzeci automat

Indeks

Ilo

Ilo elementów wyprodukowanych w czasie poszczególnych

zmian

Razem

skrócony maszyn

2080005

630 640 630 630 630 650 620 630 610 630

6300

1531A

2280 2260 2220 2300 2230 2320 2300 2240 2280 2360 22790

2 - 3

2160 2130 2120 2150 3320 3310 3360 3380 3350

25280

205

2200 2240 2180 2160 2150

10930

12A

1250 1350 1380 1360 1370

6710

Tabela 4.4 Rzeczywiste wydajno ci linii produkcyjnych

Poni sze wykresy przedstawiaj histogramy wydajno ci linii produkcyjnych

wygenerowane prze symulator. Czerwone linie reprezentuj rzeczywiste wydajno ci

linii w zało onym okresie czasu.

Politechnika Cz stochowska

Parametry linii produkcyjnej dla elementu 2080005:

czas trwania jednej zmiany: 10 godzin

czas przerwy mi dzyzmianowej: 1 godzina

czas trwania symulacji: 10 zmian (110 godzin)

ilo automatów: 1

ilo detali z jednego pr ta: 93 sztuki

Czas wytwarzania jednej sztuki detalu na automacie tokarskim: 52 sekundy

Rys. 4.1 Histogram wydajno ci linii produkcyjnej dla elementu 2080005

Parametry linii produkcyjnej dla elementu 1531A:

czas trwania jednej zmiany: 10 godzin

czas przerwy mi dzyzmianowej: 1 godzina

czas trwania symulacji: 10 zmian (110 godzin)

ilo automatów: 1

ilo detali z jednego pr ta: 96 sztuk

Czas wytwarzania jednej sztuki detalu na automacie tokarskim: 12 sekund

Rys. 4.2 Histogram wydajno ci linii produkcyjnej dla elementu 1531A

0,2

0,4

0,6

0,8

1,2

ilo elementów

22790

0,2

0,4

0,6

0,8

1,2

ilo elementów

6300

Politechnika Cz stochowska

Parametry linii produkcyjnej dla elementu 205:

czas trwania jednej zmiany: 10 godzin

czas przerwy mi dzyzmianowej: 1 godzina

czas trwania symulacji: 5 zmian (55 godzin)

ilo automatów: 2

ilo detali z jednego pr ta: 39 sztuk

Czas wytwarzania jednej sztuki detalu na automacie tokarskim:

pierwszym: 22 sekundy

drugim: 26 sekund

Rys. 4.3 Histogram wydajno ci linii produkcyjnej dla elementu 205

0,2

0,4

0,6

0,8

1,2

ilo elementów

10930

Politechnika Cz stochowska

Parametry linii produkcyjnej dla elementu 12A:

czas trwania jednej zmiany: 5 godzin

czas przerwy mi dzyzmianowej: 1 godzina

czas trwania symulacji: 5 zmian (55 godzin)

ilo automatów: 1

ilo detali z jednego pr ta: 200 sztuk

Czas wytwarzania jednej sztuki detalu na automacie tokarskim: 23 sekundy

Rys. 4.4 Histogram wydajno ci linii produkcyjnej dla elementu 12A

0,2

0,4

0,6

0,8

1,2

ilo elementów

6710

Politechnika Cz stochowska

Parametry linii produkcyjnej dla elementu 56:

czas trwania jednej zmiany: 10 godzin

czas przerwy mi dzyzmianowej: 1 godzina

czas trwania symulacji: 9 zmian (99 godzin)

ilo automatów: 3

ilo detali z jednego pr ta: 43 sztuki

Czas wytwarzania jednej sztuki detalu na automacie tokarskim:

pierwszym: 29 sekund

drugim: 30 sekund

trzecim: 25 sekund

rozpocz cie pracy przez trzeci automat tokarski na pi tej zmianie (po 44 godzinach

czasu trwania symulacji)

Rys. 4.5 Histogram wydajno ci linii produkcyjnej dla elementu 56

Wyniki testów dla elementów 2080005 i 1531A dowodz zgodno ci systemu

symulacyjnego z rzeczywisto ci . Wyniki symulacji procesów produkcji pozostałych

elementów ró ni si od wyników systemu rzeczywistego. Ró nice te mieszcz si w

granicach 10%. Wszystkie wyniki eksperymentów symulacyjnych zostały uznane przez

eksperta za prawdopodobne, a sam system symulacyjny za adekwatny.

0,2

0,4

0,6

0,8

1,2

ilo elementów

25280

Politechnika Cz stochowska

5. Wnioski

Stworzenie systemu symulacyjnego jest zadaniem trudnym, wymagaj cym

do wiadczenia i cierpliwo ci. Nie ma adnych ustalonych wzorców co do tworzenia ani

tym bardziej walidacji modelu. Zapewnienie adekwatno ci systemu symulacyjnego do

systemu rzeczywistego jest chyba najtrudniejsz , lecz równie najwa niejsz rzecz w

całym procesie tworzenia symulatora, na co starano si zwróci uwag w niniejszej

pracy. Jednak widok symulatora generuj cego prawidłowe dane daje du o satysfakcji.

Prace nad projektowaniem i implementacj systemu symulacyjnego pozwalaj na

zdobycie do wiadczenia i poszerzenie horyzontów. Wiedz t mo na potem

wykorzysta w pracach nad innymi systemami, niekoniecznie zwi zanymi z symulacj .

Pozwalaj równie zdobywa wiedz z dziedziny, jakiej dotyczy symulacja, co mo e

si okaza jeszcze cenniejszym do wiadczeniem. Poza tym opracowanie systemu

symulacyjnego pozwala na pewn dowolno , co daje poczucie satysfakcji

projektantowi. Oczywi cie ta dowolno musi zawiera si w rozs dnym przedziale.

Czynnikiem, który w znacznym stopniu ułatwił weryfikacj modelu był fakt, e

generatory liczb losowych zostały dodane w ko cowej fazie implementacji, natomiast

prototyp miał charakter modelu deterministycznego.

Praca nad systemem dostarczyła wielu do wiadcze , zarówno dotycz cych

projektowania i implementacji systemów symulacyjnych, jak i programowania w ogóle.

Model programowania z prototypowaniem okazał si bardzo u yteczny do tworzenia

systemu symulacyjnego. Rozmowy z przedstawicielami firmy "HET - MARK" były

prowadzone w oparciu o ten wła nie prototyp. Miały one charakter merytoryczny i nie

były zawieszone "w pró ni". Pozwoliło to na uszczegółowienie modelu, wykrycie

bł dów i nieporozumie dotycz cych logicznej struktury procesu produkcyjnego.

Celem niniejszej pracy jest stworzenie systemu symulacyjnego i adaptacja go do

pracy nad symulowaniem procesu produkcyjnego w firmie "HET - MARK". Model

koncepcyjny systemu oparty został na modelu, jaki w rzeczywisto ci realizowany jest w

tej firmie i zaakceptowany jako poprawny przez jej przedstawiciela. Na tej podstawie

oraz na podstawie przeprowadzonych testów mo na wyci gn nast puj ce wnioski:

system generuje dane, które poprawnie odwzorowuj działanie systemu

rzeczywistego

najwi kszy wpływ na czas produkcji partii materiału ma czas

jednostkowy obróbki detalu podczas pierwszej fazy obróbki

czas wymiany surowca przez automaty tokarskie ma znacz cy wpływ na

czas produkcji partii materiału

aby osi gn po dan wydajno liczon w sztukach na godzin na

kolejnych fazach produkcji, nale y zapewni wystarczaj c ilo

surowca dla tych faz. Mo na to osi gn poprzez przeznaczenie du ej

ilo ci automatów tokarskich do wst pnej obróbki surowca, lub przez

okre lenie czasu rozpocz cia pracy dla stanowisk tokarskich na

pó niejszy ( po trzech - czterech zmianach)

uruchomienie w jednym czasie automatów i stanowisk tokarskich daje

wyra ne efekty we wzro cie ilo ci wyprodukowanych detali, lecz

powoduje znaczne obni enie si stopnia wykorzystania stanowisk

tokarskich. W symulowanym przykładzie przy czasie startu wszystkich

stanowisk roboczych = 0, połow czasu pracy zu ywały one na

oczekiwanie na surowiec

Politechnika Cz stochowska

obróbka detali na stanowiskach tokarskich nie podlega zbyt wielkim

wahaniom i ma znikomy, w porównaniu z obróbk na automatach

tokarskich, wpływ na czas wykonania partii materiału

Porównanie danych generowanych przez symulator z danymi rzeczywistymi,

udost pnionymi przez firm , pozwoliło na walidacj systemu zapewniaj c wysoki

poziom ufno ci. Przeprowadzone testy udowodniły poprawno logicznej struktury

symulatora, a ich wyniki pozwoliły na wyci gni cie pewnych wniosków. Przyjmuj c,

e generowane przez symulator warto ci s optymalne, mo na stwierdzi , e:

wytwarzanie niektórych elementów (np. 1531A) przebiega bez zakłóce ; nie

maj na nie wpływu zdarzenia, których nie uwzgl dniono w symulacji

na proces produkcji pewnych rodzajów detali (np. 12A) maj wpływ

zdarzenia, które nie zostały uwzgl dnione w symulacji, (np. chwilowy brak

wolnego pracownika, który mógłby zało y nowy surowiec, czy usun

usterk ), czy zwi kszone czasy zdefiniowanych operacji(np. czas wymiany

surowca o czas oczekiwania na pracownika. Jest to mo liwe, gdy nie

wszystkie maszyny sygnalizuj awari , czy brak surowca), lub po prostu

czynnik ludzki.

wydajno maszyn produkuj cych pewne detale jest wy sza ni osi gni ta

przez symulator. Przyczyn tego mo e by np. dłu szy ni zało ony czas

pracy maszyny, ni sza ni zało ona awaryjno , mniejszy czas wymiany

surowca (jest to mo liwe, gdy automat stoi w cz ci hali, przez któr cz sto

przechodzi pracownik)

generowane przez system dane nale y traktowa jako przybli one, gdy taki

charakter maj niektóre z wprowadzanych do niego danych wej ciowych,

np. czas wymiany surowca. Badania prowadzone dla ustalenia rzeczywistych

czasów poszczególnych czynno ci oraz ich rozkładów dałyby w efekcie

bardziej precyzyjne odpowiedzi symulatora

dokładno wyników symulacji mo na zwi kszy poprzez modelowanie

czasów operacji za pomoc zmiennych losowych o odpowiedniej funkcji

g sto ci. Musi to by jednak poprzedzone badaniami nad systemem

rzeczywistym

Zaprezentowany system symulacyjny jest u ytecznym narz dziem

wspomagaj cym podejmowanie decyzji i oceny rzeczywistej wydajno ci linii

produkcyjnej. Pozwala on na bardziej efektywne znajdowanie operacji zmniejszaj cych

wydajno systemu, oraz daje kierownictwu firmy bardzo wa ne narz dzie, a

mianowicie dane, z którymi mo na porówna rzeczywist wydajno linii produkcyjnej.

Politechnika Cz stochowska

Literatura:

[1] Jerzy Tyszer "Symulacja cyfrowa" WNT 1990

[2] Davis Chapman"Visual C++ dla ka dego" Helion 1999.

[3] Jerzy Gr bosz "Symfonia C++" Oficyna Kallimach Kraków 1999.

[4] Mieczysław Sobczyk "Statystyka" Pa stwowe Wydawnictwo Naukowe

Warszawa 1991.

[5] Balqies Saudon "Applied system simulation: a review study"

Information Sciences Journal 1999.

[6] Averill M. Law, Michael G. McComas "Simulation Of Manufacturing System"

Proceedings of the 1997 Winter Simulation Conference (WSC)

[7] Jeffrey A. Joines, Stephen D. Roberts "An Introduction To Object-Oriented

Simulation In C++" Proceedings of the 1997 Winter Simulation Conference

[8] Averill M. Law, Michael G. McComas "Simulation Of Manufacturing System"

Proceedings of the 1999 Winter Simulation Conference (WSC)

[9] Jerry Banks "Introduction To Simulation" Proceedings of the 1999 Winter

Simulation Conference (WSC)

[10] J. Herington, A. Lane, N. Corrigan, J. A. Golightly "Representation Of Historical

Events In A Military Campaign Simulation Model" Proceedings of the 2002 Winter

Simulation Conference (WSC)

[11] Thomas J. Schriber, Daniel T. Brunner "Inside Discrette - Event Simulation

Software: How It Works And Why It Matters" Proceedings of the 2001 Winter

Simulation Conference (WSC)

[12] Ingolf Ståhl "Simulation Prototyping" Proceedings of the 2002Winter

Simulation Conference (WSC)

[13] Deborah A. Sadowski, Mark R. Grabau " Tips For Succesful Praktice Of

Simulation"Proceedings of the 2001 Winter Simulation Conference (WSC)

[14] E. J. Wiliams, D. Darwactor, L. Shorkey "Evaluation Of Machine Shop Logistic

Alternatives Using Simulation"

[15] Robert G. Sargent "Some Approaches And Paradigms For Verifying And

Validating Simulation Models" Proceedings of the 2001 Winter Simulation

Conference (WSC)

[16] Dean S. Hartley III "Verification & Validation In Military Simulations"

Proceedings of the 1997 Winter Simulation Conference (WSC)

[17] John S. Carson II "Model Verification And Validation" Proceedings of the 2002

Winter Simulation Conference (WSC)

[18] Andrzej Jaszkiewicz "In ynieria oprogramowania" HELION 1997

[19] O. M. Ulgen, E. Grajo "Macro And Micro Simulation Models - When? Why? And

How?" Production Modeling Corporation 1992

[20] Alexander Shapiro "Monte Carlo Simulation Approach To Stochastic

Programming" Proceedings of the 2001 Winter Simulation Conference (WSC)

[21] W. Dawid Kelton "Statistical Analysis Of Simulation Output"

Proceedings of the 2001 Winter Simulation Conference (WSC)

[22] "The Turing Test Page" http//cogsci.ucsd.edu/~asaygin/tt

[23]