xvddd

[xvddd]

W tym artykule opowiem trochę o potencjalnych trudnościach przy wyborze systemu zarządzania i monitorowania produkcji (MES). W niektórych pr

[xvddd]

Komunikacja linii produkcyjnej i zarządzania

Opisałem kilka problemów związanych z komunikacją pomiędzy linią produkcyjną a zarządzaniem/infrastrukturą ogólną firmy oraz sposoby ich rozwiązania przy użyciu systemów MES. Przedstawiłem również sytuacje, w których takie systemy nie będą opłacalne.

Artykuł przeznaczony dla kierowników, specjalistów ds. produkcji, inżynierów kontroli jakości oraz wszystkich zainteresowanych kwestiami optymalizacji produkcji.

Weźmy pod uwagę dwie podobne sytuacje: Pracownik zapisuje informacje dotyczące czasu i rodzaju wykonywanej pracy. Wszystko to jest wprowadzane do komputera na koniec zmiany, albo jest osoba odpowiedzialna za wykonanie tego zadania (co wymaga czasu). W rezultacie sami pracownicy rejestrują czas potrzebny na proces. Następnie inny pracownik lub kierownik musi ręcznie wprowadzić te dane do komputera. Problem tego podejścia polega na tym, że nośnik papierowy i długopis mogą zostać zgubione, uszkodzone, pracownik może coś błędnie zapisać lub się pomylić, być może nawet celowo. Osoba wprowadzająca te informacje może się mylić, albo danego pracownika może nie być na miejscu. Ponadto, wprowadzenie danych w takim przypadku nie tylko nie jest terminowe, ale zazwyczaj następuje pod koniec zmiany, co nie pozwala "trzymać ręki na pulsie". Pracownicy zbierający produkt w ogóle nie wprowadzają danych dotyczących czasu, etapów itp., a dostępne są tylko informacje o tym, że części zostały pobrane ze składu i wysłane na linię, informacje o tym, że gotowy produkt trafił na linię pakowania lub został przekazany do magazynu/na następną linię. Nie ma informacji na poziomie makro o każdym stanowisku pracy. Może być dostępna informacja od kontroli jakości, ale zazwyczaj odbywa się to przed pakowaniem, a nie na etapach pośrednich. W obu przypadkach trudno jest od razu zrozumieć, gdzie pojawiły się problemy i gdzie wystąpiło wąskie gardło (na przykład w przypadku części niskiej jakości lub uszkodzenia narzędzi przez pracownika). Kolejnym istotnym punktem jest przekazywanie instrukcji i informacji pracownikom bez konieczności organizowania spotkań, na przykład w przypadku zmian w procesie technologicznym. W przypadku dużych zakładów produkcyjnych często konieczne jest częste szkolenie nowych pracowników, a taka metoda za pomocą systemów MES znacznie skraca czas szkolenia i potrzebę kontrolowania nowych pracowników. Zmiana roli pracowników lub przeniesienie ich z jednej linii produkcyjnej na drugą, gdzie potrzebne jest dodatkowe szkolenie. Myślę, że warto wspomnieć trochę o kontroli jakości. Bardzo trudno jest przeprowadzić pełną kontrolę jakości - jest to drogie zarówno pod względem czasu, jak i pieniędzy. Często wszystko sprowadza się do kontroli gotowego produktu, a nie na każdym etapie produkcji. Kontrola na etapach pośrednich może być wykonywana tylko przez pracownika linii. Oczywiście nie można pominąć "czynnika ludzkiego". Nie mówię tutaj o zaawansowanych zautomatyzowanych systemach kontroli jakości ani o sieciach neuronowych.

Rozwiązanie takich problemów w postaci systemu zarządzania i monitorowania produkcją (MES) może pomóc, chociaż nie zawsze (o tym niżej). Dla pracownika interakcja z tym systemem sprowadzi się do kilku kliknięć na ekranie dotykowym, co jest bardzo szybkie i nie pochłania jego czasu, a wszystkie dane można łatwo zapisać w istniejącej infrastrukturze IT i ERP (o problemach z taką integracją opowiem jeszcze). Ponadto pozwoli to na uzyskanie informacji nie tylko z komputera, ale także z innych urządzeń mających dostęp do wewnętrznej sieci firmy. W rezultacie może to poprawić wydajność linii produkcyjnej i zarządzania do 15-20%, a w niektórych przypadkach nawet więcej.

W jakich sytuacjach taki system NIE jest potrzebny? Przy niewielkim obciążeniu linii, zbyt prostym procesie produkcyjnym, wysokim stopniu zautomatyzowania (w takim przypadku można rozważyć inne opcje), słabej organizacji linii (najpierw trzeba to wyeliminować, a potem patrzeć na sytuację). Na przykład, jaki jest sens wydawania pieniędzy na próby poprawy produkcji, jeśli jest ona nieużywana przez ponad 30% czasu z powodu braku obciążenia roboczego? Nie bierzemy pod uwagę sezonowości produkcji, ponieważ ten czynnik często nie odgrywa roli. W przypadku zbyt prostych procesów produkcyjnych taki system nie przyniesie znaczącego wzrostu wydajności i oszczędności firmie, ponieważ - jakie dane wprowadzić, jeśli będą one jednorodne i przewidywalne? W przypadku zrobotyzowanych systemów i maszyn z wieloma czujnikami sprawa jest bardziej skomplikowana, ponieważ często nie wykluczają one udziału człowieka w procesie produkcji, lub te systemy nie dostarczają informacji, która jest od razu widoczna w ogólnej infrastrukturze.

W tych przypadkach kwestia opłacalności pozostaje otwarta, ponieważ cena takich systemów obejmuje nie tylko sprzęt, ale także kod programowy (w moim przypadku kod programowy jest pisany pod potrzeby klienta).

Jeśli dotarłeś do tego miejsca i interesuje Cię ten temat - proszę o wyrażenie opinii w komentarzach, możliwe jest uzupełnienie, udzielenie wskazówek, podzielenie się doświadczeniem.

[xvddd]

Wspólne koncepcje budowy systemów zarządzania i monitorowania produkcji (MES), których się trzymam.

Prawdopodobnie nie powiem wiele nowego, zwłaszcza dla tych, którzy pracują w tych lub pokrewnych dziedzinach, ale to moje doświadczenie i wnioski. Napisane jest dość krótkie jak na taką tematykę i segmentowane. Nie zagłębiałem się w tematy, a jedynie opisałem je ogólnie i w najbardziej zauważalnych szczegółach. Jeśli coś pominąłem - możesz to zaznaczyć w komentarzach. Tak samo jeśli będzie zainteresowanie jednym z tematów - rozwiniemy go głębiej.

=======================

Na pierwszy rzut oka wszystko wydaje się proste - użyj koncepcji z przemysłowego sprzętu lub zwykłego tworzenia oprogramowania, ale wtedy może to obniżyć elastyczność lub niezawodność. W rezultacie trzeba szukać kompromisu, aby cena i czas pozostały akceptowalne bez utraty funkcjonalności. Nie podoba mi się, że wielu producentów wykonuje interfejsy użytkownika w sposób pozostałościowy. Szczególnie jest to aktualne w przemyśle.

=======================

Zacznę od niezawodności: Niezawodność osiąga się poprzez bezpieczne podejście do rozwoju, testowanie w rzeczywistych warunkach. Czasami trzeba testować w trakcie pracy. To zajmuje czas zarówno mnie, jak i klienta (nie można po prostu zasymulować środowiska roboczego programowo), ale niektóre problemy nie da się inaczej wykryć. Na przykład pracownik znajduje sposób interakcji szybszy niż przewidywał deweloper, ale ten sposób powoduje błąd o zmiennej naturze, który jest bardzo trudny do wykrycia. Tak samo opinia bezpośrednio od użytkowników może bardzo pomóc. Nie należy lekceważyć opinii o pracy bezpośrednio od pracownika linii lub innego kolegi, który jest użytkownikiem - kierownik może po prostu nie wiedzieć o problemie lub pracownik może uznać, że nie jest ważne, aby o tym mówić.

Tutaj również ważne jest bezpieczeństwo samego systemu - nawet proste logowanie hasłem zabezpieczy przed potencjalnym możliwością wprowadzenia chaosu do bazy danych. Najlepiej jest zrobić takie logowanie do systemu za pomocą karty RFID lub kodu kreskowego (to ostatnie często jest preferowane ze względu na łatwość użycia). Ważne jest również rozdzielenie ról użytkowników.

Nie będę poruszać kwestii związanych z cyberbezpieczeństwem i innymi rzeczami. Zazwyczaj wewnętrzne sieci firm są wystarczająco zabezpieczone, ale ważne jest, aby sysadmin dobrze skonfigurował sprzęt.

=======================

Prostota i intuicyjność użytkowania: W tym przypadku najlepiej odwołać się do doświadczenia projektowania UX/UI w przemyśle. W poprzednim poście pisałem o tym, że użytkownik podczas aktywnej lub szybkiej pracy będzie próbować skrócić nawet czas naciśnięcia przycisku lub interakcji z systemem. Dodatkowo trudnością jest fakt, że systemem mogą posługiwać się ludzie, którzy wcześniej korzystali tylko z telefonu, a użytkownik będzie używać go przez całą zmianę pracy (8-12 godzin). W rezultacie idealnym interfejsem będą dwa przyciski - start i stop. Ale w rzeczywistości trzeba komponować i myśleć, pracować z interfejsem na poziomie zwykłego pracownika, a nie tylko przeprowadzić test(UX). W ogólności nie można w pełni ogarnąć tak obszernej tematyki, pomimo chęci. Ponadto materiałów - wideo, książek, wykładów jest bardzo dużo.

=======================

Integracja z innymi systemami i bazami danych. W takim przypadku optymalnym rozwiązaniem jest wykorzystanie standardowego SQL oraz skryptów w języku Python na serwerze, jeśli nie mówimy o usługach internetowych. W przypadku systemów ERP - po prostu korzystaj z ich natywnego interfejsu API lub innych punktów dostępu do pracy z danymi. Integracja z innymi maszynami produkcyjnymi jest już trudniejsza - często posiadają one zamknięte protokoły przesyłania danych bez dokumentacji, brak możliwości fizycznego podłączenia z zewnątrz, lub po prostu jest to zabronione przez producenta.

Jeśli nie ma innych opcji - można zainstalować zewnętrzne sensory, wprowadzając niewielkie modyfikacje do maszyny. Ale zazwyczaj istnieje możliwość połączenia się z istniejącą maszyną za pomocą mikrokontrolera lub jednopłytkowego komputera. Warto dodać, że może to zająć dużo czasu, aby zrozumieć, jak zaimplementować połączenie w kodzie programowym.

=======================

Instrukcje dla użytkowników i administratorów - należy je pisać zrozumiale dla osób, które rzadko korzystają nawet z telefonu. Nie ma tu więcej do dodania.

=======================

Skalowalność. Powszechnym problemem jest kosztowność tworzenia początkowo skalowalnej architektury. O wiele taniej jest zrobić "aby zaczął działać", ale niestety taki podejście może prowadzić do utraty pieniędzy(dużych) przy długoterminowej pracy (pamiętajmy, że tworzymy produkt używany w produkcji - pamiętajmy o tym?). W rezultacie lepiej jest poświęcić czas i pieniądze na sprawdzenie skalowalności i dostosowanie się do potencjału rozwoju produkcji. Cena i czas skalowalności powinny być również przewidywalne.

=======================

Podobny problem dotyczy zmienności architektury i jej aktualizacji. W takiej sytuacji rozsądnym jest zadać sobie pytanie - czy jest to potrzebne, jeśli zamówienie jest jednorazowe, a nie umowa na kilka cykli rozwoju produktu i jego wsparcie?

=======================

Jeśli przeczytałeś tutaj-podziel się w komentarzach swoim poglądem, opinią, być może krytyką(rozsądną i konstruktywną). to dla mnie ważne.

[xvddd]

Blog o tworzeniu systemów monitoringu i zarządzania produkcją (MES)

Po co w ogóle te systemy Przykłady problemów, które mogą rozwiązywać takie systemy

Jakiego sprzętu używam

================================================

Ponieważ to mój pierwszy post, zacznę od opowiedzenia trochę o tych systemach, dlaczego akurat one i jak doszedłem do tego. Takie systemy mają doskonałe zastosowanie w produkcji do optymalizacji, poprawy komunikacji z pracownikami, monitorowania linii produkcyjnych. Obecnie rozważam możliwość integracji systemów magazynowych, ale jak dotąd mam w tym zbyt mało doświadczenia. Dla tych, którzy pracują na dużych zakładach produkcyjnych lub nimi zarządzają - prawdopodobnie takie systemy nie będą niczym nowym, a istnieje prawdopodobieństwo, że już używają najnowocześniejszych spośród nich (proszę o napisanie o tym w komentarzach. Myślę, że będzie to interesujące nie tylko dla mnie).

Dlaczego wybrałem tę ścieżkę zawodową? Początkowo chciałem produkować maszyny produkcyjne, ale do tego potrzebna jest poważna baza materialna i dość duża ekipa. Rozważałem także poszukiwanie inwestycji, ale to nie moja droga. Ostatecznie zdecydowałem się pomagać ludziom w efektywniejszym prowadzeniu procesów produkcyjnych. Być może to jeszcze nieco zbliży technologiczną singularność.

Dlaczego ja nie chcę sprzedawać gotowych rozwiązań, pracując z dużymi firmami? To mnie nie jest interesujące. Lubię tworzyć technologie. Szukać nowych rozwiązań technologicznych. Chcę także uczynić te technologie dostępnymi.

================================================

Przeanalizujmy jeden konkretny, choć niewielki, przykład, który zrealizowałem: Klient skarży się na niską jakość opakowania/braki w kompletacji towaru/możliwe złe stan towaru lub inne podobne problemy. Logicznym rozwiązaniem jest sprawdzenie procesu pakowania i przechowywania towaru. Pierwsze rozwiązanie, które przychodzi do głowy, to zawieszenie kamery monitoringu, ale jest to nieefektywne czasowo (kto będzie przeglądać materiał? a jeśli jest 10-20 punktów pakowania?). Kierownik także nie będzie w stanie kontrolować wszystkiego i wszystkich, a kontrola jakości nie może otwierać opakowań. Bardziej rozsądnym rozwiązaniem tej sytuacji jest stworzenie systemu, który będzie robił zdjęcia z kamery monitoringu (dowolnej dostępnej przez sieć) po naciśnięciu przycisku lub zeskanowaniu kodu kreskowego/znacznika RFID. Wszystkie dane zostaną zapisane na serwerze i łatwo będzie można przeglądać potrzebne informacje, zdjęcia. Może nawet kilka zdjęć z różnych kamer, w zależności od zadań. Oczywiście wprowadzanie danych do systemu ERP, innej bazy danych lub serwera. Taki system można również zastosować na każdym etapie produkcji, ale z pewnymi modyfikacjami. Taki system napisałem w Pythonie i świetnie się sprawdził, chociaż musiałem go testować i przerabiać, ponieważ pierwsza wersja była zbyt niepraktyczna i miała nieczytelny kod. Pod względem sprzętu nie było to drogie - kamery IP, przełączniki PoE, kable, skanery kodów kreskowych (najlepiej sprawdziły się skanery Zebra. Tanie skanery okazały się niskiej jakości), niewielkie monitory dotykowe oraz komputery Thin-client (okazały się tańsze niż Raspbery-Pi). Trudno oszacować czasowo, ponieważ najwięcej czasu zajęło testowanie rozwiązania, które trwało dość długo, ale sama praca nad projektem zajęła mi kilka tygodni.

Myślę, że implementacja w C++ zajęłaby o wiele dłużej, 2-3 razy, ale ponieważ nie było to krytyczne, a komputery sobie poradziły, chociaż z pewną optymalizacją kodu - postanowiono użyć Pythona.

================================================

Jeśli chodzi ogólnie o moją pracę, to pod względem sprzętu skupiam się na zwykłych komputerach, mikrokontrolerach STM32, jednopłytkowych komputerach, różnorodnych urządzeniach peryferyjnych z różnymi protokołami. Obecnie rozważam również możliwość pracy z Androidem (interfejsy internetowe nie zawsze są wygodne i często występują trudności z autonomią i szybkością).

W każdym przypadku przy takim rozszerzaniu technologii konieczne będzie zatrudnienie dodatkowych specjalistów do zespołu.

Jeśli społeczność jest zainteresowana tym, co piszę - proszę zadawać pytania w komentarzach, pisać, które tematy są nadal interesujące, możesz dodać swoje pomysły i sugestie.