Co to jest OPC UA?

Praktyczna wiedza o standardzie OPC UA.
Dowiedz się czym jest standard OPC UA i jak możesz wykorzystać go do cyfryzacji fabryki, aby Twój zakład funkcjonował zgodnie z Przemysłem 4.0.

OPC - otwarta platforma komunikacyjna

Skrót OPC historycznie pochodzi od OLE for Process Control, ale obecnie tłumaczy się go jako Open Platform Communications, czyli otwarta platforma komunikacyjna. OPC jest jednym z najważniejszych standardów komunikacyjnych dla Przemysłu 4.0 i IoT. Dzięki OPC dostęp do maszyn, urządzeń i innych systemów w środowisku przemysłowym jest ustandaryzowany i umożliwia podobną i niezależną od producenta wymianę danych.

W tym kontekście UA w OPC UA oznacza „Unified Architecture” i nawiązuje do najnowszej specyfikacji standardu. Różni się od swojego poprzednika tym, że jest niezależny od platformy i odchodzi od COM/DCOM na rzecz czysto binarnego protokołu TCP/IP lub alternatywnie SOAP. Oprócz wielu innych ulepszeń, OPC UA obsługuje także semantyczny opis danych.

Na tej stronie podsumowaliśmy wszystko, aby zapewnić Ci niezbędną orientację pomiędzy wieloma terminami technicznymi dotyczącymi OPC UA.

1. Serwer OPC

Serwer OPC jest podstawą komunikacji OPC. Jest to oprogramowanie implementujące standard OPC i w ten sposób udostępniające ustandaryzowane interfejsy OPC światu zewnętrznemu. Wewnątrz zaimplementowany jest autorski protokół komunikacyjny (drajwer) do sterowania urządzeniami danego producenta. Serwery OPC są dostarczane przez różne firmy.

Serwer OPC od dostawcy sprzętu


Podstawową ideą OPC jest to, że producent sprzętu zapewnia serwer OPC dla swojego systemu i dlatego umożliwia ustandaryzowany dostęp. Serwer OPC producenta może być dostarczony jako samodzielne oprogramowanie lub jako serwer OPC wbudowany w urządzenie lub sterownik maszyny.


Niezależne serwery OPC


Oprócz serwerów OPC pochodzących od producentów sprzętu, istnieją dostawcy, którzy opracowują niezależne serwery OPC. Serwery te różnią się szerszą obsługą protokołów komunikacyjnych. Dzięki temu możliwa jest komunikacja OPC nawet z tymi systemami, dla których producent nie oferuje własnego serwera OPC. Ponadto producenci niezależnych serwerów OPC oferują więcej funkcji, w niektórych przypadkach prostszą obsługę i lepszą stabilność.

Polecamy serwer OPC firmy Kepware (grupa PTC) o nazwie KEPServerEX lub ThingWorx Kepware Server (ponad 150 drajwerów)

Również oprogramowanie OPC Router może wykorzystywać wtyczkę serwera OPC UA do dostarczania danych jako serwer OPC.

2. Klient OPC

Klient OPC jest logicznym odpowiednikiem Serwera OPC. Serwer OPC można połączyć z Klientem OPC i odczytać dane dostarczane przez Serwer. Ponieważ serwery OPC implementują predefiniowane interfejsy standardu OPC, każdy klient może uzyskać dostęp do dowolnego serwera OPC i wymieniać dane z serwerem w ten sam sposób.

Aplikacje działające jako Klient OPC


Typowymi klientami OPC są aplikacje, które opierają się na wymianie danych z systemami przemysłowymi. To, co dzieje się z danymi w kliencie jest mocno uzależnione od aplikacji. Powszechnymi zastosowaniami są systemy wizualizacyjne (HMI) i SCADA (WinCC, InTouch, FAS inMOVE) czy systemy MES.

Również oprogramowanie OPC Router jest rozbudowanym klientem OPC UA z funkcją bramy (Gateway).

Klient testowy OPC


Na rynku dostępnych jest wielu bezpłatnych klientów testowych OPC, za pomocą których można bardzo łatwo i przejrzyście przetestować działanie i konfigurację serwera. Istniejące punkty danych można wyszukiwać, łączyć i przeglądać aktualne wartości w bardzo krótkim czasie.
W użytkowaniu operacyjnym bardzo ważne jest przetestowanie funkcji źródła danych „OPC” za pomocą niezależnej aplikacji, a tym samym wyodrębnienie go z aplikacji wyższego poziomu. Popularnym klientem testowym jest UaExpert od Unified Automation.

3. OPC Classic kontra OPC UA

Aktualnym standardem specyfikacji OPC jest OPC UA (OPC Unified Architecture). Jest następcą starego standardu OPC, który nazywa się OPC Classic (zawiera w sobie OPC DA, OPC AE oraz OPC HDA). Do dziś wiele instalacji serwerów OPC to klasyczne serwery OPC (najczęściej OPC DA). Stary standard już bardzo skutecznie rozwiązał zadanie realizacji wymiany danych w automatyce niezależnej od producenta i zdefiniował podstawowe interfejsy. Wadą OPC Classic był brak niezależności od platformy. OPC Classic opiera się na technologiach Microsoft COM i DCOM , dlatego też instalacje Serwera OPC i Klienta OPC zostały ograniczone do systemów operacyjnych i sieci Microsoft Windows. Wraz ze wzrostem sukcesu innych platform (Linux, architektury internetowe, chmura, urządzenia IoT, CPS, …) dystrybucja OPC została ograniczona.
Fundacja OPC dostrzegła to i stworzyła następcę, czyli OPC UA. Głównym celem OPC UA jest niezależność od platformy i interoperacyjność. Technicznie standard został zbudowany w oparciu o podstawowe technologie webowe (TCP/IP, http/SOAP). Przyjęto podstawowe koncepcje wymiany danych, połączono je
i uzupełniono o kolejne koncepcje (patrz specyfikacje).

4. OPC UA Pub/Sub

Uczestnicy komunikacji w OPC UA Pub/Sub dzielą się na Wydawcę (Publisher) i Subskrybenta (Subscriber). Urządzenia i oprogramowanie mogą komunikować się ze sobą za pośrednictwem Brokera bez konieczności polegania na relacjach 1 do 1 w komunikacji klient/serwer. Dzięki temu można przyspieszyć komunikację wewnątrz systemu i zaoszczędzić wydajność procesora.
OPC ROUTER

Użyj OPC UA, aby ożywić Przemysł 4.0!

OPC Router to rozbudowany klient OPC, umożliwiający graficzne "programowanie" logiki komunikacji metodą „przeciągnij i upuść” (drag&drop) pomiędzy systemami, m.in. za pośrednictwem OPC UA.

Przetestuj już teraz w pełni funkcjonalną i bezpłatną wersję demonstracyjną komunikacji OPC UA.

5. Fundacja OPC

Fundacja OPC jest organizacją stojącą za tym standardem i liczącą 678 członków. Są to często globalni gracze z branży automatyki. Na przykład: Siemens, Honeywell, Microsoft, Beckhoff, SAP, Yokogawa, ABB, Rockwell, Schneider Electric, Wago, Iconics. Wszystkich członków Fundacji można znaleźć na liście członków Fundacji OPC . Stowarzyszenie powstało w 1994 roku, a pierwszą wersję OPC wydało w 1996 roku. Od tego czasu z sukcesem i aktywnie pracuje nad dalszym rozwojem i upowszechnianiem standardu OPC.

6. Specyfikacje OPC

Standard OPC UA składa się z indywidualnych specyfikacji. Każda specyfikacja opisuje funkcję częściową i określa, które interfejsy serwera i klienta muszą być zaimplementowane dla tej funkcji, aby ją obsługiwać. Serwery i klienci OPC nie muszą obsługiwać wszystkich specyfikacji. W zależności od zastosowania często programuje się tylko indywidualne specyfikacje. Dlatego też podczas korzystania z serwera i klientów OPC ważne jest rozważenie, jakie specyfikacje są wymagane i które są wdrażane przez serwer i klienta.

OPC UA składa się z następujących specyfikacji:

1. Pojęcia (Concepts)
2. Model bezpieczeństwa (Security Model)
3. Model przestrzeni adresowej (Address Space Model)
4. Usługi (Services)
5. Model informacyjny (Information Model)
6. Mapowania (Mappings)
7. Profile (Profiles)
8. Dostęp do danych (Data Access)
9. Alarmy i warunki (Alarms and Conditions)
10. Programy (Programs)
11. Dostęp historyczny (Historical Access)
12. Wykrywanie (Discovery)
13. Agregaty (Aggregates)
14. Wydawca i Subskrybent (PubSub)

Do użytku operacyjnego nie jest konieczna szczegółowa znajomość specyfikacji. Do najważniejszych z punktu widzenia działalności projektowej należą:

Dostęp do danych


Specyfikacja Data Access opisuje klasyczną wymianę bieżących danych. Standard OPC Classic już określa, że ​​wymiana danych jest zorientowana na punkty danych. Dla każdego punktu danych można odczytać i zapisać wartość. Wartość punktu danych opisana jest przez wartość rzeczywistą, znacznik czasu, w którym wartość była aktualna, oraz jakość, która opisuje, czy wartość jest ważna, czy też np. przerwano połączenie ze sterownikiem i w związku z tym wartość jest nieważna. Już sama ta specyfikacja umożliwia pozyskiwanie i przetwarzanie danych niezależnie od systemu bazowego.
W obecnym standardzie możliwości zostały rozszerzone o złożone typy danych (struktury) i funkcje, aby sprostać nowym wymaganiom.

Dostęp historyczny


Korzystając ze specyfikacji Dostępu Historycznego, możliwy jest nie tylko odczyt danych o wartości bieżącej, ale także odpytywanie wartości historycznych. Serwer OPC realizujący tę specyfikację musi posiadać wewnętrzną pamięć danych, aby zapewnić wartości punktów danych dla ewentualnych dostępów historycznych. Klient, który odczytuje historyczne punkty danych poprzez dostęp historyczny, oprócz informacji o punktach danych przesyła również żądany okres do serwera.

Alarmy i warunki


Specyfikacja Alarmy i warunki definiuje ustandaryzowany model komunikatów alarmowych i logiki alarmów w ramach OPC UA. W przypadku aplikacji klienckich OPC upraszcza to zadanie generowania alarmów na podstawie wartości punktów danych, ponieważ logikę może zaimplementować w serwerze OPC, a nie producent oprogramowania klienckiego.

7. Specyfikacje towarzyszące

Specyfikacje towarzyszące (Companion Specifications) to modele informacyjne zbudowane przez grupy branżowe w oparciu o model standardowy OPC UA. Definiują zdefiniowane struktury punktów danych dla aplikacji i obiektów specyficznych dla branży. Przykładami są modele wtryskarek (Euromap 77), obrabiarek/CNC (umati), robotów, systemów RFID i AutoID (AutoID) i wiele innych.
Przyjęte już Specyfikacje towarzyszące są wymienione przez Fundację OPC na jej stronie internetowej.
Grupy robocze opracowują obecnie wiele innych specyfikacji towarzyszących i wkrótce zostaną przyjęte.

OPC UA standaryzuje prostą wymianę danych z maszynami i systemami, specyfikacje towarzyszące standaryzują także modele danych dla podobnych maszyn i systemów, w których określono, które dane mają być wymieniane. Prowadzi to do znacznego uproszczenia podłączenia maszyn do istniejących systemów zgodnie z ideą przemysłu 4.0, ponieważ maszyny różnych producentów dostarczają i odbierają te same struktury danych.

8. Bezpieczeństwo w OPC UA

Przy opracowywaniu standardu OPC UA od samego początku uwzględniono najwyższy stopień bezpieczeństwa. W przeciwieństwie do OPC Classic, OPC UA został opracowany w sposób „przyjazny zaporze ogniowej”, co oznacza, że ​​można nim sterować za pomocą standardowych technik sieciowych.
W warstwie transportowej udostępniono kilka protokołów. Dzięki temu protokół binarny może być używany bezpośrednio w protokole TCP/IP w przypadku szybkich aplikacji lub w wieloplatformowym SOAP z HTTPS.
Szyfrowanie 128 lub 256 bitów służy do zabezpieczenia danych podczas transmisji, a także podpisywania wiadomości, sekwencjonowania pakietów i uwierzytelniania użytkownika.
OPC UA wykorzystuje wymianę certyfikatów dla większego bezpieczeństwa, dzięki czemu każdy klient musi uwierzytelniać się za pomocą certyfikatu. W ten sposób można kontrolować, który klient może łączyć się z serwerem.

Niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji (BSI) zbadał bezpieczeństwo OPC UA
i nie znalazł żadnych systemowych luk w zabezpieczeniach.

9. Tunelowanie

Tunelowanie odnosi się do przesyłania danych OPC z jednego segmentu sieci do drugiego. Termin wywodzi się z czasów OPC Classic, gdyż ze względu na zastosowaną technologię DCOM komunikacja międzysieciowa poprzez OPC Classic jest bardzo utrudniona lub prawie niemożliwa. Niektórzy producenci oprogramowania stworzyli rozwiązanie tego problemu, hermetyzując ruch danych i konwertując go na prosty protokół TCP/IP, tak aby ruch danych mógł przechodzić przez zaporę ogniową. W sieci docelowej ruch danych został ponownie rozpakowany i udostępniony na serwerze OPC Classic.
Dzięki technologii OPC UA tunelowanie nie jest już konieczne. Jeżeli w zakładzie funkcjonuje chociaż jeden serwer OPC Classic, a mimo to komunikacja ma odbywać się w różnych sieciach, wymagany jest wrapper OPC. W tym celu używany jest serwer OPC UA, np. KEPServerEX , który pobiera dane jako klient z serwera OPC Classic (np. OPC DA) i udostępnia te dane za pośrednictwem przyjaznego zaporze ogniowej standardu OPC UA.

10. OPC UA przez TSN

OPC UA over TSN został zaprojektowany do komunikacji w czasie rzeczywistym na poziomie terenowym pomiędzy systemami sterowania. TSN oznacza Time Sensitive Network i opisuje wymagania sieci maszynowych z deterministycznymi czasami odpowiedzi. W przeciwieństwie do operacji klient-serwer w OPC UA, OPC UA over TSN komunikuje się zgodnie z metodą Wydawca-Subskrybent (Pub/Sub). W przypadku korzystania z OPC UA w normalnych środowiskach opartych na sieci Ethernet (nie w czasie rzeczywistym), OPC UA over TSN nie odgrywa obecnie żadnej roli.

11. OPC UA Pub/Sub przez MQTT

Zasada Pub/Sub jest wykorzystywana nie tylko przez wtyczkę OPC UA Pub/Sub, ale także przez wspólny protokół komunikatów MQTT. Obie wtyczki umożliwiają pracę OPC Routera w trybie wydawcy i abonenta. Jednakże wtyczka OPC UA Pub/Sub różni się od wtyczki MQTT tym, że struktura danych OPC UA jest już dostępna we wtyczce OPC UA Pub/Sub. Dzięki temu OPC Router może publikować dane OPC UA w innych urządzeniach lub systemach w celu dalszego przetwarzania lub subskrybować dane OPC UA od innych. Implementacja danych OPC UA poprzez MQTT byłaby znacznie trudniejsza, ponieważ większość treści komunikatów w MQTT jest opisana w formacie XML lub JSON.

12. OPC XML

Specyfikacja OPC XML była pierwszą próbą Fundacji OPC uzyskania niezależności od platformy i zerwania powiązania z technologią Microsoft. Pojawiający się wówczas format XML był używany w połączeniu z technologiami internetowymi. W 2003 roku opublikowano specyfikację OPC XML. Jednak trzy lata później, w 2006 roku, dostępna była już pierwsza wersja OPC UA, co spowodowało, że OPC XML stał się przestarzały.

13. DCOM

Technologia Microsoft DCOM jest sieciową wersją technologii COM. COM oznacza Component Object Model i jest technologią obiektową działającą w tle systemu operacyjnego Microsoft. Umożliwia inteligentną współpracę różnych aplikacji. Ponieważ była to wiodąca technologia w momencie opracowywania standardu OPC, została wykorzystana jako podstawa. Serwer OPC Classic jest komponentem COM i jako taki jest podłączony przez klienta. Jeśli serwer OPC Classic jest podłączony przez sieć, należy zastosować protokół Distributed COM (DCOM), który jest głęboko zakorzeniony w systemie operacyjnym Windows. DCOM ma złożoną logikę uwierzytelniania i wykorzystuje wiele dynamicznych połączeń TCP/IP, co czyni go niekontrolowanym przez zaporę ogniową i kategorycznie blokowanym. W praktyce zatem połączenia DCOM zwykle nie były nawiązywane.

14. Niezależność od platformy oraz interoperacyjność

OPC UA stała się całkowicie niezależna od platformy dzięki TCP/IP i innym protokołom sieciowym do komunikacji. Za pomocą tych protokołów można adresować serwer OPC, który udostępnia swoje dane w sieci. Nie ma znaczenia, czy Serwer OPC działa w systemie operacyjnym Windows, Linux, UNIX czy Mac. Nawet całkowicie własne platformy ze stosem TCP/IP mogą wdrożyć serwer OPC. Zatem typowe systemy wbudowane, urządzenia i elementy sterujące mogą służyć jako serwery. Cel niezależności platformy został osiągnięty i prowadzi do szybkiej dystrybucji OPC UA. Interoperacyjność jest logiczną konsekwencją infrastruktury z różnymi uczestnikami OPC UA w sieci.

15. OPC UA i Przemysł 4.0

W 2011 roku po raz pierwszy w grupie roboczej użyto terminu Przemysł 4.0. OPC UA został już dawno zdefiniowany jako standard. Niemniej jednak OPC UA jest jednym z wiodących protokołów komunikacyjnych dla Przemysłu 4.0. Inteligentne połączenie fabryk w sieć wymaga wspólnego języka. To jest dokładnie to, co zapewnia OPC UA i dlatego jest ważnym instrumentem wdrażania Przemysłu 4.0.

16. Film Fundacji OPC

What is OPC? UA in a Minute
Krótki film prezentujący czym jest standard OPC UA.
Źródło: OPC Foundation

17. Bezpieczeństwo w REST

Ponieważ do wywoływania punktów końcowych REST używany jest protokół HTTP, można również zastosować uwierzytelnienia dostępne w standardowym systemie, takie jak HttpBasic, Jwt, Ntml, OAuth1, OAuth2.

Ponadto, aby móc korzystać z zabezpieczonego połączenia, zamiast http używany jest oczywiście https.
Oprócz standardowych opcji uwierzytelniania często wymieniany jest tzw. AppKey. Klucz ten to tajny kod stworzony dla klienta, który jest przesyłany przy każdym połączeniu w celu uzyskania autoryzacji połączenia. OPC Router obsługuje także tzw. Bearer Token.

Protokół REST uznawany jest za bezpieczny ze względu na zastosowanie powszechnie stosowanych metod.

Prosta komunikacja OPC UA w praktyce

Dzięki OPC UA ujednolicona i bezpieczna komunikacja w środowisku przemysłowym staje się rzeczywistością – od poziomu terenowego po chmurę. W ten sposób OPC UA przyczynia się do rozwiązania niektórych głównych wyzwań związanych z cyfryzacją i przemysłowym Internetem rzeczy (IIoT). Zalet OPC UA jest wiele: OPC UA to architektura elastyczna, przejrzysta, bezpieczna i niezależna od platformy. Jednolite interfejsy ułatwiają dostęp do szerokiej gamy aplikacji, takich jak systemy MES, SAP i ERP, bazy danych, platformy chmurowe itp.

Aby skorzystać z OPC UA i nawiązać komunikację za pośrednictwem OPC UA, wymagane jest oprogramowanie OPC, takie jak OPC Router. W ten sposób dane mogą być dostarczane jako klient OPC lub jako serwer OPC do innych zastosowań. Oprogramowanie powinno umożliwiać indywidualne, dostosowane do aplikacji wdrożenie. Można to zrobić za pomocą interfejsów lub tzw. wtyczek, np. dostępnych dla połączenia SAP lub przesyłania danych do chmury poprzez MQTT. W praktyce pozwala to na przesyłanie danych maszynowych bezpośrednio do chmury, do której można uzyskać dostęp z dowolnego miejsca.

Efektem są całościowo zoptymalizowane procesy, wzrost produktywności i trwała modernizacja Twojej firmy.

Zobacz też:

Serwery OPC i platformy komunikacyjne

To oprogramowanie przeniesie Twój zakład w świat Przemysłu 4.0! Wymieniaj dane w obu kierunkach pomiędzy sterownikami PLC (różnych producentów), bazami danych, systemami SAP (ERP), chmurą i wiele więcej...

KEPServerEX /
ThingWorx Kepware Server

KEPServerEX to platforma komunikacyjna, a zwłaszcza serwer OPC amerykańskiej firmy Kepware, należącej do grupy PTC. Produkt występuje także pod nazwą ThingWorx Kepware Server.

Szkolenia

Szkolenia z komunikacji przemysłowej opartej o standard OPC przeznaczone dla automatyków, informatyków, specjalistów ds. cyfryzacji i Przemysłu 4.0.

Od 1 do 4 dni. Teoria + praktyka.