Większość projektów informatycznych w magazynie i zakładzie produkcyjnym rozstrzyga się nie w serwerowni, tylko na hali: przy terminalu oraz przy skanerze i drukarce etykiet. Aplikacja może być poprawna, a system mimo to nie działa, jeśli odczyt kodu nie dociera do bazy albo etykieta wychodzi nieczytelna. Strona opisuje, czego wymaga od firmy informatycznej integracja z urządzeniami i jak wygląda ta praca po stronie oprogramowania. Przykłady dotyczą mechanizmów ogólnych, a nie konfiguracji konkretnego wdrożenia.

Poznań firma informatyczna a warstwa urządzeń na hali

SoftwareStudio, firma informatyczna z Poznania, według własnego opisu specjalizuje się w integracji rozwiązań teleinformatycznych dla klientów biznesowych. Jej systemy Studio WMS.net, VSS.net, RMA.net, TCS.net i PWS.net pracują w magazynach, na placach przeładunkowych i w narzędziowniach, więc dane do nich dopływają z urządzeń na hali, na przykład z kolektorów i skanerów. Dla dostawcy oznacza to obowiązek znajomości bazy danych oraz sposobu, w jaki dane od urządzenia trafiają do aplikacji.

Każde urządzenie ma własny kierunek przepływu danych oraz własne łącze i sposób awarii. Zestawienie poniżej porządkuje te cechy. To one decydują, co dostawca musi obsłużyć w kodzie, zanim system uzna się za gotowy do pracy zmianowej.

UrządzenieKierunek danychTypowe łączeTypowa awaria
Terminal lub kolektor AndroidZadania do terminala, skany do bazyWi-Fi i HTTPSUtrata zasięgu w alejce, przerwana sesja
Skaner ręcznyZ urządzenia do aplikacjiKabel USB albo BluetoothNieczytelny kod, zła symbolika
Drukarka etykietZ aplikacji do urządzeniaEthernet, USBBrak materiału, otwarta głowica
Czytnik RFIDZ tagu do aplikacjiEthernet albo interfejs w terminaluWielokrotny odczyt tego samego znacznika

Reguła: aplikacja zakłada, że urządzenie zawiedzie, więc każdy skan i każdy wydruk ma numer, dzięki któremu powtórzenie nie zdubluje operacji.

Ta strona jest uzupełnieniem opisu wymagań, jakie stawia się dostawcom oprogramowania dla logistyki, dostępnego w tekście o firmach informatycznych z Poznania dla logistyki, oraz kryteriów oceny dostawcy z tekstu o tym, jak sprawdzić firmę informatyczną z Poznania. Ogólny obraz sprzętu i oprogramowania magazynowego przedstawia strona o systemie magazynowym jako dwóch warstwach pracy.

Terminale Android i sieć Wi-Fi

Terminal magazynowy pracuje przez całą zmianę w ruchu, więc jakość łączności decyduje o tempie hali. Każdy skan lokalizacji lub palety jest zapytaniem do serwera, które musi wrócić z odpowiedzią, zanim operator wykona następny ruch. Regały wysokiego składowania i towar z dużą zawartością metalu osłabiają sygnał, dlatego pokrycie sieci weryfikuje się pomiarem w terenie, a nie na planie hali. Szczegóły dotyczące roamingu oraz pasm i szyfrowania sesji opisuje strona o terminalu radiowym w magazynie oraz sieci Wi-Fi i TLS.

Dłoń trzymająca terminal z ekranem dotykowym i klawiaturą na tle regałów magazynowych
Terminal w ręku operatora: przez to urządzenie do bazy trafia każdy skan lokalizacji i palety.

Dla programisty najważniejsza jest odporność na przerwy. Skan wysłany tuż przed utratą zasięgu może dotrzeć do serwera, choć terminal nie dostał potwierdzenia, więc po wznowieniu połączenia wyśle go ponownie. Serwer rozpoznaje powtórkę po identyfikatorze skanu nadanym przez terminal w chwili odczytu. Poniższy fragment C# pokazuje ten mechanizm; repozytorium i typ skanu są poglądowe.

public sealed record Skan(Guid IdSkanu, string Kod, string Urzadzenie, DateTime CzasUtc);

public enum WynikSkanu { Zapisany, Powtorka }

public WynikSkanu PrzyjmijSkan(Skan skan)
{
    if (_repozytorium.SkanIstnieje(skan.IdSkanu)) return WynikSkanu.Powtorka;
    _repozytorium.Zapisz(skan);
    return WynikSkanu.Zapisany;
}

Odpowiedź na powtórkę jest taka sama jak na pierwszy skan: terminal dostaje potwierdzenie i usuwa zdarzenie z lokalnej kolejki. Zarządzanie flotą urządzeń, czyli rejestrację urządzeń oraz konfigurację i aktualizacje aplikacji przez system MDM, opisuje strona o programie magazynowym na Androida i flocie MDM. Dobór samego sprzętu, w tym szczelności obudowy i baterii, omawia strona o kolektorze danych Android WMS. Dokumentacja platformy opisuje urządzenia przeznaczone do jednego zadania w artykule Google o urządzeniach dedykowanych w Androidzie.

Rejestr urządzeń w bazie danych ułatwia diagnostykę, bo pokazuje, który terminal przestał się zgłaszać. Zapytanie z przykładu wypisuje terminale, które od piętnastu minut nie zsynchronizowały się z serwerem.

SELECT Kod, OperatorId, OstatniaSynchronizacja
FROM dbo.Urzadzenie
WHERE Typ = 'terminal'
  AND OstatniaSynchronizacja < DATEADD(minute, -15, SYSUTCDATETIME());

Certyfikaty i aktualizacje floty terminali

Połączenie terminala z serwerem po HTTPS opiera się na certyfikacie, który ma datę ważności. W dniu, w którym certyfikat wygasa, wszystkie terminale przestają się łączyć jednocześnie, bo każdy z nich odrzuca serwer. Awaria jest przewidywalna co do dnia, a mimo to zdarza się często, ponieważ termin odnowienia zapisany był w kalendarzu osoby, która odeszła. Nadzór nad datami ważności należy więc do zakresu usługi utrzymania i wymaga własnego alarmu.

Kontrolę można zautomatyzować w kilku liniach. Polecenie PowerShell z przykładu wypisuje certyfikaty komputera, których ważność upływa w ciągu trzydziestu dni; wynik trafia do zadania harmonogramu, które wysyła powiadomienie do administratora.

Get-ChildItem Cert:\LocalMachine\My |
    Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) } |
    Select-Object Subject, NotAfter

Drugą sprawą są aktualizacje aplikacji na terminalach. Nowa wersja trafia najpierw do niewielkiej grupy urządzeń, na przykład jednej zmiany w jednej strefie, i dopiero po potwierdzeniu poprawnej pracy do całej floty. Aktualizacje planuje się poza szczytem, bo pobieranie pakietów przez kilkadziesiąt terminali jednocześnie obciąża sieć Wi-Fi. Kontrakt komunikacji z serwerem musi pozostać zgodny wstecz, żeby terminal ze starszą wersją mógł zakończyć zmianę.

Reguła: serwer obsługuje jednocześnie bieżącą i poprzednią wersję aplikacji terminalowej, dopóki wszystkie urządzenia nie zostaną zaktualizowane.

Skanery i weryfikacja odczytu kodu

Skaner przekazuje aplikacji ciąg znaków, a aplikacja decyduje, co z nim zrobić. Odczyt nigdy nie jest z założenia poprawny: kod może być uszkodzony, zeskanowany z niewłaściwej etykiety albo pochodzić z innej symboliki, niż oczekuje ekran. Sprawdzenie w kodzie jest tanie, a pozwala zatrzymać błąd przy źródle, zanim trafi do bazy. Podstawową kontrolą jest cyfra kontrolna identyfikatora.

Sposób przekazania odczytu do aplikacji też wymaga decyzji. Skaner może emulować klawiaturę, czyli wpisywać odczytany kod w aktywne pole, zwykle z klawiszem Enter na końcu. Rozwiązanie jest proste, ale wrażliwe na to, które pole ma akurat fokus: skan wpisany w niewłaściwe okno trafia do niewłaściwego miejsca. Drugi sposób to odbieranie odczytu przez interfejs programistyczny producenta urządzenia, dzięki któremu aplikacja dostaje kod razem z informacją o symbolice i nie zależy od fokusu. W aplikacji magazynowej stosuje się zwykle ten drugi wariant, a pierwszy zostaje dla stanowisk biurowych.

Identyfikator GS1Postać na etykiecieKontrola po odczycie
SSCC (AI 00)18 cyfr jednostki logistycznejCyfra kontrolna metodą modulo 10
GTIN (AI 01)14 cyfr identyfikatora towaruTa sama metoda modulo 10
Partia (AI 10)Ciąg znaków o zmiennej długościZgodność z partią w dokumencie przyjęcia
Termin ważności (AI 17)Data w formacie RRMMDDPoprawność daty i zgodność z kartoteką

Metoda modulo 10 mnoży kolejne cyfry przez 3 i 1 naprzemiennie, licząc od cyfry sąsiadującej z kontrolną, a wynik uzupełnia do pełnej dziesiątki. Funkcja poniżej sprawdza numer SSCC; wymaga przestrzeni nazw System.Linq.

static bool SsccPoprawny(string sscc)
{
    if (sscc.Length != 18 || !sscc.All(char.IsDigit)) return false;

    int suma = 0;
    for (int i = 0; i < 17; i++)
    {
        int cyfra = sscc[i] - '0';
        suma += (i % 2 == 0) ? cyfra * 3 : cyfra;
    }
    int kontrolna = (10 - suma % 10) % 10;
    return kontrolna == sscc[17] - '0';
}

Budowę etykiety logistycznej i miejsca poszczególnych identyfikatorów opisuje strona o etykiecie logistycznej GS1, a wprowadzenie do standardów publikuje GS1 Polska. Wybór urządzenia do odczytu i typowe procesy operatora opisano w tekście o terminalu radiowym w procesach WMS.

Drukarki etykiet i język ZPL

Drukarka przemysłowa nie przyjmuje pliku z edytora, tylko strumień poleceń. W urządzeniach Zebra jest nim język ZPL II, a aplikacja składa polecenia z danych operacji i wysyła je przez sieć na port 9100 albo przez USB. Parametry sprzętowe mają wpływ na dane: rozdzielczość głowicy 203, 300 lub 600 dpi wyznacza najmniejszą kreskę kodu, a ilość pamięci Flash decyduje, czy w drukarce mieści się szablon razem z grafiką. Model Zebra ZM400 ma według opisu 8 MB pamięci Flash, opcjonalnie 64 MB.

Drukarka etykiet z wysuwającą się wstęgą etykiet z kodami kreskowymi na tle hali magazynowej
Drukarka etykiet w magazynie: wydruk jest ostatnim etapem obiegu danych, od którego zależy czytelność kodu dla skanera.

Drukarka zawodzi częściej niż serwer: kończy się materiał, głowica się otwiera, sieć ma przerwę. Dlatego aplikacja nie wysyła zadania bezpośrednio z okna użytkownika, tylko zapisuje je w kolejce i odbiera osobnym procesem, który ponawia próby. Szczegóły tego wzorca oraz szablon ZPL i przykład wysyłki po TCP opisuje strona o drukarce kodów kreskowych i jej integracji z WMS. Do nadzoru wystarczy zapytanie o zadania, które utknęły w kolejce; przykład dotyczy tabeli poglądowej z tamtego opisu, w której status 0 oznacza zadanie nowe, a status 2 błąd.

SELECT PrinterCode, COUNT(*) AS Zadania, MAX(Attempts) AS MaksProb
FROM dbo.PrintJob
WHERE Status IN (0, 2)
GROUP BY PrinterCode;

Rosnąca liczba zadań dla jednej drukarki jest sygnałem, że magazynier czeka na etykiety. Powiadomienie wysyłane do administratora skraca czas reakcji, zanim ktoś na hali zgłosi problem.

Starsze terminale i migracja z Windows CE

W wielu magazynach pracują jeszcze kolektory z systemem Windows CE lub Windows Mobile. Producent przestał je wspierać, więc naprawa sprzętu i aktualizacje bezpieczeństwa stały się problemem, a nowe aplikacje powstają dla Androida. Dostawca oprogramowania musi umieć obsłużyć oba światy w okresie przejściowym. Aplikacje mobilne Studio WMS.net dla Windows CE i Windows Mobile opisuje strona o aplikacjach dla Windows CE i systemów mobilnych.

Przenoszenie na Androida to więcej niż zmiana urządzenia. Zmienia się klawiatura fizyczna na ekran dotykowy, a sesję dawniej utrzymywaną na stałe zastępuje komunikacja po HTTPS, odporniejsza na przerwy. Przebieg migracji, okres pracy równoległej i szkolenie opisuje strona o migracji terminali z Windows CE na Android. Praktycznie oznacza to jedną bazę danych obsługiwaną jednocześnie przez dwie wersje aplikacji mobilnej, więc kontrakt komunikacji z serwerem musi pozostać zgodny w obie strony do końca okresu przejściowego.

Zakład produkcyjny - tagi RFID i dane z maszyn

W zakładzie produkcyjnym urządzeń jest więcej, a ich dane mają inny charakter. Narzędzia i wyposażenie oznacza się znacznikami RFID, dzięki czemu wypożyczenie i zwrot rejestruje odczyt, a nie ręczny wpis. System klasy CMMS, do której należy Studio TCS.net, powiązuje takie zdarzenia z osobą i terminem legalizacji. Odczyt tagów opisuje strona o tagach RFID w narzędziowni. Czytnik potrafi odczytać ten sam znacznik wiele razy w ciągu sekundy, więc aplikacja odfiltrowuje powtórzenia w krótkim oknie czasu.

Dane z maszyn, na przykład temperatury lub liczników cykli, napływają w dużej liczbie i mają zwykle prostą strukturę: identyfikator maszyny oraz czas i wartość odczytu. Zapytanie o ostatni odczyt maszyny jest wtedy częste, więc tabelę wspiera indeks pokrywający po identyfikatorze maszyny i czasie. Składnię indeksów opisuje dokumentacja CREATE INDEX w Microsoft Learn.

CREATE INDEX IX_Odczyt_Maszyna_Czas
ON dbo.Odczyt (IdMaszyny, CzasUtc DESC)
INCLUDE (Wartosc);

Reguła: dane z urządzeń zapisuje się ze znacznikiem czasu z urządzenia i z czasu serwera, bo zegary urządzeń się rozjeżdżają, a kolejność zdarzeń trzeba umieć odtworzyć.

Odbiór integracji z urządzeniami

Odbiór integracji z urządzeniami sprawdza scenariusze awaryjne, a nie tylko ścieżkę bez błędów. Test na czystej hali z kompletem sprzętu potwierdza jedynie, że kod działa w idealnych warunkach. Zamawiający i dostawca ustalają listę scenariuszy przed wdrożeniem, a wykonanie każdego z nich zapisują w protokole.

ScenariuszOczekiwany wynik
Skan z poprawnym kodem SSCCRuch zapisany, terminal pokazuje następne zadanie
Skan z błędną cyfrą kontrolnąOdrzucenie z komunikatem, brak zapisu w bazie
Utrata Wi-Fi w środku operacjiZdarzenia w kolejce terminala, po powrocie zasięgu zapisane raz
Wyłączona drukarkaZadanie w kolejce, powiadomienie, wydruk po włączeniu
Wymiana terminala w trakcie zmianyNowe urządzenie przejmuje profil bez ręcznej konfiguracji

Ostatni scenariusz wymaga MDM, o którym była mowa w części o terminalach, oraz rejestru urządzeń w bazie. Zebrane wyniki odbioru stają się podstawą umowy serwisowej: wiadomo, które zdarzenia system obsługuje samodzielnie, a które wymagają interwencji. Informacje o terminalach radiowych i ich dostępnych konfiguracjach SoftwareStudio zbiera na stronie terminali radiowych.