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.
