Niemal wszyscy zajmujący się branżą automatyki przemysłowej są przekonani, że o architekturze systemów zorientowanej na usługi trzeba sporo mówić, prowadzić na ten temat szkolenia i jak najszerzej implementować ją do aplikacji przemysłowych. Gdy jednak dokładniej przyjrzeć się tej tematyce, okazuje się, że wielu nie wie nawet dokładnie, czym jest taka architektura, jakie są jej podstawowe założenia, jak funkcjonuje i jak wpływa na obsługę aplikacji, w których jest zastosowana.
Architektura zorientowana na usługi (z ang. SOA) nie jest w rzeczywistości ani produktem, ani technologią, ani nawet architekturą(!). SOA to pewien zbiór zasad dotyczących integracji aplikacji programowych, mających na celu minimalizację złożoności systemu oraz redukcję liczby koniecznych do obsługi zadań interfejsów pomiędzy aplikacjami. Stąd nierozłącznie towarzysząca tej idei modułowość narzędzi programowych, interfejsów i metod wsparcia obsługiwanych aplikacji.
Zasady SOA określają reguły, według których powinno się podejmować decyzje, jaki typ oprogramowania powinien wspierać określone funkcje oraz jakiego typu informacje w aplikacji powinny być wymieniane/transmitowane. W efekcie powstaje system ze wstępnie ukształtowaną architekturą typu SOA, o jasno zdefiniowanych typach interfejsów, zorientowanych na optymalną obsługę danych, zarówno dla sfery biznesowej, jak i bezpośrednio procesów ułatwiających współdziałanie tych dwóch stref organizacyjnych w zakładzie przemysłowym. Jednak w praktyce jak dotąd istnieje bardzo niewiele systemów automatyki w pełni realizujących koncepcję SOA na poziomie bezpośredniej obsługi procesów produkcyjnych. Dzieje się tak dlatego, że wiele grup automatyków i informatyków, choć niejednokrotnie korzystają już z narzędzi programowych dla systemów zorientowanych na usługi (serwery Web, zakładowe serwisowe systemy magistralowe, bramki XML, proste modele protokołów dostępu i inne), to jednak nie wdrażają w swoich zakładach zasad organizacji systemów zgodnych z koncepcją SOA. Niestety dla uzyskania pełnej funkcjonalności systemów automatyki zorientowanych na usługi konieczne jest połączenie tych dwóch elementów i ich integralna współpraca.
Praktyczne znaczenie koncepcji SOA
Kluczem do zrozumienia znaczenia i doniosłości koncepcji systemów zorientowanych na usługi jest skupienie uwagi na funkcjonowaniu usług w narzędziach programowych, niezbędnych do jej realizacji. Usługi te dzieli się na dwie podstawowe kategorie: drobne ? obsługujące małe pakiety danych, i rozszerzone ? przeznaczone do obsługi większych zbiorów danych. Takie duże pakiety/zbiory danych nazywane są obiektami biznesowymi. W projektach systemów dla aplikacji przemysłowych zwykle spotyka się kombinację obu wspomnianych kategorii usług, które mogą się pojawić zarówno w sferze biznesowej, jak i wytwórczej zakładu. Usługi rozszerzone w sferze biznesowej zakładu zwykle wykorzystuje się w takich działaniach, jak: obsługa zamówień i zakupów, wysyłanie zleceń do magazynów i działów dystrybucji, kontroli przepływu towarów itp. System SOA w tego typu aplikacjach, zwykle skomplikowanych funkcjonalnie, powinien być wyposażony w szereg interfejsów dopasowanych do możliwych akcji niezbędnych w czasie realizacji obsługiwanych procesów, tak by zoptymalizować czas i płynność takiej akcji.
Przykładowe interfejsy usług dla obsługi obiektów biznesowych to: ?wygeneruj kwit transportowy?, ?zapłać dostawcy?. ?zapłać fakturę?, ?wygeneruj zamówienie do działu transportu? itp. W sferze produkcyjnej usługi kategorii rozszerzonej realizują takie zadania, jak: obsługa terminarzy produkcyjnych, raporty produkcji, certyfikaty i analizy, generowanie raportów i wyników testów poszczególnych aplikacji itp. Przykładowe usługi to: ?wykonaj zadanie z terminarza?, ?przypisz materiały do magazynu składowania?, ?dostarcz partię materiałów na stanowisko produkcyjne? itd.
Z kolei usługidrobne to nie tyle usługi realizujące jakieś konkretne zadania, co zwykle odpytujące aplikacje i na podstawie pozyskanych informacji zarządzające realizacją zadań już przez usługi rozszerzone. Przykładem typowych funkcji realizowanych przez usługi kategorii drobnej są: ?pobierz dane o lokalizacji partii materiałów/produktów/elementów?, ?pobierz nowy numer ID partii materiału?, ?pobierz informacje o statusie maszyny, urządzenia? itp.
Jeżeli system sterowania i zarządzania ma zaaplikowane tylko funkcjonalności kategorii drobnej, bez wykorzystania zadań charakterystycznych dla kategorii rozszerzonej, nie można zaklasyfikować go jako systemu z architekturą SOA, chociażby korzystał z narzędzi programowych przeznaczonych do takich systemów. Jednym bowiem z najpowszechniejszych problemów, wynikających w trakcie realizacji systemów w oparciu o architekturę zorientowaną na usługi, jest wykorzystanie przez integratorów olbrzymiej liczby funkcji oferowanych przez usługi drobne, bez ich koordynacji z działaniami usług rozszerzonych, bez powiązania sfery produkcyjnej z biznesową.
Usługi sfery produkcyjnej powinny obejmować następujące obszary:
- zarządzaniezamówieniami,
- zarządzanie etapami produkcji,
- zarządzanie usługami serwisu i utrzymania ruchu,
- zarządzanie testami i pracami badawczymi,
- zarządzanie sprzętem i środkami produkcji,
- zarządzanie dostawami materiałów i transportem produktów,
- zarządzanie najważniejszymi danymi i parametrami produkcji,
- monitoring, obliczanie i zarządzanie współczynnikiem całkowitej wydajności maszyn i urządzeń.
Usługi te związane są z organizacją produkcji, lokalizacją maszyn i pracowników, zarządzaniem materiałami, narzędziami i personelem. Z perspektywy architektury systemowej SOA, usługi rozszerzone i obsługiwane przez nie obiekty powinny być zgodne z 95 standardowymi obiektami zapisanymi w standardach ANSI/ISA, definiującymi harmonogramy produkcji, raporty produkcji, algorytmy operacji, zasady organizacji produkcji itp.
Modele implementacyjne SOA
Systemy zorientowane na usługi funkcjonują zwykle w oparciu o dwa modele: uporządkowany i adaptacyjny. W pierwszym z nich podstawowym elementem jest usługa koordynacyjna, w której zapisano zasady organizacji i sekwencji działania pozostałych usług rozszerzonych w systemie, zaimplementowanych do obsługi sfery biznesowej zakładu przemysłowego. Z kolei usługi rozszerzone mogą uruchamiać i korzystać w miarę potrzeb z usług drobnych. W usługach koordynacyjnych zwykle stosuje się język BPEL (z ang. język realizacji procesów biznesowych), ułatwiający implementację zasad i praw biznesowych. Język BPEL to jeden ze standardów OASIS, określających zasady wzajemnej interakcji usług sieciowych Web.
Model uporządkowany izoluje procesy biznesowe w ramach warstwy koordynacyjnej, ułatwiając usługom rozszerzonym realizację klasycznych zadań sfery biznesowej. Wiele współczesnych systemów biznesowych funkcjonuje właśnie w oparciu o ten model, wprowadzający strukturę modułową i ułatwiający wielokrotne wykorzystanie usług. Nie jest to jednak model bez wad ? podstawową jest zależność schematu działania od jednej, centralnej usługi, co czasami może wywoływać niewielkie opóźnienia w realizacji zadań itp. Są one jednak zwykle niewielkie i nie mają większego wpływu na funkcjonowanie z reguły dość powolnych procesów czy zadań biznesowych. Jeżeli w systemie czas rzeczywisty jest mierzony w minutach, wspomniane opóźnienia mogą mieć znaczenie tylko w przypadku konieczności obsługi kilku setek wiadomości i pakietów danych w czasie pojedynczych minut.
Model adaptacyjny różni się od uporządkowanego przede wszystkim tym, że nie ma w nim wyróżnionej jednej nadrzędnej usługi koordynacyjnej. Usługi rozszerzone z poziomu biznesowego mają pewną autonomię i w zależności od potrzeb mogą niezależnie uruchamiać usługi niższego poziomu. Procesy sfery biznesowej zdefiniowane są w tym modelu jako zbiór zasad i działań, zaimplementowanych w ramach kilku usług rozszerzonych. Model adaptacyjny ma zdolność szybszej obsługi prostszych procesów obróbki i transmisji danych, dlatego też częściej stosuje się go w aplikacjach produkcyjnych, wykonawczych i interfejsach klienta w sieci Internet. Oba wspomniane obszary zastosowań wymagają szybkiej obsługi setek, a nawet tysięcy niewielkich pakietów danych w ciągu minuty, przy praktycznie zerowych opóźnieniach.
Specyfikacja i narzędzia
Architektura systemów zorientowanych na usługi ? SOA, opiera się na sześciu podstawowych zasadach:
- Aplikacje są luźno ze sobą powiązane. Oznacza to, że dostęp do jednego systemu nie wpływa znacząco na pracę drugiego systemu, a implementacja usług jest ukryta dla aplikacji zgłaszającej zadanie do realizacji.
- Zadania obsługiwane na interfejsach są niezależne. Interfejsy nie przechowują danych historycznych o wcześniej obsługiwanych zadaniach i realizują swe bieżące zadania tylko w oparciu o aktualnie wymieniane z innymi modułami dane, nie korzystając z żadnych dodatkowych, ukrytych informacji historycznych lub dostarczonych przez np. operatorów.
- Interfejsy pracują w trybie modelu RPC (z ang. zdalne wywoływanie procedur). Model ten determinuje postrzeganie interfejsu jako swego rodzaju lokalnej funkcji czy podprogramu, wywoływanych z poziomu innego programu lub aplikacji, bez dodatkowych informacji o protokole komunikacji czy typie transmitowanych danych.
- Interfejsy bazujące na wiadomościach. Interfejsy tego typu przekazują wiadomości pomiędzy aplikacjami, korzystając z ogólnozakładowej magistrali komunikacyjnej. Magistrala ta zapewnia podstawowe usługi wymiany danych dla systemów o rozbudowanej architekturze, dzięki zaaplikowanemu mechanizmowi obsługi zdarzeń i standardowych wiadomości.
- Wiadomości zawierają dane w formacie XML. Nie stosuje się tu plików typu flat czy specjalnych, dedykowanych interfejsów binarnych.
- Interfejsy mogą obsługiwać dwa typy transmisji ? synchroniczny i asynchroniczny. Usługi mogą być realizowane w trybie synchronicznym, tzn. generowane jest zapytanie i następnie oczekiwana jest odpowiedź. Alternatywnym rozwiązaniem jest komunikacja asynchroniczna, gdzie aplikacja generuje zapytanie i nie czekając na odpowiedź, realizuje kolejne zadania, a odpowiedź przychodzi później.
Wspomniane zasady systemów SOA są zawsze podkreślane w specyfikacjach tej architektury i narzędziach przeznaczonych do współpracy z nimi. Specyfikacje SOA podają definicję luźno związanych procesów sfery biznesowej i produkcyjnej, usług implementowanych w procesach, obiektów zawierających informacje o usługach i transakcji, określających zasady koordynacji usług i obiektów. Narzędzia SOA to z kolei aplikacje i usługi aplikacyjne implementujące zadania sfery biznesowej, standardowe wiadomości reprezentujące obiekty sfery biznesowej i wreszcie usługi integracyjne z implementacją niezbędnych w systemie transakcji.
Systemy o architekturze SOA będą mieć większy wpływ na funkcjonowanie sfery produkcyjnej w zakładach przemysłowych tylko wtedy, gdy coraz powszechniejsze będzie ich zastosowanie w wewnętrznych i zewnętrznych aplikacjach przyłączanych do systemów. W ten sposób systemy operacyjne i automatyki będą musiały pracować zgodnie z architekturą zorientowaną na usługi, tak by możliwa była koordynacja i współpraca z innymi aplikacjami zorientowanymi na ten rodzaj architektury. Oznacza to, że aplikacje sterowania będą musiały udostępniać funkcje biznesowe w formie luźno powiązanych usług rozszerzonych oraz pozwolić na dostęp do swoich danych jako usług drobnych, funkcjonujących w trybie synchronicznym. Na przykład ? usługą rozszerzoną może być komenda z systemu MES dla automatycznie sterowanego pojazdu, zlecająca przeniesienie materiału z magazynu do linii produkcyjnej, zaś usługą drobną zapytanie o numer z kodu paskowego umieszczonego na palecie z tym materiałem.
Wdrożenie zasad architektury SOA przyczyni się do uproszczenia systemów obsługi produkcji, ponieważ bazują one na najlepszych doświadczeniach i wypracowanym modelu luźnego powiązania usług sfery biznesowej i produkcyjnej, niezbędnych w realizacji zadań. Ponadto zasady te są spójne z najlepszymi metodami zapewnienia wysokiego bezpieczeństwa produkcji. Warto zatem już dziś zainteresować się rozwojem i możliwościami adaptacyjnymi tej architektury systemowej w swoich zakładach, jej wdrożeniami w jak największej liczbie aplikacji i narzędzi obsługi procesów produkcji i sfery biznesowej.
Artykuł pod redakcją dr. inż. Andrzeja Ożadowicza, AGH Kraków