500 milionów kilometrów i zero błędów w projekcie pełnym wyzwań

To był jeden z najciekawszych, ale też najtrudniejszych projektów, w jakich miałem okazję uczestniczyć, powiedział nam Artur. I z pewnością ma z czym porównywać, ponieważ jest związany z MakoLab od dwunastu lat, a jak sam mówi, przez ten czas nie miał ani chwili na nudę.
W skład zespołu projektowego wchodziło kilku programistów, dwóch testerów, kierownik projektu oraz Scrum Master. Artur opisał ich podejście do zarządzania pracą:
Musieliśmy być wyjątkowo zorganizowani, ponieważ po wstępnym etapie planowania, mimo że część projektu miała być realizowana w siedzibie klienta, w rzeczywistości musieliśmy pracować nad nim zdalnie. Przez kilka miesięcy niezbędne były codzienne spotkania online oraz wspólne, zdalne testowanie. A każdy sprint kończył się prezentacją demo.

Operator wymagał, aby dane docierały na serwer w ciągu czterdziestu sekund od momentu ich zebrania przez aplikację. Jednocześnie założeniem było, aby klient miał możliwość pełnej konfiguracji aplikacji, czyli zmiany takich parametrów jak częstotliwość wysyłania danych, rozmiar pakietów czy rodzaj danych, żeby wymienić tylko kilka z nich. Przy tym wszystkim nie mogło dochodzić do żadnej interakcji z użytkownikiem. Aplikacja miała działać w stu procentach automatycznie – sama się włączać i wyłączać, zbierać dane, naprawiać błędy, a dodatkowo sprawdzać jakość połączenia internetowego oraz ilość wykorzystywanej pamięci.
Artur podzielił się z nami dodatkowymi szczegółami:
Musieliśmy mieć pewność, że nasza aplikacja w żaden sposób nie wpłynie na działanie innych systemów pojazdu, takich jak system nawigacji czy kamera cofania, nie mówiąc już o systemach kluczowych dla bezpieczeństwa kierowcy i pasażerów. To był jeden z najważniejszych warunków tego projektu.
Oznaczało to, że zespół musiał już od samego początku określić potencjalne zużycie zasobów. Artur przybliżył nam, co się z tym wiązało:
Na każdym etapie projektu analizowaliśmy zużycie procesora i pamięci przez aplikację. Jeśli pojawiały się jakiekolwiek problemy, od razu wprowadzaliśmy niezbędne poprawki.
Tak więc już na etapie przygotowawczym aplikacja działała w czasie rzeczywistym, odczytując, ile wolnej pamięci ma urządzenie w danym momencie, analizując jakość połączenia internetowego i na tej podstawie przygotowując odpowiednio dopasowane pod względem wielkości pakiety danych do wysyłki.
Artur rozwinął ten wątek na potrzeby „Insights”:
Architektura naszego rozwiązania pomogła nam zapewnić, że wszystko działało tak, jak powinno. Podzieliśmy aplikację na niezależne moduły odpowiedzialne za zbieranie danych, przygotowywanie ich do wysyłki, wysyłanie, analizę pamięci i jakości połączenia internetowego, konfigurację i tak dalej. Gdy pojawiał się problem, łatwo było sprawdzić, w którym module wystąpił błąd.

Możliwości testowania aplikacji były niezwykle ograniczone, ponieważ pandemia uniemożliwiła zespołowi MakoLab podróż do siedziby klienta. Artur podzielił się z nami wspomnieniami związanymi z tym konkretnym wyzwaniem:
W biurze mieliśmy tylko jeden bench [urządzenie do testowania aplikacji do multimediów pokładowych – przyp. red.]. Niestety nie oddawało to w pełni realiów środowiska produkcyjnego. Zdarzało się więc na przykład, że ktoś z zespołu klienta nagrywał działanie aplikacji w samochodzie i siedział z laptopem na kolanach, podczas gdy ja przeglądałem logi. I to wcale nie był rzadki widok!
Kolejne wyzwanie wynikało z faktu, że w trakcie działania aplikacji dzieje się bardzo wiele rzeczy. Przede wszystkim gromadzona jest ogromna ilość danych. Niektóre zdarzenia pojawiają się w systemie pięćdziesiąt razy na sekundę, a łącznie obsługiwanych jest czterdzieści typów zdarzeń. Ponadto nie zawsze możliwe jest wysłanie danych z aplikacji na serwer, dlatego informacje muszą być gromadzone i wysyłane dopiero wtedy, gdy pojawi się połączenie internetowe. Jeśli jakość połączenia jest słaba, w pierwszej kolejności wysyłane muszą być mniejsze pakiety danych, zgodnie z ustaleniami klienta.

Ostatecznie chodziło o to, by aplikacja przesyłała dane w sposób ciągły przez cały czas trwania podróży, jednocześnie anonimizując punkt początkowy i końcowy. Jak się jednak okazało, zespół MakoLab napotkał na nieoczekiwaną przeszkodę.
Oddajemy głos Arturowi!
Tą przeszkodą był powszechnie stosowany w pojazdach system Start&Stop. Na początkowym etapie projektu każde wyłączenie silnika było przez aplikację traktowane jako zakończenie podróży. W efekcie, szczególnie w warunkach miejskich, zamiast jednej podróży rejestrowano na przykład dziesięć – w zależności od tego, ile razy samochód zatrzymał się, choćby na światłach, z wyłączonym dzięki Start&Stop silnikiem. Musieliśmy więc się zastanowić, jak odróżnić rzeczywisty początek i koniec podróży od chwilowych postojów.
Nie trzeba dodawać, że zespół znalazł sposób na rozwiązanie tego problemu!
Zmodyfikowaliśmy aplikację tak, aby wyświetlane były wszystkie informacje związane z systemem Start&Stop, a następnie poprosiliśmy zespół klienta o zainstalowanie jej w kilku pojazdach i odbycie paru podróży. Mimo że wyniki nie były powtarzalne i różniły się w zależności od pojazdu, udało nam się stworzyć elastyczne rozwiązanie, które następnie wdrożyliśmy w aplikacji produkcyjnej.
To wyjaśnienie pochodzi oczywiście od Artura!
Nasza aplikacja przeszła niezwykle szczegółowe testy ze strony klienta. Najpierw trafiła do product ownera. Stamtąd przekazano ją do działu bezpieczeństwa oraz zespołu, który sprawdził jej stabilność, wpływ na system i inne aplikacje oraz, rzecz jasna, wykorzystanie procesora i pamięci. Na koniec przyszła kolej na dział RODO, który zbadał jej zgodność z Ogólnym Rozporządzeniem o Ochronie Danych Osobowych.
Artur podsumowuje to następująco: Przeszliśmy przez to wszystko bez żadnych krytycznych poprawek.
Tak trzymać!

Z Arturem Ptasińskim rozmawiała Marta Piotrowska