Światła, do których nie było instrukcji

Jak powstał svietlik, czyli aplikacja zamieniająca światła BMW w pokaz, i czemu kod był w tym wszystkim najłatwiejszy.

Z dziennika projektu, czerwiec 2026

Pomysł był prosty. Samochód sam mruga kierunkowskazem, zapala światła dzienne, płynnie ściemnia diody w reflektorach. Skoro tak, to gdzieś w jego elektronice musi być sposób, żeby te same wyjścia odpalić na żądanie. Chcieliśmy, żeby zaparkowane na zlocie BMW umiało odegrać krótką, zsynchronizowaną choreografię świateł, zamiast po prostu stać i ładnie wyglądać. Tyle teorii. Praktyka zajęła dużo dłużej, niż ktokolwiek z nas zakładał na starcie.

To nie jest kodowanie

Od razu, bo to pytanie wraca za każdym razem: svietlik niczego nie koduje. Nie zmienia żadnych ustawień zapisanych na stałe w sterownikach i nie zostawia śladów, które mogłyby zaważyć na gwarancji. Przejmuje na chwilę konkretne wyjścia świetlne, odgrywa na nich sekwencję zapaleń i ściemnień, po czym oddaje sterowanie. Każdy efekt jest z definicji tymczasowy. Po jego zakończeniu światła wracają dokładnie do stanu sprzed uruchomienia, bo właścicielem świateł przez cały czas pozostaje auto, nie aplikacja.

Co było wiadomo, a czego nie

To, że światłami da się sterować przez diagnostykę, krąży po forach od lat. Tylko że nikt nie opisał, jak to konkretnie zrobić na F-serii. Publicznie dostępna była droga do samochodu: jak telefon łączy się z adapterem w gnieździe OBD i jakim językiem auto rozmawia z diagnostyką. Brakowało tego, co na końcu tej drogi, czyli konkretnych adresów i poleceń. Bez nich nawet idealnie zestawione połączenie milczy.

Diagnostyka mówi, jak zadać pytanie. Nie mówi, o co zapytać konkretny moduł BMW, żeby zapaliła się akurat ta lampa, o którą chodzi. Tej części układanki nie było w żadnym poradniku i na żadnym forum.

Punktem wyjścia były fabryczne opisy sterowników. Rozkładaliśmy je w spokoju, bez auta, wyłuskując nazwy funkcji, tabele lamp i listy argumentów. Problem w tym, że taki opis daje hipotezę, nie pewność. Wiadomo z niego, że istnieje funkcja sterująca światłami. Nie wiadomo, jak dokładnie złożyć polecenie, żeby sterownik je przyjął. Każdą hipotezę trzeba było zawieźć do prawdziwego samochodu, a sterownik na błędne polecenie odpowiada krótko i bez litości.

Najlepiej pamiętam wygaszanie. Tryb, który roboczo nazwaliśmy Ghost, czyli pełne wyciemnienie auta, opiera się na jedynej funkcji, która potrafi nie tylko zapalić lampę, ale i trzymać ją zgaszoną. Polecenie rozpisane zza biurka wyglądało sensownie dokładnie do momentu, w którym auto odbiło je z błędem. Okazało się, że moduł wymaga jednego dodatkowego bajtu, którego w opisie nie widać wprost. Dołożyliśmy go i sterownik wreszcie potwierdził. Ta lekcja wracała potem wielokrotnie: wszystko potwierdza się na żywym aucie albo wcale.

Najciekawsza zagadka czekała z tyłu. Pierwsze pełne wygaszenie zwracało potwierdzenie, a gasiło tylko podświetlenie wnętrza. Tylne lampy paliły się dalej, jakby nigdy nic. Dopiero przy aucie złożyło się to w całość: moduł odpowiedzialny za przód steruje tylko swoimi lokalnymi wyjściami, a tył wisi na zupełnie innym sterowniku, który na dokładkę rozmawia trochę inaczej. Napisaliśmy więc prober, który po kolei odpytywał kolejne moduły i próbował zgasić lewy stop, aż w logu pojawił się adres, przy którym lampa faktycznie zgasła.

Bezpiecznik w samej zasadzie działania

Im więcej dało się zgasić, tym poważniej trzeba było podejść do bezpieczeństwa. Akurat tutaj diagnostyka gra na naszą korzyść: wymuszone sterowanie żyje tylko tak długo, jak połączenie. Aplikacja przestaje wysyłać sygnał podtrzymujący i po kilku sekundach auto samo odbiera sobie kontrolę, przywracając światła do normy. Utrata Wi-Fi, zamknięcie aplikacji, rozładowany telefon: każdy z tych scenariuszy kończy efekt automatycznie. Zanim mapa wyjść została potwierdzona, silnik chodził zresztą w trybie suchym i tylko wypisywał komendy do logu, żebyśmy przypadkiem nie zrobili na aucie czegoś, czego nie rozumieliśmy do końca.

Jedno trzeba powiedzieć wprost: gaszenie świateł stopu czy całego tyłu na drodze publicznej jest nielegalne i niebezpieczne. Te tryby powstały na zaparkowane auto na pokazie, nie na jazdę.

Co dalej

Dziś svietlik robi już sporo: proste mrugnięcia, sekwencyjne kierunkowskazy, animacje diod w reflektorach, tryby wygaszania. Wszystko z telefonu, bez kabla, bez laptopa i bez trwałej ingerencji w samochód. Od początku jest też zbudowany tak, żeby uczył się nowych aut. Po podpięciu modelu, którego jeszcze nie zna, skanuje moduły, sprawdza, co odpowiada, i zbiera log, z którego domapowujemy kolejną generację.

To, jak rozmawiać z samochodem, było opisane od dawna. Co dokładnie mu powiedzieć, musieliśmy ustalić sami.

Dla technicznych

Łańcuch komunikacji: telefon łączy się po Wi-Fi z adapterem ENET/OBD, a ten rozmawia z autem po Ethernecie. Nowsze BMW używają DoIP (ISO 13400), starsze F-serie protokołu HSFZ. Warstwą wyżej jest UDS (ISO 14229): sesja rozszerzona, ReadDataByIdentifier, InputOutputControlByIdentifier (0x2F) do wymuszania wyjść oraz TesterPresent jako podtrzymanie sesji. Transport i model usług da się odtworzyć z norm ISO i projektów typu EdiabasLib.

Mapowanie wyjść robiliśmy z plików SGBD, czyli fabrycznych opisów sterowników, których EDIABAS używa do tłumaczenia poleceń na ramki. SGBD zdradza nazwy funkcji i tabele lamp, ale nie rozstrzyga układu bajtów: czy numer lampy zajmuje jeden bajt czy dwa, czy pole czasu jest obowiązkowe i w jakiej jednostce. Przykład z praktyki: ramka 0x2F na DID 4501 wracała z NRC 0x13 (incorrect message length), dopóki nie dołożyliśmy standardowego bajtu controlOption. Działająca postać to 2F 4501 03 <element> <stan>. Tylne lampy obsługuje osobny sterownik, używający innej usługi diagnostycznej niż przedni, więc mapowanie trzeba było powtórzyć od zera proberem iterującym po adresach modułów.