Functional Safety ISO 26262 – ASIL i metryki

Według WHO na świecie rocznie w wypadkach komunikacyjnych ginie około 1,35 miliona ludzi. Między innymi z tego względu branża motoryzacyjna stara się ulepszać i wprowadzać nowe rozwiązania systemów bezpieczeństwa. Począwszy od pasów czy poduszek powietrznych, aż po zaawansowanych asystentów wspomagania kierowcy (ADAS). Systemy takie mogą przewidywać i zapobiegać zdarzeniom drogowym, wpływając znacznie na nasze bezpieczeństwo na drogach.

Funkcje te są realizowane przez skomplikowane i wyrafinowane systemy elektro-mechatroniczne. Aby umożliwić projektowanie i ocenę takich systemów, mogących zapobiegać lub kontrolować występujące niebezpieczne sytuacje, został opracowany standard bezpieczeństwa funkcjonalnego ISO 26262.

Normy ISO

Normy ISO są dokumentami opracowywanymi przez niezależnych ekspertów w danej dziedzinie i zawierają informacje, wskazówki oraz zbiory dobrych praktyk pozwalające regulować i ujednolicać funkcjonowanie firm na różnych płaszczyznach. Wdrożenie norm w firmie pozwala nie tylko zwiększyć efektywność i organizację pracy. Poprawia też globalną komunikację handlową i zwiększa prestiż przedsiębiorstwa.

Przybliżony w artykule standard opisuje proces projektowania, rozwoju oraz produkcji komponentów pojazdów. Postępowanie zgodne z wytycznymi normy pozwala na eliminowanie ryzyka i zagrożeń bezpieczeństwa, dlatego coraz więcej producentów pojazdów wymaga od dostawców certyfikacji komponentów zgodnie ze standardem ISO 26262.

Przegląd struktury standardu ISO 26262

Patrząc na wersję ISO 26262:2018, dokument jest podzielony na 12 części z czego większość dotyczy obszarów zarządzania projektem, poszczególnych faz rozwoju produktu, produkcji i eksploatacji oraz wsparcia procesów. Wdrażanie tych procesów normy wpisuje się w większość systemów zarządzania w organizacjach takich jak Waterfall czy Agile. Ponadto, jest kompatybilny z V-modelami do wytwarzania systemów inżynieryjnych (nie tylko oprogramowania) takimi jak SPICE czy CMMI.

Proces opiera się na prawidłowym definiowaniu wymagań bezpieczeństwa dotyczących wytwarzanego produktu oraz prawidłowym zarządzaniu nimi w czasie ich implementacji oraz weryfikacji. Ważnym aspektem jest też analiza pod względem bezpieczeństwa i wiarygodności używanych w czasie powstawania wyrobu narzędzi. Projektowany system, aby był bezpieczny musi mieć wbudowane mechanizmy diagnostyki wraz z procedurami postępowania w razie detekcji błędów.

Safety Management

Czytając kolejne rozdziały standardu, po lekturze rozdziału I (wyjaśnia słownictwo używane w kolejnych częściach normy) w II rozdziale czekają na nas informacje dotyczące procesu zarządzania projektem functional safety. W takim projekcie należy postępować według ściśle określonych zasad.

1. Muszą być zdefiniowane i wdrożone procedury rozwoju projektu.
2. Musi zostać mianowany wyszkolony Safety Manager odpowiadający za planowanie i kontrolowanie działań związanych z bezpieczeństwem.
3. Należy też zdefiniować „safety cases”, które zawierają dowody na bezpieczeństwo powstającego systemu. Zadanie to musi zostać wykonane bardzo dokładnie i powinni być wyznaczeni niezależni, krytyczni recenzenci, którzy to potwierdzą. Jest to obowiązkowa procedura, dzięki której można zminimalizować ryzyko błędnej interpretacji lub oszustw.

Faza koncepcyjna

Opisane w rozdziale III wytyczne wskazują, że rozwój projektu zaczyna się od zdefiniowania zakresu, który (zgodnie z rozdziałem I) w ISO 26262 nazywa się „item”. W skrócie jest to zdefiniowanie systemu, implementującego pewny zakres funkcjonalności (np.: system sterowania silnikiem jest częścią funkcjonalności układu napędowego pojazdu).

Analiza HARA

Następnie przechodzimy do analizy HARA (Hazard Analysis and Risk Assessment), która ocenia ryzyka dla ludzkiego życia, jeśli system (item) będzie wadliwy. Bazując na ryzyku, wyznacza się „safety goals” dla systemu, które są wymaganiami bezpieczeństwa funkcjonalnego.

Identyfikacja poziomu ASIL

Kolejnym z kroków, jaki wymaga standard, jest identyfikacja poziomu ASIL (Automotive Safety Integrity Level) dla zdefiniowanych uprzednio w procesie wymagań bezpieczeństwa. Jest on powiązany z ryzykiem oraz niepożądanymi zdarzeniami, jakie mogą wystąpić i zagrozić użytkownikom.

Wymagania mogą zostać skalsyfikowane w 5 klasach (QM lub ASIL A do ASIL D), które determinują zakres metod analiz i weryfikacji (A – poziom niski, zaś D – najwyższy).

Poniżej przedstawiono tabelę ryzyka dla ASIL. Przechodząc przez nią od lewej, estymujemy parametry S, następnie E i kolejno C. Na końcu mamy rezultat oceny ryzyka QM lub odpowiedni ASIL. QM jest skrótem od Quality Managed, co oznacza, że projekt powinien być prowadzony zgodnie ze standardami metodologii rozwoju takimi jak ASPICE czy CMM (Capability Maturity Model).

Przykład oceny parametrów ASIL

Analizując poszczególne parametry, od wpływu zdarzeń wywołanych przez urządzenie na zdrowie poprzez prawdopodobieństwo wystąpienia, w końcu możliwość kontroli przez użytkownika, można ocenić główny parametr ASIL.

Przykładowo elektryczne sterowana kierownica lub autopilot mają w razie awarii wysokie prawdopodobieństwo spowodowania śmiertelnego wypadku i reakcja kierowcy może nie wystarczyć, aby zapobiec niebezpiecznemu zdarzeniu w trakcie wystąpienia błędu. Obydwa systemy będą miały ocenę ASIL D. Natomiast funkcjonalność czujnika przeszkody podnośnika szyb będzie sklasyfikowana najprawdopodobniej jako QM. Ryzyko uszkodzenia ciała w czasie wystąpienia błędu jest niewielkie (już sama moc silników podnośnika jest niewystarczająca, aby zrobić krzywdę). Użytkownik też może w każdej chwili zatrzymać zamykanie, więc kontrola jest dość łatwa.

Dekompozycja

Zdarza się, że system oceniony na pewnym poziomie może zostać przeprojektowany tak, aby składał się z kilku podsystemów ocenionych na niższym poziomie. Takie przedefiniowanie w normie nazywamy dekompozycją.

Dekomponując, próbujemy rozłożyć system lub funkcjonalność na kilka podsystemów i każdemu z nich na nowo przypisać inny poziom, oceniając jeszcze raz ryzyko dla niego. Ideą takiego postępowania jest obniżenie oceny, co powoduje zmniejszenie nakładu pracy.

Może też się okazać, że wszystkie powstałe w dekompozycji systemy będą miały niższy poziom ASIL. Na przykład kiedy błąd zdefiniowanej funkcji bezpieczeństwa, przez którą osiągnięto wysoki poziom ASIL, może wystąpić tylko, jeśli pewne dwie funkcje powstałe przez podział wymagań będą miały błąd jednocześnie. Wtedy każdy z tych modułów może mieć niższy poziom ASIL.

Często taką dekompozycję stosuje się poprzez zastosowanie kilku systemów, których funkcje się chociaż częściowo pokrywają (redundantne systemy).

Przykłady dekompozycji

Przykładem może być funkcjonalność przednich świateł samochodu, które mają ocenę ASIL B. Dekomponując ją na parę równoważnych, niezależnych świateł (prawe i lewe), otrzymujemy dwie funkcje o ocenie ryzyka ASIL A. Dzięki temu awaria w nocy jednego ze świateł nie powoduje utraty widoczności, gdyż mamy jeszcze drugie działające. Zmniejszyło się zagrożenie bezpieczeństwa.

Inną ilustracją dekompozycji może być użycie biblioteki sterowników portów stworzonych w ASIL B do implementacji komponentu ASIL D. W takiej sytuacji używa się dwóch niezależnych portów i przetwarza się sygnał, używając różnych algorytmów. Na koniec wyniki są porównywane w systemie na poziomie ASIL D dla pewności, że sterowniki działają poprawnie.

Rekomendowane kroki działań dla poszczególnych poziomów ASIL

Zdefiniowanie poziomu ASIL jest kluczowe ze względu na wymagania procesowe stawiane w zależności od oceny. Jest wiele analiz i produktów pracy, które należy wytworzyć, a także potwierdzić wykonanie odpowiednimi recenzjami (review). W wyniku analizy i klasyfikacji ASIL, norma nakłada obowiązki, co do szczegółowości dokumentacji, architektury, testów czy recenzji przy wytwarzaniu.

Poniżej przedstawiono tabele pokazujące rekomendowane kroki działań dla poszczególnych poziomów.

Oznaczenia w tabelach:

„++” – wymagane
„+” – rekomendowane
„o” – bez rekomendacji

Recenzja

Kolejnym ważnym elementem jest sposób przeprowadzania recenzji dla poszczególnych produktów pracy wymaganych w czasie rozwoju projektu. Są cztery poziomy niezależności przeprowadzania recenzji opisane w tabeli poniżej.

Tabela poniżej przedstawia kilka działań, jakie podjąć muszą inżynierowie wraz z poziomami recenzji.

Nakłady pracy zależne od poziomu ASIL

Jak widać powyżej, jest wiele działań, jakie są obowiązkowe przy pracy w projekcie zgodnym z normą bezpieczeństwa funkcjonalnego. Nakład pracy przy projekcie dla wyższych poziomów rośnie ekspotencjalnie. Jeśli przyjąć, że na sam system funkcjonalny potrzebny nakład to 1, dla kolejnych poziomów ASIL szacuje się wartości czasu pracy:

• ASIL A: 1.5x — 3x
• ASIL B: 2x — 4x
• ASIL C: 5x — 8x
• ASIL D: 10x+

Jak widać, na projekt w najwyższym poziomie ASIL D potrzeba zasobów ponad dziesięciokrotnie większych niż standardowy projekt. Z tego powodu elementy systemu zakwalifikowane w poziomach wysokich, czyli ASIL C i D, często są dekomponowane do poziomów A i B, co pozwala zmniejszyć nakłady pracy.

Metryki błędów

Kiedy już zostaną określone poziomy ASIL (z reguły definiowane są przez zamawiających produkt, czyli najczęściej przez twórców pojazdów), do gry wchodzą dostawcy systemów, którzy muszą stworzyć koncept techniczy bezpieczeństwa (technical safety concept) z zakresu swojej odpowiedzialności. Zawiera on wymagania bezpieczeństwa (safety requirements), które są realizowane przez zaprojektowane mechanizmy bezpieczeństwa.

Mechanizmy te najczęściej są to sprzętowe detektory wykrywające błędy wraz z oprogramowaniem algorytmów reagujących na wykryty błąd. Wytyczne na ten temat są zawarte w rozdziale IV. Kolejne rozdziały V i VI dotyczą poszczególnych dziedzin hardware i software. Wymagania na systemowym poziomie są rozbijane na część sprzętową i oprogramowania.

Powstałe architektury muszą zawierać szereg elementów takich jak:

• Reakcja na awarie, w tym awarie przejściowe,
• Możliwości diagnostyczne,
• Uwzględnienie czasów wykrywania błędów,
• Oczekiwane wskaźniki awaryjności komponentów,
• Wymagania dotyczące weryfikacji projektu,
• Zgodność z nadrzędnymi specyfikacjami bezpieczeństwa.

Wyznaczenie metryk błędów

Aby można było otrzymać wskaźniki awaryjności, ważnym krokiem w procesie jest wyznaczanie metryk błędów (Fault Metrics). Mają one na celu ocenę skuteczności architektury w radzeniu sobie z przypadkowymi awariami. Aby ocenić w jakim stopniu system jest narażony na występujące zagrożenia, standard definiuje metryki, które przedstawiają odporność systemu na awarie i błędy. Najważniejsze z nich to:

• SPFM Single-point Fault Metric – mierzy odporność projektu na pojedyncze błędy,
• LFM Latent-fault Metric – mierzy odporność na ukryte wady projektu,
• PFH Probability of dangerous failure per hour – prawdopodobieństwo niebezpiecznego zdarzenia na godzinę.

Aby opisać metryki w pierwszym rozdziale normy, zdefiniowany jest całkowity wskaźnik awaryjności λ. Można podzielić go na poszczególne rodzaje wskaźników błędów:

gdzie:
λ_SPF – Single Point Faults (błędy mogące wystąpić w systemie poza diagnostyką),
λ_RF –  Residual Faults (błędy nie pokryte przez diagnostykę),
λ_MPF – Multiple Point Faults (kombinacja błędów pojedynczych SPF),
λ_S – Safe Faults (błędy wychwytywane przez diagnostykę systemu).

Metryka SPFM jest obliczana ze wzoru:

Natomiast LFM:

Gdzie:

λ_MPF(PER/DET) – kombinacje błędów wykrywalne przez użytkownika lub diagnostykę systemu.

Ze wzorów wynika, że powyższe wskaźniki pokazują w jakim stopniu system jest zabezpieczony przed różnorodnymi błędami. Aby wskaźnik był jak najwyższy, potrzeba jest jak najwięcej zdefiniowanych błędów, które są detektowane przez diagnostykę systemu (λ_S). W zależności od oceny ASIL system, który jest realizowany musi spełniać poniższe kryteria:

Analiza FMEDA i FTA

Do odpowiedniego wyznaczania metryk stosuje się różne analizy takie jak FMEDA (Failure modes, effects, and diagnostic analysis) czy FTA (Fault tree analysis). Dzięki tym analizom i metrykom jesteśmy w stanie określić, czy nasz koncept spełnia wartości dla zadanego poziomu ASIL i ewentualnie wprowadzić korekty lub dodatkowe wymagania, dzięki którym wskaźniki się poprawią. Dokładnym opisem analiz zajmuje się rozdział IX normy ISO 26262.

Kolejne rozdziały normy zajmują się sprawami produkcji, serwisowaniem, recyklingiem pojazdów. Są też dodatkowe informacje na temat wspierających procesów w czasie powstawania produktów automotive. Na koniec jest też rozdział XII dotyczący jednośladów.

Podsumowanie

Norma została wprowadzona, żeby usystematyzować rozwijanie produktów, których błędne działanie może zagrozić zdrowiu lub życiu ludzi. Daje ona wskazówki, jak zidentyfikować krytyczne elementy systemu, dla których należy zastosować odpowiednie progi jakościowe, aby minimalizować ryzyko awarii lub zwiększyć kontrolę sytuacji awaryjnych.

Przedstawione w artykule elementy procesu nie wyczerpują całego zakresu, jaki obejmuje norma bezpieczeństwa funkcjonalnego ISO 26262. Norma jest bogata we wskazówki i instrukcje na wszystkich szczeblach procesu wytwarzania zaawansowanych systemów. Jest to ogromny dokument liczący ponad 400 stron i w branży Automotive zagłębianie się w niego powinno być dla inżyniera bezpieczeństwa funkcjonalnego codziennością.

Źródła

• C2000™ MCU SafeTI™ control solutions: An introduction to ASIL decomposition and SIL synthesis
•  OVERVIEW ON ISO 26262
• Wzrost bezpieczeństwa funkcjonalnego pojazdów dzięki ISO 26262
• How the ISO 26262 Updates Affects You
• The Mumbo-Jumbo called ASIL Decomposition!
• Peter Kafka, The Automotive Standard ISO 26262, the innovative driver for enhanced safety assessment & technology for motor cars

***

Jeśli interesuje Cię tematyka ISO, oceny ryzyka i standardów zachęcamy do zapoznania z innym artykułami naszych ekspertów: Introduction to Risk Management for embedded Medical Device software (IEC 62304:2006/AMD 1:2015), Agile w procesach regulowanych.