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.
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.
Rys. 1. Ogólna struktura wieloagentowego systemu AIM [5]
Agent zlecenia reprezentuje w systemie wykonywany typ produktu oraz przechowuje infor-macje 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 sys-temu. Agent ten jest równie aktywny w caym okresie dziaania syssys-temu. Agent wykonaw-czy reprezentuje w systemie AIM fizyczne urzdzenie takie jak maszyna, robot, magazyn itp. Agent ten odgrywa zasadnicz rol w procesie decyzyjnym. Tworzony jest wraz z wcze-niem (uaktywniewcze-niem) fizycznego urzdzenia, które reprezentuje, a usuwany z systemu po wyczeniu tego urzdzenia. Agent przedmiotowy reprezentuje zadanie wykonania poje-dynczego produktu. Posiada informacje dotyczce marszrut technologicznych jego wykona-nia, a ponadto dysponuje biecymi informacjami o aktualnym stanie zaawansowania
realiza-Agenty
Zlece AgentyPrzedmiotowe Interakcja z wszystkimi agentami Agenty Systemowe logika Agenty Wykonawcze Agent Technolog
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ób-ki, 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 rozpatrywa-nego 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 no-wych czynnociach oraz konfiguracj wszystkich agentów wirtualnie reprezentujcych zaso-by wytwórcze wymagane przez proces technologiczny. W celu uzyskania wielowariantowej oferty symulacje przeprowadzane s dla rónych terminów wprowadzenia zlecenia do reali-zacji. Uruchomienie mechanizmu symulacyjnego realizowane jest przez operatora przyjmuj-cego zlecenie i kadorazowo rozpoczyna si od synchronizacji danych pomidzy rzeczywi-stymi i wirtualnymi agentami wykonawczymi oraz agentami zlece. Nastpnie inicjowany zostaje obieg wirtualnego etonu decyzyjnego przyznajcego uprawnienia decyzyjne po-szczególnym agentom, co w konsekwencji pozwala na rozpoczcie gównego etapu dziaa, jakim jest symulacja realizacji procesów wytwórczych. Algorytm dziaa symulujcych ste-rowanie w podsystemie wirtualnym jest analogiczny do tego, który okrela funkcjonowanie sterowania rzeczywistego, z jednym wyjtkiem dotyczcym sposobu sygnalizacji zakocze-nia poszczególnych czynnoci elementarnych. W systemie rzeczywistym zdarzezakocze-nia te s sy-gnalizowane przez ukady sterujce urzdze biorcych udzia w realizacji czynnoci, za w procesach wirtualnych zakoczenie poszczególnych czynnoci nastpuje po upywie osza-cowanych uprzednio czasów ich trwania, przy czym czasy te s proporcjonalnie skrócone w stosunku do ich faktycznych wartoci. Po zakoczeniu realizacji wszystkich zadanych
wa-riantów symulacji przygotowywana jest oferta, która nastpnie zostaje przekazana zlecenio-dawcy. Istnieje take moliwo ledzenia przebiegu i czciowych wyników poszczególnych etapów symulacji w trakcie jej trwania. Proces symulacji w trybie nowego zlecenia zobrazo-wano na UML-owym diagramie przedstawionym na rys. 2.
Superagent :Agent Wykonawczy /wirtualny/ :Agent Zlecenia /wirtualny/
zadaj synchronizacji
par
[dla kadego agenta zlecenia]
loop synchronizuj
[dla kadego agenta wykonawczego]
loop
synchronizuj [dla kolejno zadawanych warunków symulacji ]
loop
nowy :Agent Zlecenia
/wirtualny/
ref Symulacja dla
zadanych warunków
przygotuj zestawienie wyników ; sformuuj (wielowariantow) ofert
ref Synchronizacja danych z rzeczywistym agentem [dla kadego wymaganego
agenta wykonawczego]
loop
konfiguruj
ref Synchronizacja danych z rzeczywistym agentem
uruchom obieg wirtualnego etonu decyzyjnego
zatrzymaj obieg wirtualnego etonu decyzyjnego rozpocznij symulacj Warunki kolejnych przebiegów symulacji mog róni si m.in. - zastosowan regu podejmowania decyzji - terminem wprowadzenia nowego zlecenia do wirtualnej realizacji
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 trans-portowym 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.
Zdefiniowany w przykadzie typ document/literal jest najpopularniejsz sporód stosowa-nych kombinacj, która równoczenie jest rekomendowana w celu zapewnienia najwysze-go poziomu interoperacyjnoci.
Listing 1. Dokument WSDL dla usugi SystemAgentService <?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:elementname="startSimulation"> <xsd:complexType>
<xsd:sequence>
<xsd:elementname="workMode" type="xsd:string"nillable="true"minOccurs="0"/> </xsd:sequence>
</xsd:complexType> </xsd:element>
<xsd:elementname="startSimulationResponse"type="xsd1:void" /> </xsd:schema>
</wsdl:types>
<wsdl:messagename="startSimulationInputMessage">
<wsdl:part element="xsd1:startSimulation"name="parameters"/> </wsdl:message>
<wsdl:messagename="startSimulationOutputMessage">
<wsdl:part element="xsd1:startSimulationResponse"name="parameters"/> </wsdl:message>
<wsdl:portTypename="SystemAgentServicePortType"> <wsdl:operation name="startSimulation">
<wsdl:input message="tns:startSimulationInputMessage"/> <wsdl:output message="tns:startSimulationOutputMessage"/> </wsdl:operation>
</wsdl:portType>
<wsdl:bindingname="SystemAgentServiceBinding" type="tns:SystemAgentServicePortType"> <soap:bindingstyle="document"transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="startSimulation">
<soap:operationsoapAction="SystemAgentServicePortType#startSimulation"/> <wsdl:input>
<soap:body use="literal"/> </wsdl:input>
<wsdl:output>
<soap:body use="literal"/> </wsdl:output>
</wsdl:operation> </wsdl:binding>
<wsdl:servicename="SystemAgentService">
<wsdl:port binding="tns:SystemAgentServiceBinding" name="SystemAgentServicePort"> <soap:addresslocation="http://10.1.1.11:8080/axis2/services/SystemAgentService"/> </wsdl:port>
</wsdl:service> </wsdl:definitions>
- 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.
Listing 2. Dane w XML-owej postaci przesyane w czasie uruchamiania symulacji
Zapytanie:
<soapenv:Envelopexmlns: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:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body>
<startSimulationResponse xmlns="http://m6.mech.pk.edu.pl/SystemAgentService.xsd1"/> </soapenv:Body>
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 Windows / Linux Apache Tomcat Apache Axis 2 PostgreSQL Java Runtime Environment
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.
Listing 3. Kod implementujcy danie rozpoczcia symulacji (Java)
Rys. 4. Zrzut gównego okna aplikacji zarzdzajcej systemem sterowania AIM 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()); }
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.
Listing 4. Kod implementujcy danie rozpoczcia symulacji (JavaScript) 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);
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] FRYLEWICZ 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] ZAJ C J., Rozproszone sterowanie zautomatyzowanymi systemami wytwarzania. Monografia 288, Seria Mechanika. Wydawnictwo Politechniki Krakowskiej, Kraków 2003.
[4] ZAJ C 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] ZAJ C J., CHWAJO G., KMIECIK A., Integracja projektowania procesów i stero-wania produkcj w zautomatyzowanych systemach wytwarzania. Pomiary Automatyka Robotyka, 2/2007.
