{"id":16172,"date":"2022-10-03T07:00:00","date_gmt":"2022-10-03T05:00:00","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=16172"},"modified":"2023-02-16T13:46:45","modified_gmt":"2023-02-16T12:46:45","slug":"functional-safety-iso-26262-asil-i-metryki","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/functional-safety-iso-26262-asil-i-metryki\/","title":{"rendered":"Functional Safety ISO 26262 \u2013 ASIL i metryki"},"content":{"rendered":"\n

Wed\u0142ug WHO na \u015bwiecie rocznie w wypadkach komunikacyjnych ginie oko\u0142o 1,35 miliona ludzi. Mi\u0119dzy innymi z tego wzgl\u0119du bran\u017ca motoryzacyjna stara si\u0119 ulepsza\u0107 i wprowadza\u0107 nowe rozwi\u0105zania system\u00f3w bezpiecze\u0144stwa. Pocz\u0105wszy od pas\u00f3w czy poduszek powietrznych, a\u017c po zaawansowanych asystent\u00f3w wspomagania kierowcy (ADAS). Systemy takie mog\u0105 przewidywa\u0107 i zapobiega\u0107 zdarzeniom drogowym, wp\u0142ywaj\u0105c znacznie na nasze bezpiecze\u0144stwo na drogach.<\/p>\n\n\n\n

Funkcje te s\u0105 realizowane przez skomplikowane i wyrafinowane systemy elektro-mechatroniczne. Aby umo\u017cliwi\u0107 projektowanie i ocen\u0119 takich system\u00f3w, mog\u0105cych zapobiega\u0107 lub kontrolowa\u0107 wyst\u0119puj\u0105ce niebezpieczne sytuacje, zosta\u0142 opracowany standard bezpiecze\u0144stwa funkcjonalnego ISO 26262.<\/p>\n\n\n\n

Normy ISO<\/strong><\/h2>\n\n\n\n

Normy ISO s\u0105 dokumentami opracowywanymi przez niezale\u017cnych ekspert\u00f3w w danej dziedzinie i zawieraj\u0105 informacje, wskaz\u00f3wki oraz zbiory dobrych praktyk pozwalaj\u0105ce regulowa\u0107 i ujednolica\u0107 funkcjonowanie firm na r\u00f3\u017cnych p\u0142aszczyznach. Wdro\u017cenie norm w firmie pozwala nie tylko zwi\u0119kszy\u0107 efektywno\u015b\u0107 i organizacj\u0119 pracy. Poprawia te\u017c globaln\u0105 komunikacj\u0119 handlow\u0105 i zwi\u0119ksza presti\u017c przedsi\u0119biorstwa. <\/p>\n\n\n\n

Przybli\u017cony w artykule standard opisuje proces projektowania, rozwoju oraz produkcji komponent\u00f3w pojazd\u00f3w. Post\u0119powanie zgodne z wytycznymi normy pozwala na eliminowanie ryzyka i zagro\u017ce\u0144 bezpiecze\u0144stwa, dlatego coraz wi\u0119cej producent\u00f3w pojazd\u00f3w wymaga od dostawc\u00f3w certyfikacji komponent\u00f3w zgodnie ze standardem ISO 26262.<\/p>\n\n\n\n

Przegl\u0105d struktury standardu ISO 26262<\/strong><\/h2>\n\n\n\n

Patrz\u0105c na wersj\u0119 ISO 26262:2018, dokument jest podzielony na 12 cz\u0119\u015bci z czego wi\u0119kszo\u015b\u0107 dotyczy obszar\u00f3w zarz\u0105dzania projektem, poszczeg\u00f3lnych faz rozwoju produktu, produkcji i eksploatacji oraz wsparcia proces\u00f3w. Wdra\u017canie tych proces\u00f3w normy wpisuje si\u0119 w wi\u0119kszo\u015b\u0107 system\u00f3w zarz\u0105dzania w organizacjach takich jak Waterfall <\/em>czy Agile<\/em>. Ponadto, jest kompatybilny z V-modelami do wytwarzania system\u00f3w in\u017cynieryjnych (nie tylko oprogramowania) takimi jak SPICE czy CMMI.<\/p>\n\n\n\n

\"Podzia\u0142
Ryc. 1 Podzia\u0142 dokumentu ISO 26262:2018<\/a><\/figcaption><\/figure><\/div>\n\n\n\n

Proces opiera si\u0119 na prawid\u0142owym definiowaniu wymaga\u0144 bezpiecze\u0144stwa dotycz\u0105cych wytwarzanego produktu oraz prawid\u0142owym zarz\u0105dzaniu nimi w czasie ich implementacji oraz weryfikacji. Wa\u017cnym aspektem jest te\u017c analiza pod wzgl\u0119dem bezpiecze\u0144stwa i wiarygodno\u015bci u\u017cywanych w czasie powstawania wyrobu narz\u0119dzi. Projektowany system, aby by\u0142 bezpieczny musi mie\u0107 wbudowane mechanizmy diagnostyki wraz z procedurami post\u0119powania w razie detekcji b\u0142\u0119d\u00f3w.<\/p>\n\n\n\n

Safety Management<\/strong><\/h2>\n\n\n\n

Czytaj\u0105c kolejne rozdzia\u0142y standardu, po lekturze rozdzia\u0142u I (wyja\u015bnia s\u0142ownictwo u\u017cywane w kolejnych cz\u0119\u015bciach normy) w II rozdziale czekaj\u0105 na nas informacje dotycz\u0105ce procesu zarz\u0105dzania projektem functional safety. <\/em>W takim projekcie nale\u017cy post\u0119powa\u0107 wed\u0142ug \u015bci\u015ble okre\u015blonych zasad.<\/p>\n\n\n\n

  1. Musz\u0105 by\u0107 zdefiniowane i wdro\u017cone procedury rozwoju projektu.<\/li>
  2. Musi zosta\u0107 mianowany wyszkolony Safety Manager <\/em>odpowiadaj\u0105cy za planowanie i kontrolowanie dzia\u0142a\u0144 zwi\u0105zanych z bezpiecze\u0144stwem.<\/li>
  3. Nale\u017cy te\u017c zdefiniowa\u0107 \u201esafety cases<\/em>\u201d, kt\u00f3re zawieraj\u0105 dowody na bezpiecze\u0144stwo powstaj\u0105cego systemu. Zadanie to musi zosta\u0107 wykonane bardzo dok\u0142adnie i powinni by\u0107 wyznaczeni niezale\u017cni, krytyczni recenzenci, kt\u00f3rzy to potwierdz\u0105. Jest to obowi\u0105zkowa procedura, dzi\u0119ki kt\u00f3rej mo\u017cna zminimalizowa\u0107 ryzyko b\u0142\u0119dnej interpretacji lub oszustw.<\/li><\/ol>\n\n\n\n

    Faza koncepcyjna<\/strong><\/h2>\n\n\n\n

    Opisane w rozdziale III wytyczne wskazuj\u0105, \u017ce rozw\u00f3j projektu zaczyna si\u0119 od zdefiniowania zakresu, kt\u00f3ry (zgodnie z rozdzia\u0142em I) w ISO 26262 nazywa si\u0119 \u201eitem<\/em>\u201d. W skr\u00f3cie jest to zdefiniowanie systemu, implementuj\u0105cego pewny zakres funkcjonalno\u015bci (np.: system sterowania silnikiem jest cz\u0119\u015bci\u0105 funkcjonalno\u015bci uk\u0142adu nap\u0119dowego pojazdu).<\/p>\n\n\n\n

    Analiza HARA<\/strong><\/h3>\n\n\n\n

    Nast\u0119pnie przechodzimy do analizy HARA (Hazard Analysis and Risk Assessment)<\/em>, kt\u00f3ra ocenia ryzyka dla ludzkiego \u017cycia, je\u015bli system (item<\/em>) b\u0119dzie wadliwy. Bazuj\u0105c na ryzyku, wyznacza si\u0119 \u201esafety goals<\/em>\u201d dla systemu, kt\u00f3re s\u0105 wymaganiami bezpiecze\u0144stwa funkcjonalnego.<\/p>\n\n\n\n

    Identyfikacja poziomu ASIL<\/strong><\/h2>\n\n\n\n

    Kolejnym z krok\u00f3w, jaki wymaga standard, jest identyfikacja poziomu ASIL (Automotive Safety Integrity Level<\/em>) dla zdefiniowanych uprzednio w procesie wymaga\u0144 bezpiecze\u0144stwa. Jest on powi\u0105zany z ryzykiem oraz niepo\u017c\u0105danymi zdarzeniami, jakie mog\u0105 wyst\u0105pi\u0107 i zagrozi\u0107 u\u017cytkownikom.<\/p>\n\n\n\n

    Wymagania mog\u0105 zosta\u0107 skalsyfikowane w 5 klasach (QM lub ASIL A do ASIL D), kt\u00f3re determinuj\u0105 zakres metod analiz i weryfikacji (A \u2013 poziom niski, za\u015b D \u2013 najwy\u017cszy).<\/p>\n\n\n\n

    Poni\u017cej przedstawiono tabel\u0119 ryzyka dla ASIL. Przechodz\u0105c przez ni\u0105 od lewej, estymujemy parametry S, nast\u0119pnie E i kolejno C. Na ko\u0144cu mamy rezultat oceny ryzyka QM lub odpowiedni ASIL. QM jest skr\u00f3tem od Quality Managed, <\/em>co oznacza, \u017ce projekt powinien by\u0107 prowadzony zgodnie ze standardami metodologii rozwoju takimi jak ASPICE czy CMM (Capability Maturity Model<\/em>).<\/p>\n\n\n\n

    \"Tabela<\/a>
    Tab. 1 Tabela oceny ryzyka ASIL<\/figcaption><\/figure><\/div>\n\n\n\n
    S1 do S3<\/td>Severity <\/em>(dotkliwo\u015b\u0107 zdarzenia spowodowanego przez badane urz\u0105dzenie na zdrowie)
    S1: lekkie i umiarkowane uszkodzenia,
    S2: dotkliwe i mog\u0105ce zagra\u017ca\u0107 \u017cyciu uszkodzenia (lekkie),
    S3: zagra\u017caj\u0105ce \u017cyciu w du\u017cym stopniu oraz \u015bmiertelne obra\u017cenia.<\/td><\/tr>
    E1 do E4<\/td>Exposure<\/em> (prawdopodobie\u0144stwo wyst\u0105pienia)
    E1: bardzo ma\u0142e,
    E2: ma\u0142e,
    E3: \u015brednie,
    E4: wysokie.<\/td><\/tr>
    C1 do C3<\/td>Controllability<\/em> (mo\u017cliwo\u015b\u0107 unikni\u0119cia zdarzenia poprzez kontrol\u0119 kierowcy)
    C1: \u0142atwa kontrola,
    C1: normalna kontrola,
    C3: trudna kontrola lub brak kontroli.<\/td><\/tr>
    QM A, B, C, D<\/td>Quality Management<\/em> ASIL A, B, C, D<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    Przyk\u0142ad oceny parametr\u00f3w ASIL<\/strong><\/h2>\n\n\n\n

    Analizuj\u0105c poszczeg\u00f3lne parametry, od wp\u0142ywu zdarze\u0144 wywo\u0142anych przez urz\u0105dzenie na zdrowie poprzez prawdopodobie\u0144stwo wyst\u0105pienia, w ko\u0144cu mo\u017cliwo\u015b\u0107 kontroli przez u\u017cytkownika, mo\u017cna oceni\u0107 g\u0142\u00f3wny parametr ASIL.<\/p>\n\n\n\n

    Przyk\u0142adowo elektryczne sterowana kierownica lub autopilot maj\u0105 w razie awarii wysokie prawdopodobie\u0144stwo spowodowania \u015bmiertelnego wypadku i reakcja kierowcy mo\u017ce nie wystarczy\u0107, aby zapobiec niebezpiecznemu zdarzeniu w trakcie wyst\u0105pienia b\u0142\u0119du. Obydwa systemy b\u0119d\u0105 mia\u0142y ocen\u0119 ASIL D. Natomiast funkcjonalno\u015b\u0107 czujnika przeszkody podno\u015bnika szyb b\u0119dzie sklasyfikowana najprawdopodobniej jako QM. Ryzyko uszkodzenia cia\u0142a w czasie wyst\u0105pienia b\u0142\u0119du jest niewielkie (ju\u017c sama moc silnik\u00f3w podno\u015bnika jest niewystarczaj\u0105ca, aby zrobi\u0107 krzywd\u0119). U\u017cytkownik te\u017c mo\u017ce w ka\u017cdej chwili zatrzyma\u0107 zamykanie, wi\u0119c kontrola jest do\u015b\u0107 \u0142atwa.<\/p>\n\n\n\n

    Dekompozycja<\/strong><\/h2>\n\n\n\n

    Zdarza si\u0119, \u017ce system oceniony na pewnym poziomie mo\u017ce zosta\u0107 przeprojektowany tak, aby sk\u0142ada\u0142 si\u0119 z kilku podsystem\u00f3w ocenionych na ni\u017cszym poziomie. Takie przedefiniowanie w normie nazywamy dekompozycj\u0105.<\/p>\n\n\n\n

    Dekomponuj\u0105c, pr\u00f3bujemy roz\u0142o\u017cy\u0107 system lub funkcjonalno\u015b\u0107 na kilka podsystem\u00f3w i ka\u017cdemu z nich na nowo przypisa\u0107 inny poziom, oceniaj\u0105c jeszcze raz ryzyko dla niego. Ide\u0105 takiego post\u0119powania jest obni\u017cenie oceny, co powoduje zmniejszenie nak\u0142adu pracy.<\/p>\n\n\n\n

    Mo\u017ce te\u017c si\u0119 okaza\u0107, \u017ce wszystkie powsta\u0142e w dekompozycji systemy b\u0119d\u0105 mia\u0142y ni\u017cszy poziom ASIL. Na przyk\u0142ad kiedy b\u0142\u0105d zdefiniowanej funkcji bezpiecze\u0144stwa, przez kt\u00f3r\u0105 osi\u0105gni\u0119to wysoki poziom ASIL, mo\u017ce wyst\u0105pi\u0107 tylko, je\u015bli pewne dwie funkcje powsta\u0142e przez podzia\u0142 wymaga\u0144 b\u0119d\u0105 mia\u0142y b\u0142\u0105d jednocze\u015bnie. Wtedy ka\u017cdy z tych modu\u0142\u00f3w mo\u017ce mie\u0107 ni\u017cszy poziom ASIL.<\/p>\n\n\n\n

    Cz\u0119sto tak\u0105 dekompozycj\u0119 stosuje si\u0119 poprzez zastosowanie kilku system\u00f3w, kt\u00f3rych funkcje si\u0119 chocia\u017c cz\u0119\u015bciowo pokrywaj\u0105 (redundantne systemy).<\/p>\n\n\n\n

    \"\"
    Ryc. 2 Przyk\u0142ad dekompozycji<\/a><\/figcaption><\/figure>\n\n\n\n

    Przyk\u0142ady dekompozycji<\/strong><\/h2>\n\n\n\n

    Przyk\u0142adem mo\u017ce by\u0107 funkcjonalno\u015b\u0107 przednich \u015bwiate\u0142 samochodu, kt\u00f3re maj\u0105 ocen\u0119 ASIL B. Dekomponuj\u0105c j\u0105 na par\u0119 r\u00f3wnowa\u017cnych, niezale\u017cnych \u015bwiate\u0142 (prawe i lewe), otrzymujemy dwie funkcje o ocenie ryzyka ASIL A. Dzi\u0119ki temu awaria w nocy jednego ze \u015bwiate\u0142 nie powoduje utraty widoczno\u015bci, gdy\u017c mamy jeszcze drugie dzia\u0142aj\u0105ce. Zmniejszy\u0142o si\u0119 zagro\u017cenie bezpiecze\u0144stwa.<\/p>\n\n\n\n

    Inn\u0105 ilustracj\u0105 dekompozycji mo\u017ce by\u0107 u\u017cycie biblioteki sterownik\u00f3w port\u00f3w stworzonych w ASIL B do implementacji komponentu ASIL D. W takiej sytuacji u\u017cywa si\u0119 dw\u00f3ch niezale\u017cnych port\u00f3w i przetwarza si\u0119 sygna\u0142, u\u017cywaj\u0105c r\u00f3\u017cnych algorytm\u00f3w. Na koniec wyniki s\u0105 por\u00f3wnywane w systemie na poziomie ASIL D dla pewno\u015bci, \u017ce sterowniki dzia\u0142aj\u0105 poprawnie.<\/p>\n\n\n\n

    Rekomendowane kroki dzia\u0142a\u0144 dla poszczeg\u00f3lnych poziom\u00f3w ASIL<\/strong><\/h2>\n\n\n\n

    Zdefiniowanie poziomu ASIL jest kluczowe ze wzgl\u0119du na wymagania procesowe stawiane w zale\u017cno\u015bci od oceny. Jest wiele analiz i produkt\u00f3w pracy, kt\u00f3re nale\u017cy wytworzy\u0107, a tak\u017ce potwierdzi\u0107 wykonanie odpowiednimi recenzjami (review<\/em>). W wyniku analizy i klasyfikacji ASIL, norma nak\u0142ada obowi\u0105zki, co do szczeg\u00f3\u0142owo\u015bci dokumentacji, architektury, test\u00f3w czy recenzji przy wytwarzaniu.<\/p>\n\n\n\n

    Poni\u017cej przedstawiono tabele pokazuj\u0105ce rekomendowane kroki dzia\u0142a\u0144 dla poszczeg\u00f3lnych poziom\u00f3w.<\/p>\n\n\n\n

    Oznaczenia w tabelach:<\/p>\n\n\n\n

    \u201e++\u201d \u2013 wymagane
    \u201e+\u201d \u2013 rekomendowane
    \u201eo\u201d \u2013 bez rekomendacji<\/p>\n\n\n\n

    \"Metody<\/a>
    Tab. 2 Metody do weryfikacji wymaga\u0144<\/figcaption><\/figure><\/div>\n\n\n\n
    \"Tematy<\/a>
    Tab. 3 Tematy do pokrycia przy modelowaniu i wytycznych kodowania<\/figcaption><\/figure><\/div>\n\n\n\n
    \"\"<\/a>
    Tab. 4 Zasady projektowania architektury<\/figcaption><\/figure><\/div>\n\n\n\n

    Recenzja<\/strong><\/h2>\n\n\n\n

    Kolejnym wa\u017cnym elementem jest spos\u00f3b przeprowadzania recenzji dla poszczeg\u00f3lnych produkt\u00f3w pracy wymaganych w czasie rozwoju projektu. S\u0105 cztery poziomy niezale\u017cno\u015bci przeprowadzania recenzji opisane w tabeli poni\u017cej.<\/p>\n\n\n\n

    \"\"
    Tab. 5 Opis poziom\u00f3w niezale\u017cno\u015bci recenzji<\/figcaption><\/figure>\n\n\n\n

    Tabela poni\u017cej przedstawia kilka dzia\u0142a\u0144, jakie podj\u0105\u0107 musz\u0105 in\u017cynierowie wraz z poziomami recenzji.<\/p>\n\n\n\n

    \"\"
    Tab. 6 Produkty pracy i poziomy niezale\u017cno\u015bci recenzji dla kolejnych poziom\u00f3w ASIL<\/figcaption><\/figure>\n\n\n\n

    Nak\u0142ady pracy zale\u017cne od poziomu ASIL<\/strong><\/h2>\n\n\n\n

    Jak wida\u0107 powy\u017cej, jest wiele dzia\u0142a\u0144, jakie s\u0105 obowi\u0105zkowe przy pracy w projekcie zgodnym z norm\u0105 bezpiecze\u0144stwa funkcjonalnego. Nak\u0142ad pracy przy projekcie dla wy\u017cszych poziom\u00f3w ro\u015bnie ekspotencjalnie. Je\u015bli przyj\u0105\u0107, \u017ce na sam system funkcjonalny potrzebny nak\u0142ad to 1, dla kolejnych poziom\u00f3w ASIL szacuje si\u0119 warto\u015bci czasu pracy:<\/p>\n\n\n\n