AI w narzędziowni i odzieży roboczej - wspólny model danych

AI w narzędziowni i odzieży roboczej - skąd biorą się dane

Algorytm potrzebuje zdarzeń, a narzędziownia wytwarza je bez przerwy: każde wydanie i każdy zwrot to wiersz w bazie, podobnie jak przegląd albo wymiana. Wiersz niesie datę i numer egzemplarza, a przy wydaniu także osobę. Odzież robocza generuje zdarzenia tego samego rodzaju: wydanie sortu i jego wymianę, a między nimi kolejne pranie. Stąd AI w narzędziowni i odzieży roboczej zaczyna się od ewidencji, a dopiero potem od modelu.

W opisie Studio TCS.net system CMMS z modułem AI analizuje w jednym miejscu dane o zużyciu narzędzi i cyklach pracy maszyn, a osobno historię wydań odzieży ochronnej. Ten sam mechanizm prognozy da się zastosować do każdego z tych obszarów, bo różni się tylko rodzaj zdarzenia i jednostka zużycia.

Reguła: zapis zbiorczy i późniejszy jest dla modelu szumem. Zdarzenie ma powstać przy wydaniu i zawierać nazwisko oraz numer egzemplarza.

Podstawy ewidencji narzędzi opisuje strona o zarządzaniu narzędziami, a odzieży - tekst o systemie do zarządzania odzieżą roboczą. Sposób, w jaki jeden system porządkuje oba obszary razem z przeglądami maszyn, przedstawia artykuł jak jeden system porządkuje narzędziownię i odzież.

Wspólny model danych w narzędziowni

Trzy obszary mieszczą się w jednym schemacie relacyjnym. Egzemplarz narzędzia i sort odzieży są rekordami tej samej kartoteki z polem typu i statusu, a środek ochrony indywidualnej też. Wszystkie ruchy trafiają do wspólnej tabeli zdarzeń. Taki układ pozwala zadać jedno zapytanie o koszt, zamiast zbierać wyciągi z trzech arkuszy.

Kartoteka egzemplarza i tabela zdarzeń

• Egzemplarz - rekord z numerem ewidencyjnym i statusem; odpowiednik karty narzędzia albo karty sortu.
• Zdarzenie - wiersz z datą i rodzajem operacji, powiązany z egzemplarzem; nigdy nie jest nadpisywany, tylko dopisywany.
• Osoba - pracownik odpowiedzialny za egzemplarz od chwili zatwierdzenia dokumentu wydania.
• Zlecenie - powiązanie zdarzenia z naprawą maszyny, dzięki któremu koszt narzędzi trafia na właściwe urządzenie.

Zdarzenia dopisywane, a nie nadpisywane, dają modelowi pełną historię. Przy nadpisywaniu statusu znika informacja, ile razy egzemplarz był wydawany i jak długo, a tym samym podstawa do jakiejkolwiek prognozy zużycia.

CREATE TABLE dbo.zdarzenie (
    id_zdarzenia bigint IDENTITY PRIMARY KEY,
    id_egzemplarza int NOT NULL,
    rodzaj nvarchar(20) NOT NULL,      -- wydanie, zwrot, pranie, przeglad, wymiana
    id_pracownika int NULL,
    id_zlecenia int NULL,
    data_zdarzenia datetime2(0) NOT NULL DEFAULT SYSDATETIME()
);
CREATE INDEX ix_zdarzenie_egzemplarz
    ON dbo.zdarzenie (id_egzemplarza, data_zdarzenia) INCLUDE (rodzaj);

Indeks po egzemplarzu i dacie z kolumną rodzaju w części dołączonej obsługuje najczęstsze zapytanie, czyli historię jednego egzemplarza, bez odczytu całych wierszy. Nazwy są przykładowe, a struktura pokazuje mechanizm, nie schemat konkretnego produktu.

Ta sama tabela odtwarza stan egzemplarza na dowolny dzień z przeszłości, co przydaje się przy audycie i w sporze o to, kto miał narzędzie w danym tygodniu.

SELECT id_egzemplarza, rodzaj, id_pracownika, data_zdarzenia
FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY id_egzemplarza
                                   ORDER BY data_zdarzenia DESC) AS nr
      FROM dbo.zdarzenie
      WHERE data_zdarzenia <= @na_dzien) AS h
WHERE nr = 1;

Koszt utrzymania jednej maszyny

Wspólna baza odpowiada na pytanie, ile w ciągu roku kosztuje utrzymanie jednej maszyny. Zapytanie musi zsumować części zamienne i użycie narzędzi specjalistycznych, a osobno czas technika. Przy łączeniu kilku tabel powiązanych ze zleceniem zwykłe złączenia pomnożyłyby wiersze i zawyżyły sumy, dlatego każdą składową liczy się w osobnym zapytaniu skorelowanym.

SELECT z.id_maszyny,
       SUM(z.godziny_pracy * z.stawka_godzinowa) AS praca,
       SUM(cz.koszt) AS czesci,
       SUM(nw.koszt) AS narzedzia
FROM dbo.zlecenie AS z
OUTER APPLY (SELECT SUM(ilosc * cena_jedn) AS koszt
             FROM dbo.zlecenie_czesc
             WHERE id_zlecenia = z.id_zlecenia) AS cz
OUTER APPLY (SELECT SUM(godziny_uzycia * stawka_amortyzacji) AS koszt
             FROM dbo.zlecenie_narzedzie
             WHERE id_zlecenia = z.id_zlecenia) AS nw
WHERE z.data_zamkniecia >= DATEADD(YEAR, -1, SYSDATETIME())
GROUP BY z.id_maszyny;

Nazwy tabel i kolumn są przykładowe. Stawka amortyzacji narzędzia to wartość ustalana w firmie, na przykład jako koszt zakupu podzielony przez oczekiwaną liczbę godzin użycia. Zapis wypożyczenia w karcie zlecenia sprawia, że ta liczba powstaje bez dodatkowej pracy.

Prognoza zużycia narzędzi i punkt ponownego zamówienia

Narzędzia zużywalne, na przykład wiertła i tarcze, znikają ze stanu w tempie zależnym od zleceń. Punkt ponownego zamówienia liczy się jako średnie dzienne zużycie pomnożone przez czas dostawy w dniach, powiększone o zapas bezpieczeństwa. Model AI nie zmienia tego wzoru; poprawia jego pierwszy składnik, czyli oszacowanie zużycia.

Najprostsza prognoza opiera się na średniej ruchomej z kilku ostatnich tygodni. W T-SQL wystarczy do tego funkcja okna, opisana w dokumentacji klauzuli OVER.

SELECT id_typu_narzedzia, tydzien, wydania,
       AVG(1.0 * wydania) OVER (
           PARTITION BY id_typu_narzedzia
           ORDER BY tydzien
           ROWS BETWEEN 7 PRECEDING AND CURRENT ROW) AS srednia_8_tyg
FROM dbo.wydania_tygodniowo;

Jakość prognozy mierzy się błędem względem rzeczywistych wydań, na przykład średnim błędem bezwzględnym z ostatnich tygodni. Gdy błąd rośnie, prognoza przestaje pasować do zużycia i trzeba zmienić długość okna albo współczynnik wygładzania.

Zapas bezpieczeństwa zależy od zmienności zużycia oraz od zmienności czasu dostawy. Im większe odchylenie standardowe zużycia, tym większy zapas przy tym samym oczekiwanym poziomie obsługi. Dla narzędzi o stałym zużyciu wystarcza niewielki bufor, a dla tych, których użycie skacze razem ze zleceniami, bufor musi być większy albo prognoza musi korzystać z planu produkcji.

Dane o zużyciu mają wartość wtedy, gdy są powiązane z faktycznymi stanami. System narzędziowy pokazujący jedną liczbę i fizyczna kontrola pokazująca inną kończą się sporem o to, któremu zapisowi wierzyć. Integracja ze stanami magazynowymi usuwa tę rozbieżność u źródła.

Odzież robocza i środki ochrony indywidualnej

Ewidencja odzieży rządzi się innymi regułami niż narzędziownia. Ważny jest obieg egzemplarza, a także jego stan po kolejnych praniach oraz okres eksploatacji przewidziany przez producenta. Program prowadzi historię każdego sortu i sygnalizuje moment, w którym element traci właściwości ochronne. Szerzej pisze o tym strona o ewidencji środków ochrony indywidualnej.

W ewidencji opartej na zdarzeniach licznik prań jest zwykłą sumą zdarzeń danego rodzaju, więc nie wymaga osobnego pola do ręcznej aktualizacji. Zapytanie wskazuje sorty, które osiągnęły limit cykli ustalony dla danego typu odzieży.

SELECT z.id_egzemplarza, COUNT(*) AS liczba_pran
FROM dbo.zdarzenie AS z
WHERE z.rodzaj = N'pranie'
GROUP BY z.id_egzemplarza
HAVING COUNT(*) >= @limit_cykli;

Podejście predykcyjne, znane z monitorowania maszyn, sprawdza się także tutaj. System uczy się na danych o zużyciu i intensywności pracy stanowisk, więc zapotrzebowanie na nowy sort widzi z wyprzedzeniem, a nie dopiero po zgłoszeniu braku przez pracownika. Mechanizm szczegółowo rozwija tekst o sztucznej inteligencji w ewidencji sortów odzieżowych.

Rozmiar jest osobnym wymiarem prognozy. Zapas sortów liczy się dla każdej pary typ i rozmiar, bo nadwyżka w jednym rozmiarze nie pokrywa braku w innym. Zmiana obsady stanowiska albo przyjęcie nowych osób przesuwa popyt szybciej niż historia wydań, więc plan kadrowy jest dodatkowym źródłem danych dla prognozy.

Pracodawca odpowiada za to, by środki ochrony indywidualnej były sprawne, a ich wydania dało się udokumentować. Pełna historia wydań i wymian w jednym systemie skraca przygotowanie dokumentacji do kontroli, bo nie trzeba zestawiać wyciągów z kilku źródeł. Automatyczne przypomnienia o terminach wymiany mają więc znaczenie organizacyjne i formalne.

Alerty terminowe dla przeglądów i zwrotów

Część wniosków nie wymaga uczenia maszynowego. Terminy da się policzyć zwykłym zapytaniem i wysłać z wyprzedzeniem, a algorytm zostawia się dla zadań, w których reguła nie wystarcza. Przegląd okresowy i legalizacja narzędzia pomiarowego mają datę graniczną, podobnie jak zwrot wypożyczenia, więc system może ostrzegać przed jej upływem. Rejestr terminów opisuje strona o legalizacji narzędzi pomiarowych, a zasady terminów zwrotu - tekst o wypożyczaniu narzędzi z magazynu.

SELECT n.id_egzemplarza, n.nazwa, n.termin_przegladu
FROM dbo.egzemplarz AS n
WHERE n.termin_przegladu BETWEEN CAST(SYSDATETIME() AS date)
                             AND DATEADD(DAY, 14, CAST(SYSDATETIME() AS date))
ORDER BY n.termin_przegladu;

Zapytanie działa jako zadanie SQL Agent uruchamiane raz na dobę, a jego wynik trafia do kolejki powiadomień. Okno ostrzeżenia, tu czternaście dni, ustawia się osobno dla każdego typu narzędzia, bo przegląd wymagający wysyłki do zewnętrznego laboratorium potrzebuje dłuższego wyprzedzenia niż kontrola na miejscu.

Kody i znaczniki jako źródło zdarzeń

Kod kreskowy albo tag RFID zmienia pracę magazyniera narzędziowni z wpisywania numerów na rejestrację zdarzenia jednym skanem. Pracownik odbierający narzędzie potwierdza wydanie przy stanowisku, a system automatycznie nalicza czas wypożyczenia i przypomina o terminie zwrotu. W zakładach z kilkoma wydziałami taki zapis pozwala rozliczać zużycie w podziale na centra kosztów.

Narzędzia pracujące w oleju albo pod wstrząsami tracą etykiety papierowe, a metal zakłóca antenę zwykłego znacznika. Do stali stosuje się tagi zaprojektowane do montażu na metalu, opisane w tekście o tagach RFID na metal. Zasady oznaczania asortymentu zebrano w artykule o narzędziowni i tagach RFID.

Skan pozwala wykryć błąd zamiast go ukrywać. Próba zwrotu egzemplarza, którego nikt nie wydał, kończy się komunikatem, a nie cichym dopisaniem do stanu. Odrzucone operacje warto zapisywać, bo ich liczba pokazuje, gdzie proces wydań odbiega od zapisów w kartotece.

Kolejność wdrożenia i jakość zapisów

Objęcie całego zakładu naraz rzadko się sprawdza. Praktyczniej uruchomić jeden obszar, na przykład narzędziownię, w kilka dni, a potem dołączyć odzież i moduł monitorowania maszyn. Zespół oswaja się wtedy z systemem, zanim ten obejmie kolejne procesy. Typowa kolejność prac wygląda następująco.

• Inwentaryzacja - spis narzędzi, a osobno maszyn oraz zapasów odzieży roboczej, jako punkt wyjścia dla kartoteki.
• Kodowanie i stanowiska - oznaczenie zasobów kodem kreskowym lub RFID oraz konfiguracja stanowisk wydawania.
• Czujniki i progi - podłączenie wybranych maszyn i ustawienie progów alarmowych.
• Szkolenie - nauka obsługi systemu i czytania raportów przez cały zespół.

Kompletność i spójność zapisów

Narzędzia analityczne działają na danych zgromadzonych wcześniej, więc ich przydatność zależy od jakości ewidencji, a nie od samego algorytmu. Jeżeli część wydań rejestrowano zbiorczo, a część imiennie, analiza zużycia według stanowisk nie da wiarygodnego wyniku. Porządkowanie danych historycznych bywa pracochłonne, ale wykonalne. Trudniejsze jest utrzymanie dyscypliny zapisu na każdej zmianie.

Rola człowieka w interpretacji

Wskazanie odchylenia jest początkiem analizy, a nie jej wynikiem. Przyczynę ustala osoba znająca kontekst: zmianę technologii, remont wydziału albo nietypowe zlecenie, których w danych nie widać. Traktowanie wyniku jako rozstrzygnięcia prowadzi do decyzji poprawnych statystycznie i błędnych w konkretnym przypadku.

Pierwszy miesiąc pracy generuje więcej pytań od zespołu niż od samej technologii. Krótkie spotkania po pierwszych tygodniach, na których pracownicy zgłaszają trudności, są tańszym sposobem dopracowania procesu niż poprawki po kilku miesiącach, gdy nawyki już się utrwaliły. Opis platformy dostępny jest także w serwisie produktowym: Studio TCS.net. Diagnostykę maszyn w tym samym podejściu opisuje tekst o sztucznej inteligencji w diagnozowaniu maszyn, a rolę systemu jako całości - strona o roli CMMS.