OPC UA Pub/Sub

W OPC UA Pub/Sub komunikacja odbywa się między Wydawcą (Publisher) a Subskrybentem (Subscriber). Dzięki wykorzystaniu Brokera nie trzeba tworzyć relacji 1:1, jak w modelu klient-serwer, co przyspiesza komunikację i oszczędza zasoby procesora.

1. Model klient/serwer OPC UA

Model klient/serwer to tradycyjny model komunikacji w OPC UA. Opiera się na idei, że istnieje pasywny komponent serwera, który udostępnia dane innym aplikacjom działającym jako klienci. Aplikacje klienckie mogą uzyskiwać dostęp do danych i informacji z serwera za pośrednictwem kilku standardowych usług.

Najważniejszą rzeczą, jaką musi zrobić klient, jest otwarcie połączenia z serwerem. Potrzebuje adresu połączenia i (pomijając kilka szczegółów) utworzy sesję z serwerem. Sesja zawiera kontekst bezpieczeństwa, który obejmuje opcjonalne parametry szyfrowania i uwierzytelniania – w celu zidentyfikowania aplikacji klienta i użytkownika na serwerze. Klient może również zidentyfikować serwer i zdecydować, czy zezwolić na komunikację z nim.

Po ustanowieniu sesji aplikacja klienta może zażądać kilku standardowych usług od serwera. Usługi te to:

1. (Połącz i utwórz sesję)
2. Przeglądaj przestrzeń adresową – aby dowiedzieć się, co jest dostępne na serwerze
3. Odczyt – wartości zmiennych lub metadane
4. Zapis – wartości zmiennych – a czasami nawet metadane
5. Metody wywołań
6. Odczyt historii – dla zmiennych i zdarzeń
7. (Zamknij sesję i rozłącz)

Więc na koniec, gdy klient skończy, zamknie sesję i rozłączy się.

Subskrypcje klient/serwer

Model Klient/Serwer zawiera również model Subskrypcji. W tym modelu każdy Klient może utworzyć dowolną liczbę Subskrypcji dla Serwera. Każda Subskrypcja może zawierać MonitoredItems dla Zmiennych i EventNotifiers (węzły obiektów z ustawionym atrybutem EventNotifier).

Po utworzeniu subskrypcji Klient rozpocznie wywoływanie Publish do Serwera, a Serwer odpowie NotificationMessage. NotificationMessage może zawierać DataChanges i Events, odpowiednio do typu MonitoredItems.

Zalety i wady klienta/serwera

Model Klient/Serwer został pomyślnie wykorzystany w typowych scenariuszach SCADA i sprawdza się, gdy liczba połączeń między różnymi aplikacjami nie jest zbyt duża. Jeśli masz dziesiątki lub setki urządzeń (tj. Serwerów), które muszą być stale podłączone – lub podobną liczbę Klientów, którzy muszą łączyć się z dowolnym Serwerem, możesz mieć problemy z zasobami, ponieważ każde połączenie i subskrypcja wymagają utrzymania porządku i powodują oddzielny ruch w sieci.

Tradycyjnie OPC UA nie było projektowane w celu umożliwienia jakiejkolwiek deterministycznej komunikacji lub komunikacji przez zawodne sieci. Umożliwia jednak synchroniczne wywołania usług, które otrzymują natychmiastowe wyniki lub potwierdzenia działań, co może być bardzo ważne dla aplikacji.

Bezpieczeństwo jest również elastyczne i można definiować reguły dla każdej aplikacji i użytkownika – nawet dla każdej zmiennej, jeśli to konieczne.

2. Model wydawcy/subskrybenta

Model PubSub radykalnie różni się od modelu Klient/Serwer, ale w kontekście OPC UA istnieją podobieństwa.

W modelu PubSub mamy komponent Publisher, który może definiować zestawy danych zawierające zmienne lub EventNotifiers. Następnie Publisher opublikuje DataSetMessages, które zawierają odpowiednio DataChanges lub Events. Tak więc przesyłane dane są podobne do subskrypcji Klient/Serwer. Są one jednak uporządkowane w nieco inny sposób.

Wiadomości są publikowane w Sieci, gdzie Subskrybenci mogą ich słuchać i filtrować to, czego potrzebują.

W przeciwieństwie do Subskrypcji w modelu Klient/Serwer, nadawca definiuje w Zestawach danych, co zostanie wysłane, zamiast odbiorcy. W przeciwnym razie dane w DatasetMessages są zasadniczo takie same jak w NotificationMessages (chociaż w innym formacie).

Model jest skalowalny, ponieważ teoretycznie może być dowolna liczba Wydawców i dowolna liczba Subskrybentów. Wszyscy są połączeni z tą samą Siecią, ale nie ze sobą, co jest główną poprawą w stosunku do modelu Klient/Serwer.

Sieci PubSub

OPC UA definiuje dwa różne typy sieci dla PubSub.

1. Sieć lokalna – która może używać UDP Broadcast (lub Unicast w niektórych przypadkach) lub Ethernet APL. Wiadomości są zoptymalizowanym binarnym UADP, który jest zdefiniowany w specyfikacjach OPC UA. Tak więc tylko subskrybenci OPC UA mogą interpretować wiadomości.
2. Broker kolejki wiadomości – który w praktyce może być brokerem MQTT lub AMQP. W tym przypadku wiadomości są zazwyczaj wiadomościami JSON, chociaż UADP może być używane w celu poprawy wydajności. Fundacja OPC zdefiniowała standardową strukturę treści dla wiadomości, ale zasadniczo każdy subskrybent JSON może je interpretować.

Bezpieczeństwo PubSub

Bezpieczeństwo w PubSub jest nieco bardziej skomplikowane i nie tak szczegółowe jak w modelu Klient/Serwer.

W sieci lokalnej potrzebny będzie dodatkowy komponent, Security Key Server, do którego łączą się wszyscy wydawcy i subskrybenci i który udostępnia im współdzielone klucze, aby mogli szyfrować i odszyfrowywać wiadomości. Nie ma uwierzytelniania, chyba że Key Server uwierzytelnia aplikacje.

W sieciach brokerów bezpieczeństwo opiera się na SSL/TLS, które brokerzy mogą włączyć dla transportu. Mogą również definiować uwierzytelnianie na poziomie aplikacji.

W obu modelach nie ma reguły dla każdego elementu danych, która mogłaby być stosowana tylko do niektórych odbiorców od niektórych nadawców. Zasadniczo jest to wszystko albo nic dla każdego, kto może dołączyć do sieci.

Zalety i wady PubSub

Model PubSub rozwiązuje więc problem skalowalności, dlatego MQTT jest już bardzo popularny i odnosi sukcesy w wielu aplikacjach (nie-OPC UA), w których trzeba połączyć tysiące dostawców danych, takich jak małe czujniki lub zdalne liczniki, przez zawodne połączenia z centralnym monitorowaniem. Branża wpadła na nowe pomysły, jak faktycznie wykorzystać go w szerszym kontekście. Teraz OPC UA dodaje kilka standardowych formatów dla zawartości wiadomości i standardowy sposób mapowania danych OPC UA, co powinno okazać się korzystne. Nowa standaryzacja jest nadal w toku i nie zdefiniowano jeszcze, w jaki sposób bogate modele informacji OPC UA, na przykład, będą mapowane na MQTT w najlepszy sposób.

Z drugiej strony, OPC UA wykorzystuje model PubSub, aby umożliwić bardzo szybką komunikację w sieciach lokalnych, a gdy sieci staną się deterministyczne i szybkie dzięki technologiom Ethernet TSN i APL, możemy przewidzieć możliwości komunikacji w czasie rzeczywistym przez OPC UA PubSub. Właśnie na tym polega inicjatywa OPC UA Field Level Communication (FLC) i co może udostępnić nowa specyfikacja Field Exchange (FX).

3. Scenariusze PubSub

Świat powoli przechodzi od Industrie 3.0, który opierał się na dobrze znanej piramidzie automatyzacji, do Industrie 4.0, gdzie wszystkie komponenty w fabryce są połączone z siecią produkcyjną. Co więcej, sam produkt może również przenosić informacje o sobie i istnieje dostęp do informacji produkcyjnych z dowolnego miejsca na świecie. Model klient/serwer był bardzo odpowiedni dla starego świata, w którym liczba inteligentnych komponentów (tj. komputerów) i ich połączeń była niewielka. W nowym świecie problem z łącznością może eksplodować, gdy liczba komponentów, które chcą produkować i konsumować informacje w sieci współdzielonej, wzrośnie. Model PubSub powinien być bardziej odpowiedni dla nowego świata, ale przynajmniej w międzyczasie będziemy używać obu, aby się uzupełniać.

W praktyce PubSub może być i będzie łączony z modelem Klient/Serwer w większości przypadków. Umożliwia to dodanie Wydawcy do Serwera, Subskrybenta do Klienta lub dowolnej innej kombinacji.

Dwa główne scenariusze PubSub, które przewidywano na początku, to scenariusz zsynchronizowanych serwerów i scenariusz Edge-to-Cloud.

W Synchronized Servers mamy dwa lub więcej serwerów OPC UA, które odzwierciedlają wzajemnie swoje dane w swoich przestrzeniach adresowych. UDP Broadcast działa szczególnie dobrze w sieci lokalnej, a za pośrednictwem sieci czasu rzeczywistego może być użyteczny do rozproszonego sterowania, chociaż nadal brakuje mu właściwego interfejsu wywołania metody.

4. Dema PubSub

Stworzyliśmy trzy publiczne demonstracje dotyczące PubSub:

1. Łączenie OPC UA Publisher z Azure za pomocą MQTT
2. Łączenie OPC UA Publisher z Amazon AWS IoT za pomocą MQTT
3. Demo Manufacturing Gateway

Możesz sprawdzić szczegóły w powiązanych wpisach na blogu. Film zawiera również ich szybki przegląd.

5. Wnioski

Tak więc nadal potrzebujemy modelu OPC UA Client/Server, aby móc komunikować się „synchronicznie” w typowym scenariuszu SCADA.

Model PubSub umożliwia znacznie lepszą skalowalność i poprawia wydajność komunikacji, co czyni go dobrym kandydatem do komunikacji w czasie rzeczywistym i odgrywa ważną rolę w inicjatywie OPC UA Field Level Communication (FLC) i nowym standardzie Field Exchange (FX).

Georg Biehler wygłosił znakomite przemówienie na tym samym OPC Day Finland 2021 na temat OPC UA Field Exchange (FX), więc sprawdźcie je następnym razem!