TABLE OF CONTENTS:
Uniwersalne standardy komunikacji to przyszłość inżynierii, a wśród nich znajduje się jeden, na który wyjątkowo warto zwrócić uwagę – protokół OPC UA (zwany także OPC Unified architecture). Co trzeba o nim wiedzieć? Czy koniecznie musisz zapoznać się z opasłą dokumentacją, zanim zaczniesz z niego korzystać?
Maszyny i systemy informatyczne czy przemysłowe, podobnie jak ludzie, muszą się komunikować. Jeśli rozmowa toczy się między dwiema osobami, które mówią różnymi językami, to koszt takiej komunikacji jest wyższy ze względu na potrzebę zatrudnienia tłumacza. Analogicznie sytuacja wygląda, jeśli chodzi o komunikację systemów informatycznych i przemysłowych, gdy obsługują one inne protokoły komunikacyjne.
W takim przypadku koszt wymiany informacji pomiędzy nimi jest wyższy, ponieważ niezbędny jest dodatkowy mechanizm, który przełoży informacje wysyłane przez jeden z systemów, na format zrozumiały dla drugiego. W celu uniknięcia takich sytuacji, nowoczesne sterowniki czy systemy wykorzystują uniwersalne standardy komunikacji.
Jeden z takich uniwersalnych standardów jest przedmiotem niniejszego artykułu – protokół OPC UA (ang. Open Platform Communications Unified Architecture), opracowany i ciągle usprawniany przez OPC Foundation[1]. Specyfikacja protokołu jest dość obszerna – spisana w dwudziestu trzech częściach w dużych plikach pdf, co na początek może wydawać się przytłaczające.
Jednak dla chcącego nic trudnego – ja przeszedłem tę ścieżkę, więc podzielę się najważniejszymi elementami pozwalającymi zrozumieć koncepcję rozwiązania, a przy okazji wskażę kilka aspektów, o których warto byłoby pomyśleć, dodając wsparcie dla standardu OPC UA do nowo projektowanych lub istniejących już systemów.
OPC Unified Architecture to uniwersalny standard komunikacji, którego celem jest ujednolicenie sposobu wymiany danych pomiędzy maszynami, sterownikami, urządzeniami IoT, czy aplikacjami do monitoringu. Protokół definiuje architekturę klient-serwer i jest następcą istniejących wcześniej protokołów określanych zbiorczo jako OPC classic. OPC UA integruje funkcjonalności protokołów wchodzących w skład OPC classic i dodatkowo czyni je niezależnymi od konkretnego systemu operacyjnego czy platformy sprzętowej. Serwer OPC UA z powodzeniem może zostać wdrożony na komputerach przemysłowych, mini komputerach SBC (ang. Single Board Computer) czy na mikrokontrolerach. Jednym z zastosowań standardu jest integracja wielu systemów, często dostarczanych przez różnych producentów, w jednym panelu operatorskim co przedstawiono na rysunku 1.
Innym ciekawym zastosowaniem standardu OPC UA jest udostępnienie, w uniwersalny i ustandaryzowany sposób, stanu systemu IoT, który wewnętrznie komunikuje się w inny sposób np. za pomocą protokołów o niskim poborze mocy jak LoRaWAN czy Wi-SUN.
W tym tekście skupiłem się na wybranych aspektach protokołu: modelu informacji, stosie komunikacyjnym i bezpieczeństwie przesyłanych danych, które opisane są odpowiednio w piątej[4], szóstej[5] i drugiej części standardu[3]. Pełną specyfikację protokołu można pobrać ze strony OPC Foundation (wymagana rejestracja).
Model informacji w rozumieniu standardu OPC UA pozwala opisać obiekty i procesy tworzące konkretny system, a także relacje pomiędzy nimi. Każdy z obiektów charakteryzują pewne właściwości. Najprościej zobrazować to na przykładzie.
Diagram z rysunku 2 przedstawia model informacji hipotetycznej fabryki. W fabryce znajdują się dwie maszyny tego samego typu, które zawierają dwa czujniki i dwa elementy wykonawcze. Każdy z czujników posiada specyficzne dla siebie właściwości, takie jak numer seryjny czy wartość ostatniego pomiaru. Elementy wykonawcze dodatkowo posiadają metody, które pozwalają uruchomić lub zatrzymać konkretne procesy. Każda z właściwości przypisana do obiektu ma określony typ danych. W przykładzie numer seryjny czujnika przechowywany jest jako łańcuch znaków (string), a wartość pomiaru jako liczba 32-bitowa ze znakiem (int32). Wyspecyfikowanie modelu informacji w taki sposób jest jednym z kroków, jaki musi zostać wykonany w celu wdrożenia komunikacji zgodnej ze standardem OPC UA do wybranego systemu czy też sterownika. Standard OPC Unified Architecture jest na tyle obszerny, że specyfikuje także notację jaka powinna zostać użyta przy tworzeniu modelu informacji. Jest ona szczegółowo opisana w trzeciej części standardu.
OPC UA jest standardem zorientowanym na usługi i również jego stos komunikacyjny można rozumieć jako zbiór serwisów realizujących konkretne zadania, takie jak kodowanie danych, ich szyfrowanie czy transport. Wspomniane serwisy tworzą kolejne warstwy stosu komunikacyjnego i mogą być implementowane przez różne protokoły. Diagram z warstwami stosu przedstawiono na rysunku 3, a ich zadania opisano poniżej:
Transport: protokół odpowiedzialny za transport danych w sieci.
Takie podejście czyni standard elastycznym i daje możliwość dostosowania go do zmieniających się potrzeb rynku. Przykładowo, jeśli wraz z rozwojem technologii pojawią się nowe, lepsze protokoły bezpieczeństwa, to wystarczy podmienić tylko jedną warstwę stosu, nie wpływając na pozostałe. Aktualna wersja standardu określa kilka różnych profili komunikacji, które dokładnie specyfikują protokoły użyte na każdej z warstw. Wszystkie z nich opisane są na stronie OPC Foundation. Trzy wybrane profile wraz z ich nazwami przedstawiono na rysunku 4.
Dodając wsparcie dla standardu OPC UA we własnym systemie, należy zdecydować, który z profili chcemy wspierać. Powinno się dążyć do wspierania wszystkich, ale z uwagi na czasochłonność implementacji lub ograniczone zasoby sprzętowe może okazać się to trudne. W praktyce wydaje się, że profil 1 cieszy się największą popularnością, szczególnie w świecie systemów wbudowanych – zapewnia on większą wydajność i używa mniejszej ilość zasobów w porównaniu do pozostałych.
Bezpieczeństwo połączenia OPC Unified Architecture jest ściśle związane z konkretnym profilem komunikacji. Przykładowo, w profilach 2 i 3 w celu zapewniania bezpiecznego połączenia wykorzystany jest protokół TLS, który specyfikuje własne algorytmy kryptograficzne i nie jest częścią standardu OPC UA. W tym tekście skupiłem się na politykach bezpieczeństwa wyspecyfikowanych przez standard i implementowanych przez protokół UA SC (ang. UA Secure Conversation).
Standard specyfikuje 3 poziomy niezbędne do zestawienia połączenia klient-serwer. Zobrazowano je na rysunku 5, a wymieniono poniżej:
Zarówno w celu zestawienia sesji, jak i bezpiecznego kanału, wymagane są poświadczenia.
Celem bezpiecznego kanału jest zapewnienie integralności i poufności wymienianych informacji, a także sprawdzenie autentyczności komunikujących się aplikacji. Z kolei na poziomie sesji istotne jest uwierzytelnienie konkretnego użytkownika, próbującego podłączyć się do serwera, i weryfikacja jego uprawnień. W celu zestawienia bezpiecznego kanału należy zdefiniować tryb i politykę bezpieczeństwa. Dostępne tryby to “None”, “Sign” i “SignAndEncrypted”. Jak wskazują nazwy tych trybów, determinują one, czy wymieniane wiadomości powinny być podpisane i szyfrowane. Polityka bezpieczeństwa określa algorytmy kryptograficzne wykorzystywane m.in. do podpisywania i szyfrowania wiadomości.
Przykładowe polityki przedstawiono w tabeli.
| Polityka bezpieczeństwa | Poziom bezpieczeństwa | |
| 1 | Basic256Sha256 | wysoki |
| 2 | Aes256Sha256RsaPss | wysoki |
| 3 | Aes128Sha256RsaOaep | średni |
| 4 | Basic128Rsa15 | niski |
Aby umożliwić działanie wymienionych wyżej polityk, każda ze stron komunikacji powinna posiadać własny certyfikat x509, podpisany przez urząd certyfikacji, zaufany przez drugą stronę, a także klucz prywatny, komplementarny do publicznego znajdującego się w certyfikacie. Zatem określenie wspieranych algorytmów kryptograficznych, infrastruktury klucza publicznego, czy sposobu przechowywania klucza prywatnego to kolejne bardzo istotne elementy, które trzeba wziąć pod uwagę wdrażając standard OPC UA we własnym systemie IoT.
Elementy protokołu, które wskazałem powyżej, pozwalają zrozumieć koncepcję rozwiązania i są dobrym wstępem do dalszego pogłębiania wiedzy o standardzie OPC UA. Nie wyczerpujemy do końca tematu, ale niech ten tekst stanowi dobry początek dla tych, których interesują tajniki protokołu OPC UA.
Pamiętajmy, że planując wdrożenie komunikacji tego typu do własnego systemu, należy na początek przygotować jego model informacji, następnie wybrać profil komunikacji i polityki bezpieczeństwa, uważając, aby były zgodne z potrzebami i wymaganiami rynku. Kolejnym krokiem byłoby wybranie sposobu implementacji protokołu we własnym systemie, ale to już temat na kolejne opracowanie.
