Integrator dla flot w pracy spedytora - reakcja na opóźnienia

Integrator dla flot w pracy spedytora - co zmienia w dyspozycji

Integrator dla flot jest warstwą pośrednią między lokalizatorami GPS a ekranem spedytora. Każdy dostawca telematyki ma własny panel, własny format pozycji i własne nazwy zdarzeń. Integrator odbiera te dane, sprowadza je do wspólnego modelu i pokazuje w jednym miejscu, więc spedytor nie przełącza się między aplikacjami producentów lokalizatorów.

Praca dyspozytora sprowadza się do jednego pytania: czy zlecenie zdąży w okno dostawy. Odpowiedź wymaga dwóch danych: pozycji pojazdu i planu trasy. Lokalizator zna pierwszą, system spedycyjny drugą, a integrator dostarcza pierwszą tam, gdzie da się ją zestawić z drugą.

Ten tekst opisuje skutek tego połączenia dla spedytora: jak wykrywa się opóźnienie i co dzieje się potem. Sam produkt przedstawia artykuł o Linkway.INTEGRATOR i kontroli danych GPS, a zastosowania w pracy z flotą omawia tekst o integratorze GPS dla flot.

Reguła: alert o opóźnieniu wymaga dwóch źródeł naraz, pozycji z lokalizatora i okna dostawy ze zlecenia.

Dzień dyspozytora bez wspólnej mapy

Bez integratora spedytor obsługuje floty kilku dostawców GPS w osobnych kartach przeglądarki. Pojazdy własne widzi w jednym panelu, pojazdy podwykonawców w drugim, a część przewoźników w ogóle nie udostępnia pozycji i odpowiada dopiero na telefon. Każde sprawdzenie jednego zlecenia oznacza kilka logowań i ręczne porównanie godziny z oknem dostawy.

Koszt takiego trybu nie leży w pojedynczym spóźnionym transporcie, lecz w przerwach między decyzjami. Spedytor prowadzący równocześnie kilkadziesiąt zleceń przegląda je cyklicznie, a nie wtedy, gdy zmienia się sytuacja. Opóźnienie, które powstało tuż po ostatnim przeglądzie, wychodzi na jaw dopiero przy następnym.

Jedna mapa dla floty własnej i podwykonawców

Wspólna mapa wymaga wspólnego modelu danych. Pozycja z lokalizatora jednego dostawcy przychodzi jako współrzędne z prędkością w km/h, u innego jako obiekt z prędkością w węzłach, a czas raz w UTC, raz w czasie lokalnym z przesunięciem. Integrator zamienia te warianty na jeden rekord, zanim pozycja trafi na ekran.

Rekord pozycji po ujednoliceniu

Ujednolicony rekord zawiera tylko to, co potrzebne do dalszych obliczeń. Każde pole ma określoną jednostkę i znaczenie, bo różnice między dostawcami wychodzą dopiero wtedy, gdy dwa pojazdy jadą obok siebie, a jeden na mapie wyprzedza drugi o kilkaset metrów.

• Czas fiksacji - moment odczytu z odbiornika GPS zapisany w UTC, a nie czas dotarcia komunikatu do serwera.
• Identyfikator źródła - kod urządzenia albo pojazdu nadany przez dostawcę telematyki, podstawa mapowania.
• Współrzędne - szerokość i długość geograficzna w jednym układzie odniesienia (WGS 84).
• Prędkość w km/h - wartość przeliczona przy wczytaniu, a nie dopiero przy wyświetlaniu.

Identyfikacja pojazdu i mapowanie

Każde źródło identyfikuje pojazd po swojemu: numerem urządzenia, numerem rejestracyjnym albo wewnętrznym kodem floty. Integrator potrzebuje tabeli mapowania, która przypisuje te identyfikatory do jednego pojazdu w systemie spedycyjnym. Gdy lokalizator zostaje wymieniony w serwisie, zmienia się wpis w mapowaniu, a historia pozycji pozostaje przypisana do właściwego pojazdu.

Pojazdy podwykonawców

Pozycję pojazdu podwykonawcy można pokazać tylko wtedy, gdy jego system telematyczny udostępnia dane, a umowa to przewiduje. Widoczność ogranicza się zwykle do czasu trwania zlecenia, bo po jego zamknięciu spedytor nie ma powodu obserwować cudzego pojazdu. Zakres udostępnienia warto zapisać w umowie z przewoźnikiem, także ze względu na dane osobowe kierowców.

Od pozycji GPS do alertu o opóźnieniu

Opóźnienie nie jest zdarzeniem z lokalizatora. Urządzenie nie wie, że pojazd ma stanąć przy rampie o czternastej. System porównuje przewidywany czas przyjazdu z końcem okna dostawy i dopiero ta różnica staje się sygnałem. Przewidywany czas przyjazdu to pozostały dystans podzielony przez realną średnią prędkość, powiększony o obowiązkowe przerwy kierowcy. Sposób liczenia tej prognozy opisuje artykuł o ETA od Linkway.

public static bool CzyZagrozone(DateTime etaUtc, DateTime koniecOknaUtc, TimeSpan margines)
{
    // alert wyprzedzający: ETA wchodzi w margines przed końcem okna
    return etaUtc > koniecOknaUtc - margines;
}

Margines chroni przed alertami wynikającymi z błędu prognozy. Spedytor woli dostać ostrzeżenie na czterdzieści minut przed końcem okna niż w chwili jego przekroczenia, bo tylko pierwsze daje czas na decyzję. Wielkość marginesu zależy od długości trasy i od tego, jak łatwo przestawić okno u danego odbiorcy.

Średnia prędkość z ostatnich pozycji

Średnią prędkość do prognozy liczy się z okna ostatnich kilkunastu minut, a nie z pojedynczej pozycji. Jedna pozycja z postoju na światłach zaniżyłaby prędkość, a jedna z autostrady zawyżyłaby ją, więc okno wygładza oba przypadki. Zbyt długie okno reaguje za to zbyt wolno na zator, który dopiero się utworzył. Długość okna jest kompromisem, który sprawdza się na historii przejazdów z danej relacji.

Próg alertu i histereza

Prognoza ETA zmienia się o kilka minut po każdej nowej pozycji. Alert, który pojawia się i znika przy każdym odświeżeniu, jest gorszy niż jego brak, bo uczy dyspozytora ignorowania komunikatów. Stosuje się więc histerezę: alert włącza się po przekroczeniu jednego progu, a wygasa dopiero po powrocie poniżej niższego.

Reakcja na opóźnienie - kolejność działań spedytora

Alert uruchamia procedurę, a nie kończy sprawy. Spedytor najpierw ustala przyczynę: zator, awarię, długi rozładunek u poprzedniego odbiorcy albo przerwę wynikającą z czasu pracy kierowcy. Od przyczyny zależy działanie, bo awaria wymaga pojazdu zastępczego, a zator tylko informacji dla odbiorcy.

Nowy termin zgłasza się odbiorcy z realną prognozą, a nie z najlepszym scenariuszem. Odbiorca, który rezerwuje rampy w systemie awizacji, przestawia wtedy okno zamiast czekać z pustym stanowiskiem. Sposób rezerwacji okien opisuje artykuł o awizacjach w Studio VSS.net, a przykład ETA liczonego z pozycji GPS zawiera tekst o systemie VSS.net z przepustką QR.

Komunikat do odbiorcy

Komunikat o opóźnieniu zawiera nową godzinę przyjazdu i krótką informację o przyczynie. Pierwsza pozwala odbiorcy przestawić rampę, druga ocenić, czy prognoza jest wiarygodna. Wiadomość wysyła się raz po przekroczeniu progu i ponownie dopiero wtedy, gdy prognoza zmieni się o ustaloną wartość, bo seria kolejnych godzin co kilka minut kończy się zignorowaniem powiadomień. Odbiorca bez systemu awizacji dostaje tę samą treść e-mailem lub SMS-em, a spedytor zapisuje w zleceniu czas wysłania, co ułatwia późniejsze rozmowy o odpowiedzialności za opóźnienie.

Reguła: po każdym alercie w zleceniu zostaje zapisana przyczyna opóźnienia, bo bez niej nie da się później policzyć, które opóźnienia się powtarzają.

Integracje z Auto-GPS i Cargotrack w Linkway.INTEGRATOR

Linkway.INTEGRATOR obsługuje wiele źródeł telematycznych, a dwa z nich producent opisuje na osobnych stronach: Auto-GPS oraz Cargotrack Solution SRL. W obu przypadkach dane telemetryczne z pojazdów trafiają do jednego centralnego systemu, więc spedytor nie potrzebuje osobnej aplikacji dla każdej marki lokalizatorów. Zakres informacji obejmuje lokalizację ciężarówek oraz parametry ich pracy, na przykład czas pracy kierowców i zużycie paliwa. Osobno zapisywany jest stan techniczny pojazdu.

Szczegóły każdej integracji podaje producent na stronach integracji z Auto-GPS oraz integracji z Cargotrack Solution SRL. Dane synchronizują się w czasie zbliżonym do rzeczywistego, ale rzeczywiste opóźnienie zależy od dostawcy lokalizatorów: jedni wysyłają pozycję co kilkanaście sekund, inni co kilka minut. Częstotliwość raportowania wyznacza dolną granicę czasu reakcji spedytora.

Ogólny opis integratora znajduje się na stronie linkway.INTEGRATOR u producenta. Źródła danych o czasie pracy kierowców omawia artykuł o programie do logistyki transportu z tachografem, a pozycje z lokalizatorów Hertz Systems opisuje tekst o integracji Hertz GPS z Linkway.

Historia przejazdów i powtarzalne opóźnienia

Integrator przechowuje historię przejazdów, więc opóźnienia da się analizować zbiorczo. Pojedyncze zdarzenie tłumaczy się pechem, ale opóźnienie powtarzające się na tej samej relacji albo u tego samego odbiorcy wskazuje błąd planowania: zbyt krótki czas przejazdu albo źle dobrane okno. Raport z takiej analizy pokazuje spedytorowi, które zlecenia trzeba planować z większym zapasem.

-- przykładowa tabela dostaw, nazwy poglądowe (nie schemat produktu)
SELECT Relacja,
       COUNT(*) AS LiczbaZlecen,
       SUM(CASE WHEN OpoznienieMin > 0 THEN 1 ELSE 0 END) AS LiczbaOpoznien,
       AVG(CASE WHEN OpoznienieMin > 0 THEN OpoznienieMin END) AS SrednieOpoznienieMin
FROM dbo.Dostawa
WHERE DataDostawy >= DATEADD(month, -3, CAST(GETDATE() AS date))
GROUP BY Relacja
HAVING COUNT(*) >= 20
ORDER BY LiczbaOpoznien DESC;

Zapytanie grupuje dostawy według relacji i pomija relacje z małą próbką, bo średnia z trzech kursów niczego nie dowodzi. Zasady grupowania oraz klauzulę HAVING opisuje dokumentacja GROUP BY w Transact-SQL. Ocenę opłacalności takich analiz przedstawia artykuł o integratorze dla flot i kryteriach zwrotu.

Przyczyny opóźnień jako słownik

Zestawienie ma sens tylko wtedy, gdy przy każdym opóźnieniu zapisano przyczynę z krótkiej listy. Pole tekstu wolnego psuje analizę, bo ta sama przyczyna trafia do raportu pod pięcioma różnymi opisami.

• Zator lub roboty drogowe - przyczyna zewnętrzna, na którą przewoźnik nie ma wpływu.
• Awaria pojazdu - przyczyna techniczna, powiązana z serwisem i historią pojazdu.
• Rozładunek u poprzedniego odbiorcy - opóźnienie przenoszące się na kolejne punkty trasy.
• Błąd planu - zbyt krótki czas przejazdu albo źle dobrane okno dostawy.

Utrzymanie integracji i kontrola źródeł danych

Integracja działa, dopóki działają źródła. Wygasła karta SIM w lokalizatorze albo zmiana adresu API po stronie dostawcy kończą się tym samym objawem: pozycja przestaje się odświeżać. Pojazd stoi na mapie w miejscu ostatniej pozycji, więc spedytor widzi spokojną sytuację, gdy w rzeczywistości brakuje danych.

Integracja potrzebuje więc własnego monitoringu: znacznika czasu ostatniej pozycji dla każdego źródła i progu, po którego przekroczeniu system zgłasza awarię źródła, a nie pojazdu. Osobny alert kieruje sprawę do administratora integracji, a nie do dyspozytora.

SELECT s.SourceId, s.Name, MAX(p.FixTimeUtc) AS LastFixUtc
FROM dbo.GpsSource AS s
LEFT JOIN dbo.GpsPosition AS p ON p.SourceId = s.SourceId
GROUP BY s.SourceId, s.Name
HAVING MAX(p.FixTimeUtc) IS NULL
    OR MAX(p.FixTimeUtc) < DATEADD(minute, -15, SYSUTCDATETIME());

Testy przed uruchomieniem

Przed przełączeniem floty na integrator porównuje się kilkanaście pozycji z panelem dostawcy: współrzędne oraz czas muszą się zgadzać, a prędkość może różnić się co najwyżej o zaokrąglenie. Osobno sprawdza się scenariusz braku zasięgu, w którym lokalizator gromadzi pozycje w buforze i wysyła je po odzyskaniu łączności. Pozycje z bufora nie mogą nadpisać nowszych ani wywołać alertu o opóźnieniu, którego już nie ma.

Odbiór po stronie spedycji zamyka wdrożenie. Dyspozytorzy przechodzą kilka zleceń testowych: wywołują alert i wpisują przyczynę, a potem zamykają zlecenie. Dopiero wtedy wiadomo, czy procedura z tabeli powyżej działa w praktyce, a nie tylko na papierze. Aplikację dla kierowcy, która dostarcza drugie źródło statusów, przedstawia artykuł o linkway.TRACKER. Kontrolę czasu pracy kierowcy w tej samej flocie opisuje tekst o monitoringu pojazdów w spedycji.