OPC UA i AWS - integracja serwera OPC UA z AWS IoT SiteWise

Integracja OPC UA z AWS - jak wpiąć serwer OPC UA do AWS IoT SiteWise lub MQTT, żeby dane z PLC trafiły do chmury i bazy danych takiej jak TimescaleDB. Artykuł jest dla osób, które już wiedzą czym jest OPC UA i potrzebują wyjaśnienia jak można zintegrować go z usługami AWS.

Przemysł 4.0 to przede wszystkim zbieranie danych z maszyn, obiektów i procesów, a następnie podejmowanie świadomych decyzji na podstawie tych danych. Umożliwia to zaawansowaną analitykę, modelowanie AI/ML oraz analizy w czasie rzeczywistym, co pozwala na poprawę efektywności produkcji. Z AWS IoT SiteWise płacisz tylko za to, z czego korzystasz, bez opłat minimalnych ani obowiązkowego korzystania z usługi. Opłaty są naliczane osobno za wiadomości, przetwarzanie danych, przechowywanie danych, eksport danych i alarmy. Pozwala to na stworzenie Proof of Concept z minimalnym budżetem, a następnie skalowanie w miarę potrzeb.

Integrujemy OPC UA, a także inne protokoły komunikacji (Modbus TCP, Siemens S7, MQTT) z AWS w fabrykach. Najczęściej z wykorzystaniem którejś z trzech architektur opisanych poniżej.

OPC UA - co to jest i jaki port wykorzystuje

OPC UA (Open Platform Communications Unified Architecture) to standard komunikacji przemysłowej, który definiuje jak urządzenia OT (PLC, czujniki, sterowniki) wystawiają swoje dane na zewnątrz. Następca starszego OPC DA - działa cross-platform (Linux, Windows, embedded), ma wbudowany model bezpieczeństwa (certyfikaty, szyfrowanie, autoryzacja użytkowników) i pozwala modelować dane w postaci struktur (asset model).

Domyślny port OPC UA to 4840 dla wariantu binarnego (opc.tcp://). Standard dopuszcza także opc.http:// na porcie 80 i opc.https:// na 443, ale w praktyce w fabrykach 99% wdrożeń to opc.tcp na porcie 4840. To pierwszy port, który trzeba otworzyć między siecią OT a bramą przemysłową.

3 architektury integracji OPC UA z AWS

Architektura 1 - AWS IoT SiteWise Edge Gateway

To natywna ścieżka AWS dla integracji OPC UA z chmurą. Może też podłączyć się natywnie do: brokera MQTT, CloudRail, EasyEdge, Litmus Edge. SiteWise Edge Gateway może zostać zdeployowany na dwóch platformach edge:

• Self-Hosted - najczęstsza opcja, PC z Linuxem lub Windowsem
• Siemens Industrial Edge - dla fabryk z istniejącą infrastrukturą Siemens

Stack: PLC z serwerem OPC UA → PC z SiteWise Edge Gateway → AWS IoT SiteWise w chmurze → Baza danych / S3 / inne usługi AWS.

Kiedy ma sens:

• Greenfield projekt
• Standardowe asset models (maszyna, linia, hala)
• Budżet na dedykowany Industrial PC
• Chcesz wykorzystać natywne podejście AWS bez utrzymywania własnego kodu

Realne pułapki:

Duplicate TQVs. AWS ostrzega o tym w dokumentacji IoT SiteWise. Efekt: podwójne rozliczenie za te same dane. Fix: zawsze sprawdź konfigurację node filtering.

Brak filtrów = nieoczekiwany rachunek. Bez node filters cały tree leci do chmury. Zawsze używaj wildcards i testuj na środowisku testowym.

Architektura 2 - Custom Greengrass Component (OPC UA przez MQTT)

Greengrass z OPC UA to elastyczna ścieżka, gdy potrzebujesz logiki na edge zanim dane wylądują w chmurze. Część obliczeń, filtrowania można zrobić na bramie przed wysłaniem do chmury dzięki czemu można zaoszczędzić na kosztach chmury (mniej danych do przetworzenia i przechowywania) i mieć większą kontrolę nad tym, co trafia do AWS. To rozwiązanie jest bardziej skomplikowane, bo trzeba napisać własny komponent Greengrass, który będzie łączył się z serwerem OPC UA, parsował dane i publikował je do AWS IoT Core przez MQTT. Przydaje się również gdy połączenie z internetem jest słabe lub kosztowne, więc jak najmniej danych ma zostać przesłane.

Stack: PLC OPC UA → Greengrass na bramie z własnym komponentem (Python: python-opcua lub Node.js: node-opcua) → publikuje JSON do MQTT topics IoT Core → baza danych np. AWS RDS lub EC2 z TimescaleDB.

Kiedy ma sens: kiedy chcesz zaprogramować własną logikę na edge (filtering, agregacja OEE pre-cloud, własny kod) przed przesłaniem danych do chmury

Pułapki: utrzymanie własnego komponentu (update’y Greengrass mogą popsuć kompatybilność), trzeba napisać własny kod do parsowania i transformacji danych, brak natywnych funkcji SiteWise.

Architektura 3 - Broker OPC UA (Kepware/Ignition) + MQTT do AWS IoT Core

Możliwe jest też wykorzystanie istniejącego brokera OPC UA (np. Kepware lub Ignition) jako translatora protokołów, który pobiera dane z PLC i publikuje je do AWS IoT Core przez MQTT. To rozwiązanie jest bardziej elastyczne, ale też droższe i wymaga dodatkowej warstwy oprogramowania.

Stack: PLC → Kepware/Ignition jako protocol translator → publikuje MQTT do AWS IoT Core → dalej Lambda/Kinesis/SiteWise/TimescaleDB/RDS

Kiedy ma sens:

• Brownfield z istniejącym Kepware lub Ignition
• Wiele różnych źródeł danych z różnymi protokołami: Modbus, OPC UA, Siemens S7
• Potrzeba zaawansowanych funkcji brokerów (własny szablon danych, transformacje)

Minusy:

• Dodatkowy koszt licencji oprogramowania Kepware lub Ignition
• Dodatkowa warstwa, którą trzeba obsługiwać

Modbus TCP na AWS przez OPC UA gateway

Jeśli masz starsze maszyny komunikujące się po Modbus TCP, najprostsza ścieżka do AWS to ich agregacja w Kepware/Ignition (które tłumaczą Modbus → OPC UA), a następnie wysyłka do AWS IoT Core po MQTT. Dzięki temu nie musisz pisać własnego konektora Modbus → AWS - wszystko unifikujesz na warstwie OPC UA.

OPC UA vs MQTT - kiedy co wybrać do AWS

To częste pytanie i krótka odpowiedź brzmi: to nie są zamienniki, tylko warstwy.

• OPC UA jest naturalnym wyborem do odczytu danych z PLC i urządzeń OT - ma model danych, bezpieczeństwo, sesje, jest standardem w automatyce.
• MQTT jest lekkim protokołem transportowym - świetny do wysyłania wiadomości z bramy do chmury (AWS IoT Core), nie definiuje co znaczy “temperatura silnika”.

W praktyce: na hali używasz OPC UA do komunikacji z PLC, na bramie tłumaczysz to na strukturę JSON/Sparkplug B i wysyłasz przez MQTT do AWS. Jeśli wybierasz Architekturę 1 (SiteWise Edge Gateway) - AWS robi to za Ciebie pod spodem. Jeśli Architekturę 2 lub 3 - musisz to zaprojektować sam.

Wybierz OPC UA + SiteWise gdy chcesz natywnego asset modelu w AWS i nie potrzebujesz custom logiki na edge. Wybierz OPC UA + MQTT do IoT Core gdy potrzebujesz własnego schematu danych, integracji z TimescaleDB/RDS, lub agregacji na edge.

Plan wdrożenia OPC UA → AWS w fabryce

1. Audyt istniejących urządzeń i serwerów OPC UA.
2. Wybór architektury.
3. Pilot na 1 maszynie / 1 linii produkcyjnej - typowo 6 - 10 tygodni.
4. Walidacja danych.
5. Skalowanie na resztę fabryki, fazami.
6. Monitoring i alerting (wdrożenie Grafany: ustalenie jak mają wyglądać dashboardy, polityki alarmów).
7. Audyt bezpieczeństwa OT i IT przed odbiorem końcowym.

Kiedy warto skontaktować się z konsultantem

Wpięcie OPC UA do AWS to nie projekt na weekend. Każda z trzech architektur ma swoje zastosowania, koszty i pułapki.

Realizujemy integrację OPC UA → AWS dla fabryk. Łączymy ekspertyzę AWS i Linux z głęboką znajomością protokołów przemysłowych (OPC UA, Modbus, Siemens S7, MQTT). Jeśli planujesz takie wdrożenie, skontaktuj się z konsultantem AWS - przejdziemy razem przez Twój stack, sprawdzimy kompatybilność i oszacujemy koszty chmury.