Ostatnio wspominałem o przemysłowych systemach kontroli opartych na PLC (Programmable Logic Controller, czyli programowalny sterownik logiczny) i DCS (Distributed Control System, czyli rozproszony system sterowania). Zbierają one dane z czujników rozmieszczonych na obiekcie i zgodnie z zaimplementowanymi algorytmami sterują elementami wykonawczymi i regulują wartości. Same sterowniki, to jednak nie wszystko. Operator, czy to prostej maszyny, czy linii produkcyjnej, musi mieć podgląd jej stanu i możliwość wydawania komend. W najprostszym przypadku są to przyciski i lampki na drzwiach szafy sterowniczej. W wersji bardziej zaawansowanej panele operatorskie nazywane HMI (Human Machine Interface, czyli interfejs pomiędzy człowiekiem a maszyną). Jeśli mamy do czynienia z dużym obiektem, linią produkcyjną lub procesem, używany jest system komputerowy nazywany SCADA (Supervisory Control And Data Aquisition, czyli nadzór i pozyskiwanie danych).
Warto podkreślić różnicę pomiędzy HMI i SCADA, gdyż nazwy te bywają używane zamiennie, co jest błędem. HMI to interfejs między operatorem a maszyną, czyli np. ekran dotykowy, czy też ekran monitora, myszka i klawiatura. Natomiast SCADA to oprócz interfejsu z użytkownikiem cały system gromadzący i przetwarzający dane. W związku z tym HMI jest częścią SCADA.
SCADA zbiera dane z kontrolerów, archiwizuje, wizualizuje w zrozumiały dla użytkownika sposób, pokazuje alarmy, zdarzenia, trendy, pozwala sterować elementami wykonawczymi w trybie automatycznym i ręcznym, zmieniać nastawy i parametry. Składa się zwykle z serwera (lub serwerów) i kilku stacji operatorskich.
Projektując przemysłowy system kontroli możemy znaleźć się w jednej z dwóch sytuacji:
- dostajemy wolną rękę w doborze elementów składowych,
- elementy składowe są narzucone przez klienta.
W drugim przypadku powody mogą być różne: preferencje osób decyzyjnych, posiadanie produktów danego producenta, SCADA stanowi integralny element wybranego systemu (np. DCS), obawy przed koniecznością szkolenia personelu czy też strach przed nowym. Co ciekawe, często nowy system danego producenta jest diametralnie różny od produktu sprzed kilku czy kilkunastu lat, który jest obecnie użytkowany. W związku z tym szkolenie, tak czy owak, będzie konieczne.
Co robić w każdej z tych sytuacji? W przypadku, gdy klient sam wybrał system, a my uważamy, że nie jest to optymalna opcja, warto porozmawiać i poznać, co zadecydowało o takim wyborze. Z doświadczenia wiem, że racjonalnie argumentując można przekonać do wyboru innego, bardziej dopasowanego rozwiązania. Jeśli decyzja została już podjęta i nie ma pola do negocjacji trzeba dopilnować, żeby zakupić wersję produktu, która spełni wszystkie wymagania klienta. Osoby podejmujące decyzje nie zawsze są bowiem „techniczne”. Podstawą jest tutaj rozmowa i szczegółowe doprecyzowanie wymagań.
W sytuacji pierwszej, gdy mamy wolną rękę, cena nie powinna być jedynym kryterium branym pod uwagę przy wyborze rozwiązania. O czym warto zatem pamiętać?
W pierwszej kolejności należy ustalić, czy produkt wspiera protokół komunikacyjny, po jakim ma nastąpić wymiana danych ze sterownikiem. Najczęściej jest to OPC lub Modbus TCP, ale nie zawsze. Może to być również jeden z protokołów używanych w konkretnej branży, np. IEC61850. Warto sprawdzić, czy są jakieś systemy dedykowane do interesującej nas branży. Niektóre z branż mają bowiem specyficzne wymagania i są firmy wyspecjalizowane w dostarczaniu spełniających je rozwiązań. Ważnym czynnikiem jest architektura systemu. Może to być pojedynczy serwer albo rozwiązanie redundantne z dwoma. Czasem wystarczą natomiast same stacje operatorskie.
Kolejna istotna informacja dotyczy sposobu odczytywania danych ze sterowników: czy wszystkie komputery czytają bezpośrednio, czy też tylko niektóre z nich, przekazując dane do pozostałych. Z punktu widzenia bezpieczeństwa należy ustalić, czy składowe systemu zostaną połączone w sieć odizolowaną, czy też mającą dostęp do internetu. W drugim przypadku konieczne jest zadbanie o oprogramowanie antywirusowe, do tworzenia kopii zapasowych, firewall.
Licencje oprogramowania SCADA mogą być typu runtime, czyli tylko do uruchamiania gotowej aplikacji, lub development, pozwalające również na dokonywanie zmian w aplikacji. Wersja development jest oczywiście znacznie droższa, więc jeśli klient nie planuje dokonywać zmian w stworzonej aplikacji polecana jest licencja runtime. Kolejny czynnik wpływający na cenę licencji to ilość punktów danych (tagów). Konieczne jest oszacowanie i zakup licencji pokrywającej przewidywaną liczbę. Nie trzeba chyba dodawać, że im większa liczba tagów, tym droższa licencja. Pierwotny koszt zakupu licencji niekoniecznie musi być kosztem całkowitym. Licencja może być bowiem bezterminowa, albo też na czas określony, po którym należy zapłacić za jej odnowienie. Dodatkowy koszt może stanowić tzw. software update service, płatny zwykle raz do roku. W ramach tego serwisu otrzymuje się wszelkie aktualizacje oprogramowania. Porównując rozwiązania różnych producentów trzeba zwrócić uwagę, czy oprócz kosztu licencji głównego oprogramowania konieczny jest zakup licencji na dodatkowe programy (np. OPC, system bazodanowy itp.).
Czynniki mające wpływ na cenę są istotnymi, ale nie jedynymi kryteriami, które powinniśmy brać pod uwagę. Ważna są także: dostępność i popularność w kraju klienta, niezawodność, stabilność, opinie użytkowników. Dla przykładu, korzystniejsze jest czasem użycie nieco starszej, ale sprawdzonej, stabilnej i niezawodnej wersji, niż świeżo wypuszczonej na rynek, ale jak się okazuje, w pewnych kwestiach niedopracowanej. Nie do przecenienia jest jakość i dostępność dokumentacji oraz wsparcia technicznego. W trakcie tworzenia aplikacji zetkniemy się z wieloma wyzwaniami. Niektóre z nich okażą się stosunkowo łatwe do rozwiązania, inne będą wymagały pomocy ekspertów. Z kiepską dokumentacją i ograniczonym wsparciem producenta narażamy się na duże ryzyko.
Poczytajmy o procesie instalowania oprogramowania, w niektórych przypadkach jest to „przeklikanie” kilku kroków, podczas gdy w innych – żmudna procedura wymagająca przewertowania kilku manuali, forów internetowych i zdobycia „wiedzy tajemnej”. Różnie bywa z radzeniem sobie z przejściem do nowej wersji systemu. To ważne w przypadku modernizacji istniejącego systemu kontroli. Bywa, że konieczne jest ręczne przenoszenie baz danych, modyfikacja ścieżek dostępu, przeszukiwanie skryptów, ale bywa też tak, że po prostu otwiera się starą aplikację w nowszej wersji i można pracować.
Warto dowiedzieć się, jak odbywa się proces eksportu sygnałów ze sterownika do bazy danych systemu SCADA. Czy dostępne są narzędzia wspierające, czy też trzeba wszystko tworzyć ręcznie? Przy dużej ilości sygnałów będzie to czasochłonny proces. Istotne są wymagania klienta w odniesieniu do alarmów, zdarzeń, trendów. Miejmy pewność, że wybrany system pozwoli na ich realizację. Osoby lubiące tworzyć skrypty, własne narzędzia, powinny sprawdzić, czy taka możliwość jest wspierana (np. za pomocą wbudowanego edytora Visual Basic). Jest to niezwykle wygodna opcja, gdy tworzy się projekty używając oprogramowania jednego dostawcy. Daje możliwość zautomatyzowania wielu procesów.
Z punktu widzenia samej estetyki aplikacji istotna jest np. łatwość przeskalowywania grafik (przydatne, gdy mamy w systemie komputery o różnych rozdzielczościach), dostępność bibliotek z elementami, stosowanie wygładzania (antyaliasing), obecność wygodnych narzędzi do edycji, podążanie za światowymi trendami i standardami obowiązującymi w automatyce przemysłowej.
Jeśli aplikacja ma być dostępna w więcej niż jednym języku, produkt musi umożliwiać zaimplementowanie takiego rozwiązania. Wskazane jest sprawdzenie przed zakupem, czy dany język jest wspierany. Ogromne znaczenie ma też posiadana ekspertyza – zawsze starajmy się przekonywać klienta do systemów, które już znamy, mamy stworzone standardy, biblioteki, dokumentację. Jest to optymalna sytuacja. Tworzenie aplikacji od zera w nowym systemie wiąże się ze zwiększonym nakładem pracy, a co za tym idzie czasem, kosztami i ryzykiem.
Przedstawiłem tutaj istotne z punktu widzenia mojego doświadczenia aspekty, na które warto zwrócić uwagę rozważając zakup systemu SCADA. Możliwe, że istnieją jeszcze inne. Mam nadzieję, że dzieląc się moją wiedzą ułatwiłem dokonywanie wyboru oraz przyczyniłem do uniknięcia błędów, które mogłyby być kosztowne na etapie tworzenia aplikacji.
Rafał Cop
Artykuł pochodzi z wydania marzec/kwiecień 3/4 (162/163) 2021
