W tym artykule branżowym Mark Forbes of Altium bada problemy, rozwiązania i standardy bezpieczeństwa dotyczące autonomicznych pojazdów.

Ponieważ jesteśmy na progu stawania się bardziej “pasażerami” niż “kierowcami” w naszych pojazdach, kwestia “jak bezpieczna jest ta” rzecz “, która mnie napędza?” Zaczyna dokuczać neuronom. Wszyscy rozumiemy intelektualnie, że w większości przypadków automatyzacja może prawdopodobnie podjąć właściwą decyzję szybciej niż (potencjalnie rozproszony) ludzki kierowca. Ale co, jeśli się nie uda?

Czy sprzęt, który jest projektowany i produkowany jako “inteligentny” pojazd autonomiczny zaprojektowany przede wszystkim dla bezpieczeństwa? Sprzęt musi nie tylko być niezawodny, ale także wykrywać usterki i podejmować działania naprawcze (lub awaryjne). Sprzęt musi również zapewniać, że pamięć chroniona, wykorzystywana do celów o kluczowym znaczeniu dla bezpieczeństwa, nigdy nie zostanie dotknięta przez nieautoryzowanych użytkowników.

Czy deweloperzy oprogramowania wbudowanego poświęcają wystarczająco dużo uwagi kwestiom bezpieczeństwa? Jestem pewien, że przytłaczająca większość czyni to priorytetem. Istnieją jednak pewne standardy, które mogą pomóc programistom zapewnić, że ich kod jest nie tylko bezpieczny, ale również bezpieczny po kompilacji i po uruchomieniu na docelowym sprzęcie.

Niektóre pojazdy były autonomiczne przez lata

Ze względu na prasę otaczającą samochody, które wkrótce będą realizowane autonomicznie, wiele osób uważa, że ​​jest to pierwszy pojazd samozasilający się. W rzeczywistości istnieją już od jakiegoś czasu, nie tylko w środowiskach konsumenckich.

John Deere rozpoczął prace fundamentalne dla ciągników samojezdnych w latach 90-tych, a do roku 2000 ciągniki samoksięgłe wykonywały samodzielnie. Teraz ciągniki są zdolne do pełnej autonomicznej pracy, w tym do orki i zbioru, a także do wykonywania nawrotów. Inne pojazdy autonomiczne w powszechnym użyciu to “produkty do zbierania” używane przez wielu sprzedawców internetowych i hurtowników. Na przykład Amazon działał na początku 2017 roku ponad 45 000 takich robotów.

Twój następny samochód?

Pomimo dziesięcioleci pracy robotów i ciągników, Twój następny samochód prawdopodobnie nie będzie samozasilający. Istnieje lista rzeczy do prania, które mają bardzo różne problemy niż wspomniane wcześniej pojazdy autonomiczne, ale na szczycie listy znajduje się jeden prosty fakt – magazyny, dom i gospodarstwa są prywatnymi, kontrolowanymi środowiskami dostępowymi, podczas gdy podróże samochodem pociągają za sobą kompletnie inny zestaw problemów do rozwiązania:

Ruch drogowy: Najczęściej napotykany jest ruch, który nie dotyczy traktorów i robotów. Samochody muszą najpierw wykryć, a następnie określić, co zrobić w odpowiedzi na wykryte informacje.
Zakłócenia sygnału: w dużym świecie obiekty takie jak budynki i drzewa mogą zakłócać sygnały z czujników i powodować nieoczekiwane rezultaty.
Hakowanie: Bezpieczna komunikacja internetowa jest niezbędna w przypadku autonomicznych samochodów do zastosowań takich, jak aktualizacje oprogramowania bezprzewodowego. Hakowanie może potencjalnie być śmiertelne.
Nieoczekiwane doświadczenie: być może najbardziej nikczemnym problemem jest decyzja, którą należy podjąć, gdy pojawi się nowe, nieoczekiwane doświadczenie. W ciągniku lub robocie może się po prostu zatrzymać, ale w samochodzie może nie być najbezpieczniej.

Wszystkie te istniejące problemy należy rozwiązać z jednego powodu: ludzie jeżdżą samochodami, więc bezpieczeństwo musi być absolutnym priorytetem numer jeden.

Od dziesięcioleci samochody mają wbudowaną elektronikę i oprogramowanie wbudowane do takich rzeczy, jak kontrola napędu, kontrola skrzyni biegów i wtrysk paliwa. Obecnie zaawansowane systemy wspomagające kierowcę (ADAS), takie jak inteligentny tempomat i ostrzeżenia o wyjechaniu z pasa ruchu, zaczynają pojawiać się w pojazdach, które są dziecinnymi krokami w kierunku autonomii. Chociaż istnieją kwestie bezpieczeństwa, które zostały rozwiązane w zakresie sterowania zespołem napędowym, ryzyko dla ludzkiego życia, które mogą spowodować awarie ADAS, doprowadziło do opracowania kilku norm, aby złagodzić to ryzyko w jak największym stopniu.

Normy zapewniają bezpieczeństwo i interoperacyjność

Podstawowym standardem odnoszącym się do autonomicznych samochodów jest ISO 26262. Jego celem jest zapewnienie właściwego zarządzania bezpieczeństwem w systemach motoryzacyjnych. Część normy ISO 26262 to priorytetowy zestaw klasyfikacji poziomów bezpieczeństwa (ASIL) Automotive Safety Integrity Level. Klasyfikacja poziomu ASIL jest ustalana na podstawie wagi szkody, która może wynikać z awarii sprzętu (lub oprogramowania sterującego sprzętem) w różnych scenariuszach, i od A (najmniej rygorystyczna) do D (najbardziej rygorystyczna).

Zgodność z normą ISO 26262 wymaga zaprojektowania sprzętu i oprogramowania pod kątem bezpieczeństwa, takich jak korzystanie ze ścieżek zastępczych, samokontrola i redundancja. Sprzęt musi być testowany zgodnie z poziomem ASIL, w którym działa. Sprzęt lub oprogramowanie, które nie ma wpływu na jakąkolwiek funkcję krytyczną dla bezpieczeństwa (na przykład GUI dla ekranu dotykowego samochodu) mają niższą klasyfikację ASIL niż funkcje ADAS, które mogą mieć znaczący wpływ na bezpieczeństwo. Ponieważ funkcje ADAS podejmują decyzje na wysokim poziomie dla kierowcy, zwykle muszą być certyfikowane do wysokiej klasyfikacji ASIL, takiej jak ASIL-D.

Oznacza to, że uzyskanie certyfikatu bezpieczeństwa produktu ADAS może zająć dość dużo czasu. Logicznym sposobem skrócenia czasu i kosztów uzyskania certyfikatu jest użycie sprzętu, który został wstępnie certyfikowany i narzędzi programistycznych (takich jak kompilatory i biblioteki wydajności, takie jak LAPACK), aby uczynić certyfikat ISO 26262 na pełnym poziomie systemu bardziej celowym i podnieść poziom bezpieczeństwa.

Istnieje również standard rozwoju oprogramowania. Automotive SPICE (ASPICE) to standardowa platforma do projektowania i oceny procesów rozwoju oprogramowania motoryzacyjnego. Skuteczne wdrożenia prowadzą do lepszych procesów i lepszej jakości produktu.

Innym znanym standardem jest IEEE 2020. Standard ten jest obecnie w fazie wstępnej. Określa metody i metryki mierzenia i testowania jakości obrazów samochodowych w celu zapewnienia spójności i tworzenia punktów odniesienia dla różnych branż. Jest to przyszły standard, który nie został jeszcze opublikowany, ale będzie miał istotny wpływ na funkcje ADAS, które opierają się na kamerach, przetwarzaniu obrazu, wizji komputerowej i innych technologiach percepcji pojazdu.

Wybór sprzętu i oprogramowania z uwzględnieniem standardów

Wybierając sprzęt i oprogramowanie do zastosowań motoryzacyjnych, zwłaszcza aplikacje ADAS, które wymagają rygorystycznej certyfikacji bezpieczeństwa, najlepszym rozwiązaniem jest poleganie na sprawdzonych dostawcach dzięki produktom zoptymalizowanym pod kątem zastosowania.

W przypadku systemów motoryzacyjnych, a zwłaszcza ADAS, bardzo ważne jest korzystanie z procesorów i innego sprzętu specjalnie zaprojektowanego z myślą o ograniczeniach związanych z bezpieczeństwem i zużyciem energii. Istnieje kilka sprawdzonych opcji procesora dla aplikacji samochodowych. Wszystkie są zgodne z normą ISO 26262 i stanowią doskonały wybór. W przypadku aplikacji ADAS większość zawiera wiele rdzeni zarówno dla bezpieczeństwa, jak i dla wyładowania konkretnych obowiązków dla współprocesorów.

Procesory wielordzeniowe mogą znacznie zwiększyć bezpieczeństwo, a także poprawić wydajność. Niektóre mają wbudowane rdzenie bezpieczeństwa sprzętu w celu zapewnienia integralności pamięci. Niektóre mają również możliwości DSP do przetwarzania danych z czujników. Wybór docelowych procesorów, które są już zgodne z normą ISO 26262, może znacznie uprościć Twój projekt, a także zaoszczędzić czas, jeśli chodzi o certyfikację.

Choć na pierwszy rzut oka “kompilator jest kompilatorem” może wydawać się prawdą, ale na pewno nie jest. Wszystkie kompilatory wybierają kod do wygenerowania z wejścia C / C ++. Dzięki niezliczonym wbudowanym funkcjom i rdzeniom w procesorach zorientowanych na motoryzację, ważne jest, aby kompilator znał te funkcje i tworzył kod zoptymalizowany pod kątem tych funkcji.

Wybór kompilatora posiadającego certyfikat ASPICE na poziomie 2 oznacza, że ​​możesz być pewien, że produkt został opracowany zgodnie ze sprawdzonymi procesami i umożliwia spełnienie wymaganych norm bezpieczeństwa, co oznacza, że ​​Twoja aplikacja jest bardziej prawdopodobna. wolny. Nie tylko używanie certyfikowanego przez ASPICE kompilatora daje lepszy kod, ale także pozwala zaoszczędzić pieniądze.

Standardy: zbyt ograniczanie?

Zadano mi pytanie: “Czy standardy ograniczają kreatywność inżynierów?” Szczerze mówiąc, uważam, że jest dokładnie odwrotnie. Normy są jak wszelkie inne ograniczenia projektowe: eliminują niejednoznaczność projektu i pozwalają projektantowi skupić się na problemie i jak twórczo rozwiązać ten problem w ramach ograniczeń.

Kiedy normy bezpieczeństwa i operacyjne stają się ograniczeniami, jest całkowicie jasne, jakie poziomy wydajności muszą zostać osiągnięte. Nie ma potrzeby definiowania ograniczeń, które zostały już zdefiniowane przez komitet normalizacyjny – teraz dostępny jest czas na zdefiniowanie i zaprojektowanie kreatywnych rozwiązań. Używanie sprzętu zgodnego z normą ISO 26262 i kompilatory certyfikowane przez ASPICE zapewniają projektantom dodatkowe korzyści.

Ogólnie rzecz biorąc, obowiązujące normy bezpieczeństwa motoryzacyjnego, a także opracowywane rozwiązania, są kluczem do uzyskania bezpieczniejszych, bardziej wydajnych i ostatecznie napędzanych pojazdami.