w

Złe decyzje i wadliwe oprogramowanie Ubera jest odpowiedzialne za śmiertelny wypadek z 2018 roku

Radar w autonomicznym samochodzie firmy Uber wykrył pieszą Elaine Herzberg na ponad pięć sekund przed śmiertelnym uderzeniem. To najnowsze informacje z raportu National Safety Transportation Board. Niestety, szereg złych decyzji dotyczących projektowania oprogramowania uniemożliwiło podjęcie jakichkolwiek działań aż do 0,2 sekundy przed śmiertelnym uderzeniem mającym miejsce w Tempe, w Arizonie.

Śmierć Pani Herzberg miała miejsce w marcu 2018 r., a NTSB opublikowało swój wstępny raport w sprawie z maja zeszłego roku. W raporcie wyraźnie zaznaczono, że źle napisane oprogramowanie było odpowiedzialne za śmiertelny wypadek.

Nowy raport oznacza koniec 20-miesięcznego dochodzenia NTSB. Zawiera znacznie więcej szczegółów na temat działania oprogramowania Ubera oraz tego, co poszło (a właściwie wszystko) nie tak w ostatnich sekundach przed wypadkiem, w wyniku której zginęła Herzberg.

Przebieg błędnej klasyfikacji

Podobnie jak większość oprogramowania do autonomicznej jazdy, oprogramowanie Ubera próbuje sklasyfikować każdy wykryty obiekt w jednej z kilku kategorii: samochód, rower lub „inny”. Następnie, na podstawie tej klasyfikacji, oprogramowanie oblicza prędkość i prawdopodobną trajektorię obiektu. Ten system zawiódł katastrofalnie w Tempe.

Raport NTSB zawiera chronologiczny opis wydarzeń, sekundę po sekundzie, który pokazuje, jak oprogramowanie „myślało”, gdy zbliżało się do Herzberg, która prowadziła rower po wielopasmowej drodze z dala od przejścia dla pieszych:

  • 5,2 sekundy przed uderzeniem system sklasyfikował ją jako „inny” obiekt.
  • 4,2 sekundy przed zderzeniem została sklasyfikowana jako pojazd.
  • Pomiędzy 3,8 a 2,7 sekundy przed uderzeniem klasyfikacja zmieniała się kilkakrotnie między „pojazdem” a „innym obiektem”.
  • 2,6 sekundy przed uderzeniem system sklasyfikował Herzberg i jej rower jako rower.
  • 1,5 sekundy przed uderzeniem stała się „nieznana”.
  • 1,2 sekundy przed uderzeniem znów stała się „rowerem”.

W tej sekwencji zdarzeń warto zwrócić uwagę na dwie rzeczy. Po pierwsze, w żadnym momencie system nie zaklasyfikował jej jako pieszej. NTSB twierdzi, że „system nie uwzględniał pieszych poruszających się nieprzepisowo”.

Po drugie, ciągle zmieniające się klasyfikacje uniemożliwiały oprogramowaniu Uber dokładne obliczenie jej trajektorii i uświadomienia sobie, że jest na kursie kolizyjnym z pojazdem. Można założyć, że jeśli układ autonomiczny zobaczy obiekt wkraczający na drogę pojazdu, to zacznie hamować, nawet jeśli nie będzie pewien, co to za przedmiot. Ale nie tak działało oprogramowanie Ubera.

System powinien wykorzystać wcześniej zaobserwowane lokalizacje obiektu, aby pomóc obliczyć jego prędkość i przewidzieć przyszłą ścieżkę poruszania się. Jednak „jeśli system zmieniał klasyfikację wykrytego obiektu, historia śledzenia tego obiektu nie była już uwzględniana przy generowaniu nowych trajektorii”, jak informuje NTSB.

W praktyce oznaczało to, że w momencie, gdy system nie był w stanie stwierdzić, jakim obiektem była Herzberg i jej rower, zachowywał się, jakby się nie poruszała.

Na 5,2 do 4,2 sekundy przed wypadkiem system sklasyfikował Herzberg jako pojazd i zdecydował, że jest „statyczna” – co oznacza, że się nie porusza – i dlatego nie będzie prawdopodobnie wkraczać na ścieżkę samochodu. Nieco później system rozpoznał, że się porusza, ale przewidział, że pozostanie na obecnym pasie.

Kiedy system przeklasyfikował ją jako rower na 2,6 sekundy przed uderzeniem, system ponownie przewidział, że pozostanie na swojej linii – błąd, który jest znacznie łatwiejszy do popełnienia, jeśli nie bierzesz poprzednich danych na temat lokalizacji. Na 1,5 sekundy przed uderzeniem stała się „nieznanym” przedmiotem i znowu została sklasyfikowana jako „statyczna”.

Dopiero na 1,2 sekundy przed wypadkiem, gdy zaczynała wkraczać na pas, po którym poruszał się SUV, system zdał sobie sprawę, że wypadek jest nieuchronny.

„Wstrzymanie działań”

W tym momencie prawdopodobnie było już za późno, aby uniknąć kolizji, ale ostre hamowanie mogło spowolnić pojazd na tyle, aby uratować życie Pani Herzberg. Tak się nie stało. NTSB wyjaśnia, dlaczego:

„Gdy system wykryje sytuację awaryjną, inicjuje wstrzymanie działań. Jest to jednosekundowy okres, w którym [zautomatyzowany układ kierowniczy] wstrzymuje planowane hamowanie, podczas gdy system weryfikuje charakter wykrytego zagrożenia i oblicza alternatywną drogę, w przeciwnym razie kierowca pojazdu przejmuje kontrolę nad pojazdem. ”

NTSB twierdzi, że firma „wdrożyła proces wstrzymywania działań z obawy na fałszywe alarmy, powodujące, że samochód niepotrzebnie angażuje się w ekstremalne manewry”.

W rezultacie pojazd zaczął hamować dopiero na 0,2 sekundy przed śmiertelnym uderzeniem – zdecydowanie za późno, by uratować życie Herzberg.

NTBS twierdzi, że nawet po tym jednosekundowym opóźnieniu system niekoniecznie uruchamia hamulce z pełną siłą. Jeśli można uniknąć kolizji podczas gwałtownego hamowania, układ hamuje mocno, aż do ustalonego maksymalnego poziomu. Jeśli jednak awaria jest nieunikniona, system ma mniejszą siłę hamowania, inicjująca „stopniowe spowolnienie pojazdu”, angażując jednocześnie kierowcę o konieczności przejęcia kontroli.

Reportaż Julie Bort z Business Insider z 2018 roku zasugerował możliwy powód tych zagadkowych decyzji projektowych: zespół przygotowywał się do wypróbowania wersji demonstracyjnej niedawno zatrudnionego CEO Ubera, Dary Khosrowshahi. Inżynierów poproszono o zmniejszenie liczby „złych doświadczeń” odczuwalnych przez pasażerów. Niedługo potem Uber ogłosił, że „wyłącza zdolność samochodu do samodzielnego podejmowania decyzji awaryjnych, takich jak ostre hamowanie, czy gwałtowne skręcanie”.

Ostre skręcanie zostało ostatecznie ponownie włączone, ale ograniczenia dotyczące gwałtownego hamowania obowiązywały aż do śmiertelnego potrącenia w marcu 2018 r.

Autonomicznym samochodem Ubera jest Volvo XC90, które ma własny, bardzo wyrafinowany układ hamowania awaryjnego. Niestety, przed awarią w 2018 roku, Uber wyłączał system zapobiegania kolizjom Volvo, gdy oprogramowanie Ubera było aktywne. NTSB stwierdziło, że jednym z powodów tego jest fakt, że eksperymentalny radar Ubera używał tych samych częstotliwości, co radar Volvo, stwarzając ryzyko zakłóceń.

Od czasu awarii Uber przeprojektował swój radar, aby działał na innych częstotliwościach niż radar Volvo, pozwalając systemowi hamowania awaryjnego Volvo pozostać włączonym, gdy Uber testuje swoją własną technologię autonomicznej jazdy.

Uber twierdzi również, że przeprojektował inne aspekty swojego oprogramowania. „Wstrzymanie akcji” nie jest już obecne w oprogramowaniu i nie poprzedza hamowania w sytuacjach awaryjnych. Oprogramowanie nie odrzuca już przeszłych danych lokalizacji, gdy zmienia się klasyfikacja obiektu.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Jak utworzyć własny obraz odświeżenia systemu Windows 8?

Jak automatycznie naprawić Windows 8?