Z pewnością każdy inżynier jest dumny ze swojego interfejsu HMI (Human-Machine Interface), podkreślając funkcje wyświetlania danych w czasie rzeczywistym, kolorową koordynację danych oraz opanowanie funkcji kontrolnych. Także dyrektor fabryki jest dumny z wyników umieszczonych na tablicy wskaźników wydajności KPI (Key Performance Indicators) oraz zwiększonej wydajności fabryki po wdrożeniu nowego systemu nadzoru produkcji MES (Manufacturing Execution System). Rozwiązania programowe, takie jak historian lub analytics, dostają kredyt zaufania, gdy problemy ze sterowaniem fabryką są zażegnane. Czy kiedykolwiek ktoś pomyśli, aby podziękować skromnemu sterownikowi? Bez danych HMI jest po prostu ładnym obrazkiem i najlepsze na świecie analizy są właściwie tylko nic niewnoszącymi pomysłami. Ty jednak wydajesz na to dziesiątki, setki i tysiące dolarów wówczas, gdy koszt sterownika nie jest uwzględniony nawet w specyfikacji materiałowej.
Prawdą jest, że sterownik komunikacyjny jest jednym z najważniejszych elementów systemu automatyki. Jest czymś w rodzaju paliwa, które zasila system. Arterie i żyły komunikacyjne znajdują się w każdym zakątku fabryki. Wysyłają i zbierają dane w sposób wydajny i niestrudzony. Zapewniają tym samym osiąganie najwyższej wydajności. Analizują i elastycznie przystosowują się do każdych warunków.
Narodziny branży
Sterowniki na przestrzeni lat ulegały wielu przemianom. Na początku był DOS (Disk Operation System), który był poprzednikiem Windows. Sterowniki były częścią składową danej aplikacji. Jeśli używałeś HMI, to sterownik był dostarczany także przez dostawcę danego HMI i mógł współpracować tylko z takim HMI.
Następnie nastały czasy Windows z nowymi możliwościami dotyczącymi wymiany informacji pomiędzy aplikacjami przy zastosowaniu technologii zwanej Dynamic Data Exchange (DDE). Długoletnie finansowe inwestowanie w sterowniki programowalne było tak zaawansowane, że nie można było się już wycofać z poniesionych nakładów. W 1995 r. powstała organizacja OPC, która miała udoskonalić najnowsze technologie Microsoftu oraz rozwinąć standardy współdziałania umożliwiające aplikacjom automatyki wymianę danych. Takie rozwiązanie przyniosło natychmiastowe korzyści. Ostatecznie dzięki OPC powstał jednolity wysoki standard wykonania, umożliwiający sterownikom lepsze dopasowanie się do więcej niż jednego dostawcy.
HMI jest oknem operatora na procesy zachodzące w fabryce, zapewniając wizualizację pomimo otaczających ścian pokoju sterowni. Podczas gdy HMI stanowi oczy fabryki, komunikacja to arterie i żyły, a sterowniki są paliwem, które zasila system.
Dostawcy szybko wykorzystali standardy OPC. Ich własne interfejsy komunikacyjne były powiększone o dodatkowe interfejsy OPC. Aplikacje dla klientów uzyskały standard OPC, a więc były dopasowane do sterowników innych producentów i ich produktów. Niezależni wykonawcy sterowników mogli teraz znaleźć szerszy rynek dla swoich produktów. Opracowano główny system powiązania sterowników. W ten sposób narodziła się nowa branża.
Nie był to jednak model doskonały, pomimo tego, że był to krok w dobrym kierunku. Choć standard istnieje dla potrzeb dalszego współdziałania systemów, to jednak twórcy sterowników sami decydują o stosowaniu się do tego standardu i testują współdziałanie do momentu osiągnięcia poziomu samocertyfikacji. Sterowniki wytwarzane przez różnych dostawców będą zasadniczo różnie działać oraz będą pracowały z różnymi interfejsami pod względem sposobów działania i diagnozowania. Sterownik stworzony na potrzeby jednej aplikacji niekoniecznie musi być dobry dla innych aplikacji. I pomimo że występuje znaczące zapotrzebowanie na stosowanie sterowników, to długoterminowy koszt utrzymania może być zbyt wysoki.
Czynniki te miały wpływ na rynek sterowników, przynosząc różne poziomy wykonania, niezawodności, funkcjonalności i jakości. Nawet sterowniki głównych dostawców – dostarczających sterowniki razem ze strategicznymi produktami HMI/SCADA – mogą przynieść straty z powodu braku zainteresowania i rozwoju spowodowanych wysokimi kosztami utrzymania. Wielu dostawców zaopatruje się w sterowniki u poddostawców, równoważąc tym samym zapotrzebowanie na duże ilości oraz szerokie doświadczenie w przemyśle firm specjalizujących się w rozwijaniu sterowników.
Nowe standardy poprawią współdziałanie sterowników. W lutym 2008 r. stowarzyszenie OPC wprowadziło nowy poziom certyfikacji. W przeszłości jedyną drogą do certyfikacji były narzędzia testujące oraz wspólne spotkania dostawców. Natomiast dziś proces ten odbywa się w niezależnym autoryzowanym przez OPC Foundation laboratorium znajdującym się w Niemczech. Oprócz zaleceń dotyczących instalacji i użytkowania, w laboratorium dokonuje się gruntownych testów trwających kilka dni, w celu wykazania zgodności ze wszystkimi wymogami OPC. Dostawcy mogą ostatecznie otrzymać logo „Certified OPC Compliant”. Kupujący powinni zwracać uwagę na ten znak z kilku powodów. Wskazuje on, że produkt osiągnął odpowiedni poziom jakości oraz firma poczyniła duże nakłady niezbędne do uzyskania odpowiednio wysokiego poziomu jakości. Ponadto wskazuje, że dany sterownik jeszcze długo nie wyjdzie z zastosowania.
Projekt sterownika
Jakich cech powinieneś szukać w sterowniku? Nie chodzi tylko o zbieranie danych z punktu A i przesyłaniu ich do punktu B. Sterowniki powinny być zaprojektowane pod kątem wydajności, łatwości w użytkowaniu, niezawodności i optymalnego działania w przypadku przerwy w działaniu. To właśnie przerwa w działaniu systemu stanowi dość istotny i często zapomniany punkt w rozwoju komunikacji.
Na wydajność składa się wiele czynników. Pierwszy to osiągi w komunikacji. Urządzenia generalnie oferują różnorodność mechanizmów do zbierania informacji. Są przystosowane do zbierania pojedynczych zmiennych odczytów, odczytów bloków danych oraz mają zdolność przypisania do danych i otrzymywania niezapowiedzianych aktualizacji.
Najlepsze sterowniki ustawią te opcje pod kątem potrzeb użytkownika, automatycznie wybierając metodę opartą na wymogach danych. Wykonanie musi być nastawione na priorytety różnorodnych zadań. Zapisywanie informacji dla urządzeń musi być wykonywane efektywnie i dawać gwarancje poprawności działania w momencie największego natężenia. Wysokie wymagania odczytu nie mogą pomijać możliwości wysyłania pisemnych poleceń. Pisanie z kolei nie może dominować (np. zapisywanie tysiąca zmiennych potrzebnych do zmiany receptury mogłoby łatwo przerwać normalny proces odczytywania oraz wpłynąć na gromadzenie danych jakiegoś krytycznego szybkiego procesu).
Ostatecznie wymagania sterownika komunikacyjnego nie powinny nadmiernie wpływać na pracę komputera, na którym jest zainstalowany. Aplikacje często mają liczniki ciągów do setek tysięcy, niektóre aktualizuje się często, a inne wtedy, gdy aktywna jest diagnostyka. Sterowniki muszą być zoptymalizowane na jednoczesne wykonywanie wielotorowych operacji. Muszą alokować efektywnie pamięć oraz unikać wpływu na inne procesy biegnące jednocześnie w komputerze. Łatwość obsługi powinna być widoczna od razu. Menu konfiguracji powinno być łatwe i proste w obsłudze. Menu pomocy musi być zrozumiałe, szczegółowe, a objaśnienia umieszczone w konkretnym kontekście. Idealnym byłoby, gdyby sterownik wykazywał cechy samokonfiguracji wszędzie tam, gdzie byłoby to możliwe.
Wiele współczesnych urządzeń ma specyficzne cechy własnej konfiguracji, gdy chodzi o samo urządzenie, jak również o plik programowy, który może być bez trudu odkodowany przez sterownik samokonfiguracyjny. Często ta funkcja jest uruchamiana przez kreator konfiguracji. Jednakże dla wielu sterowników jest to funkcja automatyczna. Rzadko się zdarza, aby inżynier konfigurował sterownik poprzez menu. Bardziej prawdopodobnym scenariuszem jest konfiguracja jednej części procesu, prawdopodobnie jednej z wielu linii produkcyjnych, a następnie skopiowanie i wklejenie – zaimportowanie lub wyeksportowanie – w celu powielenia konfiguracji z niezbędnymi nastawami.
Excel jest ciągle najszerzej stosowanym narzędziem w automatyce wykorzystywanym do procesu samoczynnego nazywania i replikowania list wejść/wyjść. Jednym z wyzwań jest możliwość pogodzenia konfiguracji różnych sterowników z różnych źródeł dostaw. Jak zostało powiedziane wcześniej, sterowniki każdego z dostawców kompletnie się różnią z punktu widzenia konfiguracyjnych baz danych. Jedynym rozwiązaniem tego problemu jest wyselekcjonowanie sterowników od dostawcy, który skupił się na spójności biblioteki sterowników – nie tylko pod kątem działania, ale także we wszystkich narzędziach konfiguracyjnych.
Niezawodność jest konieczna w tej dziedzinie. Partia leków może być warta miliony dolarów. Nie ma tu miejsca na awarię. Co zatem zrobić, żeby sterownik był niezawodny? Niezawodność jest więc wynikiem doświadczenia, ponownego wykorzystania zbadanego kodu, testowania w rozwiązaniach przemysłowych, spotkań kooperacyjnych i wewnętrznych praktyk mających na celu rozwój oraz właściwe zapewnienie jakości sterownikowi, zanim zostanie zainstalowany na obiekcie. Niestety wiele sterowników nie spełnia potrzeb integracji systemu, są więc przeznaczane do standardowej oferty. W świecie sterowników oznacza to „uważaj na kupującego”. Nie jest to więc zbyt często dobry interes, gdy trzeba będzie w przyszłości zainwestować ponad 10 razy więcej w samą konfigurację i dostrajanie, aniżeli wynosiłby koszt samego sterownika.
Sterowniki podczas pracy
Co z pracą, jeżeli sprawy nie układają się pomyślnie? Gdy sterownik ma zapewnione optymalne warunki, wówczas będzie wykonywał swoje funkcje poprawnie. Jednak nie można liczyć na to, że warunki te będą zawsze najlepsze. Istnieje wiele typów błędów komunikacyjnych, które są często lekceważone przez niestarannych dostawców sterowników. Sterowniki mogą być komunikowane drogą bezprzewodową i mogą otrzymywać zakłócone wiadomości z powodu przeszkód atmosferycznych, w tym burz lub innych form zakłóceń. Sterowniki mogą komunikować się z setkami urządzeń. Jedne pracują, a inne nie. Awaria jednego urządzenia nie powinna mieć wpływu na komunikację z innymi urządzeniami. Inne programy mogą przypadkowo próbować skomunikować się ze sterownikiem, zalewając go nieprzewidywalnymi informacjami.
Zwraca to uwagę na szczegóły przy projektowaniu buforów komunikacyjnych, planów przestojów oraz strategii systemu pytań w celu zmaksymalizowania operacji w przypadku niekorzystnych warunków. Sterowniki często charakteryzują się tym, że mają funkcje do automatycznego obniżania priorytetu, umożliwiając sterownikowi wstrzymanie wysyłania zapytań do uszkodzonego urządzenia, a tym samym zredukować jego wpływ na cały system.
Najlepsze sterowniki są zaprojektowane tak, aby radziły sobie z tego typu sytuacjami i zapewniały konsekwentnie funkcjonalność pośród najszerszej gamy protokołów. Muszą dać inżynierom odpowiedzialnym za procesy łączność pomiędzy ich urządzeniami. Następnym razem, gdy będziesz rozpatrywał zakup sterownika, pomyśl, jak będzie pracowała twoja aplikacja, jeśli coś się zepsuje. Wydawaj swoje pieniądze rozsądnie.
Roy Kok jest wiceprezesem w firmie Kepware Technologies. Wcześniej zajmował się marketingiem i zarządzaniem produktami HMI/SCADA firmie GE Fanuc. Przed przejściem do GE Fanuc Kok zajmował kluczowe pozycje w znanych firmach przemysłu automatyki, m.in.: Intellution, VenturCom, Sytech, Negatron, Intec Controls oraz Kaye Instruments.
Artykuł pod redakcją Marka Olszewika
Autor: Roy Kok
