W poszukiwaniu złotego środka
Nie ma wątpliwości, że prawidłowy proces produkcji musi być nadzorowany przez nowoczesne systemy automatyki oraz systemy informatyczne odpowiednio zlokalizowane w warstwie procesowej i biznesowej. To jednak często już nie wystarcza. Dalsze zwiększanie efektywności wytwarzania wymaga integracji wymienionych systemów.
Ze względu na dużą złożoność współczesne systemy automatyki przemysłowej wymagają odpowiedniej dystrybucji zadań do rozproszonych podsystemów współpracujących z sobą. Niezależnie od struktury, która silnie związana jest z kulturą organizacyjną przedsiębiorstwa, rodzaju procesu i postawionej funkcji celu, komponenty tworzące system muszą się wzajemnie komunikować. Komunikacja ma za zadanie: wymianę danych potrzebnych do analizy stanu produkcji, planowania działań operacyjnych, wyznaczenia odpowiednich sterowań i synchronizacji zdarzeń występujących w całym procesie.
Budowanie systemów współdziałających z pewnym procesem fizycznym oznacza, że realizowane przez nie algorytmy ? a w tym komunikacja ? muszą uwzględniać fakt, że zjawiska fizyczne procesu przebiegają w czasie rzeczywistym. W systemach czasu rzeczywistego poprawność programu zależy również od występujących w nim i otoczeniu uzależnień czasowych. Konsekwencją jest konieczność uwzględnienia pojęcia czasu do budowy algorytmu działania systemu. Algorytmy tworzą programiści pod dyktando architektów z uwzględnieniem zaleceń technologów. Czy zatem użytkownik ? przykładowo operator ? musi mieć świadomość zależności algorytmów od czasu?
Zagadnienie nie jest banalne i zasługuje na osobny artykuł, ale odpowiedź jest jednoznaczna: tak. Albowiem algorytmy mają parametry, którymi użytkownik dostraja zachowanie systemu do aktualnych potrzeb otoczenia.
Trzy klasy podstawowe
W dziedzinie sterowania procesami podział systemów informatycznych w przedsiębiorstwie na tzw. klasy przebiega zwykle w zależności od funkcji, jaką realizują (patrz: rysunek 1). Na potrzeby artykułu można ten podział jeszcze bardziej uogólnić, grupując klasy systemów w trzy warstwy ? biznesową, operacyjną i produkcyjną (procesową). W warstwie biznesowej znajdują sięsystemy wspomagające zarządzanie przedsiębiorstwem, a więc: zasobami, relacjami z klientem, łańcuchem dostaw, produktami i in. Głównym zadaniem tych systemów jest: wykonywanie analiz, wspieranie decyzji biznesowych, parametryzacja procesu, administrowanie infrastrukturą oraz pomoc w planowaniu działań operacyjnych. Tu często stosuje się systemy klasyfikujące się do jednej z następujących grup: ERP (ang. Enterprise Resource Planning), SAP (ang. Systems Analysis and Product), CRM (ang. Customer Relationship Management), SCM (ang. Supply Chain Management), PLM (ang. Product Lifecycle Management), GIS (ang. Geographical Information System).
Z kolei warstwa operacyjna odpowiada za wykonanie planów operacyjnych. Proces technologiczny (produkcja) jest postrzegany jako pewna całość złożona z procesów składowych. Tę warstwę tworzą wszelkiego typu systemy wizualizacji i nadzoru produkcji. Ich głównym zadaniem jest zarządzanie procesem technologicznym. Naturalnie warstwa operacyjna jest bardzo często łącznikiem (pośrednikiem) w przetwarzaniu danych z produkcji do warstwy biznesowej. Tu często stosuje się systemy klasyfikujące się do jednej z następujących grup: MES (ang. Manufacturing Execution Systems), SCADA (ang. Supervisory Control And Data Acquisition) oraz HMI (ang. Human Machine Interface).
Warstwa produkcyjna (procesowa) to właściwie archipelag złożony z autonomicznych wysp systemów automatyki, odpowiedzialnych za bezpośrednie sterowanie urządzeniami produkcyjnymi. Innymi słowy, jest to zbiór urządzeń bezpośrednio przetwarzających fizyczne sygnały opisujące stan procesu i generujących sygnały sterujące, kontrolujące lokalnie jego przebieg. Głównym zadaniem systemów tej warstwy jest zapewnienie bezpiecznego przebiegu procesu technologicznego i realizacja poleceń warstwy operacyjnej. Typowym przedstawicielem systemów tej warstwy są sterowniki PLC (ang. Programmable Logic Controller) oraz systemy DCS (ang. Distributed Control System).
Kwestia czasu
Nie zawsze wszystkie warstwy są dobrze zdefiniowane z wyraźnie zaznaczonymi granicami kompetencyjnymi. Natomiast zawsze występuje potrzeba komunikacji z warstwą procesową. Często zamiast używać terminu komunikacja, mówi się o integrowaniu systemów. Po prostu z faktu, że dane zostaną poprawnie przeniesione z umownego punktu A do punktu B, nie wynika umiejętność przetworzenia ich w punkcie B. Innymi słowy komunikacja jest jedynie warunkiem koniecznym integracji. Warto również zwrócić uwagę, że do tej pory pod pojęciem integracji systemów bardzo częstorozumiano ujednolicanie procedur i procesów zachodzących wyłącznie w warstwie biznesowej.
Komunikacja i integracja nie są nowymi pojęciami, ale połączenie komunikacji, integracji i czasu rzeczywistego tworzy nową dziedzinę, która rodzi całkowicie nową jakość w zakresie optymalizacji procesów wytwarzania. Tak rozumiana integracja prowadzi do nowych możliwości w zarządzaniu przedsiębiorstwem, ale jednocześnie stanowi duże wyzwanie. Aby mu sprostać, potrzebujemy nowych narzędzi i metod postępowania. W artykule omówiono standard OPC, który dobrze sprawdził się już w aplikacjach należących do omawianej klasy zastosowań. Wiele wskazuje na to, że jego rola w tym zakresie będzie rosła.
OPC ? interfejs procesu
Warstwa produkcyjna stanowi źródło danych dla procesów zarządzania. Zbudowana jest z różnorodnych urządzeń, które udostępniają dane w różnych protokołach (językach). Każdy protokół to: składnia, semantyka, uzależnienia czasowe, przestrzeń adresowa, medium komunikacyjne.
Aby dwa urządzenia mogły z sobą współpracować, muszą używać jednego protokołu, określającego jednoznacznie wszystkie powyższe elementy. Często używa się (a często nadużywa) sformułowania: muszą używać jednego standardu, gdzie standard jest magicznym wytrychem gwarantującym sukces w procesie integracji. Jednak często stan faktyczny weryfikuje dopiero praktyka. Tak jak w życiu nie zawsze dwóch ludzi rozmawiających tym samym językiem jest się w stanie ?dogadać?. Dodatkową trudnością jest to, że znamy setki owych standardów. Niezależnie od tego, co dokładnie rozumiemy pod słowem standard.
Mamy zatem różnorodność standardów połączoną z różnorodnością rozwiązań proponowanych przez poszczególnych producentów (patrz: rysunek 2). Z punktu widzenia możliwości dopasowania rozwiązań do naszych ? zawsze przecież indywidualnych ? potrzeb wydaje się to dobrą nowiną. Pod warunkiem, że łącząc elementy, stosujemy wyłącznie rozwiązania jednego producenta. Z punktu widzenia większych systemów różnorodność bywa niestety zaporą nie do przebycia. Co najmniej z dwóch powodów:
- prowadzi do rozwiązań ?totalitarnych? i dyktatu producenta ze wszystkimi tego konsekwencjami (bariera biznesowa i prawna),
- jest funkcjonalnie ograniczona do oferty wybranego producenta ? (bariera rozwoju i otwartości).
Architekci systemów przemysłowych od początku ery komunikacji i sterowania cyfrowego próbują znaleźć rozwiązanie pozwalające obejść te bariery. Zarząd General Motors na początku lat dziewięćdziesiątych policzył, że koszty integracji dla jednej z nowych linii montażowych przekroczyły koszty wyposażenia. A zatem kolejną istotną kwestią są pieniądze. Upraszczając nieco, można stwierdzić, że architekci próbują znaleźć rozwiązanie na dwa znane sposoby: metodą ?z góry na dół? (ang. top-down) lub metodą ?z dołu do góry? (ang. bottom-up).
Przykładem pierwszej był projekt Manufacturing Automation Protocol (MAP), w którym pod przywództwem GM grupa producentów z różnych branż próbowała zdefiniować protokół na bazie istniejących i często tworzonych dopiero norm ISO. Projekt zakończył się całkowitą porażką. Przykładem drugiej metody jest projekt OPC, który bazuje na bardzo prostym spostrzeżeniu. Otóż postawiony powyżej problem wydaje się bardzo podobny do problemu komunikacji z urządzeniami peryferyjnymi w systemie operacyjnym DOS. Program aplikacyjny mógł skorzystać z drukarki, jeśli miał do niej własny drajwer komunikacyjny. W nowszych systemach po prostu wbudowano funkcję drukowania do interfejsu systemu operacyjnego (ang. Application Programming Interface). Poza tym umożliwiono dodawanie do systemu nowych komponentów, które wspierają ten interfejs. W kolejnej generacji systemów operacyjnych pojawiła się nowa możliwość samodzielnego rozszerzania API systemu operacyjnego. Każdy mógł instalować własne komponenty, które publikują interfejs jako pewną ofertę swojej funkcjonalności i implementują tę funkcjonalność. Innymi słowami w rozważanym przypadku ? nie oglądając się na producenta systemu operacyjnego ? możemy sami rozszerzyć jego funkcjonalność o ?drajwer do procesu technologicznego? (patrz: rysunek 3).
Plusy i minusy
Wydawało się, że powyższa koncepcja ma dwie istotne zalety i jedną wadę. Pierwszą zaletą jest relatywnie łatwiejsza implementacja. Taki komponent jest jedynie kawałkiem wielkiego puzzla, a nie ? jak MAP ? tysiącem kawałeczków, z których dodatkowo można było ułożyć kilka różnych obrazków. Druga zaleta to architektura klient ? serwer umożliwiająca komunikację z urządzeniem procesowym wielu klientów jednocześnie. A to jest niemożliwe w przypadku większości oferowanych protokołów komunikacyjnych. Z kolei podstawową wadą rozwiązania jest uzależnienie od systemu operacyjnego. Pojawiła się konieczność wyboru, a następnie trwania w nim ? na dobre i złe ? w przyszłości. Przetarg wygrał bez trudu Microsoft Windows. Ta wada szybko okazała się motorem sukcesu ? ze względu na popularność systemu. Rezultat: kilkanaście tysięcy oficjalnych implementacji OPC oferowanych przez ponad 450 firm zrzeszonych w organizacji OPC Foundation (w tym jedna z Polski). Oczywiście, żeby implementować i używać OPC nie trzeba być członkiem żadnej organizacji. A zatem wymienione liczby nie oddają w żadnej mierze skali popularności tego interfejsu.
W tym miejscu chciałbym rozwiać dwa mity. Specyfikacja OPC ? dostępna wyłącznie dla członków organizacji ? to zestaw dokumentów dedykowanych wyłącznie dla programistów implementujących OPC. Jej znajomość nie jest potrzebna użytkownikowi do pełnego korzystania z produktów wspierających OPC. Ponadto, z uwagi na szczegółowość sięgającą znaczenia poszczególnych bitów i hermetyczność języka, w jakim została napisana, próba wykorzystania jej w roli podręcznika dla użytkownika OPC nie jest zalecana. Drugi mit to fakt, że paradoksalnie OPC nie jest protokołem komunikacyjnym. W efekcie każda dyskusja o wyższości innych protokołów komunikacyjnych nad OPC i odwrotnie staje się bezpodstawna.
Okazuje się, że OPC to zupełnie nowa jakość, która daleko odbiegła od oczekiwań twórców. Przykładem jest platforma integracyjna, niezbędna do wdrożenia systemu optymalizacji pracy trzech elektrociepłowni o łącznej mocy cieplnej 2,5 GW, zasilających łódzki system ciepłowniczy. Platforma służy do zarządzania infrastrukturą komunikacyjną utworzoną z dwóch systemów radiowych i kilku rozległych segmentów światłowodowych. Jedynie dzięki tak rozbudowanej infrastrukturze i centralnemu zarządzaniu możliwe było zapewnienie odpowiednio bezpiecznej komunikacji pomiędzy urządzeniami procesowymi oraz systemami zarządzania procesem i przedsiębiorstwem.
Co to jest OPC?
Skoro OPC nie jest ani protokołem komunikacyjnym, ani drajwerem, to czym jest? I co trzeba wiedzieć, aby skutecznie planować wdrożenie i wykorzystywać OPC? Próbę odpowiedzi na powyższe pytania warto zacząć od rozszyfrowania skrótu OPC. Otóż dziś? nie oznacza nic. To nazwa własna. Pierwotnie oznaczał OLE for Process Control, ale od kiedy technologia OLE nie jest wspierana przez Microsoft, takie znaczenie skrótu nie ma sensu. Z przedstawionej powyżej koncepcji wynika, że konkretna implementacja, tzn. produkt implementujący serwer OPC, to dwa w jednym (patrz: rysunek 4). A zatem komponent (program) realizujący funkcjonalność opisaną w specyfikacjach OPC oraz implementacja wybranego protokołu komunikacyjnego. Z punktu widzenia specyfikacji OPC najistotniejsze są również dwa, ale zupełnie inne elementy: interfejs OPC i środowisko, w którym ten interfejs zostanie opublikowany (udostępniony).
Interfejs to formalna definicja zbioru metod i struktur danych oferowanych przez komponent. Dodatkowo jest to definicja abstrakcyjna, bo oderwana od konkretnej implementacji. Innymi słowy, interfejs jest rodzajem instrukcji obsługi komponentu. To informacja dla klienta (też pewien program), jak ma go używać i dla programisty co (ale nie jak) ma zaimplementować. Opublikowanie oznacza udostępnienie samej definicji i umożliwienie wykorzystania oferowanej funkcjonalności. Dlatego często używa się skrótu myślowego ? komponent OPC jest dostępny wyłącznie za pośrednictwem interfejsu OPC. Oczywiście nie można używać pralki za pośrednictwem jej instrukcji obsługi. W tym celu potrzebujemy gałek, przycisków, wtyczek, wyświetlaczy itd. W przypadku korzystania z komponentu ich rolę spełniają funkcje oferowane przez system operacyjny. Te funkcje stanowią pewną wydzieloną część systemu operacyjnego, do której też zdefiniowano pewien interfejs zgodny z opracowanym modelem swobodnego publikowania i wykorzystywania komponentów COM (ang. Component Object Model). Ponieważ mechanizm ten ma zastosowanie wyłącznie lokalne, tzn. komponenty mogą być wykorzystywane tylko przez aplikacje uruchomione na tym samym komputerze, w następnym kroku rozszerzono go o dostęp zdalny. Tak powstał DCOM (ang. Distributed Component Object Model).
Publicznie dostępne dokumenty na temat DCOM opisują ? podobnie jak w przypadku OPC ? co ten model oferuje. Nie ma mowy o tym, w jaki sposób zaimplementowano oferowaną funkcjonalność. Ponieważ trudno jest zbudować pralkę na podstawie instrukcji obsługi, przenoszenie tej funkcjonalności na inne platformy systemowe jest bardzo utrudnione. Świadoma tego zagrożenia OPC Foundation zaczęła prace nad rozwiązaniem alternatywnym. Przedstawiciele organizacji przekonują, że nie chodzi o ścieżkę ewakuacyjną, tylko całkowicie nową jakość. Ma powstać rozwiązanie zbudowane z uwzględnieniem dotychczas zebranych doświadczeń. Projekt otrzymał nazwę OPC Unified Architecture (OPC UA). Tym razem zrezygnowano z osadzania definiowanej funkcjonalności w ramach konkretnej platformy systemowej. Zamiast tego przyjęto, że podstawą będzie zbiór norm bazujących na języku znacznikowym XML oraz opracowanych przez konsorcjum W3C. Normy te powszechnie oznaczane są symbolem WS-*. Ponieważ standardy WS-* tworzone są bez wstępnego założenia co do platformy systemowej, na której będą implementowane, muszą precyzować, co finalnie ma znaleźć się w umownym ?drucie?. Powrócono więc do koncepcji tworzenia protokołu.
Choć wybór platformy systemowej zostawiono dostawcom oprogramowania, tym razem optymizm twórców opiera się na ogromnej popularności, jaką cieszą się wymienione specyfikacje. Wymiernym tego dowodem jest duża liczba ich implementacji. Dodatkowo implementacje te powstają dla platform wirtualnych, a więc przynajmniej teoretycznie łatwo przenośnych. Natomiast pewnym niepokojącym faktem jest to, że prace w ramach projektu wciąż trwają, a termin ich zakończenia ciągle oddala się.
MODBUS bez szans
Jak wspomniano, OPC UA to protokół. Nie ma więc żadnych formalnych przeszkód, aby porównywać go z innymi protokołami, które są od lat znane i masowo stosowane w automatyce. I tu mamy kolejny powód do pewnego zaniepokojenia. Mianowicie, stosując dobrze znany, powstały w początkach ery sterowania cyfrowego protokół MODBUS do przesłania jednego bitu reprezentującego pewną wielkość procesową (np. stan przekaźnika), potrzebujemy przesłać przez umowny ?drut? strumień kilku bajtów. Trudno policzyć, ile potrzeba w przypadku OPC UA, ponieważ zanim prześlemy bit, musimy najpierw wymienić się podpisanymi cyfrowo certyfikatami, angażując w to infrastrukturę klucza publicznego (ang. Public Key Infrastructure). Jednak kto w dobiezintegrowanego zarządzania procesem i przedsiębiorstwem przesyła tak proste informacje? Niezależnie od tego wydaje się, że pomysł budowy zintegrowanego zarządzania na bazie protokołów klasy MODBUS jest pozbawiony jakiegokolwiek sensu, o ile w ogóle realizowalny.
Reasumując, OPC to definicja zbioru interfejsów pogrupowanych na kategorie przy wymogu osadzenia określonej nimi funkcjonalności w technologii DCOM. Podobnie, OPC UA jest zestawem interfejsów oraz definicją sposobu udostępnienia określonej nimi funkcjonalności w postaci usług za pośrednictwem protokołu komunikacyjnego, bazującego na standardach z grupy WS-*. W obu przypadkach, niezależnie od istotnych różnic koncepcyjnych, używa się skrótowego określenia ?technologia OPC? do określenia wszystkich przedstawionych powyżej uwarunkowań. W obu przypadkach cel jest taki sam. Chodzi o stworzenie ujednoliconego mechanizmu swobodnego dostępu do danych znajdujących się w urządzeniach odpowiedzialnych za odczyt i generowanie sygnałów określających stan pewnego procesu technologicznego. Jego realizacja pozwala w pełni uniezależnić oprogramowanie wyższych warstw od producentów sprzętu i otwiera drogę do budowy systemów otwartych.
Platforma DCOM
OPC wymaga platformy DCOM zarówno po stronie klienta, jak i serwera. Teoretycznie istnienie DCOM dla użytkownika technologii OPC powinno być przezroczyste, podobnie jak dla użytkownika arkusza kalkulacyjnego istnienie systemu operacyjnego. Tak jednak nie jest. Do wyjaśnienia konieczne jest doprecyzowanie definicji komponentu, którym jest każdy serwer OPC. Aby komponent mógł być wykorzystany, musi zostać zainstalowany. Instalacja to proces automatyczny, przebiegający bez ingerencji użytkownika. W jego wyniku komponent, a właściwie potrzebna informacja o nim, jest umieszczana w usłudze katalogowej DCOM. W tym stanie komponent pełni rolę biblioteki i jest całkowicie pasywny. Nie zajmuje czasu procesora i miejsca w pamięci operacyjnej, a jedynie jego kod umieszczany jest na dysku twardym.
Z punktu widzenia użytkownika bardzo istotnym momentem jest chwila, w której pierwszy klient próbuje wykorzystać komponent, ponieważ wcześniej kod komponentu musi zostać załadowany do pamięci i otrzymać zarezerwowaną dla jego potrzeb pewną przestrzeń roboczą. W efekcie tworzony jest obiekt, który oprócz kodu i przydzielonej mu pamięci ma jeszcze jedną kluczową cechę, a mianowicie tożsamość. Oznacza to, że komponent tak samo, jak zwykły interaktywny użytkownik, musi mieć przypisane do niego konto systemowe. Ma to umożliwić autoryzację wykonywanych przez niego operacji. Sposób, w jaki komponent i tworzone obiekty uzyskują tożsamość, zależy od konfiguracji, czyli użytkownika. Użytkownik (używając programu narzędziowego dcomcnfg.exe), oprócz sposobu określania tożsamości, czyli konta wykorzystywanego przez tworzone obiekty, ma jeszcze wpływ na to, kto ma prawo do ładowania, korzystania z jego metod i konfiguracji uprawnień komponentu. W efekcie daje to spory poziom komplikacji i często jest bardzo kłopotliwe, nawet dla zaawansowanych administratorów. A to nie koniec kłopotów, ponieważ ? zgodnie ze specyfikacją ? po zainicjowaniu obiekt serwera tworzy pewien nowy obiekt przeznaczony do obsługi jego żądania zakończenia sesji, tym razem po stronie klienta (patrz: Błąd! Nie można odnaleźć źródła odwołania).
Z doświadczenia wiem, że rozwiązywanie tych problemów może trwać od pojedynczych minut nawet do kilku dni. Dlatego przy uruchamianiu instalacji warto mieć zagwarantowane wsparcie odpowiedniego specjalisty. Ponadto, ze względu na wzajemnie symetryczną komunikację (tworzenie obiektów po obu stronach), nie można stosować półprzezroczystych zapór ogniowych (ang. firewall) na drodze pomiędzy klientem i serwerem. Jeśli struktura sieci i polityka bezpieczeństwa zostaną starannie zaplanowane i poprawnie wdrożone, to dla użytkownika istnienie platformy DCOM staje się całkowicie ?przezroczyste?. Dowodem ?życia? serwera jest wskaźnik zajętości procesora i ewentualnie zużycia pamięci.
Specyfikacje OPC
OPC to pewien zbór interfejsów pogrupowanych w kategorie, z których każda dedykowana jest pewnej funkcjonalności. Kategoria służy również do wyróżnienia kolejnych wersji poszczególnych grup interfejsów. Każda grupa jest opisana w osobnym dokumencie ? specyfikacji, któremu nadano jednoznaczną nazwę symboliczną (np. OPC DA) i numery wersji. Niezależnie od nazw dla każdej kategorii zdefiniowany jest globalnie jednoznaczny identyfikator cyfrowy, którym posługuje się klient i serwer w fazie nawiązywania połączenia. Połączenie jest możliwe, jeśli identyfikator kategorii używany przez klienta i serwer są identyczne. O ile serwer nie wspiera kilku kategorii. Jednak nawet wtedy tworzony jest obiekt serwera tej kategorii, która została użyta przez klienta w żądaniu nawiązania połączenia.
Do najważniejszych kategorii należą:
? OPC DA (ang Data Access) ? zapewnia swobodny dostęp do aktualnych danych procesowych w czasie rzeczywistym. Za pomocą OPC DA do serwera OPC kierowane są zapytania o aktualne wartości zmiennych procesowych.
? OPC HDA (ang. Historical Data Access) ? zapewnia dostęp do ciągów danych archiwalnych, np. w celu wyznaczenia trendów, oceny przebiegu procesu w czasie itp. Klient uzyskuje dostęp do zarchiwizowanych danych (odczytów jakiegoś urządzenia itp.) poprzez zgłaszanie zapytań do serwera OPC HDA.
- OPC A&E (ang. Alarms & Events) ? umożliwia generowanie przez serwer (po stronie klienta) rodzaju przerwań informujących o występujących w procesie zdarzeniach i zgłaszanych alarmach.
- OPC Security ? pozwala dodatkowo, niezależnie od mechanizmów wbudowanych w DCOM, podnieść poziom bezpieczeństwa dostępu do danych procesowych publikowanych przez serwer OPC poprzez uwierzytelnienie i autoryzację klienta.
- OPC UA (ang. Unified Architecture) ? zbiór kilkunastu dokumentacji zawierających specyfikację dla komunikacji pomiędzy różnymi typami systemów i urządzeń, bazującą na standardach dla Internetu z grupy WS-*.
Dr inż. Mariusz Postół jest pracownikiem Samodzielnego Zakładu Sieci Komputerowych Politechniki Łódzkiej.
Autor dziękuje drowi inż. Sławomirowi Wróblewskiemu (DMCS Politechnika Łódzka) oraz mgrowi inż. Maciejowi Zbrzeznemu (CAS) za pomoc i cenne uwagi.
