Większość Twoich funkcji logistycznych w czasie rzeczywistym nie jest w czasie rzeczywistym

Każda platforma logistyczna sprzedaje czas rzeczywisty. Śledzenie w czasie rzeczywistym. Widoczność w czasie rzeczywistym. Alerty w czasie rzeczywistym. W demo ikona ciężarówki płynnie przesuwa się po mapie, a inżynier w pokoju kiwa głową z aprobatą.

W produkcji ikona ciężarówki aktualizuje się co trzydzieści sekund, a pokazywana pozycja pochodzi sprzed czterdziestu sekund. Rysowana trasa jest interpolowana. Zdarzenie „dostarczone" dociera, w normalny dzień, między dwiema a piętnastoma minutami po faktycznym dostarczeniu. Żadne z tego nie jest złe. Wszystko to jest „w czasie rzeczywistym" w sensie, w jakim branża używa tego słowa. Ale klient myśli, że czas rzeczywisty oznacza to samo co w rozmowie wideo, a przepaść między tymi dwoma definicjami powoduje około połowy eskalacji klientów w tej przestrzeni.

Co kosztuje czas rzeczywisty

Czas rzeczywisty, w ścisłym sensie, kosztuje pieniądze. Konkretnie kosztuje trzy rzeczy, które wszystkie skalują się liniowo z tym, jak rygorystycznie definiujesz termin.

Przepustowość telematyki. Ciężarówka raportująca swoją pozycję GPS raz na sekundę zużywa około sześćdziesięciokrotnie więcej danych niż raportująca co minutę. Pomnożone przez flotę dziesięciu tysięcy pojazdów, przez koszty planów danych, przez martwe strefy komórkowe, gdzie buforowane dane muszą być ostatecznie wysłane seriami przy powrocie zasięgu. Rachunek za przepustowość jest realny, a ROI z interwału pięciodziałowego nad trzydziestosekundowym jest, niemal w każdym przypadku biznesowym, zerowy.

Infrastruktura do obsługi wodospadu danych. Gdy pozycje docierają z rozdzielczością jednej sekundy, każdy downstream system musi obsługiwać taką przepustowość. Przechowywanie. Procesory strumieniowe. Silniki geofencingu. Powiadomienia push do aplikacji kierowców. Każdy z nich ma swój własny profil skalowania i nie wszystkie skalują się liniowo. Interwał aktualizacji jednej sekundy może z łatwością oznaczać dziesięciokrotnie wyższy koszt infrastruktury niż trzydziestosekundowy — przy niemal żadnej poprawie operacyjnej.

Roboczogodziny inżynierów na zawsze. Rygorystyczność staje się właściwością architektury, a architektura staje się właściwością firmy. Każda nowa funkcja musi jej honorować. Każda nowa integracja z vendorem musi jej honorować. Całkowity koszt to nie budowa; to następne pięć lat każdego inżyniera myślącego o latencji, której biznes właściwie nigdy nie potrzebował.

Czego klienci faktycznie potrzebują

Ciekawą rzeczą jest to, że niemal żaden klient logistyczny nie potrzebuje pozycji co sekundę. Potrzebują jednej z trzech konkretnych rzeczy.

Dokładnego ETA. „Kiedy przyjedzie moja ciężarówka?" Dobre odpowiadanie na to potrzebuje odległości trasy, ruchu drogowego, historycznego tempa kierowcy i pozycji wystarczająco świeżej, żeby być punktem startowym. Pozycja sprzed trzydziestu sekund w zupełności wystarczy. Pozycja sprzed jednej sekundy nie daje lepszego ETA.

Zdarzeń geofencingu. „Powiedz mi, kiedy moja ciężarówka wjedzie na teren składu." To wymaga gwarantowanego dostarczenia zdarzeń (trudniejszy problem), nie szybszego pollingu. Poprawne zdarzenie docierające czterdzieści sekund późnej jest cenniejsze niż strumień, który mógł lub nie mógł go uchwycić.

Alertowania o wyjątkach. „Powiedz mi, kiedy coś idzie nie tak." Późny wyjazd, zboczenie z trasy, nieoczekiwany postój. To są wykrycia wzorców w oknie czasowym. Nie potrzebują czasu rzeczywistego — potrzebują poprawności.

We wszystkich trzech przypadkach architektura, która wygrywa, jest event-driven z relatywnie grubym pollingiem pod spodem, a nie strumieniowaniem wysokiej częstotliwości. Wyjątkiem jest prawdziwe mapowanie na żywo — klient dosłownie oglądający ciężarówkę poruszającą się na ekranie w czasie rzeczywistym, dla celów rozrywkowych lub nadzorczych. Ten przypadek użycia istnieje i jest jeden lub dwa ekrany w biznesie, nie cała platforma.

Co faktycznie zrobić

Wzorzec, który działa, według naszych doświadczeń:

Zdefiniuj kontrakt świeżości danych na funkcję. ETA: pozycja nie może być starsza niż dziewięćdziesiąt sekund. Zdarzenia geofencingu: muszą być gwarantowanie dostarczone w ciągu pięciu minut od wystąpienia. Mapa na żywo: najlepszy wysiłek trzydzieści sekund, bez SLA. Zapisz to. Pokaż klientom. Klienci uznają to za uspokajające, nie rozczarowujące — zależy im na tym, że parzyli się przez niejasne obietnice „czasu rzeczywistego" i doceniają szczerość.

Buduj szkielet zdarzeń najpierw, potem polling. Geofence-entered, route-deviated, delivery-completed. To są zdarzenia, na których działa biznes. Buduj je jako trwałe, uporządkowane, exactly-once zdarzenia. Następnie nakładaj polling pozycji na górze, przy dowolnej częstotliwości, jakiej wymaga kontrakt świeżości.

Projektuj dla złej sieci. Kierowcy jeżdżą przez tunele. Magazyny są w stalowych budynkach. Modem ciężarówki się restartuje. Telefon wyczerpuje baterię. System logistyczny, który udaje, że łączność jest niezawodna, to system, który produkuje niepoprawne dane w większości dni. Buforuj lokalnie, uzgadniaj po ponownym połączeniu, projektuj każde zdarzenie tak, żeby było replayable.

Uczciwy pitch

Zbudowaliśmy dużo tego. Wersja, która jest dostarczana i pozostaje dostarczona, niemal nigdy nie jest tą z najbardziej agresywnymi liczbami czasu rzeczywistego. Jest to ta, w której kontrakt między systemem a klientem jest uczciwy co do tego, co „czas rzeczywisty" oznacza, a architektura jest zoptymalizowana pod rzeczy, których biznes faktycznie potrzebuje — dokładne ETA, gwarantowane zdarzenia i odporność na sieć, która od czasu do czasu próbuje zepsuć Twój dzień.