PLC, HMI, MES i ERP – jak zintegrować system znakowania z danymi produkcyjnymi?

Integracja systemu znakowania z ERP i MES – rola PLC i HMI

Największym błędem podczas integracji systemu znakowania jest rozpoczęcie projektu od pytania: „jakim protokołem połączymy drukarkę?”.

Najpierw trzeba odpowiedzieć na inne pytanie:

„Który system jest właścicielem konkretnej informacji?”

Czy numer partii pochodzi z ERP?

Czy jest nadawany przez MES?

Czy PLC zna jedynie numer aktualnej receptury?

Czy operator może zmienić datę z poziomu HMI?

Kto generuje numer seryjny?

Kto potwierdza, że konkretny serial został rzeczywiście wykorzystany?

Dopiero po określeniu odpowiedzialności można zaprojektować komunikację. Taka analiza powinna obejmować cały przepływ danych w ramach procesów produkcyjnych – od zlecenia i receptury po fizyczne wykonanie nadruku na hali produkcyjnej.

Nowoczesne systemy REA mogą pracować w środowisku zautomatyzowanym i pobierać dane z różnych źródeł, m.in. ze zlecenia, receptury, bazy danych oraz systemów produkcyjnych. Integracja może zapewniać automatyczną wymianę danych, ale sposób ich przekazywania zawsze powinien wynikać z architektury konkretnego zakładu. Aktualna platforma REA JET TITAN wykorzystuje m.in. komunikację opartą na XML, a rozwiązania REA są przewidziane do integracji z automatyką oraz systemami nadrzędnymi.

PLC, HMI, MES i systemie ERP – jaka jest różnica?

Najprościej przedstawić to jako cztery różne odpowiedzialności.

Model ISA-95/IEC 62264 wykorzystuje podobne rozdzielenie odpowiedzialności: sterowanie procesem znajduje się niżej niż warstwa zarządzania operacjami produkcyjnymi, a ERP odpowiada warstwie planowania biznesowego. ISA podkreśla, że model służy właśnie porządkowaniu wymiany informacji pomiędzy funkcjami produkcyjnymi i biznesowymi.

Najprostsza architektura danych

W typowej instalacji przepływ może wyglądać następująco:

ERP

↓

MES

↓

PLC / system sterowania linii

↓

system znakowania

↓

produkt

↓

kamera / weryfikacja

Nie każda fabryka musi stosować dokładnie taką architekturę.

W mniejszym zakładzie może nie występować MES.

W innym MES może komunikować się z drukarką bezpośrednio.

Jeszcze gdzie indziej wykorzystywany jest serwer znakowania, middleware albo centralna baza danych. ERP i MES mogą współpracować w jednym ekosystemie IT/OT, ale oba systemy mają inne odpowiedzialności i nie powinny automatycznie dublować swojej logiki.

Najważniejsza zasada: architektura musi jednoznacznie określać właściciela danych i odpowiedzialność każdego systemu.

ERP – jakie dane powinny pochodzić z systemu biznesowego?

ERP jest zwykle miejscem, w którym przedsiębiorstwo zarządza m.in.:

• indeksami produktów,

• zleceniami,

• klientami,

• zamówieniami,

• materiałami,

• danymi podstawowymi.

W kontekście znakowania może być źródłem takich informacji jak:

• kod produktu,

• nazwa,

• GTIN,

• numer zlecenia,

• odbiorca,

• rynek docelowy,

• wariant produktu.

Nie oznacza to jednak, że ERP powinien wysyłać sygnał:

PRINT

przy każdym przejeżdżającym produkcie.

ERP działa na innym poziomie procesu niż sterowanie maszyną. Coraz więcej przedsiębiorstw decyduje się ograniczać ręczne przepisywanie danych pomiędzy warstwą biznesową i produkcyjną, ale nie oznacza to, że ERP powinien bezpośrednio sterować każdym cyklem maszyny.

Model ISA-95 opisuje ERP jako warstwę planowania biznesowego, podczas gdy bezpośrednie sterowanie procesem znajduje się na niższych poziomach automatyki.

Systemy MES – pomost pomiędzy zleceniem a rzeczywistą produkcją

MES, czyli Manufacturing Execution System, wspiera zarządzanie realizacją operacji na poziomie produkcji. Integracja systemu MES z warstwą znakowania może pozwolić na automatyczne przekazywanie właściwych danych do odpowiedniej linii lub stanowiska, zależnie od architektury zakładu. Lepsza kontrola jakości i reklamacji możliwa jest dzięki szybkiej identyfikacji wadliwych partii produktów.

MES może odpowiadać na pytanie:

„Co rzeczywiście produkujemy właśnie teraz?”

W zależności od architektury przedsiębiorstwa MES może zarządzać lub przetwarzać:

• aktywne zlecenie,

• numer partii,

• numer operacji,

• recepturę,

• status produkcji,

• Traceability,

• dane jakościowe,

• serializację,

• raport wykonania.

To właśnie dlatego MES bywa bezpośrednim lub pośrednim źródłem danych wykorzystywanych przez system znakowania. W zależności od projektu dane mogą trafiać do urządzenia przez PLC, middleware, serwer znakowania albo inne oprogramowanie integracyjne.

REA wskazuje możliwość integracji swoich systemów znakowania z ERP i MES, a na stronie kategorii REA JET opisano m.in. automatyczne pobieranie numeru partii i zlecenia, zmianę projektu, generowanie seriali oraz przesyłanie statusów. Takie podejście może tworzyć lepsze warunki do efektywnego zarządzania danymi znakowania i ograniczać liczbę ręcznych operacji.

PLC – system, który wie, co dzieje się z produktem

PLC jest zwykle najbliżej fizycznego procesu i – zależnie od architektury maszyny – może znać bieżący stan urządzeń na hali produkcyjnej.

Może wiedzieć:

• czy produkt znajduje się przed głowicą,

• czy transporter pracuje,

• jaka receptura maszyny jest aktywna,

• czy osłona jest zamknięta,

• czy cykl może zostać wykonany,

• kiedy należy wyzwolić oznaczenie.

Dlatego PLC bardzo często odpowiada za:

trigger druku.

Przykład:

MES: produkujemy partię 250817A.

PLC: właśnie nadjechał kolejny produkt tej partii.

drukarka: wykonuję przypisany do niego nadruk.

To trzy różne informacje.

Nie warto próbować umieszczać ich wszystkich w jednym systemie tylko po to, aby uprościć schemat.

HMI – ekran operatora, a nie drugi system zarządzania danymi

HMI powinien przede wszystkim pomagać operatorowi kontrolować proces. Jego menu i zakładki nie powinny zmuszać użytkownika do przeszukiwania wielu ekranów tylko po to, aby sprawdzić status znakowania lub aktywną recepturę. Dobrze zaprojektowany interfejs wspiera codzienną pracę operatora, ale nie zastępuje systemu odpowiedzialnego za dane nadrzędne.

Może wyświetlać:

• aktywny produkt,

• zlecenie,

• numer partii,

• projekt nadruku,

• status drukarki,

• poziom materiału eksploatacyjnego,

• ostrzeżenia,

• alarmy.

Może również umożliwiać określone działania operatora.

Problem zaczyna się wtedy, gdy operator może niezależnie zmienić:

Produkt A w MES

na:

Produkt B na ekranie drukarki.

Powstają wtedy dwa niezależne źródła informacji.

W rozwiązaniach OEM REA możliwe jest sterowanie systemem znakowania z poziomu istniejącego sterowania maszyny, a interfejs może być integrowany z HMI. Oficjalne materiały REA opisują m.in. WebGUI oraz komunikację XML/TCP/IP.

Najważniejsza zasada: jedno źródło prawdy dla każdej danej

Dla każdej zmiennej należy ustalić właściciela.

Przykład:

Nie chodzi o to, że tabelę tę należy zastosować identycznie w każdej fabryce.

Chodzi o to, aby dla jednej informacji nie istniały dwa niekontrolowane źródła prawdy.

Integracja ERP, MES i PLC nie polega na kopiowaniu wszystkich danych do wszystkich systemów. Dobra architektura jednoznacznie określa, który system jest właścicielem każdej informacji i które systemy jedynie ją wykorzystują.

Dlaczego ręczne przepisywanie danych jest ryzykowne?

Załóżmy, że numer partii istnieje już w MES.

Operator musi następnie:

1. odczytać go z ekranu,

2. przejść do drukarki,

3. wpisać go ręcznie,

4. potwierdzić.

Powstaje dodatkowy punkt procesu, w którym możliwa jest pomyłka.

Jeżeli dane można przekazać automatycznie:

MES → system znakowania

albo:

MES → PLC → system znakowania,

operator nie musi ponownie wpisywać informacji. Taka automatyczna wymiana może ograniczać ryzyko pomyłek i wspierać wzrost efektywności procesu, o ile dane źródłowe, logika potwierdzeń i reakcje na błędy są prawidłowo zaprojektowane.

Aktualna strona REA JET wskazuje właśnie ograniczenie ręcznego wprowadzania danych i ryzyka niewłaściwego projektu jako jedną z korzyści integracji z systemami produkcyjnymi. W dobrze zaprojektowanym środowisku może to również wspierać optymalizację przepływu pracy, jednak rzeczywisty wpływ na wydajność i liczbę przestojów zależy od całego procesu, nie tylko od drukarki.

Receptura maszyny i projekt nadruku powinny być powiązane

Jednym z najgroźniejszych scenariuszy jest:

PLC: Produkt A

drukarka: projekt Produkt B

Maszyna działa poprawnie.

Drukarka działa poprawnie.

Ale produkt jest oznaczany błędnie.

Dlatego zmiana SKU powinna uruchamiać kontrolowany proces:

zmiana receptury

↓

identyfikacja produktu

↓

wybór właściwego projektu znakowania

↓

przesłanie danych zmiennych

↓

potwierdzenie gotowości

↓

start produkcji

System znakowania nie musi przechowywać pełnej logiki biznesowej. Powinien natomiast otrzymać jednoznaczną informację, jaki projekt i jakie dane zastosować. Po ustaleniu zależności receptura–projekt następnie należy przejść do zdefiniowania pól zmiennych, potwierdzeń i zachowania systemu po błędzie.

Automatyczna zmiana nadruku – co powinna zawierać?

Zmiana produktu może wymagać aktualizacji:

• projektu,

• GTIN,

• numeru partii,

• daty,

• języka,

• rynku docelowego,

• symboli,

• kodu kreskowego,

• Data Matrix,

• QR,

• danych klienta.

Przy prawidłowej integracji operator nie musi wykonywać tych zmian oddzielnie na każdym urządzeniu.

W rozwiązaniach REA dane mogą pochodzić ze zlecenia, receptury, bazy produktowej lub systemu zarządzającego produkcją.

Dane stałe i zmienne – warto je rozdzielić

Nie wszystkie elementy nadruku powinny być generowane w czasie rzeczywistym.

Dane stałe

Przykładowo:

• logo,

• opis,

• elementy graficzne,

• stałe napisy.

Mogą stanowić część przygotowanego projektu.

Dane zmienne

Przykładowo:

• numer partii,

• data,

• serial,

• kod produktu,

• zlecenie,

• kod 2D.

Mogą być przekazywane z systemu nadrzędnego.

Takie rozdzielenie ogranicza wielkość wymienianych danych i ułatwia zarządzanie projektami.

Gdzie powinien znajdować się layout nadruku?

Istnieją trzy popularne koncepcje.

Model 1 – layout w systemie znakowania

System nadrzędny przesyła:

• ID projektu,

• wartości pól zmiennych.

Przykład:

Template: PRODUCT_A

LOT: 250817

EXP: 2027-08-17

SERIAL: 0087112

To bardzo czytelny model.

Model 2 – centralne zarządzanie projektami

Projekty przechowywane są w centralnym środowisku.

Stamtąd trafiają do urządzeń.

To rozwiązanie może być interesujące, gdy przedsiębiorstwo ma:

• wiele linii,

• wiele fabryk,

• dużą liczbę SKU,

• potrzebę centralnego zarządzania wersjami.

Centralne zarządzanie może ułatwiać utrzymanie spójnych projektów na wielu stanowiskach i wspierać optymalizację procesu zmian, ale wymaga jasno określonej kontroli wersji, uprawnień i procedur awaryjnych.

Model 3 – architektura hybrydowa

Część projektu pozostaje lokalnie, a dane dynamiczne dostarcza system nadrzędny.

Nie istnieje jeden model najlepszy dla wszystkich przedsiębiorstw.

Komunikacja – protokół nie jest architekturą

Bardzo częste pytanie brzmi:

„Czy drukarka ma Ethernet?”

Albo:

„Czy obsługuje OPC UA?”

To ważne pytania.

Ale sam interfejs ani port komunikacyjny nie definiują integracji. Sposób fizycznego podłączenia urządzenia do sieci lub sterownika jest dopiero jednym z etapów projektu.

Należy ustalić również:

• strukturę danych,

• kierunek komunikacji,

• potwierdzenia,

• timeout,

• reakcję na błąd,

• zachowanie po restarcie,

• sposób ponowienia transmisji,

• sposób kontroli aktualności danych.

Platforma REA JET TITAN wykorzystuje protokół komunikacyjny oparty na XML oraz oferuje serwer WWW i VNC, co może ułatwiać obsługę także z poziomu komputera w odpowiednio skonfigurowanym środowisku. Oficjalne materiały REA dla systemów znakowania wskazują również przykłady przemysłowych interfejsów, takich jak Ethernet/IP, Profinet czy OPC UA. Dostępność konkretnego interfejsu należy jednak zawsze potwierdzić dla wybranego modelu i konfiguracji.

Port Ethernet, OPC UA lub XML rozwiązuje problem transportu informacji, ale nie odpowiada na pytanie, który system jest właścicielem danych ani jak proces ma zareagować na ich brak lub niezgodność.

PLC ↔ drukarka – jakie sygnały warto przewidzieć?

Minimalna integracja może ograniczać się do:

Trigger → Print

W bardziej zaawansowanym systemie warto rozważyć wymianę statusów.

Do systemu znakowania

• start,

• ID projektu,

• dane zmienne,

• trigger,

• prędkość / synchronizacja,

• reset błędu.

Z systemu znakowania

• Ready,

• Busy,

• Printing,

• Warning,

• Error,

• projekt załadowany,

• dane zaakceptowane,

• wykonanie zadania,

• stan materiału – jeżeli dostępny.

Dokładny zestaw zależy od urządzenia i procesu. Nie istnieje jeden standard zestawu sygnałów właściwy dla każdej aplikacji.

Najważniejsze jest określenie handshake’u, czyli jasnej sekwencji potwierdzeń pomiędzy urządzeniami.

„Wysłano dane” nie oznacza „dane zostały zastosowane”

Wyobraźmy sobie:

MES wysyła:

LOT 123

System otrzymuje wiadomość, ale przed aktywacją projektu następuje błąd.

Jeżeli MES uzna sam fakt wysłania danych za potwierdzenie, może powstać rozbieżność.

Bezpieczniejsza logika rozróżnia:

wysłano

↓

odebrano

↓

zaakceptowano

↓

aktywne

↓

wykonano

Nie każda aplikacja wymaga wszystkich etapów.

W procesach krytycznych różnica pomiędzy nimi może jednak być bardzo istotna.

Serializacja – gdzie integracja staje się szczególnie wymagająca?

Przy zwykłym nadruku:

LOT 250817

ten sam numer może zostać wydrukowany na tysiącach produktów.

Przy serializacji:

każdy produkt otrzymuje inny identyfikator.

System musi wtedy ustalić:

1. kto tworzy serial,

2. kiedy zostaje zarezerwowany,

3. kiedy zostaje przesłany,

4. kiedy zostaje uznany za wykorzystany,

5. co zrobić po nieudanym nadruku,

6. czy możliwy jest reprint,

7. co zrobić po odrzuceniu produktu,

8. gdzie zapisać wynik.

REA wskazuje integrację z ERP, MES i systemami Traceability jako element swoich rozwiązań dla kodów 2D i procesów identyfikowalności.

Reprint serialu – drobny szczegół, który może spowodować duży problem

Załóżmy:

produkt 1 → serial 000001

Kod został źle wykonany.

Produkt odrzucono.

Co dalej?

Czy:

000001 może zostać użyty ponownie?

Czy:

zostaje trwale anulowany?

Odpowiedź zależy od procesu i wymagań systemu.

Nie powinien jednak decydować o tym przypadkowo operator drukarki.

Zasada obsługi numerów powinna być określona w systemie odpowiedzialnym za serializację.

W serializacji należy zdefiniować nie tylko generowanie numeru, lecz również jego cykl życia — rezerwację, wykorzystanie, odrzucenie, ewentualny reprint i archiwizację.

Kody Data Matrix i QR – dane powinny powstawać przed drukiem

Przy kodach 2D system znakowania może otrzymać:

gotową zawartość kodu

lub:

poszczególne pola

na podstawie których generuje symbol.

Przykład:

• GTIN,

• data,

• partia,

• serial.

Ważne, aby architektura jednoznacznie określała:

• kto odpowiada za strukturę danych,

• kto wykonuje walidację,

• kto tworzy symbol,

• kto kontroluje rezultat.

Jeżeli wdrażasz oznaczenia GS1 2D, zobacz również poradnik o kodach 2D i GS1.

Drukowanie to nie koniec przepływu danych

W systemie krytycznym właściwa architektura może wyglądać tak:

ERP

↓

MES

↓

PLC

↓

system znakowania

↓

produkt

↓

kamera / REA VERIFIER

↓

PLC / MES

↓

zapis wyniku

W ten sposób powstaje zamknięta pętla:

dane → wykonanie → kontrola → decyzja

Taki przepływ może wspierać automatyczne podejmowanie decyzji procesowych, np. odrzut NOK, alarm lub blokadę dalszej produkcji – pod warunkiem że logika została świadomie zaprojektowana i zwalidowana dla danej aplikacji.

REA oferuje zarówno systemy znakowania, jak i rozwiązania do weryfikacji kodów, a w rozwiązaniach przemysłowych wynik kontroli może stanowić element zintegrowanej architektury produkcyjnej.

HMI – jakie informacje powinien widzieć operator?

Dobry ekran nie musi zawierać kilkudziesięciu parametrów technicznych.

Najczęściej operator potrzebuje:

• statusu znakowania,

• aktywnego produktu,

• aktywnej partii,

• aktualnego projektu,

• podglądu danych,

• liczby wykonanych oznaczeń,

• ostrzeżeń,

• błędów.

Dostęp do ustawień powinien być dostosowany do roli użytkownika.

Operator

Obsługuje produkcję.

Technolog

Zarządza parametrami i recepturami.

Serwis / automatyk

Diagnozuje komunikację i urządzenie.

Takie rozdzielenie może ograniczać przypadkową zmianę parametrów procesu i ułatwiać zarządzanie uprawnieniami w codziennej pracy.

Czy HMI powinien umożliwiać ręczną zmianę partii?

Czasami tak.

Ale wtedy trzeba określić:

• kto ma uprawnienie,

• kiedy ręczna zmiana jest dopuszczalna,

• czy zmiana jest zapisywana,

• czy MES otrzymuje informację,

• czy poprzednia wartość pozostaje w historii.

Jeżeli numer partii pochodzi z MES, a HMI pozwala dowolnie go nadpisać bez kontroli, pojawiają się dwa źródła prawdy.

Dlatego ręczny tryb powinien być świadomie zaprojektowaną funkcją awaryjną lub procesową, a nie przypadkowym obejściem integracji.

Co zrobić po utracie połączenia z MES?

To jedno z najważniejszych pytań projektu.

Nie istnieje jedna odpowiedź dla każdej produkcji.

Możliwe strategie:

STOP

Produkcja nie może rozpocząć kolejnego produktu bez danych.

HOLD

Aktualna seria może zostać dokończona, ale nowe zlecenie nie zostanie uruchomione.

BUFFER

System posiada kontrolowany bufor danych pozwalający kontynuować określony zakres produkcji.

TRYB LOKALNY

Dopuszczony jest lokalny scenariusz awaryjny.

To, który wariant wybrać, powinno wynikać z:

• ryzyka błędnego znakowania,

• wymagań jakości,

• Traceability,

• regulacji,

• wartości produktu,

• procesu klienta.

Właściwie zaprojektowany scenariusz awaryjny może ograniczać nieplanowane przestoje, ale nie powinien obniżać poziomu kontroli wymaganej dla jakości lub identyfikowalności.

Co po restarcie drukarki lub PLC?

System powinien potrafić jednoznacznie odpowiedzieć:

Jaki produkt jest obecnie produkowany?

Jaki projekt powinien być aktywny?

Czy dane w pamięci są nadal aktualne?

Czy można kontynuować produkcję bez ponownej synchronizacji?

W przypadku krytycznych danych rozsądnym rozwiązaniem może być ponowne potwierdzenie:

receptura → projekt → dane → gotowość

przed wznowieniem procesu.

Jak zabezpieczyć się przed wydrukiem „starych danych”?

Scenariusz:

1. linia produkuje partię A,

2. komunikacja zostaje utracona,

3. zmieniono produkcję na partię B,

4. drukarka nadal posiada dane partii A.

To klasyczny przykład problemu wynikającego nie z jakości drukarki, lecz z logiki integracji.

Możliwe zabezpieczenia to m.in.:

• ID aktywnego zlecenia,

• potwierdzenie wersji receptury,

• znaczniki aktualności,

• blokada startu bez synchronizacji,

• handshake po zmianie produktu.

Jednym z największych zagrożeń integracji znakowania nie jest brak danych, lecz wykorzystanie danych poprawnych technicznie, ale nieaktualnych dla bieżącego zlecenia.

Monitoring systemu znakowania

Integracja może służyć nie tylko do wysyłania danych do drukarki.

Można również zbierać:

• status gotowości,

• aktywny projekt,

• alarmy,

• historię zdarzeń,

• informacje serwisowe,

• dane diagnostyczne.

Platforma REA JET TITAN oferuje m.in. serwer VNC do zdalnej obsługi oraz WebGUI, a REA opisuje możliwość monitorowania i sterowania urządzeniami w środowisku produkcyjnym. Zbieranie statusów i historii zdarzeń może ułatwiać analizę przyczyn błędów, diagnostykę oraz identyfikację trudności pojawiających się podczas pracy linii.

REA JET TITAN – rola wspólnej platformy

Platforma REA JET TITAN została zaprojektowana jako wspólna koncepcja obsługi dla technologii znakowania REA JET.

Oficjalne materiały REA wskazują m.in.:

• architekturę interfejsu,

• komunikację opartą na XML,

• WebGUI,

• VNC,

• możliwość integracji OEM,

• gotowość do środowisk Industry 4.0.

Jednolita koncepcja jest szczególnie przydatna wtedy, gdy w zakładzie pracuje kilka różnych technologii znakowania i operatorzy korzystają ze wspólnego sposobu obsługi. Za pomocą odpowiednich interfejsów i oprogramowania można włączyć urządzenia do szerszego ekosystemu produkcyjnego. Integracja systemu znakowania z systemami ERP i MES to kluczowy krok w kierunku Przemysłu 4.0.

Nie oznacza to jednak, że każde urządzenie REA posiada identyczny zestaw fizycznych interfejsów lub protokołów.

Konkretne możliwości należy potwierdzić dla wybranego modelu.

Integracja nie zależy od technologii znakowania

W warstwie logicznej przepływ danych może być projektowany podobnie dla wielu technologii, ale fizyczne interfejsy, czasy cyklu, sposób wyzwalania i wymagania bezpieczeństwa nadal zależą od konkretnego urządzenia. Pod względem danych endpointem może być:

• TIJ,

• CIJ,

• DOD,

• Piezo,

• laser,

• Print & Apply.

ERP nie musi wiedzieć, w jaki sposób atrament trafia na karton.

MES nie musi wiedzieć, jak galvo steruje wiązką lasera.

Z punktu widzenia warstwy danych ważne są:

• zadanie,

• projekt,

• wartości zmienne,

• status,

• wynik.

Dlatego dobrze zaprojektowana architektura informacji może pozostać podobna nawet po zmianie technologii znakowania.

Integracja systemu MES, ERP z etykieciarkami

Ten sam model może dotyczyć systemów Print & Apply.

System może otrzymać:

• produkt,

• adres,

• numer logistyczny,

• SSCC,

• partię,

• dane odbiorcy,

a następnie automatycznie utworzyć i nanieść etykietę.

REA LABEL opisuje integrację z ERP, MES i PLC oraz automatyczne uzupełnianie zmiennych danych etykiet. Taka integracja może wspierać automatyczną wymianę danych i zwiększać efektywność zarządzania zmienną treścią, przy zachowaniu kontroli nad źródłem informacji. Systemy MES monitorują efektywność maszyn produkcyjnych w czasie rzeczywistym.

Zobacz systemy etykietujące REA LABEL.

Integracja lasera z MES i ERP

Laser również może być elementem tej samej architektury.

Zmienia się technologia wykonania oznaczenia, ale nadal mogą być przekazywane:

• numer produktu,

• partia,

• serial,

• kod,

• projekt znakowania.

REA opisuje możliwość integracji systemów laserowych z ERP i MES w celu przesyłania danych i zmiany zadań znakowania.

Zobacz systemy znakowania REA LASER.

PLC, HMI, MES i ERP – przykład 1: prosta data i partia

Zakład produkuje jeden produkt.

MES posiada:

LOT 250817

PLC wykrywa produkt.

Przepływ:

MES → LOT → drukarka

PLC → trigger → drukarka

Drukarka wykonuje:

LOT 250817

W tym przypadku nie jest potrzebna skomplikowana serializacja.

Kluczowe jest jedynie zapewnienie, że aktywna partia i fizyczny produkt są ze sobą zsynchronizowane.

Przykład 2: automatyczne przezbrojenie SKU

ERP tworzy zlecenie na Produkt B.

MES uruchamia zlecenie.

PLC zmienia recepturę maszyny.

System znakowania otrzymuje:

• ID Produkt B,

• właściwy template,

• GTIN,

• datę,

• numer partii.

Operator nie wybiera projektu osobno.

Po potwierdzeniu gotowości linia uruchamia produkcję.

To przykład integracji, w której automatyzacja ogranicza liczbę ręcznych wyborów.

Przykład 3: serializowany Data Matrix

MES lub dedykowany system generuje:

serial 00082731

↓

system znakowania tworzy Data Matrix

↓

PLC wyzwala druk

↓

kamera kontroluje kod

↓

wynik OK

↓

serial 00082731 zostaje zapisany jako wykorzystany

W takim układzie potrzebna jest jasna logika również dla wyniku:

NOK.

Przy dużej liczbie unikalnych kodów trzeba również sprawdzić wydajność całego łańcucha: generowania danych, transmisji, znakowania, kontroli oraz zapisu wyniku. Wąskim gardłem nie musi być sama drukarka.

Czy serial zostaje anulowany?

Czy można go ponowić?

To powinno być określone jeszcze przed uruchomieniem produkcji.

Przykład 4: system Print & Apply na końcu linii

ERP posiada dane odbiorcy.

MES zna jednostkę produkcyjną.

System logistyczny przygotowuje dane wysyłkowe.

Print & Apply:

1. pobiera dane,

2. drukuje etykietę,

3. aplikuje ją,

4. potwierdza proces.

W tym przypadku endpointem nie jest drukarka atramentowa, lecz etykieciarka.

Logika zarządzania danymi pozostaje jednak podobna.

Jak przetestować integrację?

Test powinien wynikać z wcześniej przygotowanej analizy ryzyka i scenariuszy pracy. Czynności serwisowe oraz restart urządzeń należy wykonywać zgodnie z dokumentacją i instrukcją właściwą dla danego systemu.

Test nie powinien ograniczać się do:

„dane pojawiły się na drukarce”.

Sprawdź również:

Zmianę produktu

Czy prawidłowo zmienia się projekt?

Zmianę partii

Czy poprzednia wartość zostaje usunięta?

Restart PLC

Czy system odzyskuje właściwy stan?

Restart drukarki

Czy stary projekt nie zostaje przypadkowo aktywny?

Utratę MES

Czy zachowanie odpowiada założonej strategii?

Zerwanie sieci

Czy występuje kontrolowany timeout?

Błędne dane

Czy system potrafi je odrzucić?

Zły projekt

Czy PLC/MES wykryje rozbieżność?

Błąd kodu

Czy linia wie, jak zareagować?

Checklista przed uruchomieniem integracji ERP/MES/PLC

• Określono źródło danych produktu.

• Określono źródło numeru partii.

• Określono źródło daty.

• Określono system odpowiedzialny za serializację.

• Powiązano recepturę maszyny z projektem nadruku.

• Określono sposób wyzwalania druku.

• Zdefiniowano status Ready.

• Zdefiniowano status Error.

• Określono handshake danych.

• Określono reakcję na timeout.

• Określono reakcję na utratę MES.

• Określono reakcję na utratę drukarki.

• Określono zachowanie po restarcie PLC.

• Określono zachowanie po restarcie systemu znakowania.

• Ustalono prawa operatora do ręcznych zmian.

• Zdefiniowano reprint.

• Zdefiniowano obsługę odrzuconego serialu.

• Zaplanowano kontrolę kodu.

• Sprawdzono logowanie zdarzeń.

• Przygotowano testy sytuacji awaryjnych.

Najczęstsze błędy przy integracji systemu znakowania z ERP i MES

1. Brak jednoznacznego właściciela danych

ERP i MES posiadają różne wartości tej samej zmiennej.

2. Ręczna zmiana projektu na drukarce

Receptura maszyny i projekt nadruku mogą się rozjechać.

3. Brak potwierdzenia załadowania danych

System nadrzędny wie tylko, że komunikat został wysłany.

4. Brak kontroli aktualności danych

Po utracie komunikacji drukarka może posiadać poprawne, lecz stare dane.

5. Brak logiki po restarcie

Nie wiadomo, czy produkcję można bezpiecznie wznowić.

6. HMI staje się drugim źródłem informacji

Operator może nadpisać dane pochodzące z MES bez kontroli.

7. Brak scenariusza NOK dla serializacji

Nie wiadomo, co zrobić z numerem po błędzie druku.

8. Protokół wybrano przed zaprojektowaniem procesu

Zespół wie, że użyje OPC UA, ale nadal nie wie, jakie informacje mają być przesyłane i kto jest ich właścicielem.

9. Brak integracji informacji zwrotnej

System wysyła dane do znakowania, ale nie otrzymuje statusu procesu.

10. Testowany jest tylko idealny przypadek

Pierwszy test awarii odbywa się dopiero podczas rzeczywistej produkcji.

PLC / HMI / MES / ERP – 12 faktów

1. ERP, MES, PLC i HMI nie pełnią tej samej funkcji w procesie znakowania.

2. ERP jest przede wszystkim warstwą biznesową i planistyczną, a PLC steruje fizycznym przebiegiem procesu. Model ISA-95 umieszcza zarządzanie operacjami produkcyjnymi pomiędzy sterowaniem a warstwą ERP.

3. MES może łączyć zlecenie produkcyjne z rzeczywistą partią, operacją i danymi Traceability.

4. PLC jest naturalnym źródłem informacji o fizycznym momencie wyzwolenia nadruku.

5. HMI powinien przede wszystkim prezentować operatorowi stan procesu i umożliwiać kontrolowane działania, a nie tworzyć niekontrolowanego drugiego źródła danych.

6. Dobra integracja określa właściciela każdej zmiennej przed wyborem protokołu komunikacyjnego.

7. Ethernet lub OPC UA nie definiują architektury danych — określają jedynie część sposobu komunikacji.

8. Przy zmianie SKU projekt nadruku powinien być jednoznacznie powiązany z właściwym produktem lub recepturą.

9. W serializacji trzeba zarządzać całym cyklem życia numeru: generowaniem, rezerwacją, użyciem, błędem i ewentualnym reprintem.

10. Najgroźniejszym błędem komunikacji może być nie brak danych, ale wykorzystanie nieaktualnych danych z poprzedniego zlecenia.

11. Platforma REA JET TITAN została zaprojektowana do integracji przemysłowej i wykorzystuje m.in. komunikację opartą na XML, WebGUI oraz narzędzia zdalnej obsługi.

12. Integracja powinna obejmować nie tylko wysyłanie danych do urządzenia, ale również statusy, kontrolę wykonania oraz zdefiniowaną reakcję na błędy.

PLC, HMI, MES i ERP – szybkie drzewo decyzji

Skąd pochodzi indeks produktu?
→ najczęściej ERP / dane podstawowe

Co jest aktualnie produkowane?
→ MES / system zarządzający produkcją

Czy produkt właśnie znajduje się przy drukarce?
→ PLC

Kiedy wykonać nadruk?
→ PLC / czujnik / logika maszyny

Co powinien widzieć operator?
→ HMI

Gdzie powinien znajdować się projekt?
→ system znakowania lub centralne repozytorium – zależnie od architektury

Kto generuje unikalny serial?
→ MES / system serializacyjny / baza nadrzędna

Kto potwierdza jakość kodu?
→ kamera / weryfikator

Gdzie archiwizować wynik?
→ MES / system Traceability / odpowiednia baza

Integracja systemu znakowania z ERP i MES – podsumowanie

Dobra integracja nie zaczyna się od przewodu.

Nie zaczyna się również od wyboru OPC UA, XML czy Ethernet/IP.

Zaczyna się od odpowiedzi:

Jakie dane są potrzebne?

Skąd pochodzą?

Który system jest ich właścicielem?

Kiedy powinny trafić do urządzenia?

Jak potwierdzamy ich zastosowanie?

Co dzieje się po błędzie?

W praktyce ERP, MES, PLC i HMI powinny tworzyć spójny łańcuch informacji prowadzący do systemu znakowania. W firmie posiadającej wiele linii lub zakładów szczególnego znaczenia nabierają również spójne zasady wersjonowania projektów, uprawnień i obsługi błędów.

Najprostszy model można zapisać jako:

ERP → zlecenie

MES → realizacja

PLC → fizyczny proces

HMI → operator

system znakowania → wykonanie

weryfikacja → potwierdzenie

Dopiero po zdefiniowaniu tej logiki warto wybrać konkretne interfejsy komunikacyjne.

FAQ – PLC / HMI / MES / ERP i system znakowania

Czy drukarkę przemysłową można połączyć z ERP?

Tak. System znakowania może otrzymywać z systemu nadrzędnego dane potrzebne do przygotowania nadruku. Dokładna architektura zależy od urządzenia, ERP i infrastruktury przedsiębiorstwa. REA opisuje integrację swoich rozwiązań z ERP i MES.

Czy drukarka może współpracować z MES?

Tak. MES (Manufacturing Execution System) może dostarczać m.in. informacje związane ze zleceniem, partią lub serializacją, zależnie od architektury procesu. Integracja systemu MES z systemem znakowania powinna określać źródła danych, potwierdzenia i zachowanie po utracie komunikacji.

Czy PLC powinien wysyłać dane do drukarki?

Może. PLC często przekazuje trigger, recepturę, ID projektu lub dane potrzebne na poziomie maszyny. Nie musi jednak być właścicielem wszystkich danych biznesowych.

Czy ERP powinien bezpośrednio sterować drukarką?

Nie ma jednej uniwersalnej architektury. W wielu instalacjach pomiędzy ERP a fizycznym procesem występuje MES, middleware albo PLC. Model powinien wynikać z architektury IT/OT zakładu.

Do czego służy HMI przy integracji znakowania?

Do prezentacji operatorowi stanu procesu, aktywnego produktu, danych i alarmów oraz realizacji dozwolonych działań.

Czy operator powinien ręcznie wpisywać numer partii?

Jeżeli numer istnieje już w systemie nadrzędnym, automatyczne przekazanie danych może ograniczyć ryzyko ręcznej pomyłki.

Co to jest handshake?

To uzgodniona sekwencja sygnałów lub komunikatów potwierdzających kolejne etapy wymiany informacji między systemami.

Czy Ethernet wystarczy do integracji?

Nie. Ethernet zapewnia warstwę komunikacyjną, ale nadal trzeba określić format danych, logikę potwierdzeń, reakcję na błędy i źródło informacji.

Czy REA JET obsługuje XML?

Platforma REA JET TITAN wykorzystuje protokół komunikacyjny oparty na XML.

Czy REA JET współpracuje z OPC UA?

Oficjalne materiały REA dotyczące systemów znakowania wymieniają wśród przykładów interfejsów m.in. OPC UA, Ethernet/IP i Profinet. Dostępność należy potwierdzić dla konkretnego systemu.

Czy można sterować drukarką z HMI maszyny?

W odpowiednio zaprojektowanych systemach tak. REA opisuje możliwość użycia WebGUI oraz bezpośredniej integracji z systemem sterowania maszyny.

Co zrobić po utracie MES?

Reakcję trzeba określić podczas projektowania procesu. Może to być zatrzymanie, hold, kontrolowany bufor danych albo dopuszczony tryb lokalny.

Kto powinien generować numery seryjne?

System odpowiedzialny za serializację i kontrolę unikalności — może to być MES, dedykowany serwer lub inny system nadrzędny.

Czy po błędzie można ponownie wydrukować ten sam serial?

To zależy od zasad procesu. Reguła powinna być zdefiniowana centralnie, aby uniknąć duplikatów.

Czy system znakowania może przesyłać dane zwrotne?

Odpowiednio zintegrowany system może przekazywać statusy i informacje procesowe. Zakres zależy od urządzenia oraz użytego interfejsu.

Czy laser również można integrować z ERP/MES?

Tak. REA opisuje integrację systemów laserowych z ERP/MES i automatyczne przekazywanie danych do znakowania.

Czy etykieciarka może współpracować z MES?

Tak. REA LABEL przewiduje integrację z ERP, MES i automatyką PLC.

Czym ten temat różni się od integracji OEM?

Integracja OEM koncentruje się przede wszystkim na wbudowaniu systemu znakowania w maszynę: mechanice, sterowaniu, przestrzeni, HMI, czujnikach i uruchomieniu. Integracja PLC/HMI/MES/ERP dotyczy przede wszystkim architektury informacji, źródeł danych oraz komunikacji pomiędzy warstwami produkcji. Każdy wyprodukowany detal otrzymuje unikalny kod powiązany z partią surowców w bazie MES/ERP.

Chcesz połączyć system znakowania z PLC, MES lub ERP?

Nie zaczynaj projektu od wyboru protokołu.

Najpierw przygotuj:

• schemat architektury systemów,

• przykładowe dane do nadruku,

• listę zmiennych,

• źródło numeru partii,

• źródło serializacji,

• model PLC,

• system MES,

• system ERP,

• sposób zmiany receptury,

• wymagane statusy,

• scenariusze błędów.

Na tej podstawie można określić właściwą architekturę komunikacji i dobrać system znakowania do infrastruktury w Twojej firmie. Przy danych pochodzących z różnych źródeł warto dodatkowo zdefiniować priorytety, walidację i jednoznaczne zasady odpowiedzialności.

Zobacz drukarki przemysłowe REA JET oraz rozwiązania dla producentów maszyn i integratorów OEM.