Monitoring pojazdów w spedycji - telematyka i alerty

Monitoring pojazdów w spedycji - zakres i podział danych

Monitoring pojazdów w spedycji polega na ciągłym porównywaniu tego, co dzieje się z pojazdem, z tym, co zaplanowano w zleceniu. Sam odczyt pozycji niczego nie rozstrzyga. Znaczenie ma dopiero różnica: pojazd stoi tam, gdzie nie powinien, albo od godziny nie przysyła pozycji.

Firma spedycyjna ma przy tym inną sytuację niż przewoźnik, ponieważ część pojazdów należy do podwykonawców, więc zakres danych zależy od ich systemów i umów. Ten artykuł zajmuje się warstwą pomiarową i regułami alertów. Łączenie wielu źródeł w jednym widoku opisuje tekst o integratorze GPS dla flot, a rozliczenie kosztów floty w zleceniach - artykuł o systemie TMS a koszty floty.

Reguła: monitoring nie wykrywa problemów, tylko odchylenia od planu, więc bez planu w systemie nie ma czego alarmować.

Źródła danych w pojeździe - lokalizator i magistrala CAN

Pozycja z odbiornika GPS

Lokalizator zapisuje pozycję w stałym interwale albo po zdarzeniu, na przykład po włączeniu zapłonu lub po zmianie kierunku o zadany kąt. Krótszy interwał daje dokładniejszy ślad trasy, ale zwiększa ruch w sieci komórkowej i liczbę wierszy w bazie. Dla spedycji zwykle wystarcza interwał, przy którym ślad na mapie oddaje przebieg trasy, a nie każdy zakręt.

Gdy pojazd traci zasięg, urządzenie gromadzi pozycje w pamięci i przesyła je po odzyskaniu łączności. Mają one wtedy czas fiksacji z przeszłości, więc system musi wstawić je na właściwe miejsce w historii, a nie traktować jako bieżące. Alert o bezruchu policzony z pozycji z bufora byłby fałszywy.

Dane z magistrali CAN

Magistrala CAN przenosi dane z komputera pokładowego pojazdu: obroty silnika i stan licznika, a w części pojazdów także poziom paliwa oraz kody usterek. Lokalizator podłącza się do niej bezpośrednio albo, w innych rozwiązaniach, korzysta z osobnych sond paliwa. Zakres dostępnych parametrów zależy od marki i modelu ciągnika, więc przed zakupem lokalizatorów sprawdza się listę obsługiwanych pojazdów.

-- ostatnia pozycja każdego urządzenia (tabela poglądowa, nie schemat produktu)
SELECT DeviceId, FixTimeUtc, Lat, Lon
FROM (
    SELECT DeviceId, FixTimeUtc, Lat, Lon,
           ROW_NUMBER() OVER (PARTITION BY DeviceId ORDER BY FixTimeUtc DESC) AS rn
    FROM dbo.GpsPosition
) AS x
WHERE rn = 1;

Zapytanie z funkcją okna zwraca po jednym wierszu na urządzenie, a jego składnię opisuje dokumentacja ROW_NUMBER w Transact-SQL. Przy dużej tabeli pozycji zapytanie przyspiesza indeks klastrowy (DeviceId, FixTimeUtc), a mechanizm od lokalizatora do ekranu opisuje artykuł o integracji Hertz GPS z Linkway.

Reguły alertów i progi

Alert jest regułą, a nie zdarzeniem. System sprawdza warunek na każdej nowej pozycji, a po jego spełnieniu tworzy wpis przypisany do osoby, która ma zareagować. Ta sama pozycja może więc nie wywołać niczego w jednym zleceniu i uruchomić alarm w innym, jeśli inny jest plan.

public sealed record Position(int DeviceId, DateTime FixUtc, double SpeedKmh, bool Ignition);

// ostatnie: pozycje jednego urządzenia z ostatnich minut, od najstarszej do najnowszej
public static bool CzyNieplanowanyPostoj(IReadOnlyList<Position> ostatnie, TimeSpan prog, bool wStrefie)
{
    if (wStrefie || ostatnie.Count == 0) return false;
    bool stoi = ostatnie.All(p => p.SpeedKmh < 1 && !p.Ignition);
    return stoi && ostatnie[^1].FixUtc - ostatnie[0].FixUtc >= prog;
}

Warunek wymaga kilku pozycji, a nie jednej, bo pojedynczy odczyt z zerową prędkością występuje przy każdym czerwonym świetle. Próg czasu dobiera się do rodzaju trasy: dwudziestominutowy postój na trasie międzynarodowej może być przerwą kierowcy, a w mieście przy dostawie do sklepu oznacza problem. Próg zapisuje się więc przy typie zlecenia, a nie jako jedną wartość dla całej floty.

Reguła: każdy alert ma zdefiniowany warunek oraz właściciela, który odpowiada za reakcję.

Progi zależne od typu zlecenia

Ten sam pojazd wymaga różnych progów w zależności od zlecenia. Przy transporcie z wieloma punktami rozładunku postój w każdym z nich jest planowany, a przy przejeździe bez postojów każdy postój jest odchyleniem. Progi przypisuje się więc do typu zlecenia albo do klienta, a nie do pojazdu. System podpowiada wartość domyślną, a dyspozytor może ją zmienić dla konkretnego zlecenia, pod warunkiem że zmiana zostaje w historii razem z autorem i czasem. Bez takiego śladu po kilku miesiącach nikt nie wyjaśni, dlaczego alert nie zadziałał.

Geostrefy - załadunek i rozładunek

Geostrefa zamienia współrzędne na zdarzenie zrozumiałe dla procesu, takie jak wjazd na teren klienta. W monitoringu spedycyjnym strefy mają dwa zastosowania: wyznaczają miejsca, w których postój jest oczekiwany, oraz miejsca, w których jest podejrzany. Ten sam parking bywa jednym i drugim, zależnie od zlecenia.

Strefę opisuje okrąg o zadanym promieniu albo wielokąt. Okrąg jest prostszy w obliczeniach, wielokąt dokładniejszy, bo lepiej oddaje kształt placu i nie obejmuje sąsiedniej drogi dojazdowej. W SQL Server odległość punktu od środka okręgu zwraca metoda STDistance typu geography, która podaje wynik w metrach.

DECLARE @centrum geography = geography::Point(52.4030, 16.9250, 4326);
DECLARE @pozycja geography = geography::Point(52.4041, 16.9268, 4326);

SELECT CASE WHEN @pozycja.STDistance(@centrum) <= 150 THEN 1 ELSE 0 END AS WStrefie;  -- promień 150 m

Opis typów przestrzennych zawiera dokumentacja danych przestrzennych w SQL Server. Odbiornik GPS ma błąd rzędu kilku metrów, więc wjazd potwierdza się po kilku kolejnych pozycjach wewnątrz strefy. Bez tego pojazd stojący przy granicy generowałby wjazdy i wyjazdy co kilkanaście sekund.

Czas pracy kierowcy i odczyt tachografu

Pozycja pojazdu nie mówi nic o tym, czy kierowca może jechać dalej. Tę informację zapisuje tachograf cyfrowy: czas prowadzenia oraz odpoczynki kierowcy. Producent oprogramowania Linkway opisuje w tym obszarze integrację z TachoByte, która ułatwia automatyczne pobieranie danych z tachografów oraz zdalne sczytywanie kart kierowców i pamięci masowej urządzenia. Dzięki temu firma nie musi czekać, aż kierowca zjedzie do bazy z kartą.

Wartości podano poglądowo. Wyjątki i pełne zasady określa unijne rozporządzenie o czasie prowadzenia pojazdów, więc przed wpisaniem progów do systemu konfigurację warto potwierdzić z osobą odpowiedzialną za przepisy transportowe w firmie. Odczyt tachografu uzupełnia też mechanizm planowania: spedytor, który zna pozostały czas jazdy, nie przydzieli kierowcy trasy niemożliwej do wykonania w limicie. Dodatkowe informacje o odczycie z tachografu zawiera artykuł o programie do logistyki transportu.

Zalew alertów - deduplikacja i eskalacja

Najczęstszy błąd konfiguracji monitoringu to zbyt wiele alertów. Dyspozytor, który dostaje kilkadziesiąt komunikatów na godzinę, po tygodniu przestaje je czytać, a wtedy prawdziwy problem ginie w szumie. Alerty deduplikuje się więc według prostej zasady: dopóki alert danego typu dla danego pojazdu jest otwarty, kolejne wystąpienie tego samego warunku nie tworzy nowego wpisu.

CREATE UNIQUE INDEX UX_Alert_Open
    ON dbo.Alert (VehicleId, AlertType)
    WHERE Status = 'open';

Filtrowany indeks unikalny pilnuje, by istniał najwyżej jeden otwarty alert danego typu dla pojazdu, a zamknięte wpisy z historii mu nie przeszkadzają. Składnię i ograniczenia opisuje dokumentacja indeksów filtrowanych. Próba wstawienia duplikatu kończy się błędem, który aplikacja traktuje jako sygnał, że alert już istnieje.

Eskalacja nie zastępuje dyspozytora, tylko zabezpiecza sytuację, w której alert nie ma odbiorcy. Czas do eskalacji ustala się osobno dla każdego typu alertu, bo brak pozycji przez kwadrans wymaga innej reakcji niż zjazd z trasy w pobliżu granicy.

Historia przejazdu jako materiał dowodowy

Zapis przejazdu służy nie tylko do bieżącej kontroli. Gdy odbiorca reklamuje opóźnienie albo twierdzi, że pojazd nie dotarł w umówionym oknie, ślad trasy z czasami wjazdu i wyjazdu ze stref staje się materiałem do rozmowy. Ten sam ślad rozstrzyga spory o czas rozładunku: jeśli pojazd stał na terenie odbiorcy dwie godziny, a rozładunek miał trwać trzydzieści minut, odpowiedzialność nie leży po stronie kierowcy.

Zapis ma wartość dowodową tylko wtedy, gdy jest spójny. Pozycje mają czas w UTC, zdarzenia stref są potwierdzone kilkoma pozycjami, a nie jednym odczytem, i wiadomo, jaka wersja reguł obowiązywała w dniu przejazdu. Zmiana promienia strefy po fakcie nie może przepisywać historii, więc zdarzenia zapisuje się w chwili wykrycia, a nie wylicza ponownie z aktualnej konfiguracji.

• Czas wjazdu i wyjazdu - potwierdzone kilkoma pozycjami, w UTC, z przeliczeniem na czas lokalny przy wyświetlaniu.
• Identyfikator i wersja strefy - pozwalają odtworzyć, jaki obszar obowiązywał w dniu przejazdu.
• Liczba pozycji potwierdzających - pokazuje, jak pewne jest zdarzenie przy słabym sygnale GPS.
• Zlecenie powiązane ze zdarzeniem - łączy dane z pojazdu z dokumentami transportowymi.

Zestawianie przebiegu z GPS z kosztami omawia artykuł o monitoringu transportu a kosztach floty, a wykorzystanie czasu przyjazdu przy rezerwacji ramp - tekst o systemie VSS.net z przepustką QR i ETA z GPS.

Dane lokalizacyjne kierowców i retencja

Pozycja pojazdu przypisanego do konkretnego kierowcy jest daną osobową, więc monitoring podlega przepisom o ochronie danych. W praktyce oznacza to dwa pytania do rozstrzygnięcia przed uruchomieniem: po co dane są zbierane i jak długo się je przechowuje. Trzeci temat, czyli kontrola dostępu, jest opisany niżej. Kierowcy powinni wiedzieć, że pojazd jest monitorowany, a zakres tej wiedzy wynika z regulaminu pracy i umów z podwykonawcami.

Techniczne konsekwencje są proste. Dostęp do historii przejazdów przydziela się według ról, a nie wszystkim użytkownikom systemu. Surowe pozycje przechowuje się przez ustalony okres, a dłuższą historię trzyma w postaci zagregowanych zdarzeń, takich jak wjazdy do stref i postoje. Zakres i okres przechowywania warto uzgodnić z prawnikiem albo inspektorem ochrony danych, bo zależą od celu, dla którego dane zbiera konkretna firma.

Wdrożenie monitoringu i pomiar skuteczności alertów

Monitoring uruchamia się zwykle na kilku pojazdach, na których sprawdza się reguły i progi, a dopiero potem rozszerza na całą flotę. Pilotaż pokazuje, które alerty są potrzebne, a które tylko męczą dyspozytorów. Aplikację dla kierowcy jako drugie źródło statusów opisuje artykuł o linkway.TRACKER, a producent przedstawia ją także na stronie linkway.TRACKER.

Skuteczność monitoringu mierzy się na alertach, a nie na liczbie pojazdów na mapie. Cztery wskaźniki wystarczają do oceny, czy reguły działają.

• Czas potwierdzenia alertu - od utworzenia wpisu do chwili, gdy dyspozytor przejmuje sprawę.
• Odsetek fałszywych alertów - alerty zamknięte bez działania, wskazujące zbyt czuły próg.
• Alerty na pojazd na dobę - miara szumu; rosnąca wartość zapowiada ignorowanie komunikatów.
• Odsetek alertów z zapisaną przyczyną - podstawa do analizy powtarzalnych problemów.

Wyniki porównuje się co kilka tygodni i koryguje progi. Więcej o alertach związanych z oknami dostaw pisze artykuł o monitoringu transportu i oknach dostaw, a o ETA liczonym z pozycji - tekst o ETA od Linkway. Podział odpowiedzialności w firmie spedycyjnej przedstawia opis oprogramowania spedycyjnego.