Certyfikacja bezpieczeństwa funkcjonalnego zgodna z ISO 26262
| TechnikaDzisiejsze samochody wykorzystują od setek do tysięcy podzespołów półprzewodnikowych i innych komponentów elektronicznych, które realizują systemy interfejsu dotykowego, ładowania akumulatorów i zarządzania ich pracą, a także wspomagania i sterowania silnikiem. Wymagania specyfikacji ISO 26262, przygotowanej przez International Organization for Standardization, dotyczące bezpieczeństwa funkcjonalnego, zapewniają bezpieczne działanie tych coraz bardziej złożonych i wyrafinowanych aplikacji.
Opracowanie zgodnych z normą projektów i uzyskanie certyfikacji może być czasochłonnym i kosztownym procesem. Na szczęście problemy można stosunkowo prosto pokonać, ponieważ przemysł półprzewodnikowy zapewnia producentom OEM i ich dostawcom kompletne środowiska bezpieczeństwa funkcjonalnego, które minimalizują koszty, ryzyko i czas projektowania niezbędne do uzyskania certyfikatu.
Czym jest ISO 26262?
Norma ISO 26262 definiuje specyfikacje bezpieczeństwa funkcjonalnego systemów elektrycznych i elektronicznych montowanych w seryjnie produkowanych pojazdach drogowych (z wyłączeniem motorowerów). Regulacja ta została opublikowana w 2011 r. i była zaktualizowana w 2018 r., kiedy to dodano do niej sekcję definiującą wymagania w zakresie półprzewodników. ISO 26262 opisuje proces rozwoju produktu od specyfikacji do serii produkcyjnej. Producenci OEM i dostawcy z branży motoryzacyjnej muszą jej przestrzegać i dokumentować swoje działania podczas kwalifikowania urządzeń do pracy w pojazdach drogowych, które wymagają zapewnienia bezpieczeństwa funkcjonalnego.
Certyfikacja systemów odbywa się poprzez potwierdzenie przez niezależnego asesora ich zgodności z wymaganiami normy ISO 26262. W ramach tego procesu urządzenia w samochodzie są "klasyfikowane" do różnych poziomów integralności bezpieczeństwa (Automotive Safety Integrity Level, ASIL), w zależności od ich poziomu krytyczności dla działania, gdyż praca niektórych aplikacji wiąże się z wyższym zagrożeniem bezpieczeństwa w przypadku ich awarii. Stosowane poziomy od A do D odzwierciedlają dotkliwość skutków takiej awarii i prawdopodobieństwo pojawienia się potencjalnych obrażeń u ludzi oraz zakres, w jakim działanie tego sprzętu może być kontrolowane. Istnieją także związane z poziomami wymogi bezpieczeństwa dotyczące komponentów składowych, z których te aplikacje są budowane. I tak, ASIL-D reprezentuje najwyższy stopień zagrożenia i dotyczy zastosowań takich jak poduszki powietrzne, układ ABS i wspomagania kierownicy. Tylne światła są natomiast klasyfikowane jako ASIL-A – najmniejszy stopień zagrożenia. Światła mijania i hamowania są generalnie klasyfikowane jako ASIL-B. Tempomat jest klasyfikowany jako ASIL-C. Im wyższy poziom ASIL, tym więcej jest wymagań dotyczących zapewnienia nadmiarowości w warstwie hardware.
Istnieje wiele sposobów, dzięki którym dostawcy komponentów mogą przyspieszyć i ułatwić sobie projektowanie aplikacji bezpieczeństwa i jej certyfikację zgodnie z ISO 26262. Dostępne do tego celu zasoby zilustrowano na rysunku 1. Po pierwsze, komponenty muszą być starannie dobrane, aby ich specyfikacje obejmowały niezbędne informacje z zakresu bezpieczeństwa funkcjonalnego. Obejmują one raporty z analizy skutków i diagnostyki trybu awaryjnego (Failure Mode Eff ect and Diagnostics Analysis, FMEDA) oraz instrukcje zapewnienia bezpieczeństwa. Komponenty muszą być również wspierane przez środowisko programistyczne zakwalifikowane do tworzenia aplikacji o krytycznym znaczeniu.
Gotowość do zapewnienia bezpieczeństwa funkcjonalnego
We współczesnych samochodach używa się wiele różnych układów scalonych. Największe znaczenie mają oczywiście mikrokontrolery (MCU), które pracują we wszystkich elektronicznych jednostkach sterujących (ECU) i są używane w systemach zapewniających komfort podróży, takie jak systemy jazdy autonomicznej. Obejmują one jednostki 8-bitowe, które są zoptymalizowane pod kątem wydajności, energooszczędności i możliwości pracy w systemach czasu rzeczywistego. Układy te realizują także sprzętowe interfejsy dotykowe. Na drugim biegunie plasują się układy 32-bitowe, które mogą obsługiwać aplikacje wielowątkowe, graficzne interfejsy użytkownika, komunikację i funkcje bezpieczeństwa. Wymienić trzeba ponadto kontrolery DSC (Digital Signal Controllers), które łączą rdzeń MCU z silnikiem DSP, aby zapewnić solidną i szybką deterministyczną wydajność niezbędną do obsługi czujników, silników lub konwerterów zasilających.
Każdy z używanych układów scalonych musi spełniać motoryzacyjne standardy kwalifikacji w zakresie produkcji i wydajności, które zostały ustanowione przez Automotive Electronics Council (AEC). Normy AEC-Q100 definiują proces kwalifikacji komponentów oparty na analizie awaryjności oraz testach zmęczeniowych i precyzują różne klasy temperaturowe. W zależności od docelowych zastosowań mikrokontroler jest kwalifikowany do AEC Q100 Grade 2, Grade 1 lub Grade 0. Stopień 0 to temperatura 150ºC, stopień 1 to 125ºC, a stopień 2 to 105ºC.
Poza kwalifikacją AEC dodatkowe wymagania nakładane na aplikacje dotyczą funkcji zapewniających bezpieczeństwo funkcjonalne. Na przykład 8-bitowe MCU często zawierają interfejs CAN FD do komunikacji z systemami w pojeździe i z inteligentnymi czujnikami. Takie mikrokontrolery są też zwykle używane jako kontrolery interfejsu użytkownika (UI), obsługują przyciski mechaniczne i dotyk pojemnościowy w kabinie, w kierownicy, konsoli środkowej lub pracują jako część bezkluczykowego systemu dostępu. Zintegrowane funkcje bezpieczeństwa sprzętowego w tych jednostkach zwykle dotyczą działania pamięci, resetowania systemu, bezpiecznego wykonywania kodu, bezpiecznej komunikacji i ochrony przepięciowej linii GPIO. Są one integrowane z użyciem specjalizowanych układów peryferyjnych typu CIP (działających niezależnie od rdzenia) i innych funkcji, w tym resetowania po włączeniu zasilania (POR), resetowania przy zaniku napięcia (BOR), okienkowego timera typu watchdog (WWDT) i jednostki wyliczającej sumę kontrolną CRC danych w celu poprawy bezpieczeństwa pracy i niezawodności działania aplikacji (patrz rys. 2).
W zakresie wydajniejszych jednostek w ofercie są 16-bitowe kontrolery DSC z blokami bezpieczeństwa funkcjonalnego. Funkcje te są realizowane sprzętowo i obejmują zazwyczaj pamięć z wbudowaną detekcją i korekcją błędów, autotest pamięci (memory built-in self-test, MBIST), monitorowanie sygnału zegara i dodatkowy (redundantny) oscylator i podobne bloki do wykrywania błędów, autodiagnostyki i testowania systemu oraz reakcji na błędy. Takie funkcje umożliwiają projektowanie aplikacji embedded o krytycznym znaczeniu dla bezpieczeństwa, podłączanie czujników, tworzenie cyfrowych systemów zasilania i aplikacji do sterowania silnikami. Typowe zastosowania obejmują systemy konwersji DC/DC, ładowarki OBC, siłowniki i czujniki (pozycja, ciśnienie), sensory dotykowe i sterowniki ukierunkowane na zgodność z ASIL-B lub ASIL-C. Rysunek 3 przedstawia schemat blokowy kontrolera DSC wybranego pod kątem spełnienia wymagań bezpieczeństwa funkcjonalnego.
Podobnie jak w przypadku wszystkich innych mikrokontrolerów z funkcjami bezpieczeństwa funkcjonalnego, jednostki 32-bitowe realizują takie funkcje w warstwie sprzętowej, w tym mają pamięć z korekcją błędów (ECC) i wstrzykiwaniem błędów (Fault Injection), wbudowany autotest pamięci (Memory Built-in Self Test, MBIST), generator taktowania, w tym zapasowy oscylator i obwód wykrywania awarii taktowania, a także zabezpieczone przed wyładowaniami elektrostatycznymi (ESD) linie GPIO (patrz rys. 4). Z omawianego punktu widzenia ważne są również obwody monitorowania zasilania, takie jak POR, BOR, watchdog WDT, sprzętowy generator CRC oraz blok ochrony pamięci. 32-bitowe mikrokontrolery są używane w wielu zastosowaniach, od aplikacji kabinowych po zaawansowane systemy wspomagania kierowcy (ADAS) w celu zapewnienia bezpieczeństwa funkcjonalnego.
Osiągnięcie poziomów bezpieczeństwa ASIL C/D za pomocą standardowych mikrokontrolerów i DSC też jest możliwe. Realizuje się to poprzez połączenie MCU lub DSC z drugą jednostką lub z tzw. koprocesorem bezpieczeństwa. Pozwala na to zasada dekompozycji ASIL: połączenie dwóch podsystemów zgodnych z ASIL-B może być wykorzystane do osiągnięcia wyższego ASIL, takiego jak ASIL C/D: ASIL-C = ASIL B (C) + ASIL A (C) ASIL-D = ASIL B (D) + ASIL B (D) = ASIL-C (D) + ASIL A (D)
Dekompozycję uzyskuje się poprzez rozdzielenie wymagań bezpieczeństwa na poszczególne jednostki systemowe.
Narzędzia programistyczne i wsparcie procesu certyfikacji
Rozwojowe pakiety narzędziowe, które są certyfikowane pod kątem bezpieczeństwa funkcjonalnego i stanowią część kompletnego środowiska programistycznego, mogą ułatwić spełnienie wymagań ISO 26262 w zakresie weryfikacji i walidacji kodu. Dotyczy to w szczególności projektów wykorzystujących mikrokontrolery i układy DSC. Producenci takiego oprogramowania współpracują z niezależnymi agencjami oceniającymi (tzw. strona trzecia), aby certyfikować kompilatory pod kątem zapewniania przez nie bezpieczeństwa funkcjonalnego. Zwykle obejmuje to także dodatkową dokumentację, taką jak właśnie certyfikat, podręcznik zapewnienia bezpieczeństwa funkcjonalnego, plan bezpieczeństwa i klasyfikację narzędzi oraz raportów kwalifi- kacyjnych kompilatorów, zintegrowane środowisko programistyczne (IDE) oraz debuggery i programatory pamięci. Taki pakiet dokumentacji w zakresie bezpieczeństwa funkcjonalnego upraszcza późniejszą kwalifikację narzędzi i certyfikację aplikacji końcowej.
W idealnym przypadku w procesie projektowania jest również używane narzędzie do zbierania pokrycia kodu, pozwalające ocenić, jak dobrze oprogramowanie zostało przetestowane i wskazujące, które fragmenty kodu zostały, a które nie zostały wykonane. Narzędzie to powinno być również uwzględnione w raportach klasyfikacji i kwalifikacji. Stąd warto wybierać takie produkty, które mogą testować w jednym przebiegu bez dzielenia kodu na bloki i używania wymagającego dużej ilości modyfikacji sprzętu, unikać kosztownego oprogramowania i wymagającego znacznego wysiłku związanego z przeszukiwaniem dużych plików danych w celu znalezienia odpowiednich informacji. Certyfikacja aplikacji wymaga przeprowadzenia testów kodu, dlatego narzędzia jednoprzebiegowe do zbierania pokrycia kodu odgrywają istotną rolę w usprawnieniu procesu i skróceniu czasu wprowadzenia na rynek.
Aby opracować aplikację motoryzacyjną zgodną z normą ISO 26262, inżynier będzie potrzebował, aby producent układów półprzewodnikowych dostarczył mu dodatkowych informacji poza kartami katalogowymi. Są one zwykle udostępniane jako "pakiety bezpieczeństwa funkcjonalnego" i zapewniają producentom OEM i dostawcom z branży motoryzacyjnej to, czego potrzebują na różnych etapach cyklu oceny i projektowania urządzenia. W tych pakietach powinny znajdować się certyfikowane podręczniki, raporty FMEDA oraz, w niektórych przypadkach, oprogramowanie diagnostyczne, takie jak certyfikowane biblioteki autotestów dla odpowiednich poziomów ASIL.
Ujęcie ilościowe awarii urządzenia, rozkład wskaźnika awarii w czasie (FIT) i odpowiednie metody wykrywania precyzuje raport FMEDA, pomagając w stworzeniu planu pokrycia. Innym ważnym źródłem informacji jest podręcznik bezpieczeństwa (Safety Manual, SM). Zawiera on informacje na temat metod wykrywania usterek wymienionych w raporcie FMEDA i proponuje sposoby użytkowania urządzenia w celu zapewnienia najbezpieczniejszego działania. Zawiera opis awarii zależnych i funkcji sprzętowych do wykrywania awarii systematycznych, które można wykorzystać do tworzenia bibliotek diagnostycznych. One z kolei mogą pomóc w ocenie stanu operacyjnego systemu w stanie awarii, wykrywaniu losowych usterek i osiąganiu celów bezpieczeństwa funkcjonalnego. Wybór układu, który ma certyfikowany przez firmę trzecią raport FMEDA i podręcznik bezpieczeństwa oraz biblioteki diagnostyczne, ułatwia certyfikację aplikacji o kluczowym znaczeniu dla zapewnienia bezpieczeństwa.
Tworzenie aplikacji o krytycznym znaczeniu dla bezpieczeństwa rozpoczyna się od zdefiniowania celów i docelowego poziomu, który należy osiągnąć. Podstawowy pakiet zapewnia zasoby, takie jak FMEDA, podręcznik bezpieczeństwa i certyfikaty, które ułatwiają rozpoczęcie oceny docelowych poziomów bezpieczeństwa funkcjonalnego i projektowania aplikacji motoryzacyjnych o kluczowym znaczeniu.
Pakiet startowy bezpieczeństwa funkcjonalnego dla projektu opartego na mikrokontrolerze w idealnym przypadku obejmowałby certyfikowany raport FMEDA ASIL B Ready, podręcznik bezpieczeństwa i biblioteki diagnostyczne zgodne z ASIL B/C, w połączeniu z projektem referencyjnym, które pomagają projektantom zrozumieć, w jaki sposób można wykorzystać te zasoby do rozwoju urządzeń o krytycznym znaczeniu dla bezpieczeństwa przy przestrzeganiu normy ISO 26262. Pomaga on przyspieszyć cykl projektowania i opracować aplikację zgodnie z normą ASIL-B lub C.
Pełny pakiet bezpieczeństwa funkcjonalnego może rozszerzyć ofertę o certyfikowane biblioteki diagnostyczne zawierające kod źródłowy i odpowiednie raporty analizy bezpieczeństwa dla projektów do ASIL B/C. Biorąc pod uwagę, że wielu klientów końcowych żąda certyfikacji aplikacji o kluczowym znaczeniu dla bezpieczeństwa, pełny pakiet przyspiesza proces certyfikacji.
Podsumowanie
Samochody stają się coraz bardziej złożone, a stopień ich elektronizacji stale się zwiększa. Coraz ważniejsze staje się zapewnienie ich bezpieczeństwa funkcjonalnego zgodnego z wymaganiami normy ISO 26262. Dostawcy układów scalonych mogą w tym zakresie pomóc klientom z branży motoryzacyjnej w przejściu procesu rozwoju i certyfikacji produktu. Mogą zapewnić, że podzespoły używane w certyfikowanym systemie będą dostarczane tak długo, jak długo klient będzie je zamawiał, eliminując ryzyko przeprojektowania z powodu zakończenia produkcji (EOL). Zwiększa to pewność, że certyfikacja nie tylko zostanie ukończona szybko i łatwo, ale także będzie musiała zostać przeprowadzona tylko raz.
Jacob Lunn Lassen, Technical Staff Engineer, Functional Safety
Microchip Technology
www.microchip.com
