Czy można zrobić nie-pełny serwer OPC UA? Co z urządzeniami Embedded/PLC? [PL]

Niniejszy wpis jest próbą odpowiedzi na pytania dotyczących implementacji serwera OPC UA, z którymi spotykam się od czasu do czasu:

• „Słyszałem, że OPC UA łączy ze sobą sposoby dostępu do danych aktualnych (Data Access, DA), historycznych (Historical Data Access, HDA), o zdarzeniach (Allarms & Events, A&E lub Alarms & Conditions, A&C) i innych typów danych. Mnie interesuje tylko prosty serwer DA, czy muszę zaimplementować lub zakupić od razu również HDA i A&E?”
• „Podobno serwer OPC UA, oferuje usługi jako serwisy, które są rejestrowane, aby klient mógł je odszukać i nawiązać połączenie. Zakładając, że chcemy więc tylko przesłać wartości danych, czy wystarczy jeżeli nie zaimplementujemy całego serwera OPC UA, ale tylko pewien serwis, który odpowiednio zarejestrujemy?”
• „Interesuje mnie proste udostępnianie dane, czy mogę wybrać pewne usługi serwera OPC UA, zaimplementować je i poinformować wszystkich, że mam serwer OPC UA o „nie pełnej funkcjonalności” ?”

OPC UA jest dosyć skalowalne – oprogramowanie wspierające tę technologię nie musi implementować wszystkich elementów opisanych w specyfikacji (która ma przecież kilkanaście tomów) aby móc je określić np. mianem serwera OPC UA. Nie jest jednak tak, że można zaimplementować dowolny serwis (wybrany zbiór usług, itp...), który zostanie zarejestrowany w serwerze typu OPC UA Discovery, by móc stwierdzić, że mamy serwer OPC UA.

Specyfikacja OPC UA przewiduje tzw. Profile. Profile definiują zbiory funkcjonalności wchodzących w skład specyfikacji OPC UA. Dostawca oprogramowania deklaruje, jakie profile są wspierane przez jego produkt, a użytkownik może wskazywać, dla jakich profili on potrzebuje wsparcia. Poszczególne aplikacje mogą być sprawdzane, czy wspierają dany profil w procesie certyfikacyjnym. Więcej na temat profili można znaleźć na moim blogu lub w książce "OPC - From Data Access to Unified Architecture”, która jest pewnego rodzaju kompendium wiedzy o standardzie komunikacyjnym OPC UA.

W przypadku najprostszego serwer OPC UA należy dać wsparcie dla profilu "Nano Embedded Device Server", który jest zbiorem całej dużej grupy funkcjonalności (profili aspektowych, ang. Facets). Co ciekawe taki serwer udostępnia dane nie poprzez Web-Serwisy, a strumienie binarne (specyfikacja OPC UA pozwala na różne kanały transmisyjne, o czym można przeczytać we wspomnianej książce lub na moim blogu w artykule „Kodowanie i mapowanie w OPC Unified Architecture”). Serwer, aby mógł być uznany za zgodny z OPC UA, musi wspierać przynajmniej jeden profil typu „w pełni funkcjonalny” (ang. Full-featured), np.:

• Nano Embedded Device Server
• Micro Embedded Device Server
• Embedded UA Server
• Standard UA Server

Więcej informacji, odnośnie co zawiera konkretny profil znaleźć można pod adresem: https://opcfoundation.org/profilereporting/index.htm.

Nie wystarczy wybrać sobie dowolne usługi, zaimplementować je i twierdzić, że ma się serwer OPC UA.

Można zaimplementować w serwerze tylko wybrane funkcjonalności, np. tylko DA, jednak trzeba wskazać, które profile są spełnione (elementy HDA, A&E, A&C są określone w osobny profilach aspektowych (ang. Facets))

Reasumując, wydaje mi się, że samodzielne stworzenie serwera OPC UA (tym bardziej na urządzenie typu PLC) to raczej trudne zadanie. Nie wielu producentów sterowników ma już coś takiego. Wiem m.in. że Beckhoff ma rozwiązanie typu serwer OPC UA na sterowniku PLC (które testował już na warsztatach OPC interoperability) jest to TwinCAT OPC UA Server, z innych urządzeń słyszałem o FasaLink, gdzie serwer OPC został zaimplementowany w małym układzie, który może być zabudowany w innym urządzeniu.