Jak dobrze dobrać kontroler do systemu sterowania?

Właściwe zaprojektowanie przemysłowego systemu sterowania wymaga od inżynierów przeanalizowania wielu obszarów. Proces ten wygląda inaczej w małych, kilkuosobowych firmach inżynierskich, w których wybór realizowany jest przez mały zespół, a inaczej w dużych przedsiębiorstwach, gdzie proces decyzyjny jest rozproszony. Na inne aspekty zwróci uwagę integrator, który ma dostarczyć i uruchomić system, a na inne użytkownik końcowy, który będzie z systemu korzystał. Obszary, które należy brać pod uwagę, zwykle w części nakładają się na siebie, dlatego warto przeanalizować każdy z nich z osobna, a następnie holistycznie ocenić, jak nasz wybór wpisuje się w oczekiwania użytkownika.

Obszary, jakie będziemy analizowali to:

• Przeznaczenie urządzeń.
• Architektura pracy.
• Wielkość aplikacji sterującej.
• Możliwości programistyczne.
• Możliwości komunikacyjne.
• Praca w układach wysokiej dostępności.
• Integracja z rozwiązaniami Edge.
• Serwis, obsługa i utrzymanie.
• Cena i koszty utrzymania.

Zanim zaczniemy analizę, warto krótko wspomnieć, czym są rozwiązania PACSystems. Emerson Machine Automation Solution – dział odpowiedzialny za rozwój obszaru PLC i PAC – wiele lat temu podjął decyzję, że wszystkie oferowane urządzenia będą programowane za pomocą jednego środowiska i będą ze sobą w pełni kompatybilne pod kątem programistycznym. Taki model daje szereg korzyści dla użytkownika systemu oraz dla projektanta aplikacji. Dzięki opanowaniu jednego narzędzia uzyskują oni możliwość wykorzystania zdobytej wiedzy w aplikacjach różnego typu, przenoszenia funkcjonalności pomiędzy różnymi seriami urządzeń, a także łatwej migracji systemu z mniejszego do większego kontrolera.

Przeznaczenie urządzeń

Branża i typ aplikacji bardzo często pozwalają właściwie dokonać pierwszej selekcji. Koniecznie trzeba zdawać siebie sprawę, jaką rolę w całym procesie produkcyjnym będzie odgrywał system, który automatyzujemy. Czy będzie działać niezależnie od innych układów na produkcji, czy będzie elementem składowym całego ciągu technologicznego?

Z tego punktu widzenia systemy możemy podzielić na układy autonomiczne (pracują samodzielnie, bez współpracy z innymi urządzeniami) oraz rozproszone (w których system jest elementem składowym większego procesu technologicznego i od jego pracy zależy praca pozostałych urządzeń w całym układzie). Mimo iż może się wydawać, że zadania wykonywane przez systemy sterowania w obu przypadkach są podobne (po prostu wykonanie programu sterującego), to fizyczne urządzenia sterujące, które te zadania będą wykonywać, mogą znacząco się różnić – np. z punktu widzenia funkcji komunikacyjnych, wymiany danych, możliwości serwisu na ruchu czy wbudowanych mechanizmów podnoszących dostępność układu.

Drugi podstawowy podział systemów sterowania to podział z punktu widzenia typu aplikacji. Jeśli w systemie przeważają sygnały cyfrowe, liczą się krótkie cykle wykonania programu lub potrzebujemy obsługiwać precyzyjne pozycjonowanie obrabianych detali, to mówimy o systemach sterowania dyskretnego. Taki model jest bardzo często spotykany w autonomicznych maszynach. Jeśli natomiast w systemie mamy do czynienia z obsługą dużej ilości pomiarów analogowych, cykl programu nie musi być wykonywany w czasie pojedynczych milisekund, ale potrzebna jest współpraca z szeregiem innych urządzeń obiektowych, konieczny jest serwis i rozbudowa na ruchu oraz możliwość podniesienia dostępności, wówczas mówimy o systemach sterowania ciągłego (analogowego). Takie sterowanie najczęściej znajdziemy w aplikacjach procesowych i przy kontroli całych ciągów technologicznych.

Układ sterowania w aplikacjach dyskretnych

Jeśli system sterowania ma być przeznaczony do obsługi maszyn lub linii, w których występuje np. precyzyjne pozycjonowanie napędów, wówczas idealnie sprawdzą się systemy sterowania dedykowane dla takich aplikacji. Charakteryzują się, między innymi, bardzo szybkim sterowaniem, niskimi cyklami programu, bardzo szybką komunikacją i łatwą integracją z systemem bezpieczeństwa. Takie układy cechuje też to, że aby cały układ działał prawidłowo, muszą działać wszystkie elementy. Często takie systemy budowane są pod potrzeby konkretnej maszyny i nie zakłada się ich dalszej rozbudowy. Będą one przez okres eksploatacji cały czas wykonywać te same czynności. Serwis takiego układu zwykle oznacza zatrzymanie całej maszyny. Układ nie może działać w pełnym zakresie funkcjonalności, jeśli jeden z jego elementów składowych nie działa, więc zatrzymanie takiego elementu blokuje całą maszynę. Przykładem może być maszyna pakująca, w której zatrzymanie jednego z serwonapędów wyłącza cały układ.

Układ sterowania w aplikacjach ciągłych

Jeśli nasza aplikacja ma mieć możliwość pracy w trybie ciągłym, a serwis jednego z elementów nie powinien mieć wypływu na pozostałe elementy systemu, wówczas mówimy o rozwiązaniach do obsługi aplikacji o charakterze ciągłym. W takim przypadku system sterowania powinien mieć inną architekturę i wbudowane mechanizmy sprzętowe, pozwalające na serwis w czasie pracy.

Takie często odgrywają kluczową rolę w procesie i ich zatrzymanie może unieruchomić całą produkcję, dlatego często pojawiają się w nich opcje redundancji kluczowych elementów. Również rozbudowa takich układów musi być możliwa na ruchu – w takich przypadkach dokładanie kolejnych funkcjonalności w systemie może być realizowane podczas pracy całego obiektu. Łatwiejszy jest też serwis takich aplikacji. Wymiana modułów może być realizowana bez potrzeby zatrzymywania całego układu. Przykładem może być tu system sterowania stacją uzdatniania wody w branży wod-kan. Produkcja wody jest procesem ciągłym i ani serwis, ani rozbudowa systemu nie mogą mieć na niego wpływu.

Często też aplikacje, które na pierwszy rzut oka wyglądają jak proste maszyny z nieskomplikowanym sterowaniem, mogą być elementem składowym bardzo złożonego procesu produkcyjnego. Zatrzymanie takiej maszyny wstrzymuje część procesu lub nawet całą produkcję. Idealnym przykładem może być stacja kompresorowa, która przygotowuje sprężone powietrze do wielu maszyn zainstalowanych na produkcji. Zatrzymanie jednego kompresora może skutecznie unieruchomić cały ciąg technologiczny.

Architektura pracy

Jeśli już zdecydowaliśmy się na konkretny system sterowania, należy zweryfikować, jak powinien być zbudowany. Jeśli będzie to system autonomiczny, działający w oparciu o jeden PLC, to sytuacja jest prosta. Ale jeżeli ma on być rozproszony, to musimy wiedzieć, czy będzie zainstalowany jako jeden kontroler w jednej szafie sterującej, czy będzie rozproszony na większym obszarze i zainstalowany w kilku szafach sterujących. To z kolei determinuje sposób komunikacji kontrolera głównego z układami oddalonymi – jakie magistrale wykorzystamy i jak urządzenia polowe mają być podłączone (czy bezpośrednio do kontrolera głównego czy do węzłów oddolnych).

Informacja o tym, jakie urządzenia będą podłączone do systemu sterowania, pozwala określić, w jakie interfejsy powinien być wyposażony system. Czy urządzenia polowe będą podłączane po tzw. drutach (czyli będą sterowane fizycznymi sygnałami dyskretnymi i analogowymi) czy też będziemy je podłączać za pośrednictwem sieci przemysłowej? A jeżeli tak, to jakiej? To jest też moment, aby zastanowić się również nad tym, czy system będzie sterował krytycznym fragmentem instalacji i zasadne jest zastosowanie architektury redundantnej. Jeżeli tak, to na jakim poziomie ta redundancja powinna być realizowana.

Kolejny ważny aspekt to określenie, jak układ oddalony ma się zachować w chwili, gdy z jakiegoś powodu utraci komunikację z kontrolerem nadrzędnym. Czy ma się zatrzymać, czy też zacząć realizować lokalną logikę, utrzymującą proces w stanie stabilnym do chwili odzyskania komunikacji z kontrolerem głównym. Na architekturę będzie też mieć wpływ zdefiniowanie z czym nasz system będzie się komunikował poza urządzeniami podłączonymi do sieci obiektowej. Czy będzie wymieniał dane z innymi kontrolerami i sterownikami PLC, czy będzie udostępniał swoje dane do systemów warstwy wizualizacyjnej i nadzorczej w zakładzie produkcyjnym, czy wręcz będzie w sposób pośredni podłączony do systemów poza zakładem produkcyjnym? Te elementy determinują, w jakie mechanizmy podnoszące bezpieczeństwo powinien być wyposażony kontroler i jakie certyfikaty, potwierdzające jego odporność na cyberataki, powinien posiadać.

Wielkość aplikacji sterującej

To obszar, który jest łatwy do przeanalizowania dla inżynierów i programistów, mających doświadczenie w budowaniu aplikacji konkretnego typu. Są oni w stanie z dużą dokładnością oszacować rozmiar aplikacji sterującej, znając zakres funkcjonalności, jaki ma być realizowany przez kontroler – i tym samym wytypować właściwą jednostkę centralną. Dla inżynierów rozpoczynających pracę z nowym sprzętem może to być początkowo trudniejsze.

Wybierając konkretny kontroler warto w pewnym stopniu przeszacować niezbędne zasoby, aby zostawić sobie ewentualny zapas na potrzeby przyszłej rozbudowy systemu. Za realizację programów sterujących w systemie odpowiedzialny jest moduł CPU, który wyposażony jest w konkretną ilość pamięci RAM i Flash, przeznaczonej na program i konfigurację. Pozwala też zaadresować konkretną liczbę zmiennych wewnętrznych, niezbędnych do przygotowania programu sterującego oraz konkretną liczbę zmiennych zewnętrznych pozwalających adresować fizyczne sygnały obiektowe. Często CPU posiada też ograniczenia co do liczby węzłów oddalonych, jakie można podłączyć do systemu oraz liczby modułów rozszerzeń, które można podłączyć do jednostki centralnej.

Jak widać, właściwe określnie zasobów musi być poprzedzone rzetelną analizą funkcji realizowanych przez system. Ważnym aspektem przy wyborze jednostki centralnej będzie też to, jak sama aplikacja sterująca będzie realizowana w CPU. Jeśli jest na tyle rozbudowana, że duża liczba wątków będzie mocno obciążać procesor, warto wybrać taki, który ma co najmniej dwa rdzenie. W takim przypadku jednostka centralna potrafi samodzielnie rozdzielać zadania na poszczególne rdzenie, gwarantując wysoką szybkość przetwarzania danych i niezakłóconą komunikację.

Możliwości programistyczne

Ten obszar ma ogromne znaczenie dla programistów i serwisantów systemów. Program sterujący powinien być przygotowany w języku sterowania najbardziej dopasowanym do aplikacji. Inny język programowania będzie właściwszy do obsługi sterowania dyskretnego, a inny do analogowego. Inaczej będziemy obsługiwali proste sterowanie, a inaczej zaawansowany układ regulacji w aplikacjach krytycznych. Do dyspozycji programisty jest zawsze kilka języków programowania i każdy z nich nadaje się lepiej do konkretnych zastosowań.

I tak, jeśli musimy w ramach programu sterującego obsługiwać proste zależności pomiędzy sygnałami wejściowymi i wyjściowymi, idealny będzie język drabinkowy (LD) – z uwagi na swoją prostą składnię i łatwość użycia. Jeśli w naszej aplikacji ma się pojawić sterowanie konkretnymi urządzeniami w określonym kontekście technologicznym, wówczas wygodniej będzie skorzystać z języka bloków funkcyjnych (FBD) – z uwagi na przejrzystość składni i tworzenia własnych struktur programowych.

Jeśli z kolei w naszym programie pojawia się potrzeba obsługi konkretnych instrukcji i formuł matematycznych, wówczas najlepszy będzie język strukturalny (ST) lub język instrukcji (IL). Jeszcze inne potrzeby mogą pojawiać się przy obsłudze zaawansowanych procedur i funkcji, których działania najlepiej opisać językiem programowania wysokiego poziomu, jakim jest na przykład C++ lub Python. W takim przypadku warto zainwestować w jednostkę posiadającą wbudowany kompilator kodu przygotowanego w takim standardzie.

Możliwości komunikacyjne w warstwie obiektowej

Ten obszar wymaga szczególnej uwagi przy wyborze rozwiązania. Wymiana danych w systemie sterowania jest elementem kluczowym do uzyskania niezbędnego poziomu wydajności układu oraz możliwości zintegrowania go w ramach kompleksowego sytemu sterowania. System zawsze będzie wymieniał dane z innymi urządzaniami, bez względu na to czy będzie to pojedyncza maszyna, czy kompleksowy układ sterowania. Komunikacja realizowana jest w większości przypadków na kilku poziomach i każdy z tych poziomów ma konkretne potrzeby.

Podstawowy poziom wymiany danych to sieć obiektowa. To na tym poziomie urządzenia wykonawcze przesyłają dane między sobą, gwarantując działanie podstawowych układów w systemie. Komunikacja na tym poziomie powinna być przede wszystkim niezawodna i działać bardzo szybko. Niezawodność ma wpływ na ciągłości działania systemu, szybkość z kolei na uzyskanie niezbędnej wydajności. 

Wymiana danych realizowana jest obecnie w oparciu o kilka standardów komunikacji przemysłowej, które ze względu na typ magistrali komunikacyjnej można podzielić na szeregowe oraz oparte na sieci Ethernet. Komunikacja szeregowa jest wykorzystywana najczęściej do lokalnej komunikacji z układami obiektowymi na małe odległości i z niewielką prędkością. Dzięki niej urządzenia obiektowe są w stanie udostępniać do systemu sterowania znacznie więcej informacji, niż tylko ich fizyczny stan. Są to dodatkowe informacje diagnostyczne, statusowe oraz dane procesowe, które mogą mieć znaczenie na poziomie logiki sterującej. Wadą komunikacji szeregowej jest natomiast ograniczenie odległości, w jakiej urządzenia mogą być zainstalowane, ograniczona liczba urządzeń mogących pracować w jednej sieci, a także brak zabezpieczeń przed nieuprawnionym dostępem do danych.

Alternatywą dla transmisji szeregowej jest komunikacja w oparciu o sieć Ethernet. Popularna skrętka może przesyłać dane w różnych protokołach, a sieć w tym standardzie jest bardzo łatwa i tania w budowie. Sprawia to, że Ethernet stał się obecnie standardem dominującym w przemyśle. Oczywiście kluczową rolę odgrywa tu protokół, jaki wykorzystamy do przesyłania danych.

I tak dla maszyn, w których obsługujemy szybkie i precyzyjne pozycjonowanie, najlepszym standardem będzie EtherCAT – z uwagi przede wszystkim na komunikację w czasie pojedynczych milisekund, co daje możliwość łatwej synchronizacji wielu osi jednocześnie. Z kolei w aplikacjach rozproszonych i wolnozmiennych nie będzie to już miało takiego znaczenia – komunikacja musi być tutaj przede wszystkim niezawodna i dawać możliwość obsługi redundancji. W takich aplikacjach dominuje obecnie Profinet – sieć będąca połączeniem najlepszych cech sieci Profibus ze standardem Ethernet. Standard ten jest wykorzystywany w coraz większej gamie urządzeń obiektowych. Bez problemu znajdziemy go nie tylko w rozmaitych sterownikach PLC, ale i w oddalonych układach wejść-wyjść, przemiennikach częstotliwości czy systemach bezpieczeństwa.

Komunikacja w warstwie procesowej to również wymiana danych bezpośrednio pomiędzy kontrolerami i sterownikami PLC. W takim przypadku stosuje się często model peer-to-peer, w którym – w odróżnieniu od modelu master/slave (gdzie odpowiedź jest efektem zapytania) –dane z urządzeń sterujących są wysyłane na sieć procesową i może z nich skorzystać każde inne urządzenie, które do tych danych powinno mieć dostęp i jest podłączone do tej sieci. Eliminujemy więc potrzebę cyklicznego odpytywania urządzeń nawzajem, dzięki czemu ten model komunikacji jest znacznie bardziej odporny na wyłączenie niektórych urządzeń z sieci (w przypadku protokołów master/slave wyłączenie urządzenia nadrzędnego zatrzymuje całą wymianę danych z uwagi na brak odpytującego).

Możliwości komunikacyjne w warstwie wizualizacyjnej

Wymiana danych pomiędzy systemem sterowania a warstwą wizualizacyjną ma miejsce nie tylko w dużych zakładach produkcyjnych, ale i na poziome autonomicznych maszyn. Mówimy w tym przypadku o komunikacji urządzeń sterujących z pulpitami operatorskimi (którymi mogą być panele HMI, komputery IPC z oprogramowaniem SCADA) oraz stacjami serwerowymi, które są elementem kompleksowych systemów wizualizacji i rozwiązań klasy Control Room.

Wybór sposobu, medium i protokołu komunikacji zależy od architektury systemu sterowania i urządzeń, jakie wchodzą w ich skład. Konieczna jest analiza, z czym nasz system będzie się łączył i jak będzie udostępniał dane. W przypadku prostych maszyn, w których najczęściej pracuje jeden sterownik PLC i jeden pulpit HMI (np. panel operatorski), urządzenia te mogą pracować w jednej sieci. Wymieniają one stosunkowo mało danych i komunikacja w oparciu o łącze szeregowe w wielu przypadkach jest wystarczająca.

W przypadku większych systemów zasadne jest wykorzystanie komunikacji opartej na sieci Ethernet. Komunikacja w warstwie wizualizacji powinna być odseparowana od komunikacji w warstwie obiektowej. Jest to wskazane dla zapewnienia niezbędnego poziomu bezpieczeństwa, a także odpowiedniej szybkości i wydajności komunikacji. Warstwa komunikacji SCADA często ma dostęp do zewnętrznych systemów, co zwiększa ryzyko nieautoryzowanych dostępów do sterownika PLC i do sieci obiektowej. Systemy SCADA potrzebują też dużo danych, aby właściwie zobrazować cały proces. Cykliczne pytanie o te dane generuje dużo ruchu w sieci. To z kolei może wpływać na pierwszeństwo w dostępnie do danych i skutecznie opóźniać komunikację z innymi urządzeniami.

Separację sieci SCADA od sieci procesowej najprościej zrealizować na poziomie sterownika PLC, który powinien niezależnie obsługiwać komunikację na dwóch odseparowanych portach komunikacyjnych, zapewniając jednocześnie dostęp przechowywanych w pamięci.

Jeśli aplikacja stawia wysokie wymagania w zakresie bezpieczeństwa, warto zwrócić uwagę na standard OPC-UA. To protokół, który oprócz możliwości przesyłania bardzo dużej ilości danych pozwala na komunikację z urządzeniami opartymi o inne standardy systemów operacyjnych oraz inne platformy sprzętowe. Jego uniwersalność idzie w parze z wysokim poziomem bezpieczeństwa. Komunikacja w modelu OPC-UA zakłada bowiem konieczność podania loginu i hasała, aby do danych mieć dostęp, a w układach najbardziej wymagających komunikacja może wymagać dodatkowo certyfikatów po stronie urządzeń nadawczych i odbiorczych.  Ten protokół staje się obecnie coraz popularniejszy i z pewnością warto inwestować w urządzenia, które go obsługują.

Praca w układach wysokiej dostępności

Na ten obszar szczególną uwagę powinni zwrócić inżynierowie, którzy przygotowują aplikacje sterujące dla urządzeń i obiektów o znaczeniu kluczowym (krytycznym). Pominięcie tego aspektu skutkuje powstaniem błędów w architekturze całego systemu oraz problemami na etapie serwisu i utrzymania instalacji.

Kiedy należy rozważyć wysoką dostępność w systemie sterowania? Jeśli nieplanowany przestój generuje duże koszty, zatrzymuje ciąg produkcyjny lub stwarza zagrożenie dla obiektu i personelu. Jeśli instalacja jest kluczowa i inwestor decyduje się na zakup na stan wewnętrzny urządzeń serwisowych, wówczas bardzo poważnie należy rozważyć wysoką dostępność i redundancję kluczowych elementów w systemie.

Redundancja w systemie automatyki może być realizowana na kilku poziomach: zasilania, komunikacji, sterowania i wizualizacji. Redundancja na poziomie zasilania powinna pozwolić zasilić kontroler z dwóch niezależnych źródeł oraz dać możliwość dostarczenia nadmiarowej mocy do układu. Realizuje się to w systemach, które pozwalają obsługiwać więcej niż jeden zasilacz systemowy.

Podniesienie dostępności na poziomie komunikacyjnym to możliwość wymiany danych w oparciu o rezerwowe łącza komunikacyjne i rezerwowe moduły komunikacyjnie. Redundancja na tym poziomie zabezpiecza system sterowania na wypadek uszkodzenia magistral komunikacyjnych. Realizowane jest to dzięki właściwej topologii sieci (pierścień/RING) do pojedynczych modułów komunikacyjnych lub podwojenie modułów komunikacyjnych oraz magistral, co pozwala zbudować system w pełni odporny na awarie. Należy jednak pamiętać że same interfejsy i magistrale nie gwarantują jeszcze wysokiej dostępności. Urządzenia, które to takiego systemu są podłączone, również taką wysoką dostępność muszą obsługiwać, aby właściwie zarządzać interfejsami komunikacyjnymi. Redundancja w warstwie komunikacyjnej jest stosowana zarówno na poziomie sieci obiektowej, jak i sieci SCADA.

Najbardziej złożony system redundancji to redundancja jednostek centralnych. To z uwagi na kluczową rolę, jaką w systemie sterowania odgrywa sterownik PLC, mechanizmy przełączania na układ rezerwowy muszą zachowywać niezbędne procedury diagnostyki i sprawdzania gotowości układu rezerwowego do przejęcia kontroli. Kluczowa jest też synchronizacja danych procesowych pomiędzy kontrolerami. Czołowi dostawcy automatyki na świecie dostarczają gotowe, przetestowane rozwiązania, które automatycznie taką wysoką dostępność potrafią obsłużyć, a inżynier konfiguruje i programuje układ redundantny tak, jakby programował pojedynczy PLC.

Sama redundancja jednostek centralnych może być realizowana w 3 modelach: Cold-StandBy, Warm-StandBy oraz Hot-StandBy. Pierwszy model to nic innego, jak moduł rezerwowy na magazynie serwisowym. Uszkodzenie elementu sterującego wymaga, aby w jego miejsce zainstalować moduł rezerwowy i ponownie z wartościami domyślnymi uruchomić proces. Drugi model zakłada, że w systemie pracują dwa kontrolery, ale nie synchronizują ze sobą danych i przełączenie na moduł rezerwowy realizowane jest automatycznie w chwili zatrzymania urządzania głównego. Jest to model dobry dla obiektów, gdzie kontrolery w chwili przełączenia roli nie muszą mieć tego samego zestawu danych procesowych i dopuszcza się występowanie stanów nieustalonych. Model Hot-StandBy zakłada ze w systemie są dwa kontrolery, które synchronizują ze sobą dane, dzięki czemu w chwili przełączenia sterowania na rezerwę proces ten jest niezauważalny i realizowany bezzderzeniowo. O tym, jaki model renuncjacji jest potrzebny, decyduje analiza potrzeb klienta i ryzyka związanego z awaryjnym zatrzymaniem pracy.

Integracja z rozwiązaniami Edge

Z integracją systemu sterowania w ramach aplikacji Edge mamy do czynienia wszędzie tam, gdzie kluczowe jest przetwarzanie danych procesowych w czasie rzeczywistym na poziomie maszyny czy linii technologicznej. To wymaga dużo większej mocy obliczeniowej niż ta, która dostępna jest w klasycznych rozwiązaniach PLC. Warto zatem rozważyć opcję integracji naszego systemu sterowania z urządzeniami dedykowanymi do obsługi brzegowej. Jeśli już wstępna analiza wskazuje zasadność takiej integracji, warto wybrać rozwiązanie, które funkcję Edge ma już wbudowaną. Na rynku dostępne są bowiem rozwiązania, które w ramach jednego urządzenia integrują klasyczny układ sterujący z komputerem Edge.

Do czego potrzebny jest Edge? Wiele systemów do optymalnej pracy wymaga bieżącej analizy danych produkcyjnych, aby na ich podstawie podejmować lepsze decyzje. Ważne jest też, że dane muszą być przetwarzane lokalnie. Dzieje się to z dwóch powodów. Pierwszy to szybkość przetwarzania i czas odesłania informacji zwrotnej do urządzenia sterującego, drugi to konieczność zapewnienia bezpieczeństwa i przesyłania kluczowych danych produkcyjnych poza zakład produkcyjny. Edge i przetwarzanie brzegowe to przede wszystkim przeniesienie części funkcjonalności z chmury na poziom urządzeń produkcyjnych, ale także zapewnienie dodatkowych możliwości przy obsłudze aplikacji. Samo urządzenie Edge ma na tyle rozbudowane zasoby sprzętowe, że jest w stanie obsługiwać lokalna wizualizację, systemy wskaźników KPI, składowanie danych w bazach, a także dokonywać konwersji protokołów czy uruchamiać dodatkowe narzędzia wspierające proces produkcyjny.

Samo urządzenie Edge jest najczęściej prekonfigurowane i posiada preinstalowane konkretne funkcje, które po zasileniu danymi produkcyjnymi i bazowej konfiguracji pozwalają zyskać nowe możliwości w zakresie sterowania, wizualizacji i optymalizacji produkcji. Preinstalowane funkcjonalności to bardzo często popularne i dostępne w modelu OpenSource narzędzia, które pozwalają realizować na poziomie maszyny funkcje, jakie do tej porty były zarezerwowane dla systemów spoza obszaru automatyki.

I tak na przykład Grafana jest świetnym narzędziem do podglądu danych procesowych oraz wyświetlania ich w konkretnym kontekście technologicznym w postaci dashboardów w przeglądarce internetowej. Node-Red będący z kolei narzędziem Flow Creator pozwoli zbudować aplikacje do prostego przetwarzania danych i udostępnianie wyników w postaci np. emaila czy powiadomień na komunikatorach i serwisach social media. Realizowane jest to w oparciu o gotowe biblioteki oraz funkcje, które bez potrzeby znajomości języków programowania dają możliwość korzystania z dodatkowych funkcji.

Jeszcze innym przykładem mogą być dedykowane narzędzia do analityki danych diagnostycznych i alarmów pochodzących z maszyn i urządzeń, a także do analizowania zachowania układu w celu detekcji źródeł problemu.  Jeszcze innym zastosowaniem Edge może być konwersja protokołów komunikacyjnych z jednego standardu na inny, co daje poszerza możliwości komunikacji z różnymi urządzeniami i platformami. Przykładów można podać więcej, a stosowanie takich rozwiązań zależy od wyłącznie od wymagań użytkownika. Dlatego już na etapie wyboru systemu sterowania warto zainwestować w urządzenie, które na taką integrację pozwoli.