Plik PDF - PAR Pomiary - Automatyka
Transkrypt
Plik PDF - PAR Pomiary - Automatyka
Pomiary Automatyka Robotyka 2/2009 dr hab. in. Jerzy Zajc, prof. PK mgr in. Grzegorz Chwajo Politechnika Krakowska WYKORZYSTANIE TECHNOLOGII WEB SERVICES DO BUDOWY ROZPROSZONEGO SYSTEMU STEROWANIA Wspóczesne technologie internetowe otwieraj nowe moliwoci w budowie otwartych, rekonfigurowalnych systemów sterowania. W pracy przedstawiono wybrane elementy wieloagentowego systemu sterowania AIM opracowanego w Politechnice Krakowskiej. Komunikacja pomidzy rozproszonymi elementami systemu sterowania realizowana jest przy uyciu technologii Web services. BUILDING DISRIBUTED CONTROL SYSTEM USING WEB SERVICES TECHNOLOGY Contemporary Internet technologies open new opportunities for building open, reconfigurable control systems. The paper presents selected elements of multiagent control system AIM developed at Cracow University of Technology. The communication among distributed elements of control system is performed by means of Web services technology. 1. WPROWADZENIE Otwarto i rekonfigurowalno to zasadnicze wymagania stawiane wspóczesnym systemom sterowania zoonych systemów produkcyjnych. Osignicie tych wymaga jest obecnie moliwe dziki rozwojowi technologii informacyjnych, zwaszcza w zakresie standardów komunikacyjnych, wród których dominuj technologie internetowe, a take szeroka dostpno profesjonalnych pakietów aplikacji typu open-source gwarantujcych niezaleno na wci czciowo zmonopolizowanym rynku IT. Szczególn rol w budowie systemów sterowania odgrywaj aktualnie technologie wieloagentowe. Wychodz one naprzeciw dominujcym trendom rozpraszania decyzji polegajcym na przyblianiu decydenta do miejsca decyzji, co docelowo prowadzi bdzie do powstawania inteligenych urzdze dziaajcych w systemach produkcyjnych zgodnie z zasad plug and play [3]. Takie dziaanie wie si jednak z ograniczeniem dostpu do informacji o charakterze systemowym, co powoduje, e lokalny decydent musi uzyskiwa dodatkowe informacje, aby móc podejmowa decyzje uwzgldniajce realizacj celów systemowych. Odbywa si to w praktyce na dwa sposoby. Albo wykorzystuje si elementy wspólnego rodowiska albo te stosuje bezporedni komunikacj midzyagentow. Elementami wspólnego rodowiska w systemie wieloagentowym s zazwyczaj scentralizowane lub rozproszone tablice ogosze. Na takich tablicach agenty umieszczaj informacj o realizowanych procesach, zgaszaj swoje zapotrzebowania na zasoby itp. S to wic miejsca, przez które odbywa si kontakt agentów - klientów poszukujcych okrelonych usug i agentów – usugodawców, usugi te oferujcych. Najbardziej znanym przykadem narzdzia umoliwiajcego bezporedni komunikacj midzyagentow jest protokó kontraktu sieciowego CNP (ang. Contract Net Protocol) [2]. Jest to protokó prowadzenia negocjacji wykorzystujcy mechanizmy rynkowe. Istnieje równie wiele rónych „mutacji” tego protokou. Protokó ten jest czsto wykorzystywany take w procesach rozproszonego sterowania produkcj. automation 2009 105 Pomiary Automatyka Robotyka 2/2009 Zastosowanie technologii wieloagentowych do budowy rozproszonych systemów sterowania, przyjmujc jednoczenie jako platform implementacyjn technologi Web services, jedn ze znanych technologii internetowych, otwiera nowe moliwoci budowy otwartych, rekonfigurowalnych systemów sterowania. W pracy przedstawiono ogóln struktur wieloagentowego systemu sterowania AIM (Agents Integrated Manufacturing) opracowanego w Politechnice Krakowskiej i omówiono elementy technologii Web services wykorzystane do jego budowy. 2. WIELOAGENTOWY SYSTEM STEROWANIA AIM Wieloagentowy system sterowania AIM zbudowany jest czterech typów uniwersalnych agentów oraz dwóch typów agentów dedykowanych. Agenty uniwersalne to agent zlecenia, agent systemowy, agent wykonawczy i agent przedmiotowy. Agenty Systemowe Interakcja z wszystkimi agentami Agenty Zlece Agent Technolog Agenty Przedmiotowe logika Agenty Wykonawcze Rys. 1. Ogólna struktura wieloagentowego systemu AIM [5] Agent zlecenia reprezentuje w systemie wykonywany typ produktu oraz przechowuje informacje dotyczce zamówienia, takie jak liczba sztuk produktu, termin i koszt jego wykonania oraz dokumentacj konstrukcyjn zawierajc m.in. model CAD. Agent ten tworzony jest po wpyniciu zlecenia, a usuwany albo po zakoczeniu jego realizacji w przypadku przyjcia zlecenia, lub te bezporednio po odrzuceniu zlecenia w przypadku jego nieprzyjcia. Agent systemowy odpowiedzialny jest za dziaania o charakterze systemowym, tj. administracj systemu, nadzór i rejestracje agentów, a ponadto gromadzi informacje o biecym stanie systemu. Agent ten jest równie aktywny w caym okresie dziaania systemu. Agent wykonawczy reprezentuje w systemie AIM fizyczne urzdzenie takie jak maszyna, robot, magazyn itp. Agent ten odgrywa zasadnicz rol w procesie decyzyjnym. Tworzony jest wraz z wczeniem (uaktywnieniem) fizycznego urzdzenia, które reprezentuje, a usuwany z systemu po wyczeniu tego urzdzenia. Agent przedmiotowy reprezentuje zadanie wykonania pojedynczego produktu. Posiada informacje dotyczce marszrut technologicznych jego wykonania, a ponadto dysponuje biecymi informacjami o aktualnym stanie zaawansowania realiza- 106 automation 2009 Pomiary Automatyka Robotyka 2/2009 cji procesu. Agent ten tworzony jest w momencie wprowadzenia pófabrykatu do magazynu, a usuwany po wykonaniu gotowego produktu. Linie przerywane czce agenty na rys. 1 wskazuj na wspódziaanie w procesie przygotowywania procesów technologicznych obróbki, natomiast linie cige oznaczaj wspódziaanie w procesie sterowania produkcj. Dwa typy agentów dedykowanych tworz agent technolog i agent dostosowujcy (pominity na rys. 1). Agent technolog jest wyposaony w eksperck wiedz z zakresu projektowania procesów technologicznych, a jego zadaniem jest opracowywanie i modyfikacja procesów technologicznych dla przyjmowanych zamówie. Agent ten jest aktywny w caym okresie dziaania systemu AIM. Rola agentów dostosowujcych sprowadza si najogólniej mówic do zapewnienia wspópracy pomidzy agentami wykonawczymi a sterownikami urzdze. Jedn z najciekawszych cech systemu AIM jest wprowadzenie mechanizmu symulacyjnego wykorzystujcego tzw. wirtualne procesy wytwórcze [4]. Trzon omawianego mechanizmu stanowi wirtualne kopie (klony) agentów biorcych udzia w procesie sterowania operatywnego tj. wirtualne agenty wykonawcze oraz przedmiotowe, a take wirtualne agenty zlece. Wymienione agenty wspódziaaj z ich rzeczywistymi odpowiednikami, a take w ograniczonym zakresie z pozostaymi elementami tworzcymi system sterowania. Za koordynacj wirtualnych procesów odpowiedzialny jest tzw. superagent, tj. okrelony, uprzywilejowany agent wchodzcy w skad grupy agentów systemowych, które w systemie peni role administracyjne i monitorujce. Jednym z zasadniczych celów zastosowania wspomnianego mechanizmu symulacyjnego jest weryfikacja moliwoci przyjcia nowego zlecenia. Rozpoczcie wirtualnego procesu wytwórczego w trybie nowego zlecenia poprzedzone jest w pierwszej kolejnoci weryfikacj moliwoci technologicznych realizacji zamówienia. W przypadku pozytywnego wyniku weryfikacji, w nastpnej kolejnoci opracowany zostaje proces technologiczny. W efekcie, dla poszczególnych zasobów wytwórczych sporzdzone zostaj zbiory dodatkowych czynnoci elementarnych niezbdnych do realizacji rozpatrywanego zlecenia. Dopóki jednak warunki realizacji zamówienia nie zostan zaakceptowane przez zleceniodawc, dane te nie s przesyane do agentów wykonawczych reprezentujcych rzeczywiste zasoby wytwórcze. S one jednak niezbdne w celu przeprowadzenia procesu symulacji. Jego rozpoczcie wie si zatem z wczeniejszym dostarczeniem danych o nowych czynnociach oraz konfiguracj wszystkich agentów wirtualnie reprezentujcych zasoby wytwórcze wymagane przez proces technologiczny. W celu uzyskania wielowariantowej oferty symulacje przeprowadzane s dla rónych terminów wprowadzenia zlecenia do realizacji. Uruchomienie mechanizmu symulacyjnego realizowane jest przez operatora przyjmujcego zlecenie i kadorazowo rozpoczyna si od synchronizacji danych pomidzy rzeczywistymi i wirtualnymi agentami wykonawczymi oraz agentami zlece. Nastpnie inicjowany zostaje obieg wirtualnego etonu decyzyjnego przyznajcego uprawnienia decyzyjne poszczególnym agentom, co w konsekwencji pozwala na rozpoczcie gównego etapu dziaa, jakim jest symulacja realizacji procesów wytwórczych. Algorytm dziaa symulujcych sterowanie w podsystemie wirtualnym jest analogiczny do tego, który okrela funkcjonowanie sterowania rzeczywistego, z jednym wyjtkiem dotyczcym sposobu sygnalizacji zakoczenia poszczególnych czynnoci elementarnych. W systemie rzeczywistym zdarzenia te s sygnalizowane przez ukady sterujce urzdze biorcych udzia w realizacji czynnoci, za w procesach wirtualnych zakoczenie poszczególnych czynnoci nastpuje po upywie oszacowanych uprzednio czasów ich trwania, przy czym czasy te s proporcjonalnie skrócone w stosunku do ich faktycznych wartoci. Po zakoczeniu realizacji wszystkich zadanych waautomation 2009 107 Pomiary Automatyka Robotyka 2/2009 riantów symulacji przygotowywana jest oferta, która nastpnie zostaje przekazana zleceniodawcy. Istnieje take moliwo ledzenia przebiegu i czciowych wyników poszczególnych etapów symulacji w trakcie jej trwania. Proces symulacji w trybie nowego zlecenia zobrazowano na UML-owym diagramie przedstawionym na rys. 2. Superagent nowy :Agent Zlecenia /wirtualny/ loop :Agent Wykonawczy /wirtualny/ :Agent Zlecenia /wirtualny/ [dla kadego wymaganego agenta wykonawczego] konfiguruj loop [dla kolejno zadawanych warunków symulacji ] rozpocznij symulacj zadaj synchronizacji par loop [dla kadego agenta zlecenia] synchronizuj ref loop Synchronizacja danych z rzeczywistym agentem [dla kadego agenta wykonawczego] synchronizuj ref Warunki kolejnych przebiegów symulacji mog róni si m.in. - zastosowan regu podejmowania decyzji - terminem wprowadzenia nowego zlecenia do wirtualnej realizacji Synchronizacja danych z rzeczywistym agentem uruchom obieg wirtualnego etonu decyzyjnego ref Symulacja dla zadanych warunków zatrzymaj obieg wirtualnego etonu decyzyjnego przygotuj zestawienie wyników ; sformuuj (wielowariantow) ofert Rys. 2. Symulacja w trybie nowego zlecenia 108 automation 2009 Pomiary Automatyka Robotyka 2/2009 3. ZASTOSOWANIE TECHNOLOGII WEB SERVICES Komunikacja pomidzy rozproszonymi elementami systemu na wszystkich etapach sterowania, zarówno w trybie rzeczywistym jak i wirtualnym, realizowana jest przy uyciu technologii Web services [1]. Poszczególne kroki wymagane w procesie projektowania i implementacji mechanizmów wymiany informacji wykorzystujcych powysz technologi zostan przedstawione w dalszej czci rozdziau na przykadzie funkcji startSimulation wywoywanej na agencie systemowym, za pomoc której inicjowany jest proces symulacji opisanej w rozdziale 2. Jednym z podej do projektowania mechanizmów komunikacyjnych opartych na technologii Web services jest rozpoczcie ich budowy od przygotowania dokumentu WSDL (ang. Web Services Description Language) opisujcego w szczegóowy sposób funkcjonowanie mechanizmów. Podejcie takie zapewnia najpeniejsz kontrol nad reguami wymiany informacji i jest ono rekomendowane. Listing 1 przedstawia dokument (zgodny z wersj 1.1 standardu WSDL) definiujcy reguy wymiany komunikatów w czasie wywoywania funkcji startSimulation, która jest metod typu void (nie zwraca adnego rezultatu swego dziaania) i przyjmuje jeden parametr okrelajcy tryb symulacji. Dokument ten zbudowany jest z piciu zasadniczych typów elementów: types, message, portType, binding oraz service, które wchodz w skad elementu nadrzdnego definitions. Wszystkie te elementy zdefiniowane s w przestrzeni nazw „http://schemas.xmlsoap.org/wsdl/” (ich nazwy poprzedza przedrostek wsdl, który jest niejako „skrótem” penej nazwy wspomnianej przestrzeni, co zostao okrelone poprzez atrybut: „xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/”). Znaczenie poszczególnych elementów jest nastpujce: - element types zawiera deklaracje struktur danych wykorzystanych do definicji komunikatów. Struktury takie opisywane s najczciej przy uyciu schematów XML (XML Schema). W omawianym przykadzie struktury te zostay zdefiniowane poprzez dwa elementy: startSimulation zawierajcy jeden parametr typu string o nazwie workMode oraz startSimulationResponse nie zwracajcy adnego rezultatu. Omówiona wyej symulacja w trybie nowego zlecenia realizowana jest dla parametru workMode przyjmujcego warto virtual. - elementy message definiuj komunikaty przesyane w czasie wymiany informacji. W omawianym przykadzie okrelono dwa takie elementy: startSimulationInputMessage oraz startSimulationOuputMessage, a take powizano z nimi definicje wprowadzono uprzednio w ramach elementu types. - element portType tworzy interfejs zawierajcy okrelony zbiór udostpnianych operacji. Kada z operacji zdefiniowana jest w elemencie potomnym operation. W analizowanym, uproszczonym przykadzie element portType definiuje jedn operacj o nazwie startSimulation. W odpowiadajcym wymienionej operacji elemencie operation zdefiniowano z kolei który z okrelonych uprzednio komunikatów jest komunikatem wejciowym, a który wyjciowym. Taki ukad komunikatów tworzy tzw. wzorzec wymiany komunikatów typu „danie-odpowied”. - element binding definiuje powizanie elementu portType z konkretnym protokoem. W przedstawionym dokumencie WSDL element binding dokonuje powizania w standardzie SOAP elementu o nazwie SystemAgentServicePortType z protokoem transportowym HTTP. Istotne znaczenie odgrywaj take atrybuty style oraz use, które okrelaj typ wizania majcy w efekcie wpyw na ostateczn posta przesyanych pakietów danych. automation 2009 109 Pomiary Automatyka Robotyka 2/2009 Zdefiniowany w przykadzie typ document/literal jest najpopularniejsz sporód stosowanych kombinacj, która równoczenie jest rekomendowana w celu zapewnienia najwyszego poziomu interoperacyjnoci. <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="SystemAgentService" targetNamespace="http://m6.mech.pk.edu.pl/SystemAgentService.wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://m6.mech.pk.edu.pl/SystemAgentService.wsdl" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd1="http://m6.mech.pk.edu.pl/SystemAgentService.xsd1"> <wsdl:types> <xsd:schema elementFormDefault="qualified" targetNamespace="http://m6.mech.pk.edu.pl/SystemAgentService.xsd1" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsd1="http://m6.mech.pk.edu.pl/SystemAgentService.xsd1"> <xsd:complexType name="void"> <xsd:sequence /> </xsd:complexType> <xsd:element name="startSimulation"> <xsd:complexType> <xsd:sequence> <xsd:element name="workMode" type="xsd:string" nillable="true" minOccurs="0" /> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="startSimulationResponse" type="xsd1:void" /> </xsd:schema> </wsdl:types> <wsdl:message name="startSimulationInputMessage"> <wsdl:part element="xsd1:startSimulation" name="parameters"/> </wsdl:message> <wsdl:message name="startSimulationOutputMessage"> <wsdl:part element="xsd1:startSimulationResponse" name="parameters"/> </wsdl:message> <wsdl:portType name="SystemAgentServicePortType"> <wsdl:operation name="startSimulation"> <wsdl:input message="tns:startSimulationInputMessage"/> <wsdl:output message="tns:startSimulationOutputMessage"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="SystemAgentServiceBinding" type="tns:SystemAgentServicePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="startSimulation"> <soap:operation soapAction="SystemAgentServicePortType#startSimulation"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="SystemAgentService"> <wsdl:port binding="tns:SystemAgentServiceBinding" name="SystemAgentServicePort"> <soap:address location="http://10.1.1.11:8080/axis2/services/SystemAgentService"/> </wsdl:port> </wsdl:service> </wsdl:definitions> Listing 1. Dokument WSDL dla usugi SystemAgentService 110 automation 2009 Pomiary Automatyka Robotyka 2/2009 - element service okrela lokalizacje, pod jakimi osigalne bd kade ze zdefiniowanych uprzednio wiza. W prezentowanym przykadzie usuga o nazwie SystemAgentService udostpnia zdefiniowane wizanie pod adresem: http://10.1.1.11:8080/axis2/services/SystemAgentService. Z tej informacji korzysta moe oprogramowanie klienckie dedykowane danej usudze. Warto jednak zauway, e wiele implementacji aplikacji klienckich umoliwia podawanie lokalizacji usug niezalenie od informacji zawartych w omawianym elemencie service, co bywa w okrelonych sytuacjach przydatne. Na podstawie tak przygotowanego dokumentu WSDL mona nastpnie za pomoc okrelonych narzdzi (np. WSDL2Java w rodowisku Apache Axis2 lub wsdl.exe dostpnym w Microsoft .NET Framework) wygenerowa kod poredniczcy (dla strony serwerowej lub klienckiej), który w dalszej kolejnoci naley zintegrowa z waciwym kodem implementujcym logik agenta bd wykorzysta w zewntrznym oprogramowaniu klienckim. Listing 2 przedstawia tre wymienianych w celu inicjalizacji symulacji XML-owych pakietów danych, których struktura wie si w sposób cisy z definicj zawart w dokumencie WSDL. Warto zwróci uwag, i w przedstawionej sytuacji, mimo e wywoywana funkcja jest typu void, w odpowiedzi zwracany jest XML-owy pakiet. Wynika to z faktu zastosowania w definicji operacji zawartej w dokumencie WSDL wzorca wymiany komunikatów typu „danie-odpowied”. Podejcie takie pozwala w przeciwiestwie do potencjalnego zastosowania wzorca jednokierunkowego stwierdzi czy funkcja zakoczya swe dziaanie poprawnie. Zapytanie: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sys="http://m6.mech.pk.edu.pl/SystemAgentService.xsd1"> <soapenv:Header/> <soapenv:Body> <sys:startSimulation> <sys:workMode>virtual</sys:workMode> </sys:startSimulation> </soapenv:Body> </soapenv:Envelope> Odpowied: <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <startSimulationResponse xmlns="http://m6.mech.pk.edu.pl/SystemAgentService.xsd1"/> </soapenv:Body> </soapenv:Envelope> Listing 2. Dane w XML-owej postaci przesyane w czasie uruchamiania symulacji automation 2009 111 Pomiary Automatyka Robotyka 2/2009 4. PLATFORMA IMPLEMENTACYJNA Implementacja warstwy logiki systemu sterowania AIM zostaa dokonana przy uyciu jzyka Java. Mechanizmy komunikacyjne wykorzystujce technologi Web services opracowano w oparciu o silnik Web services - Apache Axis2/Java. Aby poszczególne agenty wchodzce w skad systemu sterowania mogy by dostpne dla siebie oraz dla zewntrznych aplikacji klienckich w postaci usug Web services, oprogramowanie agentów wraz z silnikiem Axis2 umieszczono w kontenerze aplikacji WWW, którego rol peni w omawianym rodowisku serwer Apache Tomcat. Zarówno Axis2 jak i Tomcat nale do grupy aplikacji typu open source. Wykorzystywanym serwerem bazodanowym jest PostgreSQL, który w zalenoci od konfiguracji systemu moe by uruchamiany centralnie lub te na kadej stacji roboczej. System sterowania AIM moe by uruchamiany w rodowisku MS Windows lub Linux, a take na innych systemach operacyjnych, dla których istnieje implementacja maszyny wirtualnej Java. Struktura rodowiska uruchomieniowego zostaa przedstawiona na rys. 3. AZ AW AS AW_wirt Apache Axis 2 Apache Tomcat PostgreSQL Java Runtime Environment Windows / Linux Rys. 3. rodowisko uruchomieniowe systemu AIM Kliencka aplikacja do zarzdzania systemem sterowania AIM zostaa równie zaimplementowana przy uyciu jzyka Java oraz silnika Apache Axis2/Java. Do stworzenia graficznego interfejsu uytkownika aplikacji wykorzystano bibliotek Qt Jambi. Cao komunikacji pomidzy aplikacj a systemem AIM realizowana jest w oparciu o technologi Web services. Listing 3 zawiera przykadowy kod implementujcy danie rozpoczcia symulacji. Na rys. 4 przedstawiono zrzut gównego okna aplikacji. 112 automation 2009 Pomiary Automatyka Robotyka 2/2009 public void pushButtonStartSimulation() { try { // stwórz obiekt odpowiadajcy elementowi startSimulation zdefiniowanemu w WSDL StartSimulation req = StartSimulation.Factory.newInstance(); req.setWorkMode(WorkMode.VIRTUAL.toString()); // stwórz obiekt reprezentujcy wysyany komunikat StartSimulationDocument reqDoc = StartSimulationDocument.Factory.newInstance(); reqDoc.setStartSimulation(req); // wywoaj metod uruchamiajc symulacj, przeka jej obiekt z komunikatem SystemAgentServiceStub stub = new SystemAgentServiceStub(m_superAgentUrl); stub.startSimulation(reqDoc); } catch(RemoteException e) { Utils.showError("Error while starting simulation: " + e.getMessage()); } } Listing 3. Kod implementujcy danie rozpoczcia symulacji (Java) Rys. 4. Zrzut gównego okna aplikacji zarzdzajcej systemem sterowania AIM automation 2009 113 Pomiary Automatyka Robotyka 2/2009 Wykorzystujc jeden z zasadniczych atutów technologii Web services, jakim jest relatywnie duy stopie niezalenoci od stosowanych jzyków programowania i platform systemowych mona w atwy sposób komunikowa si z poszczególnymi elementami systemu AIM z poziomu moduów programowych zaimplementowanych nie tylko w jzyku Java. Listing 4 zawiera przykadowy kod implementujcy danie rozpoczcia symulacji napisany w jzyku JavaScript z wykorzystaniem skryptu WSRequest wchodzcego w skad oprogramowania WSO2 Web Services Framework/AJAX. var req = new WSRequest(); var reqOptions = { useSOAP : true }; var url = "http://10.1.1.11:8080/axis2/services/SystemAgentService"; req.open(reqOptions, url, true); var message = "<startSimulation xmlns=\"http://m6.mech.pk.edu.pl/SystemAgentService.xsd1\" />"; req.send(message); Listing 4. Kod implementujcy danie rozpoczcia symulacji (JavaScript) 5. PODSUMOWANIE Znaczca liczba wspóczesnych przemysowych rozwiza ukadów sterowania oferuje moliwo komunikacji za pomoc protokoów TCP/IP. Umoliwia to ich podczanie bezporednio do Internetu lub zakadowego intranetu. Oznacza to take, i producenci urzdze automatyki przemysowej widz nowe moliwoci dziki wykorzystaniu potgi Internetu. Jest to trend obserwowalny w bardzo wielu obszarach dziaalnoci czowieka. Std, wykorzystanie technologii internetowych w budowie rozproszonych systemów sterowania naley uzna za krok we waciwym kierunku. Technologie internetowe oprócz akceptowanego globalnie standardu komunikacyjnego jakim s protokoy TCP/IP stanowiy baz do powstania znaczcej i cigle rosncej liczby profesjonalnych aplikacji typu open source, które pozwalaj na budow systemów oprogramowania niezalenych od sprztu czy systemu operacyjnego. 6. LITERATURA [1] FRY LEWICZ Z., SALAMON A., Podstawy architektury i technologii usug XML sieci WEB. Wydawnictwo Naukowe PWN SA, Warszawa 2008, ISBN 978-83-01-15371-7 [2] SMITH R.G., The Contract Net Protocol: High-Level Communication and Control in a Distributed Problem Solver. IEEE Trans. on Computers, Vol. C-29, No. 12, 1980, s. 1104-1113 [3] ZAJC J., Rozproszone sterowanie zautomatyzowanymi systemami wytwarzania. Monografia 288, Seria Mechanika. Wydawnictwo Politechniki Krakowskiej, Kraków 2003. [4] ZAJC J., CHWAJO G., Wykorzystanie wirtualnych procesów sterowania produkcj do wspomagania decyzji w zautomatyzowanych systemach wytwarzania. Problemy Robotyki Tom II, Red. K. Tcho, C. Zieliski. Oficyna Wydawnicza Politechniki Warszawskiej 2008, s. 625-634. [5] ZAJC J., CHWAJO G., KMIECIK A., Integracja projektowania procesów i sterowania produkcj w zautomatyzowanych systemach wytwarzania. Pomiary Automatyka Robotyka, 2/2007. 114 automation 2009