Standaryzacja programowania przemysłowych systemów sterowania dzięki językom opisanym w normie IEC 61131-3

Po raz pierwszy w historii automatyki przemysłowej programowanie przemysłowych systemów sterowania (ICS) może być zrealizowane niezależnie od typu sterownika – za pomocą tego samego standardowego języka, zaś programy tworzone w takim ustandaryzowanym języku mogą być łatwo przeniesione z jednego kompatybilnego systemu sterowania do innego.

Dzięki normie IEC 61131-3, opracowanej przez międzynarodową organizację PLCopen, użytkownicy przemysłowych systemów sterowania (ICS – industrial control systems) mają możliwość swobodnego wyboru optymalnego sprzętu czy modułów sterowniczych do wykorzystania w swoich aplikacjach i nie muszą już być dłużej uzależnieni od firmowego sprzętu, pochodzącego tylko od jednego producenta, jak miało to niejednokrotnie miejsce w dotychczasowych inwestycjach w sprzęt i oprogramowanie napisane według zamkniętych, firmowych standardów takiego producenta.

Najnowsza wersja międzynarodowej normy IEC 61131-3, będącej międzynarodowym standardem programowania przemysłowych systemów sterowania, opisuje zarówno języki niskiego poziomu, przeznaczone do szczegółowego programowania sterowników PLC i PAC, jak i cechy języków obiektowych (OOL – object-oriented language), wykorzystywanych do tworzenia i konfigurowania rozproszonych systemów sterowania (DCS) oraz przemysłowych komputerów PC wysokiego poziomu. Zarówno w przypadku dyskretnego programowania niskiego poziomu sterowników PLC, jak i programowania wysokiego poziomu systemu DCS, sterującego ciągłym procesem wsadowym zgodnym z normą ISA-S88, ten sam standard języków programowania – IEC 61131-3 i nowoczesne środowiska deweloperskie umożliwiają programistom systemów ICS również pełną symulację ich programów oraz proponowanych ekranów interfejsów operatorskich (HMI – human-machine interface), co zapewnia, że zaprogramowane ostatecznie systemy i aplikacje sterowania będą prawidłowo działać w praktyce.

Inżynierowie automatycy mają obecnie do wyboru wiele możliwych narzędzi i technik programowania sterowników przemysłowych, co może wprowadzać pewne zamieszanie i zakłopotanie. Narzędzia programistyczne ewoluowały według różnych ścieżek, częściowo na skutek zadań, do których były przeznaczane, jednak głównie z powodu ograniczeń dawnego sprzętu, ewolucji specjalistycznych narzędzi w ramach większych narzędzi aplikacyjnych, zależnie od cech i funkcji właściwych tylko dla określonych producentów układów automatyki oraz braku jednolitych, międzynarodowych standardów. Na szczęście nowoczesny sprzęt i nowoczesne standardy, w tym IEC 61131-3, PLCopen i OPC-UA, umożliwiły opracowywanie aplikacji systemów ICS, od sterowników PLC poprzez sterowniki PAC, zabezpieczenia, jednostki RTU (odległe jednostki końcowe – remote terminal unit), sterowanie ruchem, komputery IPC, aż po systemy DCS i całą ścieżkę do sterowania procesami wsadowymi zgodnymi z ISA-S88/S95 w tym samym środowisku i w tym samym standardzie. Nie jest już dłużej konieczne uczenie się obsługi i używanie różnych narzędzi, przy zmieniających się wymaganiach systemów i urządzeń automatyki przemysłowej.

Analogicznie, dzięki nowym standardom firmy przemysłowe nie muszą już dłużej być uzależnione od jednego tylko producenta sprzętu automatyki oraz związanego z tym sprzętem oprogramowania, będącego własnością tegoż producenta. Programy aplikacyjne systemów ICS, opracowane przy wykorzystaniu norm IEC 61131-3 i PLCopen, mogą być przeniesione z jednego kompatybilnego zintegrowanego środowiska programistycznego (IDE – integrated development environment) do zupełnie innego. Do tej pory platforma kompatybilna z IEC 61131-3/PLCopen jest wykorzystywana przez ponad 350 producentów wyposażenia oryginalnego (OEM). W tym postępującym procesie standaryzacji można zauważyć podobieństwa do lat 80. XX w., gdy producenci pierwszych komputerów PC dostarczali swoje własne systemy operacyjne aż do umocnienia się systemów firm Microsoft i Apple, albo do lat 90., gdy producenci pierwszych smartfonów dostarczali swoje własne systemy operacyjne aż do umocnienia się systemów Android oraz iOS. Podobna konsolidacja w świecie programowania aplikacji systemów ICS ma miejsce obecnie, gdy dostępne są standardy i metodologie ujednolicające.

Rys. 1. Norma IEC 61131-3 zawiera tradycyjną logikę drabinkową (LD) i model pamięci płaskiej w celu ułatwienia programistom przejścia ze starych narzędzi programistycznych na nowe. Źródło: Bedrock Automation

Narzędzia opisane w normie IEC 61131-3

Norma IEC 61131-3 obejmuje w pierwszym rzędzie tradycyjną logikę drabinkową (LD, ladder logic) i płaski model pamięci (flat memory), co ułatwia programistom przejście ze starszych narzędzi na nowe. Jednak IEC 61131-3 zawiera także strukturalne i obiektowe narzędzia programistyczne, przeznaczone do tworzenia aplikacji wysokiego poziomu i opracowane w dużym stopniu w celu ułatwienia pracy nowemu pokoleniu inżynierów, którym często włos jeży się na głowie na myśl o programowaniu w języku swoich dziadków i pradziadków. Narzędzia te obejmują trzy nowe języki programowania, neutralne językowo hierarchiczne bloki funkcyjne, symboliczne adresowanie hierarchiczne, wskaźniki, metody, dziedziczenie oraz interfejsy.

Dlatego też, poza tradycyjną logiką drabinkową nowe języki IEC 61131-3 obejmują: język strukturalny (ST – structured text), język graficzny SFC („sekwencyjną kartę funkcji”, sequential function chart) oraz język graficzny CFC („ciągłą kartę funkcji”, continuous function chart). Logika drabinkowa pozostaje dobrym narzędziem do tego, co zostało wynalezione i opracowane już niemal sto lat temu: prostej logiki dyskretnej, która mogła być wykorzystana w układach przekaźnikowych i czasowych. Język SFC jest doskonałym narzędziem do operacji sekwencyjnych lub zależnych od stanu (wszędzie, gdzie następna akcja zależy od historii oraz wejść). CFC jest nowym językiem graficznym i doskonałym narzędziem wysokiego poziomu, do umieszczania i wzajemnego łączenia wbudowanych, gotowych lub zbudowanych przez użytkownika, bloków funkcyjnych.

Język CFC służy do tego samego celu co SFC, jednak jest znacznie lepszą alternatywą dla umieszczania bloków bibliotek lub instrukcji add-on w logice drabinkowej. Natomiast język ST jest dobry do każdego innego programowania (pętle, warunki, złożona matematyka, manipulacja bitami itd.).

Rys. 2. Niezależna od języków natura normy IEC 61131-3 umożliwia stworzenie programu sterującego pracą silnika w języku najlepszym do tego celu: język SFC realizuje kroki (stany), logika drabinkowa – tranzycje, a język strukturalny – akcje. Źródło: Bedrock Automation

Elastyczność funkcjonalna języków opisanych w normie IEC 61131-3

Olbrzymią zaletą języków opisanych w normie IEC 61131-3 jest możliwość tworzenia za ich pomocą programów zarówno małych, jak dla pojedynczego sterownika PLC obsługującego silnik, jak i dużych, jak dla systemu DCS sterującego pracą zakładu przemysłu przetwórczego. Na przykład program sterujący silnika może być zrealizowany w postaci drabinki, jak pokazano na rys. 1. lub, ponieważ jego zachowanie zależy od historii, może okazać się bardziej sensowne napisanie go w języku SFC. Implementacja tego języka może również doprowadzić do powstania aplikacji korzystającej ze swego rodzaju mieszaniny różnych języków, przy czym stany/kroki są realizowane przez język SFC, tranzycje (przejścia, transitions) przez logikę drabinkową, zaś akcje przez język strukturalny (patrz rys. 2).

Modele niższego poziomu, takie jak sterownik silnika, mogą być łączone w celu tworzenia modeli wyższego poziomu. Te bloki konstrukcyjne mogą być modelami tworzonymi przez użytkownika lub obiektami z biblioteki procesowej. Używając zestawu modeli zbiorników zbudowanych z czujnika wejściowego, układu sterującego, pompy wyporowej (PD – positive displacement pump) i obiektów pomp, które same są zbudowane z obiektów niższego poziomu, można stworzyć system sterowania DCS dla całej fabryki przemysłu przetwórczego. Obiekt sterujący jest także zbudowany z obiektów niższego poziomu, co obejmuje wykorzystanie języka SFC do zarządzania procesami przepłukiwania i napełniania oraz bloków sterujących do zarządzania pracą pompy wyporowej i pętlami sterowania tej pompy.

Te bloki sterujące są wykonane na podstawie napisanego w języku strukturalnym bloku użytkownika, który oblicza różnicę pomiędzy całką sygnału przepływu wejściowego a akumulacją impulsów pompy PD. Wyjście tego bloku steruje filtrem dolnoprzepustowym, znajdującym się w otwartej bibliotece układów sterowania OSCAT (Społeczność Otwartego Kodu Źródłowego dla Technologii Automatyki, Open Source Community for Automation Technology), który z kolei steruje blokiem proporcjonalno-różniczkująco-całkującym (PID), pochodzącym także z biblioteki OSCAT.

Techniki hierarchicznego projektowania w językach z normy IEC 61131-3 nieznacznie upraszczają projektowanie zaawansowanych systemów sterowania w fabrykach. Mają one wpływ także na ogólną strukturę projektów, które są w rezultacie bardzo użyteczne dla służb utrzymania ruchu w fabrykach. Rozważmy np. technika zakładowego, który został wezwany do rozwiązania problemu z silnikiem napędzającym pompę wyporową w zbiorniku mieszaniny nr 2 w strefie przetwarzania nr 3. Technik ten może rozpocząć pracę od góry i podwójnie kliknąć na każdym bloku, aż do osiągnięcia pompy wyporowej krzemionki na widoku systemu sterowania i sprzętu lub iść tam bezpośrednio za pomocą widoku urządzenia.

Następnie technik kontroluje wejścia pompy, aby sprawdzić, czy do silnika dochodzi sygnał uruchomienia. Jeśli tak, to przechodzi do samej pompy oraz modelu jej silnika, aby zobaczyć, dlaczego silnik nie pracuje. Jeśli natomiast do silnika nie dochodzi sygnał uruchomienia, to technik bada blok sterujący znajdujący się w systemie przed pompą, aby dowiedzieć się, dlaczego sekwencja robocza pompy została zatrzymana na etapie przed włączeniem silnika. Ponieważ kod programu sterującego odzwierciedla hierarchię fabryki, to nawigowanie do właściwego obszaru w tym kodzie jest intuicyjne. A ponieważ wszystkie fizyczne układy We/Wy (I/O) są zlokalizowane na modelach sprzętu, to odnajdowanie i rozwiązywanie problemów jest także intuicyjne. Nie ma potrzeby dodatkowego szkolenia techników zakładowych w zakresie rozpoznawania i obsługi złożonych procedur rozwiązywania problemów w skomplikowanym kodzie sterującym.

Rys. 3. Cechy programowania obiektowego zgodnego z normą IEC 61131-3, obejmujące dziedziczenie, interfejsy i wskaźniki, umożliwiają proste wdrożenie procesów wsadowych S88.

Idąc jeden krok dalej, dziedziczenie i wskaźniki mogą być wykorzystane do wdrożenia technik modelowania procesów wsadowych, zgodnych z normami ISA-S88 oraz ISA-S95, bezpośrednio w normie IEC 61131-3, co staje się coraz ważniejsze, ponieważ różne platformy automatyki są wdrażane w seryjnych schematach integracyjnych na poziomie całego przedsiębiorstwa, obejmując zasoby połączone w sieci (rys. 3). Po lewej stronie tego rysunku pokazano, w jaki sposób klasa podstawy sprzętowej, posiadająca układy We/Wy i funkcjonalność taką jak cały sprzęt w zakładzie, może być dziedziczona za pomocą wielu klas jednostek – co definiuje wejścia i wyjścia oraz fazy dla danej klasy – i same mogą być dziedziczone przez wiele typów sprzętu. Fazy, które są budowane za pomocą podobnej struktury klas, definiują operacje możliwe do realizacji w klasie jednostki sprzętowej. Następnie fazy te są konkretyzowane w tych klasach jednostek sprzętowych, dla których są one istotne. Operacje, procedury, moduły i komórki procesu są zestrukturyzowane podobnie, aby utworzyć kompletny system procesu wsadowego S88.

Po prawej stronie rysunku 3 pokazano, w jaki sposób obiekty z tej hierarchii klas są konkretyzowane w projekcie. Klasa podstawowa zbiera informacje na temat sprzętu wraz ze związanymi z nim fazami i zapisuje te informacje w rejestrze. Następnie rejestr ten jest udostępniany dla serwera procesu wsadowego za pomocą standardu komunikacyjnego OPC-UA. Serwer wykorzystuje te informacje do określenia miejsca i czasu uruchomienia procesów wsadowych. Następnie, na podstawie wybranej receptury oraz wolnego sprzętu, serwer procesu wsadowego wysyła wybrane receptury z powrotem do programu głównego za pomocą OPC-UA. Wówczas program główny wykorzystuje wskaźniki przechowywane w rejestrze do wykonania pożądanych faz przez właściwy sprzęt.

Dzięki mechanizmowi dziedziczenia złożoność operacji klasy podstawowej jest ukryta przed programistą. Wszystko, co musi on zrobić, to tylko zmontować pochodzące z biblioteki bloki, które odzwierciedlają różne typy sprzętu. Ewentualnie, wykorzystując obiekty dynamiczne, programista może skonfigurować strukturę także z serwera procesu wsadowego.

Rys. 4. Cechy języków normy IEC 61121-3 oraz wbudowane i obejmujące wszystkie funkcje symulatory promują walidację i weryfikację systemów sterowania oraz interfejsów operatorskich (HMI) przed wdrożeniem projektu. Źródło: Bedrock Automation

Testy symulacyjne udowadniają właściwe działanie aplikacji sterujących

Oczywiście żaden projekt systemu sterowania ICS nie jest kompletny, zanim nie będzie mógł być przetestowany i zweryfikowany w praktyce. Na szczęście cechy języków z normy IEC 61131-3 oraz ich wdrożenia dostarczają narzędzia, które czynią testowanie bardzo łatwym procesem. Na rys. 4 pokazano, w jaki sposób można zmontować bloki symulacyjne fabryki i stworzyć z nich kompletny model symulacyjny tej fabryki, który może być podłączony do kodu sterującego wymiennie z fizycznymi układami We/Wy.

Następnie ten kod sterujący i symulacyjny może być wykonany na symulatorze uruchomieniowym, zainstalowanym na komputerze typu PC, dzięki czemu można udowodnić, że aplikacje sterujące kompletnego systemu są wolne od błędów jeszcze przed zakupem jakiegokolwiek sprzętu. Wykorzystując środowiska uruchomieniowe na komputerach PC, serwer OPC-UA umożliwia także projektowanie i testowanie ekranów interfejsów operatorskich. W efekcie zyskuje się pewność, że projekt systemu ICS jest kompletny i poprawny jeszcze przed rozpoczęciem instalowania czy uruchomienia sprzętu.


Gary Pratt jest menedżerem tworzenia aplikacji w firmie Bedrock Automation.