Architektura technologii OPC UA stanowiąca nową platformę komunikacyjną w komputerowym systemie logistycznym przedsiębiorstwa

Transkrypt

1 KWIECIEŃ Roman 1 Architektura technologii stanowiąca nową platformę komunikacyjną w komputerowym systemie logistycznym przedsiębiorstwa WSTĘP Technologia OPC (ang. OLE for Process Control) zyskała juŝ renomę na całym Świecie w procesie sterowania i akwizycji danych procesowych w systemach automatyki przemysłowej [2]. Jej popularność przyczyniła się do stosowania jej w róŝnych gałęziach przemysłu, w tym w komputerowych systemach logistycznych. UŜywanie tego samego medium transmisyjnego informacji ma wiele zalet. Przede wszystkim sprzyja integracji wielu systemów informatycznych róŝnych dostawców. W konsekwencji zmniejszyło to czas opracowywania specyfikacji i produktów, które naleŝałoby tworzyć, aby była moŝliwość współdzielenia róŝnych zasobów i magazynów informacji. Niestety technologia OPC bazująca na technologii COM/DCOM (ang. Distributed Component Object Model), wcześniej znanej jako technologia OLE (ang. Object Linking and Embedding) [1, 4], nie jest pozbawiona wad. Z faktu, Ŝe jest dedykowana tylko do systemu operacyjnego Microsoft Windows, wynika brak moŝliwości stosowania jej na innych platformach. Ta zaleŝność wyklucza moŝliwość ingerencji w działanie obiektów komunikacyjnych DCOM, które często uniemoŝliwiały zdalną komunikację w sieci komputerowej. Technologia DCOM jest trudna w konfiguracji, ma bardzo długie i nie konfigurowalne limity czasu oraz nie moŝe być uŝywana do komunikacji internetowej. Pojawienie się róŝnych systemów operacyjnych oraz wzrost ich udziału w róŝnych platformach sprzętowych, jak równieŝ wynikające wady klasycznej technologii OPC spowodowało powstanie nowego sposobu realizacji usług sieciowych, który nazwano technologią OPC Unified Architecture (w skrócie ). Technologia powstała w celu utworzenia alternatywy, dla wszystkich istniejących specyfikacji opartych na technologii COM, zachowującej poŝądane właściwości oraz sposób funkcjonowania. Dodatkowo ma za zadanie objąć wszystkie wymogi interfejsów systemowych, stawiane niezaleŝnym platformom, w bogate i rozszerzalne funkcje modelowania, które będą takŝe w stanie opisać złoŝony system [5]. W związku z powyŝszym w artykule zostaną przedstawione charakterystyczne właściwości technologii, jej specyfikacje oraz architektura klienta i serwera. 1. OGÓLNY ZARYS TECHNOLOGII Technologia jest niezaleŝną od platformy standardem, za pomocą którego róŝne rodzaje systemów i urządzeń mogą komunikować się poprzez przesyłanie wiadomości pomiędzy klientami i serwerami pracującymi w róŝnych rodzajach sieci komputerowych. Obsługuje ona solidną, odporną na ataki i bezpieczną komunikację, która zapewnia toŝsamość klientów oraz serwerów. Definiuje zestawy usług, które klienty mogą realizować w ramach pracy serwerów. Informacja jest przekazywana za pomocą odpowiednio zorganizowanej struktury komunikatu i typów danych dostawcy. Serwery natomiast posiadają zdefiniowane modele obiektów, które klienci mogą z nich odczytywać informacje i dynamicznie wywoływać ich metody. Mogą one równieŝ zapewnić dostęp do danych bieŝących i archiwalnych oraz do alarmów i zdarzeń, aby powiadomić klientów o waŝnych zmianach. Forma treści informacji moŝe być mapowana dla róŝnych protokołów komunikacyjnych, 1 Uniwersytet Technologiczno-Humanistyczny im. Kazimierza Pułaskiego w Radomiu, Wydział Transportu i Elektrotechniki; Radom; ul. Malczewskiego 29. Tel: , , Fax: , r.kwiecien@uthrad.pl 3611

2 a dane mogą być kodowane w róŝny sposób w celu ustalenia kompromisu przy ich transmisji i zapewnieniu wydajności [6]. Celem projektowania technologii jest zapewnienie spójności, zintegrowanej Przestrzeni Adresowej (ang. AddressSpace) oraz odpowiedniego modelu usług. Pozwala to poszczególnemu serwerowi na konsolidację danych bieŝących i archiwalnych oraz alarmów i zdarzeń do wspólnej Przestrzeni Adresowej oraz umoŝliwienie dostępu do nich za pomocą jednolitego zestawu usług (ang. Services). Usługi te obejmują równieŝ zintegrowany model zabezpieczeń [6]. Technologia pozwala na przedstawianie danych w wielu róŝnych formatach, w tym struktur binarnych i dokumentów XML (ang. Extensible Markup Language). Format danych moŝe być definiowany przez fundację OPC, inne organizacje standaryzujące lub producentów. Poprzez Przestrzeń Adresową, klienci mogą zaŝądać z serwera informacji o metadanych, które opisują odpowiedni format danych [6]. W wielu przypadkach klienci bez znajomości zaprogramowanych formatów danych będą w stanie je określić w czasie wykonywania usługi i właściwie je wykorzystać. Technologia udziela wsparcia przy realizowaniu wielu relacji pomiędzy węzłami struktur danych, zamiast ograniczać się do tylko jednej hierarchii. W ten sposób serwer moŝe przedstawić dane w róŝnych uporządkowanych strukturach, dostosowanych do sposobu ich zestawień według typowych zleceń klientów. Ta elastyczność, w połączeniu ze wsparciem dla definicji typu danych sprawia, Ŝe technologia ma zastosowanie w szerokiej gamie dziedzin problemowych [6]. Technologia nie jest typowo ukierunkowana na system SCADA (ang. Supervisory Control And Data Acquisition), rozproszony system sterowania DCS (ang. Distributed Control System) oraz sterowniki programowalne PLC (ang. Programmable Logic Controller), ale posiada takŝe sposób zapewnienia większej interoperacyjności pomiędzy wyŝszymi poziomami funkcjonalności (rys. 1). Przedsiębiorstwo Korporacyjne Manufaktura, Produkcja i Konserwacja Zaawansowane Sterowanie HMI MES Sterowanie SCADA Aplikacje wsadowe Batch PLC DCS Komputerowe sieci przemysłowe Akwizycja danych??...?? Rys. 1. Ukierunkowanie technologii na aplikacje [6] Główną cechą wszystkich serwerów OPC jest moŝliwość publikowania danych i powiadomień o zdarzeniach. Technologia zapewnia klientom mechanizmy do szybkiego wykrywania i odzyskiwania połączeń komunikacyjnych po ich awarii, bez konieczności oczekiwania na długie limity czasu przewidzianych w protokołach bazowych. Jest ona przeznaczona do obsługi wielu serwerów, które charakteryzują się szerokim zakresem moŝliwości funkcjonalnych, wydajnością oraz wykonywaniem na róŝnych platformach. Z tego względu technologia ta definiuje kompleksowy zestaw funkcji, a serwery mogą wdroŝyć moŝliwości tego zestawu. W celu promowania interoperacyjności, technologia definiuje podzbiory, zwane profilami, które przyczyniają się do Ŝądań zgodności serwerów. Klienty mogą pozyskać profile serwera i dostosować ich interakcje z poŝądanymi działaniami [6]. 3612

3 Technologia jest zaprojektowana z moŝliwością migracji klientów i serwerów OPC opartych na technologii COM firmy Microsoft. DołoŜono starań w projektowaniu technologii OPC UA, aby istniejące dane udostępniane przez serwery OPC COM (tj. DA, HDA i A&E) moŝna łatwo dopasować i zmapować. Producenci swoich produktów mogą wybrać natywną migrację do technologii lub uŝyć zewnętrznych modułów do konwersji formatu informacji z OPC COM do i naprzemian. KaŜde z poprzednich specyfikacji technologii OPC definiują własny adres przestrzeni modelu i swój własny zestaw usług. Technologia jednoczy poprzednie modele w jedną zintegrowaną przestrzeń adresową z pojedynczych zestawów usług [6]. 2. SPECYFIKACJE TECHNOLOGII Liczba specyfikacji 2 technologii została usystematyzowana do trzynastu części, które są posegregowane w następujące grupy (rys. 2): 1. Grupa podstawowa (ang. Core Specification Parts), 2. Grupa dostępu do danych (ang. Access Type Specification Parts), 3. Grupa narzędzi uŝytkowych (ang. Utility Specification Parts). STRUKTURA SPECYFIKACJI TECHNOLOGII Grupa podstawowa (ang. Core Specification Parts) Grupa dostępu do danych (ang. Access Type Specification Parts) Część 1 Pojęcia (Concepts) Część 2 Model bezpieczeństwa (Security Model) Część 8 Część 9 Dostęp do danych (Data Access) Alarmy i warunki (Alarms and Conditions) Część 3 Model przestrzeni adresowej (Address Space Model) Część 4 Usługi (Services) Część 5 Model informacyjny (Information Model) Część 6 Mapowanie usług (Service mappings) Część 7 Profile (Profiles) Część 10 Programy (Programs) Część 11 Dostęp do danych archiwalnych (Historical Access) Grupa narzędzi uŝytkowych (ang. Utility Specification Parts) Część 12 Wyszukiwanie serwerów (Discovery) Część 13 Agregaty (Aggregates) Rys. 2. Podział specyfikacji technologii [3, 5, 6] Dwie pierwsze części specyfikacji nie są normatywne. Przedstawiają zarys technologii opisując wymagania bezpieczeństwa oraz model zabezpieczeń. Pierwsza część specyfikacji ma zastosowanie przy tworzeniu oprogramowania w róŝnych obszarach zastosowań, do których zalicza się urządzenia polowe 3, systemy sterowania, systemy realizacji produkcji MES (ang. Manufacturing Execution Systems) i systemy planowania zasobów przedsiębiorstwa ERP (ang. Enterprise Resource Planning). Systemy te są przeznaczone do wymiany informacji oraz do kontrolowania procesami przemysłowymi [6]. W celu ułatwienia przesyłania informacji technologia definiuje wspólny model infrastruktury, na który składa się: a) model informacji reprezentujący strukturę, zachowanie i semantykę, b) model wiadomości do interakcji pomiędzy aplikacjami, 2 Są opisane międzynarodową normą IEC Urządzenia polowe kontrolują lokalne operacje czujników i elementów wykonawczych, takie jak otwieranie i zamykanie zaworów i wyłączników, zbieranie danych z systemów czujników oraz monitorowanie lokalnego środowiska przydatnego do określenia stanów alarmowych. 3613

4 c) model komunikacyjny do przesyłania danych między punktami końcowymi, d) model zgodności do celów zagwarantowania interoperacyjności systemów. Do najwaŝniejszych specyfikacji zalicza się część trzecią i czwartą, które są podstawowymi dokumentami dotyczącymi projektowania i rozwijania aplikacji opartych na technologii. Model przestrzeni adresowej (część trzecia) definiuje odpowiednie bloki, które udostępniają instancję i rodzaj informacji, uŝywanej do opisywania i eksponowania modeli informacyjnych, w celu zbudowania Przestrzeni Adresowej serwera. Abstrakcyjne usługi zdefiniowane w części czwartej, reprezentują moŝliwości interakcji pomiędzy aplikacjami klienta i serwera. Klient korzysta z usług, aby wyszukać i uzyskać dostęp do informacji dostarczanych przez serwer. Usługi są abstrakcyjne, poniewaŝ są one zdefiniowane tylko do wymiany informacji pomiędzy aplikacjami, toteŝ nie są konkretną reprezentacją obiektów API uŝywanych przez aplikacje komputerowe [5]. Podstawowy model informacyjny zdefiniowany w części piątej, dostarcza strukturę dla wszystkich modeli informacyjnych uŝywanych w technologii i określa: a) punkty wejścia do przestrzeni adresowej uŝywanej przez klientów do identyfikacji instancji i typu serwera, b) typy bazowe tworzące fundament dla róŝnych typów hierarchicznych, c) wbudowane na stałe typy obiektów i typy danych, z moŝliwością ich rozbudowy, d) obiekt serwera dostarczający informacje o jego moŝliwościach oraz dane diagnostyczne. Kolejną specyfikacją technologii jest część szósta, dotycząca mapowania usług. Mapowanie to polega na przyporządkowaniu jednych zasobów systemowych do drugich, często wirtualnych. Profile części siódmej technologii są przydatne przy definiowaniu podzbiorów funkcji. Podzbiór ten musi być implementowany całkowicie przez aplikację w celu zapewnienia interoperacyjności. Specyfikacja określa podzbiory na dwóch poziomach. Pierwszy poziom dotyczy zgodności jednostek (ang. Conformance Unit) tworzących niewielki zestaw funkcji, które są zawsze uŝywane razem i mogą być testowane i weryfikowane za pomocą odpowiednich narzędzi. Drugi poziom to profile (ang. Profiles) złoŝone z listy zgodności jednostek (ang. Conformance Unit). Profil musi być implementowany w całości, aby moŝliwe było zweryfikować go jako kompletny zestaw w trakcie certyfikacji produktów technologii. [5] Lista obsługiwanych i uŝywanych profili jest zamienna podczas nawiązywania połączenia pomiędzy klientem a serwerem i umoŝliwia aplikacjom ustalić, czy potrzebne funkcje są obsługiwane przez partnera komunikacyjnego. Model informacyjny specyfikacji obejmuje następujące części [5]: a) część 8 dostęp do danych DA (ang. Data Access) definiuje sposób reprezentowania i uŝywania danych procesowych oraz określa cechy charakterystyczne, takie jak jednostki inŝynierskie, b) część 9 alarmy i warunki AC (ang. Alarms and Conditions) określa definicje alarmów procesu automatyki oraz warunki generowania róŝnych rodzajów zdarzeń podczas monitorowania stanu pracy odpowiednich maszyn, c) część 10 programy definiuje stan bazowy maszyny do wykonywania, manipulowania i monitorowania pracy programów, d) część 11 dostęp do danych archiwalnych HA (ang. Historical Access) określa sposób wykorzystywania usług, mających dostęp do danych zarchiwizowanych oraz definiuje sposób prezentacji danych konfiguracyjnych i historii zdarzeń. W skład grupy narzędzi uŝytkowych wchodzą ostatnie dwie specyfikacje: część dwunasta i trzynasta. Część dwunasta określa sposoby wyszukiwania serwerów w sieci oraz sposoby uzyskania przez klienta niezbędnych informacji. KaŜdy z serwerów OPC moŝe posiadać róŝny zestaw usług do wykonywania, wynikających z jego przeznaczenia w systemie komputerowym. Przy pomocy tej części specyfikacji, moŝliwe jest zlokalizowanie poŝądanego serwera OPC oraz odczytanie podstawowych informacji o nim, na podstawie których będzie podejmowana decyzja o nawiązaniu z nim połączenia. Część trzynasta opisuje agregaty (ang. Aggregates), które są stosowane do obliczania wartości zagregowanych, czyli informacji (najczęściej pojedyncza liczba) podsumowującej pewien zbiór danych jednego rodzaju, np. wartość sumy, wartość średnia, wartość minimalna lub 3614

5 maksymalna, liczba danych itp. Agregacje mają zastosowanie do danych pierwotnych, reprezentujących dane archiwalne oraz bieŝące wartości procesowe podlegające monitorowaniu [5]. a) b) Klient klasycznej OPC Klient DA A&E HDA DA A&C HA DA A&E HDA DA A&C HA Serwer klasycznej OPC Serwer Rys. 3. Architektura organizowania pracy głównych serwerów dla: a) klasycznej technologii OPC; b) technologii ; DA Data Access; A&E Alarms&Events; HDA Historical Data Access; A&C Alarms&Conditions; HA Historical Access [5] Specyfikacje pod względem funkcjonalnym określają sposób realizacji trzech klasycznych specyfikacji: OPC DA, OPC HDA oraz OPC A&E (rys. 3). Na tej podstawie, w projektowaniu komputerowych aplikacji klientów i serwerów uwzględnia się jednoczesną implementację trzech specyfikacji: dostępu do danych DA (ang. Data Access), dostępu do alarmów i warunków A&C (ang. Alarms&Events) oraz dostępu do danych archiwalnych HA (ang. Historical Access). Oznacza to stosowanie tylko jednej aplikacji, zamiast trzech zbudowanych w klasycznym ujęciu technologii OPC. Serwer OPC zaprojektowany w oparciu o technologię Unified Architecture definiuje swoim klientom zestaw usług, jakie oferuje oraz format danych procesowych za pośrednictwem, którego ma odbywać się komunikacja. Z powodu zastosowania protokołu SOAP (ang. Simple Object Access Protocol) nastąpił podział wspólnego interfejsu programistycznego i sieciowego utworzonego przez Microsoft Windows, jak miało to miejsce w klasycznej technologii OPC. W technologii przesyłanie informacji odbywa się za pomocą indywidualnych interfejsów, ale posiadających standard protokołu komunikacyjnego pomiędzy klientem i serwerem. 3. ARCHITEKTURA SYSTEMU Architektura systemów modeluje klienty i serwery jako interakcyjnych partnerów. KaŜdy system moŝe zawierać wiele klientów i wiele serwerów. KaŜdy klient moŝe współdziałać jednocześnie z jednym lub większą liczbą serwerów, jak równieŝ kaŝdy serwer moŝe równocześnie być w interakcji z jednym lub większą liczbą klientów (Rys. 3). Aplikacja moŝe łączyć komponenty serwera i klienta w celu umoŝliwienia wykonywania połączeń komunikacyjnych z innymi serwerami i klientami [6]. OPC UA Klient Zapytanie Klienta Odpowiedź Serwera Opublikowane powiadomienia Kombinacja OPC UA Serwer i Klient Zapytanie Klienta Odpowiedź Serwera Opublikowane powiadomienia OPC UA Serwer Rys. 3. Struktura połączeń klienta i serwera technologii [6] Architektura klienta modeluje klienta końcowego, którego główne elementy oraz ich wzajemne powiązania przedstawiono na rysunku 4. Aplikacja klienta posiada kod, który implementuje funkcję klienta technologii. Korzysta z interfejsu API klienta w celu 3615

6 wysyłania i odbierania Ŝądań oraz odpowiedzi kierowanych do serwera. Wewnętrzny interfejs "API klienta " izoluje kod aplikacji klienta od stosu komunikacyjnego (ang. Communication Stack) technologii. Stos komunikacyjny konwertuje interfejs API klienta do komunikatu wiadomości i przesyła go poprzez bazową jednostkę komunikacyjną do serwera [6]. Stos ten równieŝ otrzymuje odpowiedzi i komunikaty powiadomień (ang. NotificationMessages) z podstawowej jednostki komunikacyjnej i dostarcza je do aplikacji klienta za pośrednictwem interfejsu API klienta. Klient Aplikacje Klienta Wysłanie zlecenia do wykonania usług Dostarczenie otrzymanych odpowiedzi usług Wysłanie zlecenia o Ŝądania publikacyjne Dostarczenie otrzymanych odpowiedzi powiadomień API Klienta Stos komunikacyjny Req Msg Rsp Msg Publ Msg Notif Msg Do Serwera Z Serwera Do Serwera Z Serwera Rys. 4. Architektura typowego klienta ; Req Msg (ang. Request Messages) - Komunikaty Zapytań; Rsp Msg (ang. Response Messages) - Komunikaty Odpowiedzi; Publ Msg (ang. Publishing Messages) - Komunikaty Publikacyjne; Notif Msg (ang. Notification Messages) - Komunikaty Powiadomień [6] Serwer Aplikacja Serwera Rzeczywiste obiekty Przestrzeń Adresowa Widok Monitorowane dane Subskrypcje API Serwera Stos komunikacyjny Req Msg Rsp Msg Publ Msg Notif Msg Do Klienta Z Klienta Do Klienta Z Klienta Rys. 5. Architektura serwera ; Req Msg (ang. Request Messages) - Komunikaty Zapytań; Rsp Msg (ang. Response Messages) - Komunikaty Odpowiedzi; Publ Msg (ang. Publishing Messages) - Komunikaty Publikacyjne; Notif Msg (ang. Notification Messages) - Komunikaty Powiadomień [6] 3616

7 Architekturę serwera ilustruje rysunek 5, w którym pokazano główne elementy serwera i relacje pomiędzy nimi. Rzeczywiste obiekty (ang. Real Objects) są obiektami fizycznymi lub obiektami oprogramowania, które są dostępne przez aplikacje serwera lub są to obiekty stanowiące wewnętrzną budowę serwera. Aplikacja serwera korzysta z API serwera do wysyłania i odbierania wiadomości od klientów. API Serwera jest wewnętrznym interfejsem, izolującym kod aplikacji serwera od stosu komunikacyjnego (ang. Communication Stack). Przestrzeń Adresowa jest modelowana jako zbiór węzłów dostępnych dla klientów uŝywających serwisów technologii (interfejsy i metody). Węzły (ang. Node) są uŝywane do reprezentowania rzeczywistych obiektów, ich definicji oraz określają ich wzajemne referencje. Zastosowanie referencji umoŝliwia zorganizowanie Przestrzeni Adresowej w hierarchię do pełnej lub nieuporządkowanej siatki węzłów. Widoki (ang. View) są podzbiorami Przestrzeni Adresowej. Są one uŝywane do redukcji liczby węzłów i ich referencji, widocznych dla klienta, ograniczając w ten sposób wielkość Przestrzeni Adresowej. Domyślnym widokiem jest cała Przestrzeń Adresowa, jednakŝe serwery mogą opcjonalnie zdefiniować dowolnie inne widoki. Widoki często posiadają strukturę hierarchiczną w formie drzewa, gdyŝ są łatwiejsze w nawigacji dla klientów [6]. Przestrzeń Adresowa wspiera modele informacyjne poprzez następujące regulacje [6]: a) referencje węzła, które umoŝliwiają obiektom być we wzajemnej relacji, b) typ obiektów węzłów dostarczających informacji semantycznych do rzeczywistych obiektów (definicje typu), c) typ obiektów węzłów wspierające podklasy definicji typu, d) definicje typów danych ujawnianych w Przestrzeni Adresowej, które umoŝliwiają stosowanie specyficznych w przemyśle typów danych, e) standardy towarzyszące, które pozwalają grupom branŝowym na definicje własnych modelów informacyjnych, reprezentowanych w Przestrzeni Adresowej serwera. Monitorowane dane (ang. Monitored Item) są elementami serwera utworzonymi przez klienta, który monitoruje węzły Przestrzeni Adresowej i ich odpowiedniki w trybie czasu rzeczywistego. W przypadku wykrycia zmiany wartości danych lub wystąpienia zdarzenia, bądź alarmu, generują one powiadomienie do klienta poprzez Subskrypcje (ang. Subscription). Subskrypcja jest punktem końcowym w serwerze, która publikuje powiadomienia do klientów, z częstością ustalaną przez klientów [6]. WNIOSKI Komputerowe systemy automatyki przemysłowej stanowią część ogólnej infrastruktury procesów logistycznych, które obejmują budynki magazynowe, środki transportu, maszyny, urządzenia itp. W tego typu systemie stosuje się róŝne systemy informacyjne, które odgrywają duŝą rolę nie tylko przy przetwarzaniu ogromnej liczby informacji, ale równieŝ przy jej przesyłaniu. Przy budowie systemu informatycznego moŝna implementować róŝne technologie komunikacyjne, jednakŝe uŝywanie standardów pozwala na prostą integrację wielu aplikacji komputerowych w jeden transparentny system nadzorujący pracą przedsiębiorstwa. Jednym z takich standardów jest technologia OPC, która od niedawna rozwinęła swoje moŝliwości komunikacyjne przyczyniając się do powstania technologii OPC Unified Architecture. W artykule przedstawiono charakterystyczne cechy technologii, które fundacja OPC w przemyślany sposób nadała właściwy kierunek w budowie aplikacji komputerowych pracujących jako klient i serwer. Kierunek ten odzwierciedlono w specyfikacjach, aby producenci i dostawcy oprogramowania mogli dopasowywać się do ustalonych reguł wywoływania usług sieciowych, do których przede wszystkim naleŝy wydawanie rozkazów sterujących oraz akwizycja danych procesowych pochodzących z róŝnych źródeł logistycznego magazynu informacji. Wspomniane specyfikacje precyzują model informacji, model wiadomości do współdziałania pomiędzy aplikacjami, model komunikacyjny oraz model zgodności do celów zagwarantowania interoperacyjności systemów. Modele te mają za zadanie sprzyjać uniwersalności działania systemu 3617

8 komputerowego, aby przygotować go do moŝliwie wielu wyszukanych moŝliwości spełniających wymagania klientów. Pewną część artykułu poświęcono architekturze klienta i serwera systemu bazującego na technologii. W tego typie budowie charakterystyczne są pewne warstwy, które obejmują interfejsy API do zbioru funkcji składających się działanie kanałów komunikacyjnych klienta i serwera pracujących na róŝnych platformach. Zaprezentowano równieŝ strukturę hierarchii danych procesowych oraz subskrypcji, za pomocą których moŝna cyklicznie realizować róŝne zlecenia. Przedstawiony model wykonywania usług sieciowych, dedykowanych do systemów automatyki przemysłowej, sprzyja równieŝ tendencjom rozwojowym ogólnie przyjętych złoŝonych modelów informatycznych systemów przedsiębiorstwa. Streszczenie Na proces zarządzania przedsiębiorstwem logistycznym składa się wiele systemów, w tym systemy komputerowe, które swym działaniem obejmują przede wszystkim przetwarzanie i przesyłanie informacji za pośrednictwem róŝnych rodzajów sieci komputerowych. Działanie to jest realizowane w formie technologii komunikacyjnej, jaką moŝe być technologia, która jest juŝ standardem stosowanym w systemach automatyki przemysłowej. W związku z tym, w niniejszym artykule przedstawiono charakterystyczne właściwości technologii, jej specyfikacje oraz skupiono się na przedstawieniu jej architektury. Specyfikacje usystematyzowano do trzynastu części, w których miedzy innymi pokazano modelowanie informacji oraz budowę klienta i serwera. W budowie tej wyszczególniono wspólne warstwy i kanały komunikacyjne oraz sposób zorganizowania danych serwera i zarządzania nimi poprzez klienty. Architecture of technology as a new communication platform in the logistics enterprise computing system Abstract In the process of managing logistics company consists a number of systems, including computer systems, that its action mainly include the processing and transmission of information via different types of networks. This activity is implemented in the form of communications technology, which can be technology, which is already standard used in industrial automation systems. Therefore, this article presents the characteristics of the technology, its specifications and focused on the presentation of its architecture. Specifications systematized into thirteen parts, which among other things shows information modeling and construction of the client and server. In this construction specified common layers and channels of communication and a way to organize data in the server and manage them via clients. BIBLIOGRAFIA 1. Horstman M., Kirtland M., DCOM Architecture, Microsoft Developer Network Iwanitz F., Lange J.: OLE for Process Control. Fundamentals, Implementation and Applications, Huthig Verlag heiderberg, RFN, Mahnke W., Leitner S.-H.: Damm M., OPC Unified Architecture, ISBN , 2009 Springer-Verlag Berlin Heidelberg. 4. Williams S., Kindel C., The Component Object Model: A technical Overview, Microsoft Developer Network Kwiecień R.: Komputerowe systemy automatyki przemysłowej, Computer systems for industrial automation, ISBN: / , Pub. Helion, Gliwice The OPC Foundation: