PRACA MAGISTERSKA
OPRACOWANIE OPROGRAMOWANIA DLA
SYMULACJI PROCESU
TECHNOLOGICZNEGO DLA
PRZEDSI BIORSTWA "HET-MARK"
Spis tre ci
1.
Cel pracy
4
2.
Wst p teoretyczny
6
2.1.
Definicja podstawowych poj
6
2.2.
Odmierzanie czasu w systemie symulacyjnym
6
2.3.
Rodzaje symulacji cyfrowej
10
2.4.
rodowiska programowania
12
2.5.
Etapy tworzenia systemu symulacyjnego
14
2.5.1.
Ogólny schemat tworzenia systemu symulacyjnego
15
2.5.2.
Projektowanie i implementacja
20
2.5.3.
Weryfikacja i walidacja systemu symulacyjnego
22
2.5.4.
Metody walidacji systemu symulacyjnego
23
2.5.5.
Bł dy w procesie weryfikacji i walidacji
27
2.5.6.
Weryfikacja i walidacja w procesie tworzenia
modelu symulacyjnego
29
2.5.7.
Techniki przydatne w fazie weryfikacji i walidacji
31
2.6.
Cele, zalety i wady symulacji
31
3.
Opracowanie i implementacja systemu symulacyjnego
33
3.1.
Przedsi biorstwo wielobran owe "HET- MARK"
33
3.1.1.
Struktura firmy "HET - MARK". Działy i ich zadania
33
3.1.2.
Proces produkcji
36
3.2.
Model koncepcyjny
42
3.2.1.
Modelowane obiekty
42
3.2.2.
Schemat działania modelu
44
3.3.
Wymagania funkcjonalne i niefunkcjonalne
46
3.3.1.
Wymagania funkcjonalne
46
3.3.2.
Wymagania niefunkcjonalne
49
3.4.
Projektowanie systemu symulacyjnego
49
3.5.
Implementacja systemu symulacyjnego
53
3.5.1.
Generator liczb losowych
56
4.
Prowadzenie eksperymentów symulacyjnych
59
4.1.
Schemat prowadzenia eksperymentów
59
4.2.
Walidacja systemu symulacyjnego
61
4.2.1.
Przygotowanie danych wej ciowych
61
4.2.2.
Schemat procesu walidacji
62
4.2.3.
Eksperymenty walidacyjne i ocena poprawno ci modelu
62
5.
Wnioski
70
Literatura
72
Politechnika Cz stochowska
4
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
5
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
6
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
7
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
8
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
= 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
9
Dłu sze pionowe linie oznaczaj momenty sprawdzenia stany systemu
- moment wyst pienia zdarzenia na danej maszynie
Przy takich zało eniach momenty wywołania zdarze , oraz momenty
sprawdzania stanu systemu b d kształtowa si nast puj co:
obiekty
C
B
A
0
czas
Rys. 2.1 Schemat przykładowego systemu opartego na technice stałego przyrostu
czasu
obiekty
C
B
A
0
czas
Rys. 2.2 Schemat przykładowego systemu opartego na technice kolejnego
zdarzenia
Politechnika Cz stochowska
10
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
11
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
12
(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
6
8
8
7
6
8
2
8
6
9
7
8
8
3
7
7
6
6
9
7
4
9
9
7
8
7
9
5
7
10
9
9
10
6
6
6
6
10
10
9
8
7
8
7
7
6
6
9
8
10
8
10
7
5
7
REDNIO
SZT/H
7,625
7,625
8,25
7,5
7,5
7,75
W CI GU
ZMIANY
61
61
66
60
60
62
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
13
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
14
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
15
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
16
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:
a)
Okre lenie systemu
b)
Sformułowanie modelu
c)
Przygotowanie danych
d)
Zaprogramowanie modelu
e)
Ocen adekwatno ci modelu
f)
Planowanie strategiczne eksperymentów symulacyjnych
g)
Planowanie taktyczne eksperymentów symulacyjnych
h)
Prowadzenie wła ciwych eksperymentów
i)
Interpretacja uzyskanych wyników
j)
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.
a)
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.
b)
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
17
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].
c)
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.
d)
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.
e)
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.
f)
Taktyczne i strategiczne planowanie eksperymentów symulacyjnych - plany
eksperymentów symulacyjnych obejmuj ce zestawy oraz warto ci parametrów
Politechnika Cz stochowska
18
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.
g)
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:
a)
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.
b)
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
19
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.
c)
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.
d)
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
20
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
21
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
22
-
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
23
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
24
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
25
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
cz
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
26
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
27
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
28
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]
a)
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)
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
29
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
c)
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.
d)
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
30
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
31
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]:
a)
wst pne sprawdzenie danych wyj ciowych i okre lenie, czy mogłyby one
wyst pi w rzeczywisto ci
b)
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
c)
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
32
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].
a)
wymusza nietypowe zachowania i warunki skrajne w celu zbadania
odpowiedzi na nie systemu
b)
zidentyfikowa warto ci zmiennych wyj ciowych wskazuj ce na bł dne
działanie modelu, lub jego podejrzane zachowanie
c)
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
d)
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
e)
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
f)
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 "
g)
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
33
-
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
34
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
35
a)
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.
b)
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
36
c)
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.
d)
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.
e)
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
37
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
b)
przeniesienie wyrobu do strefy kontroli
c)
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
d)
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
M
A
G
A
Z
Y
N
Politechnika Cz stochowska
38
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
39
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
40
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
ST
R
E
FA
K
O
N
T
R
O
L
I
JA
K
O
C
I
Politechnika Cz stochowska
41
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
ST
R
E
FA
W
Y
R
O
B
Ó
W
G
O
T
O
W
Y
C
H
ST
R
E
FA
K
O
N
T
R
O
L
I
JA
K
O
C
I
pojemnik
wyj ciowy
ST
R
E
FA
P
R
O
D
U
K
C
JI
W
T
O
K
U
ST
R
E
FA
K
O
N
T
R
O
L
I
JA
K
O
C
I
Politechnika Cz stochowska
42
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
ST
R
E
FA
K
O
N
T
R
O
L
I
JA
K
O
C
I
STREFA
WYROBÓW
GOTOWYCH
Politechnika Cz stochowska
43
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.
a)
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
b)
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
c)
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
44
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
d)
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
e)
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
f)
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
45
-
ilo detali
-
maksymalna ilo detali
-
symbol detalu jaki zawiera
-
czy detale powinny przej kontrol jako ci
g)
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
46
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
47
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
48
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
Tworzenie linii produkcyjnej
Edycja kontroli jako ci
Tworzenie kontroli jako ci
Edycja cyklu zmianowego
Edycja czasu trwania oraz rodzaju symulacji
Politechnika Cz stochowska
49
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
50
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
51
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
52
-
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
53
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
54
-
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
55
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
56
Rys. 3.5 Graficzna prezentacja linii produkcyjnej w trybie animacyjnym
Rys. 3.6 Graficzna prezentacja linii produkcyjnej w trybie schematycznym
Politechnika Cz stochowska
57
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.
a)
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
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
ilo trafie
lic
zb
a
Zmienna losowa o stałej g sto ci
9500
9600
9700
9800
9900
10000
10100
10200
10300
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
liczba
ilo
w
ys
t
pi
e
Politechnika Cz stochowska
58
b)
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
a
-
wylosowa liczb u o rozkładzie jednostajnym z przedziału <0,1>
-
obliczy warto zmiennej r o rozkładzie trójk tnym
u
avg
r
*
min)
(max
*
min)
(
min
−
−
+
=
dla a < u
)
1
(
*
min)
(max
*
)
(max
max
u
avg
r
−
−
−
−
=
dla a > u
r = avg
dla a = u
Zmienna losowa o rozkładzie
trójk tnym
0
5000
10000
15000
20000
25000
1
14
27
40
53
66
79
92
liczba
ilo
w
ys
t
pi
e
rednia = 20
rednia = 50
rednia = 75
Politechnika Cz stochowska
59
c)
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
1
, r
2
) tak , e r
1
jest liczb losow o
rozkładzie równomiernym na przedziale (a, b), r
2
za jest liczb losow o
rozkładzie równomiernym na przedziale (0, c). Przyjmujemy ponadto, e
r
1
i r
2
s warto ciami dwóch niezale nych zmiennych losowych R
1
i R
2
.
-
je eli f(r
1
)
/r
2
, jako wynik nale y przyj r
1
; 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
2
+1, warto r
1
jest
losowana na przedziale <0, 2> a nast pnie rzutowana na przedział
<min, max>, natomiast r
2
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
4
(x) dla 0
≤ x ≤
2
π
Zmienna losowa o rozkładzie
parabolicznym
0
5000
10000
15000
20000
1
10
19
28
37
46
55
64
73
82
91
10
0
liczba
ilo
w
ys
t
pi
e
Politechnika Cz stochowska
60
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
61
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:
a)
Zaprojektowa struktur linii produkcyjnej
b)
Przeprowadzi symulacj wst pn
c)
Dokona oceny symulacji wst pnej. Je eli niektóre z parametrów
wyj ciowych symulacji budz w tpliwo ci, przeprowadzi symulacj
graficzn
d)
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)
e)
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
0,2
0,4
0,6
0,8
1
1,2
1
2
3
4
5
6
7
8
9
50
100
250
500
1000
Politechnika Cz stochowska
62
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
63
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
64
Faza
Ilo
czas
wymiana
zwot wyr.
kontrola rozpocz cie wydajno
stanowisk jednostkowy
surowca
gotowych
jako ci
pracy
[szt.]
[s]
[s]
[s]
[s]
[h]
[szt/h]
1
3
35
90 - 150
90 - 150
600 - 900
0
65
2
1
6
45 - 85
90 - 150
brak
64
570
3
2
14
45 - 85
90 - 150
300 - 600
64
250
4
1
5
45 - 85
90 - 150
brak
72
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]
[szt/h]
1
75 - 81
78
2
579 - 581
579
3
253 - 254
253
4
691 - 696
693
Tabela 4.2 Wydajno ci maszyn wygenerowane przez system symulacyjny
Histogram wydajno ci linii produkcyjnej
0
0,2
0,4
0,6
0,8
1
1,2
48
84
49
56
50
28
51
00
51
72
52
44
53
16
53
88
54
60
55
32
ilo elementów
Politechnika Cz stochowska
65
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]
[szt/h]
1
75 - 81
78
2
235 - 243
239
3
161 - 167 (82 - 87)
163 (85)
4
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
0,2
0,4
0,6
0,8
1
1,2
16
65
9
16
72
8
16
79
7
16
86
6
16
93
5
17
00
4
17
07
3
17
14
2
17
21
1
17
28
0
ilo elementów
Politechnika Cz stochowska
66
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
1
630 640 630 630 630 650 620 630 610 630
6300
1531A
2
2280 2260 2220 2300 2230 2320 2300 2240 2280 2360 22790
56
2 - 3
2160 2130 2120 2150 3320 3310 3360 3380 3350
25280
205
2
2200 2240 2180 2160 2150
10930
12A
1
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
67
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
0,2
0,4
0,6
0,8
1
1,2
21
41
9
21
69
2
21
96
5
22
23
8
22
51
1
22
78
4
23
05
7
23
33
0
23
60
3
23
87
6
ilo elementów
22790
0
0,2
0,4
0,6
0,8
1
1,2
61
57
61
99
62
41
62
83
63
25
63
67
64
09
64
51
64
93
65
35
ilo elementów
6300
Politechnika Cz stochowska
68
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
0,2
0,4
0,6
0,8
1
1,2
10
88
0
10
95
6
11
03
2
11
10
8
11
18
4
11
26
0
11
33
6
11
41
2
11
48
8
11
56
4
11
64
0
11
71
6
11
79
2
11
86
8
11
94
4
12
02
0
12
09
6
12
17
2
12
24
8
12
32
4
12
40
0
12
47
6
12
55
2
12
62
8
ilo elementów
10930
Politechnika Cz stochowska
69
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
0,2
0,4
0,6
0,8
1
1,2
66
95
67
43
67
91
68
39
68
87
69
35
69
83
70
31
70
79
71
27
71
75
72
23
72
71
73
19
73
67
74
15
74
63
75
11
75
59
ilo elementów
6710
Politechnika Cz stochowska
70
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
0,2
0,4
0,6
0,8
1
1,2
23
89
5
24
02
8
24
16
1
24
29
4
24
42
7
24
56
0
24
69
3
24
82
6
24
95
9
25
09
2
25
22
5
25
35
8
ilo elementów
25280
Politechnika Cz stochowska
71
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
72
-
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:
a)
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
b)
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.
c)
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)
d)
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
e)
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
73
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]
www.lanner.com
Wyszukiwarka
Podobne podstrony:
Opracowanie oprogramowania dla symulacji procesu
Symulacja procesu kucia jako przykład procesów niestacjonarnych, POLITECHNIKA OPOLSKA
projekt Konstrukcja karty procesu dla wybranego procesu przedsiębiorstwa z wykorzystaniem metodyki I
Modelowanie i symulacja procesów elektrycznych w obwodzie z lampą rtęciową
Komputerowa symulacja procesów obróbki plastycznej, i inne elementy tej laborki, POLITECHNIKA OPOLSK
Komputerowa symulacja procesów obróbki plastycznej, i inne elementy tej laborki, POLITECHNIKA OPOLSK
Symulacja procesu g k Nagy Geopetrol
Komputerowa symulacja procesów obróbki plastycznej, POLITECHNIKA OPOLSKA
Opracowanie redaktorskie dla studentow(1)
OPROGRAMOWANIE DLA SCOUTING I ANALIZY SIATKÓWKI MECZE
opracowanie laborki dla Dawida 25, Labolatoria fizyka-sprawozdania, !!!LABORKI - sprawozdania, 25 -
Opracowanie podręcznika, Studia-Psychologia, Procesy poznawcze
Opracowali procedury dla sêu╛b medycznych na autostradzie?
Propozycje obszarów dla mierników procesów(druk), ISO, ISO
więcej podobnych podstron