dr inĪ. Waldemar Maáopolski Politechnika Krakowska
METODA WYZNACZANIA DOWOLNYCH TRAS PRZEJAZDU
OBIEKTÓW SYSTEMU TRANSPORTOWEGO W ĝRODOWISKU
SYMULACYJNYM ARENA
W artykule przedstawiono model systemu transportowego, zbudowany w Ğrodowi-sku symulacyjnym Arena, który umoĪliwia dowolne wyznaczanie trasy przejazdu obiektu systemu transportowego. Opisano równieĪ sposób integracji modelu z aplikacją zewnĊtrzną, co umoĪliwia wykorzystanie Areny do testowania algo-rytmów sterujących systemem transportowym.
A METHOD OF DETERMINATION OPTIONAL ROUTE
OF TRANSPORTATION SYSTEM OBJECTS IN ARENA SIMULATION
ENVIRONMENT
This paper presents a transportation system model, developed in Arena simulation software, which enables optional determination of route of transportation system objects. In this paper an integration of model with external desktop applications is presented too. Therefore Arena can be used for testing transportation system control algorithms.
1. WPROWADZENIE
Rozwój gospodarki opartej na zasadach rynkowych wym usza ciągáe wprowadzanie ulepsze Ĕ we wszystkich obszarach dzia áania zwi ązanych z wytwarzaniem dóbr konsum pcyjnych. Gáównym celem tych dzia áaĔ jest sprostanie oczekiwaniom klientów. W ymusza to koniecznoĞü dostosowania oferowanych produktów do gustów klientów oraz obni Īenia ich ceny i podniesienia jakoĞci. Pozycja producentów na rynku, a nawet ich przetrwanie, zale Īy od um iejĊtnoĞci szybkiego dostosowania si Ċ do zm ieniających si Ċ potrzeb. Zdolno Ğü do szybkiego i taniego wprowadzania zm ian w zakresie technologii i organizacji produkcji staje siĊ zagadnieniem kluczowym. Z tego wzgl Ċdu duĪego znaczenia nabieraj ą wszelkie m etody i narzĊdzia wspomagające poszukiwanie najlepszych (optymalnych) rozwiązaĔ.
Zagadnienia optym alizacyjne m ogą by ü rozwi ązywane m etodami analitycznym i lub symulacyjnymi. W przypadku braku rozwi ązaĔ analitycznych, bardzo cz Ċsto jedynym moĪliwym rozwi ązaniem jest zastosowanie m etod sym ulacyjnych. Sta áo si Ċ to przyczyn ą dynamicznego rozwoju narz Ċdzi sym ulacyjnych ukierunkowanych na ró Īne obszary zastosowaĔ. Podstawow ą zalet ą stosowania sym ulacji jest m oĪliwoĞü poszukiwania najlepszych rozwiązaĔ bazując na matematycznym modelu obiektu (systemu) rzeczywistego. Pozwala to na obni Īenie kosztów takich bada Ĕ a cz Ċsto zapobiega uszkodzeniom obiektu rzeczywistego.
W sferze produkcyjnej sym ulacja kom puterowa znalaz áa szerokie zastosowanie do rozwiązywania problem ów zarz ądzania i sterowania produkcj ą. Narz Ċdzia sym ulacyjne s ą wykorzystywane do optymalizacji budowy linii produkcyjnych, podsystemów, a nawet caáych systemów produkcyjnych, czy te Ī fabryk. Mo Īliwe jest te Ī wykorzystanie sym ulacji
komputerowej do testowania nowych rozwi ązaĔ w zakresie m etod sterowania system ami produkcyjnymi. Pozwala to na weryfikacj Ċ poprawno Ğci przyj Ċtych rozwi ązaĔ przed wdroĪeniem ich do obiektu rzeczywistego.
Na przestrzeni ostatnich lat obserwuje si Ċ dynamiczny rozwój bada Ĕ naukowych nad zastosowaniem koncepcji sterownia rozproszonego (agentowego) do sterowania system ami produkcyjnymi. W Instytucie Technologii Maszyn i Autom atyzacji Produkcji (ITMiAP) Politechniki Krakowskiej jest rozwijany oryginalny wieloagentowy system sterowania produkcją AIM (ang. Agents Integrated Manufacturing) [7, 11]. Ze wzgl Ċdu na to, Īe w procesie produkcyjnym bardzo du Īe znaczenie odgrywa transport m iĊdzyoperacyjny, podjĊto obecnie w ITMiAP prace zwi ązane z zastosowaniem wieloagentowego sterowania rozproszonego do podsystem u transportowego [9]. Poniewa Ī czynno Ğci transportowe nie generują warto Ğci dodanej, nale Īy d ąĪyü do m inimalizacji ich kosztów. Stawia to przed systemem steruj ącym szereg trudnych zada Ĕ. Problem y te s ą obiektem bada Ĕ w wielu oĞrodkach naukowych na Ğwiecie.
Podstawowa grupa zagadnie Ĕ jest zwi ązana z techniczn ą budow ą podsystem u transportowego, a szczególnie z budową obiektów wchodzących w jego skáad. Ze wzglĊdu na duĪą elastyczno Ğü w zakresie realizacji zada Ĕ transportowych, cz Ċsto stosowanym rozwiązaniem są autonomiczne wózki mobilne. Z tego te Ī wzglĊdu podjĊto w ITMiAP prace na budow ą dwóch autonom icznych wózków mobilnych [9]. Autonom icznoĞü wózków wymaga zastosowania odpowiednich rozwi ązaĔ w zakresie zasilania, sterowania nap Ċdem, komunikacji z system em steruj ącym i lokalizacji po áoĪenia wózka [6]. Zbudowane wózki umoĪliwią weryfikacjĊ opracowanego systemu sterowania.
Druga grupa zagadnie Ĕ, wymagających rozwiązania, jest zwi ązana z budow ą samego systemu sterowania. Do wa Īniejszych problem ów, które m uszą by ü rozwi ązane, m oĪna zaliczyü wyznaczanie tras przejazdu wózków [2, 3], harm onogramowanie zada Ĕ transportowych [5], czy te Ī rozwi ązania zapewniaj ące efektywne wykorzystanie wózków, w tym zapobieganie kolizjom [1, 4] i blokadom systemu transportowego [8].
Zbudowanie system u steruj ącego podsystem em transportowym jest zatem zagadnieniem z áoĪonym i wym aga dok áadnego przetestowania przed wdro Īeniem go do obiektu rzeczywistego. Z tego wzgl Ċdu celowym wydaje si Ċ opracowanie m odelu symulacyjnego podsystem u transportowego, który pozwoli na testowanie i weryfikowanie róĪnych rozwi ązaĔ zaimplementowanych do system u sterującego. Pociąga to jednak szereg wymogów, jakie musi speániü symulator. Podstawowym wymogiem jest moĪliwoĞü wymiany danych (integracji) system u steruj ącego z m odelem w czasie rzeczywistym . Drugi wa Īny wymóg, to m oĪliwoĞü dok áadnego zam odelowania sieci transportowej i m oĪliwoĞü dowolnego wyznaczania tras przejazdu wózków.
2. MODELOWANIE SYSTEMÓW TRANSPORTOWYCH W ĝRODOWISKU SYMULACYJNYM ARENA
Arena jest jednym z najbardziej popularnych program ów kom ercyjnych do m odelowania i symulacji system ów dyskretnych. Interfejs graficzny um oĪliwia bardzo áatwe i szybkie budowanie m odeli i przeprowadzanie sym ulacji. Bogaty zestaw narz Ċdzi wspom agających przygotowanie danych wej Ğciowych oraz analiz Ċ wyników sym ulacji w znacz ący sposób uáatwia prac Ċ w tym Ğrodowisku. Na szczególn ą uwag Ċ zas áuguje m oĪliwoĞü wym iany
danych pom iĊdzy m odelem sym ulacyjnym a aplikacj ą zewn Ċtrzną w trakcie procesu symulacji w czasie rzeczywistym . Dzi Ċki t emu mo Īna wykorzysta ü Aren Ċ do sterowania obiektami rzeczywistymi lub zbudowaü w Arenie model systemu rzeczywistego i testowaü na nim ukáady lub programy sterujące.
u a a
W zakresie m odelowania system ów transportowych Arena dostarcza bogaty zestaw narzĊdzi, który pozwala na m odelowanie system ów zbudowanych z obiektów dyskretnych, np. robotów m obilnych, jak równie Ī system ów transportu ci ągáego, np. ta Ğmociągów. Modelowanie dyskretnych systemów transportowych moĪna zrealizowaü na dwa sposoby.
Pierwszy sposób polega na uproszczonym definiowaniu dróg transportowych, po których porusza si Ċ obiekt. Sprowadza si Ċ to do definiowania d áugoĞci dróg transportowych i prĊdkoĞci, z jaką realizowany jest transport. Ca áa logika zwi ązana z zapobieganiem powstawaniu zastojów oraz nie dopuszczanie do kolizji m usi byü zawarta w m odelu. Takie podejĞcie jest w wielu prostych przypadkach zupeánie wystarczające.
Drugi sposób m odelowania dyskretnych system ów transportowych daje wi Ċksze moĪliwoĞci w zakresie definiowania parametrów systemu transportowego. Podstawową cechą tego podej Ğcia jest m oĪliwoĞü definiowania sieci transportowej, sk áadającej si Ċ z w Ċzáów (skrzyĪowaĔ) i linii (dróg transportowych), która dok áadnie okreĞla przestrzeĔ transportową, w której m ogą si Ċ porusza ü obiekty system u transportowego. Definiowanie sieci transportowej wymaga okreĞlenia wszystkich linii áączących wĊzáy, rys. 1. Oprócz podania nazwy linii, nazwy w Ċzáa pocz ątkowego i ko Ĕcowego oraz ich kierunków (od 0 do 360 stopni), definiowany jest typ linii (droga jednokierunkowa, dwukierunkowa i ko Ĕcowa) oraz liczba odcinków z których sk áada si Ċ dana linia. Okre Ğlenie kierunku linii przy w ĊĨle początkowym i ko Ĕcowym pozwala na definiowanie zakr Ċtów, co wp áywa na zm niejszenie prĊdkoĞci, z jak ą porusza si Ċ obiekt, który pokonuje zakr Ċt. Zdefiniowanie d áugoĞci odcinka jednoznacznie okre Ğla d áugoĞü linii. Ponadto definiowany jest wspó áczynnik zm iany prĊdkoĞci jazdy obiektu transportowego na danej linii w stosunku do jego pr ĊdkoĞci nominalnej.
Rys. 4. Graficzna prezentacja sieci transportowej
Zbiór wszystkich linii (dróg transportowych) jest wykorzystywany do definiowania sieci transportowej, rys. 2. W modelu moĪna zdefiniowaü wiele róĪnych sieci transportowych. Po ka Īdej sieci m ogą porusza ü si Ċ inne obiekty transportowe. Definiowanie obiektów transportowych polega m.in. na wprowadzeniu nastĊpujących danych: nazwy obiektu (nazwy grupy obiektów), liczby obiektów w danej grupie, nazwy sieci transportowej, po której m ogą siĊ porusza ü obiekty, m aksymalnej pr ĊdkoĞci, przyspieszenia, opó Ĩnienia, wspó áczynnika zmiany prĊdkoĞci na zakrĊtach oraz miejsca początkowego poáoĪenia obiektu w sieci, rys. 3.
Po zdefiniowaniu sieci transportowej i obiektów poruszaj ących si Ċ po danej sieci moĪna przyst ąpiü do utworzenia graficznej wizualizacji sieci, która jest niezb Ċdna do animacji dzia áania system u transportowego. W tym celu rysuje si Ċ odcinki reprezentuj ące linie, które áączą si Ċ w w Ċzáach. Po tych odcinkach b Ċdą si Ċ porusza áy obiekty system u transportowego podczas realizacji swoich zada Ĕ. Na rys. 4 przedstawiono sie ü transportową. Dodatkowo zaznaczono w Ċzáy sieci i podano ich num ery. Na ka Īdej linii um ieszczono informacjĊ o jej num erze i podano w nawiasie d áugoĞü drogi. Kolejnym etapem jest rozbudowanie modelu symulacyjnego o elementy wykorzystujące system transportowy.
Na rys. 5 przedstawiono schem at prostego m odelu, realizuj ącego zadanie transportowe, polegające na przewiezieniu przedm iotu z w Ċzáa nr 1 do w Ċzáa nr 12. Model skáada z kilku m oduáów. Pierwszy m oduá „Poczatek” generuje przewo Īony przedmiot, który przechodzi do m oduáy „Param etry”. W m odule tym zostaje do param etru „NumerWozka” przypisana warto Ğü 1, która okre Ğla pierwszy wózek z dwuelem entowego zbioru obiektów systemu transportowego. Kolejnym m oduáem jest „StacjaPoczatkowa” typu Station, w którym przedmiotowi zostaje przypisane aktualne poáoĪenie. Zadania transportowe w modelu mogą byü realizowane pom iĊdzy stacjami zdefiniowanymi w m oduáach typu Station. Ka Īda stacja jest przypisana do okre Ğlonego w Ċzáa sieci transportowej. Dzi Ċki tem u definiuj ąc zadanie transportowe od stacji do stacji okre Ğlamy w Ċzeá pocz ątkowy i ko Ĕcowy. W omawianym przykáadzie „StacjaPoczatkowa” jest przypisana do wĊzáa nr 1.
Kolejnym m oduáem, do którego wchodzi przedm iot jest m oduá „W yjazd”, który odpowiada za przybycie wózka nr 1 do w Ċzáa pierwszego, zajecie wózka przez przedm iot i rozpoczĊcie transportu przedm iotu na wózku do w Ċzáa nr 12, czyli do stacji
„StacjaKoncowa”. Po dotarciu do w Ċzáa nr 12, w m odule „StacjaKoncowa” nast Ċpuje zwolnienie wózka przez przedmiot i opuszczenie modelu.
Zadanie transportowe zosta áo wykonane. Pojawia si Ċ jednak pytanie, w jaki sposób Arena dokona áa wyboru trasy w sieci transportowej (trasa zaznaczona czerwon ą lini ą). Po zdefiniowaniu sieci transportowej z d áugoĞciami dróg Arena buduje wewn Ċtrzną m acierz moĪliwych po áączeĔ pom iĊdzy w Ċzáami ze wzgl Ċdu na najkrótsz ą odleg áoĞü. W trakcie symulacji obiekt system u transportowego jest przem ieszczany najkrótsz ą drog ą od w Ċzáa początkowego do ko Ĕcowego. Jedynym kryterium wyboru jest m inimalna d áugoĞü trasy. Bardzo czĊsto moĪe zdarzyü si Ċ tak, Īe czas przejazdu inn ą trasą (dáuĪszą) bĊdzie krótszy. ZaleĪy to od m aksymalnych prĊdkoĞci, jakie obiekt system u transportowego m oĪe rozwinąü na poszczególnych liniach sieci transportowej. Pewnym u áatwieniem wp áywania na wybór trasy jest m oĪliwoĞü zdefiniowania po Ğredniego m iejsca w sieci transportowej, przez które obiekt m a przejecha ü, jad ąc od w Ċzáa pocz ątkowego do ko Ĕcowego. W ymaga to jednak stosowania specjalnych m oduáów, a i tak nie daje nam pe ánej kontroli na wyborem trasy przejazdu. Chc ąc zastosowa ü inne kryteria wyboru trasy przejazdu dla danego obiektu systemu transportowego nale Īy zastosowaü rozwiązania niestandardowe. Jest to szczególnie istotne, gdy celem budowy m odelu system u transportowego jest testowanie zewn Ċtrznego systemu sterowania.
3. METODA WYZNACZANIA DOWOLNYCH TRAS PRZEJAZDU OBIEKTÓW SYSTEMU TRANSPORTOWEGO
Przedstawiona poni Īej m etoda jest rozwi ązaniem niestandardowym . Podstawowym za áoĪe-niem przyj Ċtym przy opracowywaniu tej m etody by áa pe ána m oĪliwoĞü dowolnego wyzna-czania tras przejazdu obiektów system u transportowego. W tym celu zbudowano m odel w programie Arena wykorzystujący specjalny blok „Move”, rys. 6, który pozwala na wskazanie miejsca poĞredniego, przez które m a przebiegaü trasa przejazdu. Ponadto tras Ċ przejazdu od wĊzáa początkowego do ko Ĕcowego definiuje si Ċ przez podanie wszystkich po Ğrednich wĊ-záów. Realizacja z áoĪonego zadania transportowego zosta áa sprowadzona do realizacji ele-mentarnych zadaĔ transportowych pom iĊdzy sąsiadującymi wĊzáami przez lini Ċ áączącą oba wĊzáy. Linia áącząca sąsiadujące wĊzáy jest okreĞlona przez wyraĪenie „VIA(LINK(Linia))”. WĊzeá docelowy (w kolejnym elem entarnym zadaniu transportowym ) jest okre Ğlany przez wyraĪenie „INTX(Trasa(1,Pozycja))”. Takie rozwi ązanie zapewnia pe áną kontrolĊ nad tras ą przejazdu obiektu od wĊzáa początkowego do koĔcowego.
Drugim waĪnym zaáoĪeniem, mającym wpáyw na przyj Ċte rozwiązanie, byáo umoĪli-wienie wym iany danych z aplikacj ą zewn Ċtrzną, co pozwoli áoby na zbudowanie w Arenie wirtualnego Ğrodowiska do testowania zewn Ċtrznego systemu sterowania obiektam i systemu transportowego. W tym celu wprowadzono do m odelu specjalny elem ent „Arrivals”, który umoĪliwia przesyáanie danych do Areny. Elem ent ten w oparciu o otrzymane dane generuje nowe jednostki (reprezentuj ące zadania transportowe lub przedm ioty, które m ają byü trans-portowane) i wprowadza je do m oduáu typu Station. Do tak wygenerowanych jednostek ele-ment „Arrivals” dodaje szereg informacji (otrzymanych z aplikacji zewnĊtrznej), opisujących
zadaną trasĊ przejazdu, rys. 7. Dane te s ą zapisywane w postaci wartoĞci atrybutów przynale-Īących do konkretnych jednostek w nast Ċpującej kolejnoĞci: numer stacji (miejsce, gdzie po-jawiają siĊ jednostki), numer przedmiotu transportowanego, numer obiektu (transportującego przedmiot) i kolejne numery wĊzáów zdefiniowanej trasy, jako wartoĞci tablicy.
Rys. 6. Definiowanie elementarnej drogi przejazdu obiektu systemu transportowego
Dane okreĞlające trasĊ przejazdu są przesyáane z aplikacji zewnĊtrznej o nazwie „RT-Console” (rys. 8). Aby um oĪliwiü przesy áanie danych, konieczne jest prze áączenie Areny w tryb pracy w czasie rzeczywist ym. W tym trybie Arena „nas áuchuje” na porcie 4334 i jest gotowa do nawi ązania po áączenia. Ponadto czas „sym ulacyjny” w program ie Arena jest zgodny z czasem komputera. Po nawi ązaniu poáączenia moĪna przygotowaü w aplikacji RT-Console dane o zadanej trasie przejazdu. Kolejno Ğü danych zosta áa opisana powy Īej. Ci ąg wartoĞci „01 05 09 10 11 12” okre Ğla kolejne num ery wĊzáów, skáadających siĊ na zadan ą trasĊ
przejazdu.
Rys. 8. Aplikacja zewnĊtrzna wyznaczająca trasĊ przejazdu
Po wysáaniu danych do Areny, zostają one odebrane przez element „Arrivals” i wyge-nerowana jednostka (opisana powy Īej) przechodzi do m oduáu „ZajacieW ozka” (rys. 9). W module tym zostaje jednostce przydzielony wózek i jednostka przechodzi do m oduáu ”CzyKoniecTrasy?”, gdzie nast Ċpuje sprawdzenie osi ągniĊcia m iejsca docelowego. Je Īeli wózek dojecha á do m iejsca docelowego, to nast Ċpuje zwolnienie wózka przez jednostk Ċ w module „ZwolnienieW ozka” i opuszczenie m odelu. W przeciwnym wypadku jednostka przechodzi do m oduáu „KolejnyOdcinek”, w którym są przygotowywane dane potrzebne do rozpoczĊcia elementarnego przejazdu wywoáanego przez blok „Move”. Po pokonaniu pierw-szego odcinka cykl si Ċ powtarza, a Ī do osi ągniecia w Ċzáa ko Ĕcowego trasy. W ten sposób trasa przejazdu obiektu (zaznaczona czerwon ą lini ą na rys. 9) jest zgodna z tras ą zadan ą w aplikacji RTConsole.
W trakcie realizacji zadania transportowego uwzgl Ċdniane s ą param etry m ające wpáyw na prĊdkoĞü przejazdu obiektu przez sie ü transportową (zakrĊty, ograniczenia prĊdko-Ğci na pewnych liniach). W prezentowanym rozwi ązaniu wszystkie elem entarne zadania transportowe m uszą by ü realizowane ze sta áą pr ĊdkoĞcią obiektów transportowych na po-szczególnych liniach sieci. Nie jest uwzgl Ċdnianie przyspieszenie i opó Ĩnienie zwi ązane z ruszaniem i zatrzym aniem si Ċ obiektu. Rozwi ązanie tego problem u wym aga opracowania odpowiedniego algorytmu, który obliczaáby skorygowaną (zmniejszoną) wartoĞü prĊdkoĞci na danym odcinku, przy której czas pokonania odcinka by áby taki sam, jak dla ruchu, w którym wystĊpowaáoby przyspieszenie i ewentualnie opóĨnienie.
5. PODSUMOWANIE
Zastosowanie m odeli sym ulacyjnych do testowania innowacyjnych rozwi ązaĔ w zakresie sterowania system em produkcyjnym oraz podsystem em transportowym pozwala na sprawdzenie poprawno Ğci przyj Ċtych rozwi ązaĔ. Jest to szczególnie istotne ze wzgl Ċdów bezpieczeĔstwa. Testowanie niesprawdzonych rozwi ązaĔ na obiektach rzeczywistych m oĪe doprowadziü do kolizji i uszkodze Ĕ. Zaproponowany w pracy m odel um oĪliwiający wyznaczanie dowolnych tras przejazdu obiektów system u transportowego pozwoli na
wykrywanie zastojów i kolizji spowodowanych ewentualnym i báĊdami systemu sterującego. Dodatkową zalet ą wykorzystania m etod sym ulacyjnych jest niski koszt i áatwoĞü przeprowadzania testów. Ponadto zastosowanie Ğrodowiska symulacyjnego Areny w zakresie wizualizacji i anim acji sym ulowanego m odelu, w znacz ący sposób u áatwi prac Ċ nad testowaniem systemu sterującego.
Peáne przygotowanie m odelu do przeprowadzania testów wym aga jeszcze jego rozbudowy. Konieczna jest im plementacja algorytm u nadzoruj ącego pr ĊdkoĞü, z jak ą poruszają siĊ wózki tak, aby czas pokonania trasy przez obiekt rzeczywisty i obiekt w modelu symulacyjnym by á taki sam . Uszczegó áowienia wym aga rodzaj inform acji i form at ich przesyáania pom iĊdzy m odelem sym ulacyjnym a aplikacj ą steruj ącą system em transportowym.
PracĊ wykonano w ram ach projektu badawczego w áasnego Nr N N503 214237 pt. ”Integracja rozproszonego system u sterowania produkcj ą z podsystem em transportu miĊdzyoperacyjnego zbudowanym z autonom icznych wózków m obilnych”, finansowanego przez Ministerstwo Nauki i Szkolnictwa W yĪszego w latach 2009–2011.
6. BIBLIOGRAFIA
1. Che-Fu Hsueh. A sim ulation study of a bi-directional load-exchangeable autom ated guided vehicle system. Computers & Industrial Engineering 58 (2010), s. 594–601.
2. B. Cherkassky, A.V. Goldberg, T. Radzik. Shortest Paths Algorithm s: Theory and Expe-rimental Evaluation. Proc. Of 5 th Annual ACM-SIAM Sym posium on Discrete
Algo-rithms, Arlington 1994, s. 516–525.
3. R. Fox, A. Garcia, M. Nelson. A Generic Path Planning Strategy for Autonom ous Ve-hicles. The University of Texas – Pan Am erican, Department of Computer Science Tech-nical Report CS-00-25, August, 2000.
4. S. E. Kesen, O. F. Baykoc. Sim ulation of automated guided vehicle (AGV) systems based on just-in-time (JIT) philosophy in a job-shop environm ent. Simulation Modelling Prac-tice and Theory 15 (2007), s. 272–284
5. L. Qiu, W -J Hsu, S-Y Huang, H. Wang. Scheduling and routing algorithm s for AGVs: a survey. International Journal of Production Research. 2002, vol. 40, no. 3, s. 745–760. 6. T. WiĊk. Laserowy system nawigacji autonom icznej platformy mobilnej na przyk áadzie
urządzenia NAV300. Pomiary Automatyka Robotyka, Nr 2, 2011.
7. J. Zając. Rozproszone sterowanie zautomatyzowanymi systemami wytwarzania. Monogra-fia 288, Seria Mechanika. Wydawnictwo Politechniki Krakowskiej, Kraków 2003.
8. J. Zajac. A Deadlock Handling Method for Autom ated Manufacturing System s. CIRP Annals - Manufacturing Technology 2004, Vol. 53, No. 1, s. 367–370.
9. J. Zając, G. Chwajo á. Koncepcja integracji rozproszonego system u sterowania produkcj ą AIM z podsystem em transportu m iĊdzyoperacyjnego zbudowanym z autonom icznych robotów mobilnych. Pomiary Automatyka Robotyka, Nr 2, 2011.
10. J. Zając, K. Krupa, A. Sáota, T. WiĊk. Konstrukcja i ukáad sterowania autonomicznej plat-formy mobilnej. Pomiary Automatyka Robotyka, Nr 2, 2011.
11. Zając J, S áota A., Chwajo á G., Distributed Manufacturing Control: Models and Software Implementations. Managem ent and Production Engineering Review, Vol. 1., No. 1., May 2010, s. 38–56.
