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