Panele produkcyjne w systemie ERP - rejestracja zdarzeń na hali

Panel produkcyjny jest ekranem, przy którym operator zgłasza systemowi ERP to, co dzieje się na stanowisku. Zamiast papierowej karty i wieczornego wpisywania danych w biurze zdarzenie trafia do bazy w chwili, gdy zaszło. Artykuł opisuje ten mechanizm na przykładzie panelów produkcyjnych systemu HermesSQL firmy Humansoft oraz jako wiedzę ogólną o rejestracji zdarzeń na hali.

Według opisu programu operator rejestruje rozpoczęcie i zatrzymanie operacji oraz jej wznowienie i zakończenie, a także melduje wykonaną ilość, a system generuje dokumenty i ruchy magazynowe. Elementy takie jak walidacja, kody przyczyn czy tryby zapisu opisujemy jako typowe rozwiązania inżynierskie, bez deklarowania, że każde z nich występuje w konkretnej wersji produktu.

Panele produkcyjne jako punkt rejestracji na hali

Panel stoi blisko maszyny albo na jej stanowisku i ma jedno zadanie: przyjąć zdarzenie od człowieka i przekazać je do systemu bez pośredników. Im mniej ekranów i pól, tym krótszy czas zgłoszenia i mniejsze ryzyko pomyłki.

Co rejestruje panel

Podstawowy zestaw zdarzeń jest krótki, a każde z nich zmienia stan operacji w zleceniu produkcyjnym.

• Start i wznowienie - operacja przechodzi do statusu w toku, a system zaczyna liczyć czas pracy.
• Stop i zakończenie - zatrzymanie z przyczyną albo domknięcie operacji z ostatecznym zameldowaniem ilości.
• Zameldowanie ilości - liczba sztuk wykonanych od poprzedniego zgłoszenia, dodawana do wyniku operacji.
• Przestój lub przerwa - okres, w którym stanowisko nie produkuje, wraz z powodem wybranym z listy.

Panel a meldunek wprowadzany w biurze

Meldunek wpisywany po fakcie opiera się na pamięci operatora albo na kartce, więc rejestruje wynik, a nie przebieg. Panel zapisuje moment każdego zdarzenia. Różnica ujawnia się w analizie: z samego wyniku nie da się odczytać, że operacja stała czterdzieści minut przez brak materiału. Ogólne zasady meldowania postępów opisuje artykuł o zarządzaniu produkcją w HermesSQL.

Ekran stanowiskowy i identyfikacja operatora

Ekran stanowiskowy projektuje się pod rękawice robocze i hałas na hali. Większe przyciski i wyraźne stany oraz minimum pisania decydują o tym, czy operatorzy będą używać panelu, czy wrócą do kartki.

Logowanie operatora

Każde zdarzenie potrzebuje autora. Operator loguje się kartą lub skanem kodu z identyfikatora, co trwa sekundę. Na czas pracy stanowiska system zapamiętuje sesję, ale wymusza ponowną identyfikację po przerwie. Ma to znaczenie przy rozliczaniu czasu pracy i przy wyjaśnianiu, kto zameldował daną ilość.

Układ ekranu

Ekran pokazuje tylko zlecenia i operacje przypisane do danego stanowiska, w kolejności planu. Aktywna operacja jest wyróżniona, a dostępne akcje ograniczone do tych, które wynikają z jej statusu. Operacja w toku nie oferuje przycisku start, a operacja niezaczęta nie pozwala zameldować ilości.

Role i uprawnienia na panelu

Operator zgłasza zdarzenia, ale nie poprawia cudzych zapisów. Korekta zameldowanej ilości należy do brygadzisty albo kontrolera, a każda zmiana zostawia ślad w historii wraz z wartością przed korektą i po niej. Dzięki temu zapis produkcji zachowuje wartość dowodową, a spór o wynik zmiany kończy się na danych.

Kilku operatorów może pracować przy jednej operacji, na przykład przy montażu wieloosobowym. Panel zapisuje wtedy zdarzenia z podziałem na osoby, a system sumuje ilości i czasy na poziomie operacji. Bez takiego podziału nie da się ocenić wydajności pojedynczego stanowiska.

Kody kreskowe zamiast pisania

Czytnik kodów kreskowych zastępuje wpisywanie numerów. Skan kodu z przewodnika warsztatowego wskazuje zlecenie i operację jednym ruchem, a skan etykiety materiału potwierdza pobranie właściwego surowca. Wprowadzanie danych z klawiatury zostaje dla wyjątków. O identyfikacji kodami piszemy szerzej w tekście o kodach kreskowych w programie WMS.net.

Zdarzenia produkcyjne i model danych

Panel produkcyjny sprowadza rejestrację do kilku typów zdarzeń zapisywanych w jednej tabeli. Taki model jest prosty, ale z zapisu można odtworzyć pełną historię operacji i wyliczyć z niej czasy oraz ilości.

Tabela zdarzeń w bazie SQL

Schemat poniżej jest przykładowy i nie odzwierciedla struktury żadnego produktu. Pokazuje za to dwie ważne cechy: ograniczenia CHECK pilnujące poprawnych typów oraz unikalny identyfikator zgłoszenia nadawany przez klienta.

-- przykładowy schemat zdarzeń produkcyjnych z kontrolą po stronie bazy
CREATE TABLE dbo.ZdarzenieProdukcji (
    Id               bigint IDENTITY(1,1) PRIMARY KEY,
    IdKlienta        uniqueidentifier NOT NULL UNIQUE,
    ZlecenieId       int           NOT NULL,
    OperacjaId       int           NOT NULL,
    Typ              varchar(10)   NOT NULL,
    Ilosc            decimal(12,3) NULL,
    OperatorId       int           NOT NULL,
    Czas             datetime2(0)  NOT NULL DEFAULT SYSDATETIME(),
    CONSTRAINT CK_Zdarzenie_Typ   CHECK (Typ IN ('START', 'STOP', 'WZNOW', 'KONIEC', 'ILOSC', 'BRAK')),
    CONSTRAINT CK_Zdarzenie_Ilosc CHECK (Ilosc IS NULL OR Ilosc > 0)
);

Identyfikator klienta chroni przed dublami. Gdy sieć zerwie się w chwili potwierdzenia, panel ponowi zgłoszenie z tym samym identyfikatorem, a baza odrzuci powtórkę przez klucz UNIQUE zamiast zaliczyć ilość dwa razy. Ograniczenia opisuje dokumentacja ograniczeń CHECK w SQL Server.

Dozwolone przejścia stanów operacji

Operacja ma cykl życia, w którym nie każde przejście jest możliwe. Z gotowej można przejść do w toku, z w toku do zatrzymanej albo zakończonej, z zatrzymanej z powrotem do w toku. Zakończonej operacji nie wznawia się bez decyzji osoby z uprawnieniami.

Walidacja wejścia na panelu

Walidacja decyduje o jakości danych, bo błąd zapisany na hali wraca później jako rozjazd w magazynie i kosztach. Kontrole działają w dwóch miejscach: na ekranie, żeby operator dostał szybką informację, i w bazie, która nie ufa niczemu z zewnątrz.

Walidacja po stronie ekranu

Ekran blokuje oczywiste pomyłki jeszcze przed wysłaniem: ilość ujemną, pole puste albo zdarzenie niedozwolone dla bieżącego statusu. Przykład wywołania AJAX pokazuje, jak panel przekazuje zdarzenie i wyświetla operatorowi przyczynę odrzucenia.

// przykładowe wywołanie AJAX z panelu; adres i format są poglądowe
async function zglosZdarzenie(zdarzenie) {
  const odp = await fetch('/api/produkcja/zdarzenia', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ ...zdarzenie, idKlienta: crypto.randomUUID() })
  });

  if (!odp.ok) {
    const blad = await odp.json();
    pokazKomunikat(blad.komunikat);   // operator widzi przyczynę odrzucenia
    return false;
  }
  return true;
}

Walidacja w bazie danych

Ostateczną kontrolę wykonuje baza, ponieważ ekran można ominąć albo uruchomić w starej wersji. Procedura sprawdza status operacji pod blokadą wiersza, więc dwa równoległe zgłoszenia nie uruchomią jej podwójnie.

-- przykładowa procedura: start operacji z kontrolą dozwolonego statusu
CREATE PROCEDURE dbo.ZglosStart
    @IdKlienta uniqueidentifier, @ZlecenieId int, @OperacjaId int, @OperatorId int
AS
BEGIN
    SET NOCOUNT ON;
    BEGIN TRANSACTION;

    DECLARE @Status varchar(12) =
        (SELECT Status
         FROM dbo.OperacjaZlecenia WITH (UPDLOCK, ROWLOCK)
         WHERE ZlecenieId = @ZlecenieId AND OperacjaId = @OperacjaId);

    IF @Status IS NULL OR @Status NOT IN ('GOTOWA', 'ZATRZYMANA')
    BEGIN
        ROLLBACK TRANSACTION;
        THROW 50010, N'Operacja nie może zostać uruchomiona w bieżącym statusie.', 1;
    END;

    UPDATE dbo.OperacjaZlecenia SET Status = 'W_TOKU'
    WHERE ZlecenieId = @ZlecenieId AND OperacjaId = @OperacjaId;

    INSERT INTO dbo.ZdarzenieProdukcji (IdKlienta, ZlecenieId, OperacjaId, Typ, OperatorId)
    VALUES (@IdKlienta, @ZlecenieId, @OperacjaId, 'START', @OperatorId);

    COMMIT TRANSACTION;
END;

Reguła: panel nigdy nie decyduje, czy zdarzenie jest dozwolone. Robi to procedura po stronie serwera, a ekran tylko wyświetla wynik.

Czas rzeczywisty a zapis zbiorczy

Zdarzenie można zapisać od razu albo zebrać kilka i wysłać razem. Oba podejścia mają zastosowanie, a wybór wynika z charakteru operacji i jakości łączności na hali.

Kiedy wybrać czas rzeczywisty

Zapis natychmiastowy ma sens tam, gdzie liczy się reakcja: przy przestojach maszyn, przy krótkich seriach i przy zleceniach z rygorystycznym terminem. Dyspozytor widzi wtedy stan hali bez chodzenia po wydziałach, a kierownik utrzymania ruchu dostaje sygnał o zatrzymaniu w chwili jego zgłoszenia.

Kiedy wystarczy zapis zbiorczy

Przy operacjach wykonywanych masowo i rzadko kontrolowanych zapis zbiorczy bywa wystarczający. Operator melduje ilość raz na paletę albo na koniec zmiany. Traci się dokładność czasu, ale zyskuje prostszą obsługę. Wąskim gardłem takiego wyboru jest jakość deklaracji: liczba wpisana z pamięci różni się od liczby zliczonej na bieżąco.

Kolejka lokalna przy słabej sieci

Tam, gdzie sieć bezprzewodowa gubi zasięg, panel może kolejkować zdarzenia i wysyłać je po odzyskaniu łączności. Zdarzenia zachowują wtedy czas zajścia, a nie czas dostarczenia, co wymaga zegara zsynchronizowanego z serwerem. Rozwiązanie zwiększa odporność, ale wydłuża okres niepewności dla planisty.

Braki i przestoje w danych panelu

Sama ilość wykonana opisuje tylko połowę przebiegu operacji. Druga połowa to to, co poszło źle: sztuki niezgodne oraz zatrzymania z oczekiwaniem na materiał. Panel zbiera je razem z ilością, więc analiza nie wymaga osobnego formularza.

Kody przyczyn zatrzymań

Lista kodów przyczyn ma być krótka i jednoznaczna. Kilkanaście pozycji, na przykład brak materiału albo awaria, pozwala operatorowi wybrać jedną w dwie sekundy. Długa lista zamienia się w pole, do którego wpisuje się ostatnią pozycję. Zapis przestojów stanowi podstawę do wyliczania wydajności stanowisk, czym zajmuje się tekst o monitorach wydziałowych.

Rejestracja braków

Sztuki niezgodne zgłasza się osobno od dobrych, z kodem wady. Dzięki temu do przyjęcia na magazyn trafia wyłącznie ilość zgodna, a brak nie zawyża wyniku operacji. Reguły kwalifikacji wad i ich wpływ na zamknięcie zlecenia omawia artykuł o kontroli jakości w systemie produkcyjnym.

Skutki magazynowe i rozliczenie zlecenia

Zgłoszenia z panelu zmieniają nie tylko status zlecenia. Według opisu HermesSQL system rejestruje na ich podstawie ruchy magazynowe: wydanie surowców do produkcji i przyjęcie wyrobów gotowych. Dokumenty powstają automatycznie, więc nikt nie wpisuje ich ponownie.

Ruchy magazynowe z meldunków

Zameldowana ilość dobra zwiększa stan wyrobu gotowego, a zużycie surowca wynika z normatywu lub z rzeczywistego pobrania. Skutek widać na stronie o stanach magazynowych oraz w opisie dokumentów magazynowych. Zlecenie, z którego wynikają te ruchy, powstaje przy emisji, a jej przebieg opisuje artykuł o emisji zleceń produkcyjnych.

Czasy i koszty operacji

Zapisy start i stop dają czas rzeczywisty operacji, który porównuje się z normatywem z technologii. Odchylenie wskazuje, gdzie norma jest nierealna albo gdzie proces ma stratę. Na tym opiera się kalkulacja kosztu, którą rozwija tekst o tym, jak dokładnie poznać koszt produkcji, a zestawienia trafiają do raportów opisanych w artykule o raportach kontroli produkcji.

Wdrożenie paneli na hali

Panel działa dobrze wtedy, gdy zmieści się w rytmie pracy stanowiska. Wdrożenie zaczyna się więc od hali, a nie od oprogramowania.

Sprzęt i sieć

Terminal, tablet przemysłowy albo komputer z ekranem dotykowym wybiera się pod warunki stanowiska: pył i wilgoć oraz rękawice robocze i oświetlenie. Sieć bezprzewodowa musi pokrywać całą halę, w tym miejsca przy regałach i za maszynami. Urządzenia mobilne z czytnikami oferuje SoftwareStudio w ramach usługi terminali radiowych, choć panel produkcyjny HermesSQL nie musi z nich korzystać.

Kontrola kompletności zapisów

Po uruchomieniu paneli trzeba sprawdzać, czy dane faktycznie napływają. Operacja oznaczona jako w toku, od której od kilku godzin nie ma żadnego zgłoszenia, wskazuje zapomniany stop albo panel, który przestał działać. Prosta kwerenda wykrywa taką sytuację i trafia do raportu poranka.

-- przykładowa kontrola: operacje w toku bez zgłoszenia od ponad 4 godzin
SELECT o.ZlecenieId, o.OperacjaId, MAX(z.Czas) AS OstatnieZdarzenie
FROM dbo.OperacjaZlecenia AS o
JOIN dbo.ZdarzenieProdukcji AS z
  ON z.ZlecenieId = o.ZlecenieId AND z.OperacjaId = o.OperacjaId
WHERE o.Status = 'W_TOKU'
GROUP BY o.ZlecenieId, o.OperacjaId
HAVING MAX(z.Czas) < DATEADD(HOUR, -4, SYSDATETIME());

Próg czterech godzin jest przykładowy i zależy od czasu trwania operacji. Dla operacji krótkich, trwających kilka minut, próg powinien być znacznie niższy. Wynik kwerendy nie oznacza błędu operatora. Bywa tylko sygnałem, że proces wymaga wyjaśnienia na hali.

Szkolenie i pilotaż

Pilotaż na jednym wydziale pokazuje, które zdarzenia operatorzy faktycznie zgłaszają, a które omijają. Szkolenie trwa krótko, bo obsługa opiera się na kilku przyciskach. Trudniejsze bywa przyzwyczajenie do zgłaszania przestojów, które odsłaniają problemy wcześniej niewidoczne. Ogólny plan projektu opisuje artykuł o przebiegu wdrożenia systemu ERP.