OPC UA
Najnowszą wersją standardu OPC jest UA (Unified Architecture). Wcześniejsze szybko zyskały na popularności, gdyż skutecznie rozwiązały problem z wymianą danych w automatyce niezależnie od producenta sprzętu. Ich wadą była jednak zależność od platformy, gdyż opierały się na API COM i DCOM Microsoft (patrz: ramka), przez co możliwości instalacji serwerów i klientów OPC były ograniczone do systemu operacyjnego Microsoft Windows. Z tego powodu w miarę upowszechniania się takich platform jak Linux, chmura i urządzenia IoT, popularność OPC zaczęła spadać. Doprowadziło to do opracowania wersji UA, niezależnej od platformy i interoperacyjnej. Osiągnięto to, opierając się na technologiach sieciowych TCP/IP i http/SOAP. Początkowo wykorzystywano architekturę klient–serwer, a od niedawna także typu publikuj–subskrybuj, co umożliwia komunikację multicast.
OPC przed OPC UA
COM (Component Object Model) to interfejs programistyczny umożliwiający komunikację między komponentami oprogramowania opatentowany przez firmę Microsoft. Ponieważ było to wiodące rozwiązanie w czasie prac nad protokołem OPC, został on na nim oparty. W wersjach sprzed OPC UA serwer był komponentem COM, do którego podłączał się klient. Jeśli klient podłączał się przez sieć, wykorzystywano Distributed COM (DCOM), sieciową wersję interfejsu COM. DCOM ma złożoną logikę uwierzytelniania i wykorzystuje wiele dynamicznych połączeń TCP/IP. To czyni go niekontrolowanym przez firewall i kategorycznie blokowanym. Z powodu interfejsu DCOM komunikacja międzysieciowa w klasycznej wersji standardu OPC była bardzo utrudniona lub niemożliwa. W związku z tym opracowano obejście tego problemu w postaci techniki tunelowania. Polegało ono na konwersji do formatu opartego na protokole TCP/ IP, tak by transmisja danych nie była blokowana przez firewall. W sieci docelowej następowała konwersja odwrotna i dane były udostępniane na serwerze OPC. W standardzie OPC UA tunelowanie nie jest już konieczne. |
W pracach nad OPC UA od początku duży nacisk kładziony był na kwestie bezpieczeństwa. Inaczej niż w przypadku wcześniejszych wersji w tym przypadku zastosowano podejście firewall friendly, co oznacza, że wykorzystywane są standardowe sieciowe rozwiązania bezpieczeństwa. Przykładami są: szyfrowanie danych, podpisywania wiadomości, sekwencjonowanie pakietów i uwierzytelnianie użytkownika. Każdy klient musi się uwiarygodnić za pomocą certyfikatu.
Specyfikacje oraz OPC UA over TSN
Standard OPC UA składa się z kilku specyfikacji. W serwerach i klientach OPC implementowane są wybrane z nich. Kluczowe znaczenie ma ta dotycząca wymiany danych.
Jak we wcześniejszych wersjach standardu, OPC jest zorientowana na punkty danych. Dla każdego z nich można odczytywać i zapisywać wartość opisaną znacznikiem czasu, kiedy była aktualna oraz wskaźnikiem jakości, który określa, czy wartość jest aktualna czy, na przykład na skutek przerwania połączenia ze sterownikiem, straciła już ważność. W OPC UA specyfikacja ta została uzupełniona o nowe typy danych i dodatkowe funkcje.
Zestandaryzowany jest też dostęp do danych archiwalnych. Serwer implementujący tę specyfikację musi mieć wewnętrzną pamięć danych, zaś klient odczytujący dane historyczne musi określić okres, dla którego chce poznać wartości konkretnych punktów danych. W oddzielnym dokumencie zostały zestandaryzowane modele komunikatów alarmowych i logika alarmów.
Dostępne są poza tym specyfikacje towarzyszące opracowywane przez grupy branżowe w oparciu o model standardowy OPC UA. Definiuje się w nich struktury punktów danych dla konkretnych aplikacji i obiektów – przykładami się modele dla wtryskarek, obrabiarek, robotów. Listę oficjalnie zaakceptowanych specyfikacji towarzyszących można znaleźć na stronie internetowej organizacji OPC Foudation, która zarządza standardem OPC.
Warto na koniec wspomnieć o specyfikacji OPC UA over TSN. Jest to oparta na modelu publikuj–subskrybuj wersja tego standardu opracowana na potrzeby komunikacji w czasie rzeczywistym w sieciach automatyki w przemyśle.
