ekst pochodzi z nr 5/2017 magazynu "Control Engineering" 2017-12-04

Przepływ informacji w systemach SCADA

Właściwa komunikacja sieciowa pomiędzy sterownikiem PLC a komputerem z zainstalowanym systemem SCADA wymaga najpierw zrozumienia istoty tego procesu. To z kolei oznacza konieczność jednoznacznego określenia kilku elementów, takich  jak język, którym posługuje się komputer, oraz narzędzia potrzebne do usprawnienia procesu komunikacji.

Przyjrzyjmy się komunikacji sieciowej pomiędzy sterownikiem PLC a komputerem z zainstalowanym systemem SCADA.

 

Komunikacja sieciowa

Dla inżynierów oprzyrządowania, dyskutujących na temat systemów SCADA, komunikacja sieciowa była zawsze jednym z najbardziej drażliwych tematów.

Rozważmy sytuację, w której dysponujemy sterownikiem PLC z zapisaną w rejestrach pamięci informacją dotyczącą temperatury płynu w zbiorniku oraz nowiutkim komputerem z zainstalowaną najnowszą wersją pakietu SCADA XYZ (więcej o tym przykładzie: patrz ramka Online). Jak ów komputer będzie się komunikował ze sterownikiem PLC? Czy te urządzenia w ogóle mogą wymieniać między sobą informacje?

Odpowiedź brzmi: tak, ale aby jakiekolwiek dwa urządzenia mogły przekazywać sobie dane, muszą zaistnieć cztery elementy:

-> wspólny interfejs komunikacyjny lub wspólna sieć, a do tego oba urządzenia muszą być wyposażone w porty Ethernet lub innego standardu i być ze sobą połączone – bezpośrednio, za pomocą przełącznika sieciowego (switcha) lub za pomocą sieci przełączników;

-> wspólny język, zwany w automatyce protokołem komunikacyjnym;

-> znane adresy sieciowe – nie możemy zatelefonować do kogoś, kogo numeru nie znamy i ta sama sytuacja występuje w przypadku dwóch komunikujących się ze sobą urządzeń w sieci transmisji danych;

-> adresy pamięci – w urządzeniu typu slave lub serwer muszą się znajdować adresy pamięci umożliwiające adresowanie komórek albo obszarów pamięci w celu przechowywania przesyłanych danych.

Dyskusja na temat komunikacji w sieciach przemysłowych może się toczyć bez końca. Zamiast jednak wdawać się w dywagacje, powróćmy do naszego przykładu i zastosujmy w nim cztery wspomniane punkty.

-> Interfejs komunikacyjny – w naszym przykładzie sterownik PLC wyposażono tylko w port szeregowy RS232, nie mamy więc żadnego wyboru i musimy go użyć, a także upewnić się, że w komputerze PC również zainstalowano podobny port. Jeśli nie, możemy dokupić kartę portów szeregowych i włożyć ją do gniazda na płycie głównej komputera. Musimy też nabyć kabel szeregowy, sprawdzić, czy ma poprawny przydział pinów, a następnie włożyć wtyczki do gniazd portów szeregowych obydwu urządzeń.

-> Protokół komunikacyjny – nasz sterownik PLC wykorzystuje jeden z najpopularniejszych protokołów komunikacyjnych na świecie, czyli Modbus.

-> Znane adresy – ponieważ protokół komunikacji szeregowej sieci Modbus pozwala na istnienie w sieci tylko jednego urządzenia typu master i tylko master może zainicjować żądania komunikacji, to nie potrzebuje on żadnego adresu. Natomiast adres sterownika PLC, czyli urządzenia typu slave w sieci Modbus, jest ustawiony na 01.

-> Adres danych – w rozważanym przykładzie przydzielono obszar pamięci umożliwiający rejestrację danych; wartości temperatury cieczy w zbiorniku ustalono na poziomie 100°C.

Komputery i ich systemy operacyjne natywnie nie komunikują się za pomocą protokołu Modbus. Do tego wymagane jest odpowiednie oprogramowanie zainstalowane w komputerze. Jeśli używane przez nas oprogramowanie SCADA nie jest zgodne z protokołem Modbus, wymagany jest serwer OPC, który będzie pośrednikiem w komunikacji.

Serwer OPC – pośrednik w komunikacji

OPC to standard programowego interfejsu komunikacyjnego, który umożliwia programom działającym w środowisku Windows komunikowanie się z przemysłowymi urządzeniami automatyki:

OPC – jest to mechanizm OLE w sterowaniu procesami technologicznymi,

OLE – mechanizm łączenia i osadzania obiektów.

 

Serwer OPC to oprogramowanie, które konwertuje protokół komunikacji sprzętowej wykorzystywany przez sterownik PLC na protokół OPC. Oprogramowanie klienckie OPC to każdy program, który wymaga połączenia się z urządzeniami automatyki, np. oprogramowanie SCADA. Klient OPC wykorzystuje serwer OPC do uzyskiwania danych z urządzeń automatyki lub do wysyłania im poleceń (rys. 2).

Zaletę OPC stanowi to, że jest on standardem otwartym. Użytkownicy w zależności od potrzeb mogą wybierać między różnymi dostępnymi programami typu klient OPC (tj. dowolne oprogramowanie SCADA). System SCADA jest w stanie płynnie komunikować się ze sprzętem automatyki tak długo, jak istnieje serwer OPC, który potrafi komunikować się i ze sprzętem, i z systemem (rys. 3).

 

Serwery OPC są zwykle bardzo przyjazne dla użytkownika. W przypadku małej aplikacji, z jaką mamy do czynienia w naszym przykładzie, skonfigurowanie takiego serwera zajmie najwyżej kilka minut. Użytkownik jest zwykle proszony o skonfigurowanie czterech elementów: kanału, urządzenia, grupy, pozycji.

-> Kanał. Użytkownik definiuje interfejs komunikacyjny, protokół komunikacyjny oraz port wykorzystywany w komputerze PC. W naszym przykładzie są to: interfejs szeregowy, protokół transmisji szeregowej Modbus oraz port transmisji szeregowej COM1.

-> Urządzenie. Użytkownik przeważnie definiuje adres węzła sieciowego sterownika PLC. W przykładzie pokazanym na rys. jest tylko jeden sterownik PLC, a jego adresem jest 01.

-> Grupa. To pozycja opcjonalna, zwykły folder służący do posegregowania pozycji OPC, jeśli jest ich zbyt wiele. W tym przypadku stworzymy grupę i nazwiemy ją „Zbiornik”.

-> Pozycja. Pod tą nazwą kryje się aktualne miejsce przechowywania informacji w serwerze OPC. Każda pozycja odpowiada adresowi w pamięci sterownika PLC i dla każdej pozycji może istnieć opcja odczytu/zapisu lub tylko odczytu (w przypadku naszej temperatury cieczy w zbiorniku z pewnością nie musimy tu niczego zapisywać, chcemy tylko odczytywać wartość tej temperatury). W rozważanym przykładzie występuje tylko jedna pozycja OPC, o nazwie „Temperatura płynu w zbiorniku” (rys. 4).

 

Te cztery elementy reprezentują adres pozycji OPC. Może on być wywołany przez klientów OPC (tj. oprogramowanie SCADA XYZ). W następnym artykule z tej serii zostaną omówione: oprogramowanie SCADA i sposób definiowania jego znaczników, sposób wizualizacji, przechowywania i raportowania informacji oraz koncepcja klienta/serwera w aplikacjach SCADA.

Autor: Shady Yehia jest założycielem i autorem bloga o sterowaniu (The Control Blog), na którym opublikowano po raz pierwszy niniejszy artykuł, a także menedżerem ds. ofertowania sprzętu pomiarowego, produktów z branży automatyki i sterowania oraz usług inżynierskich w firmie zajmującej się integracją systemów procesów technologicznych.



ekst pochodzi z nr 5/2017 magazynu "Control Engineering"
Na podstawie: www.controlengineering.pl

Zapraszamy do skomentowania artykułu

Treść opini 
Popis 

Pozostałe artykuły z tej kategorii