Pozyskiwanie danych z fabryki

Prawdziwa hala produkcyjna to zlepek różnych rozwiązań. Sterowniki różnych producentów, różnych generacji i różnych protokołów stoją obok siebie — Siemens S7 na jednym module, PLC Allen-Bradley na kolejnym, liczniki energii Modbus i napędy o zmiennej częstotliwości w stacji transformatorowej, czujniki IO-Link na linii pakującej, obrabiarki CNC w warsztacie oraz sterowniki BACnet obsługujące HVAC budynku. Niemal żadne z tych urządzeń nie zostało zaprojektowane tak, aby dzielić się danymi z czymkolwiek innym.

Zadaniem pozyskiwania danych z fabryki jest pobranie wiarygodnych, nazwanych i opatrzonych znacznikiem czasu pomiarów ze wszystkich tych urządzeń i zebranie ich w jednym miejscu — bez przeokablowania zakładu, wymiany sterowników czy przepisywania programów PLC. W praktyce oznacza to mówienie natywnym protokołem każdego urządzenia, przekształcanie surowych rejestrów i tagów w nazwane wartości inżynierskie z jednostkami, dołączanie sygnału jakości, dzięki któremu wiadomo, czy odczytowi można ufać, oraz robienie tego niezawodnie na krawędzi nawet wtedy, gdy sieć zawodzi.

IronFlock rozwiązuje to za pomocą rodziny lekkich aplikacji kolektora wdrażanych na krawędzi — po jednej na rodzinę protokołów. Każda działa jako zwykły kontener Docker na dowolnej bramie z systemem Linux, automatycznie wykrywa to, co może, normalizuje surowe adresy w nazwane wartości, buforuje dane podczas przerw i przesyła wszystko do bazy danych szeregów czasowych Twojego projektu. Każdy kolektor konfiguruje się w całości w przeglądarce i dostarczany jest z trybem demo, dzięki czemu można ocenić pełne doświadczenie zanim podłączysz jakikolwiek sprzęt.

Rzeczywistość brownfield

Nie istnieje jeden protokół, który obejmuje całą fabrykę. Praktyczne pytanie zawsze brzmi: „który kolektor odczytuje moje urządzenia?” Poniższa tabela mapuje sprzęt, który prawdopodobnie znajdziesz, na kolektor, który go obsługuje.

Modbus i OPC UA działają już dziś, podobnie jak IO-Link, MTConnect i BACnet. Sterowniki Industrial Collector dla Siemens S7 (S7comm) i Allen-Bradley (EtherNet/IP) są napędzane silnikiem Apache PLC4X i są walidowane na różnych urządzeniach — sterowniki S7-1200/1500 można już dziś odczytywać przez ich wbudowany serwer OPC UA.

Gdzie kolektory IronFlock mają wspólne podejście

Niezależnie od tego, jaki protokół zbierasz, wszystkie pięć aplikacji działa pod maską tak samo. Zapisują do tych samych tabel bazy danych per projekt (gateways, assets, datapoints, measurements, assetstatus), buforują odczyty lokalnie i przekazują je w kolejności, gdy łącze upstream do platformy powróci, izolują każde urządzenie tak, aby jedna niedostępna maszyna nigdy nie wstrzymywała pozostałych, oraz konfigurowane są na żywo w przeglądarce bez plików konfiguracyjnych i restartów. Dotyczy to każdego sposobu wdrożenia IronFlock — zarządzanej chmury, chmury prywatnej lub w pełni offline’owego urządzenia on-premises. Każda strona poniżej powtarza te wspólne cechy, dzięki czemu jest samodzielna.

Znane ograniczenia

Niektóre starsze urządzenia nie mają jeszcze bezpośredniej ścieżki. Starsze Allen-Bradley MicroLogix / SLC (PCCC przez DF1), cele tylko z Profibusem bez wolnego portu Ethernet, pakiety obsługiwane wyłącznie z zakładowego DCS oraz sprzęt bez żadnego sterownika cyfrowego (tylko okablowanie sprzętowe) wymagają bramy, mostu protokołów lub doposażenia w czujniki. Jeśli nie masz pewności, czy Twój sprzęt jest obsługiwany, skontaktuj się z nami — jeśli urządzenie mówi Modbus lub OPC UA, prawie na pewno działa już dziś, a nowe sterowniki i pakiety profili są dodawane na życzenie.

Kolektory

• Industrial Collector — jedna aplikacja dla całej hali: Siemens S7, Allen-Bradley, Modbus i OPC UA obok siebie, z katalogiem wstępnie zmapowanych profili sprzętu.
• IO-Link Collector — mastery IO-Link i inteligentne czujniki z automatycznym wykrywaniem i automatycznym dekodowaniem IODD przez HTTP, OPC UA lub MQTT.
• Modbus Collector — najlżejszy sposób na odczyt ogromnej zainstalowanej bazy liczników, napędów i sterowników Modbus.
• MTConnect Collector — obrabiarki CNC i sprzęt warsztatowy przez otwarty standard MTConnect, z wykrywaniem bez konfiguracji.
• BACnet Collector — automatyka budynkowa, HVAC i systemy energetyczne przez BACnet/IP, z automatycznym wykrywaniem sieci i punktów.

Dokąd trafiają dane

Każdy kolektor przechowuje swoje odczyty w prywatnej bazie danych szeregów czasowych Twojego projektu, gdzie są one natychmiast dostępne dla reszty platformy: odpytuj je i modeluj przez Data Backend, wizualizuj je na żywo w Panelach IoT i tablicach SCADA oraz obserwuj je z aplikacją Alarmy dla powiadomień SMS/e-mail. Aby uruchomić urządzenia i zainstalować te aplikacje, zobacz Zarządzanie urządzeniami i Zarządzanie aplikacjami.

Od zbierania do wniosków: typowy wzorzec wdrożenia

Pozyskiwanie danych to fundament, a nie cel. Nikt nie chce rejestrów i tagów — zakłady chcą wskaźników OEE, wczesnych ostrzeżeń zanim wrzeciono ulegnie awarii, energii na sztukę, raportu zmianowego, który pisze się sam. Typowe wdrożenie IronFlock składa się zatem z dwóch warstw, które pozostają wyraźnie rozdzielone:

Warstwa 1 — zbieraj. Zainstaluj aplikacje kolektora dopasowane do Twojego sprzętu na bramach obok niego i zmapuj swoje maszyny w przeglądarce. Od tego momentu nazwane, opatrzone znacznikiem czasu i flagą jakości pomiary gromadzą się nieprzerwanie w ustandaryzowanej bazie danych Twojego projektu — każdy projekt otrzymuje tę samą, więc kolektor zachowuje się identycznie wszędzie tam, gdzie jest zainstalowany, a właściciel projektu zyskuje jeden centralny punkt wglądu we wszystko, co jest zbierane. Wewnątrz niej dane każdej aplikacji żyją we własnym, izolowanym schemacie: pojedynczy, rosnący zasób, który należy do Ciebie, domyślnie prywatny per aplikacja.

Warstwa 2 — konsumuj. Zainstaluj (lub zbuduj) aplikacje, które zamieniają te pomiary w decyzje, i pozwól im czytać dane kolektorów przez dostęp do danych między aplikacjami:

• Gotowa aplikacja panelu OEE konsumuje stany maszyn i liczniki produkcji i dostarcza dostępność, wydajność i jakość per linia — na żywo na ścianie, bez ani jednego spotkania integracyjnego.
• Aplikacja predykcyjnego utrzymania ruchu trenuje na miesiącach historii wibracji, prądu i temperatury, którą kolektory już zebrały, a następnie ocenia strumień na żywo, aby wskazać łożysko, które zaczęło dryfować.
• Analityka energii łączy zużycie z liczników Modbus z licznikami produkcji maszyn, aby raportować energię na sztukę, straty biegu jałowego i ryzyko szczytów obciążenia.
• Aplikacje raportowe i jakościowe czytają te same tabele, aby automatycznie wypełniać księgi zmianowe, zapisy partii i ślady audytu.
• Środowisko Node-RED (lub dowolny uniwersalny warsztat) deklaruje, że konsumuje wszystkie dane projektu za pomocą jednego symbolu wieloznacznego, a następnie wykrywa dostępne tabele w czasie działania — dzięki czemu inżynier może połączyć przepływy w poprzek każdego kolektora i aplikacji analitycznej na hali, bez pisania integracji dla każdego z osobna.

Każda aplikacja konsumująca deklaruje, których danych kolektorów potrzebuje — konkretnej listy albo - app: "*" dla wszystkiego — a Ty zatwierdzasz lub cofasz ten dostęp per projekt jednym przełącznikiem — zawsze tylko do odczytu. Ponieważ każdy kolektor IronFlock zapisuje ten sam schemat tabel (gateways, assets, datapoints, measurements, assetstatus), aplikacja konsumująca napisana pod jeden kolektor działa ze wszystkimi: panelu OEE nie obchodzi, czy stany maszyn dotarły przez S7, Modbus, MTConnect czy IO-Link.

Rezultatem jest architektura, która rośnie razem z Tobą, zamiast Cię ograniczać: zacznij od jednego kolektora na jednej linii, dodaj aplikacje analityczne, gdy będziesz gotów, wymieniaj lub rozszerzaj dowolną warstwę niezależnie — a jeśli gotowe aplikacje nie pasują, zbuduj własną aplikację konsumującą na danych, które już zbierasz.