Przemys\u0142 lotniczy od dawna przyjmuje normy, kt\u00f3re obejmuj\u0105 planowanie bezpiecze\u0144stwa i opracowywanie specyficznych proces\u00f3w. Wraz z przyj\u0119ciem normy DO-178 w latach 80-tych, procesy te odpowiadaj\u0105 za rozw\u00f3j oprogramowania zwi\u0105zanego z bezpiecze\u0144stwem. Przemys\u0142 motoryzacyjny dopiero od roku 2012 zacz\u0105\u0142 przyjmowa\u0107 standard ISO26262 jako system rozwoju oparty na bezpiecze\u0144stwie. Standard definiuje projektowanie w oparciu o bezpiecze\u0144stwo w procesie tworzenia oprogramowania dla pojazd\u00f3w produkowanych na du\u017c\u0105 skal\u0119.<\/p>\n\n\n\n
Wykorzystanie oprogramowania w transporcie samochodowym w ci\u0105gu ostatnich trzydziestu lat ukaza\u0142o potrzeb\u0119 standaryzacji proces\u00f3w zorientowanych na bezpiecze\u0144stwo. Systemy staj\u0105 si\u0119 coraz bardziej z\u0142o\u017cone, z milionami linii kodu i znajduj\u0105 coraz cz\u0119\u015bciej zastosowanie w autonomicznych systemach transportowych. Bardzo z\u0142o\u017cone oprogramowanie i systemy elektroniczne stosowane w transporcie, czy to lotniczym, cywilnym czy wojskowym, maj\u0105 bezpo\u015bredni wp\u0142yw na bezpiecze\u0144stwo.<\/p>\n\n\n\n
Zauwa\u017ca si\u0119 du\u017ce zainteresowanie potencjalnymi korzy\u015bciami, jakie niesie ze sob\u0105 technologia zautomatyzowanych pojazd\u00f3w w zastosowaniach zar\u00f3wno komercyjnych jak i wojskowych. Poniewa\u017c zautomatyzowane systemy pojazd\u00f3w przenosz\u0105 bezpo\u015brednio odpowiedzialno\u015b\u0107 z kierowcy na oprogramowanie, systemy te musz\u0105 by\u0107 zaprojektowane od podstaw jako systemy krytyczne dla bezpiecze\u0144stwa, o wystarczaj\u0105cym poziomie nadmiarowo\u015bci i odporno\u015bci na uszkodzenia. Przyj\u0119cie tych norm zar\u00f3wno do za\u0142ogowych, jak i bezza\u0142ogowych system\u00f3w pojazd\u00f3w naziemnych ma na celu zastosowanie dobrych praktyki rozwojowych, skutkuj\u0105cych popraw\u0105 bezpiecze\u0144stwa i minimalizacji ryzyka.<\/p>\n\n\n\n
Przegl\u0105d standard\u00f3w wykorzystywanych w lotnictwie i pojazdach naziemnych<\/strong><\/h2>\n\n\n\nDO-178<\/strong><\/h3>\n\n\n\nPrzemys\u0142 lotniczy wykorzystuje norm\u0119 DO-178 w procesach rozwoju oprogramowania od 30 lat. Wprowadzono kilka aktualizacji tych standard\u00f3w, z kt\u00f3rych ostatni\u0105 jest DO-178C wydana w 2011 roku przez Radiotechniczn\u0105 Komisj\u0119 ds. Lotnictwa \u2013 RTCA (ang. Radio Technical Commission for Aeronautics<\/em>).<\/p>\n\n\n\nNorma ta zapewnia ramy i wytyczne dotycz\u0105ce zar\u00f3wno opracowywania procesu tworzenia oprogramowania, jak i integracji identyfikowalno\u015bci opartej na wymaganiach i zarz\u0105dzania w jego ramach.<\/p>\n\n\n\n
Wytyczne dotycz\u0105ce procesu rozwoju DO-178, kt\u00f3re u\u017cywane s\u0105 jako cz\u0119\u015b\u0107 normalnego cyklu rozwoju oprogramowania, sk\u0142adaj\u0105 si\u0119 z nast\u0119puj\u0105cych krok\u00f3w:<\/p>\n\n\n\n
- Ocena wp\u0142ywu systemu na oprogramowanie.<\/li>
- Proces planowania oprogramowania \u2013 SW (ang. Softwa<\/em>re),<\/li>
- Wytyczne dotycz\u0105ce projektowania i kodowania oprogramowania komputerowego.<\/li>
- Proces wymaga\u0144 oprogramowania.<\/li>
- Architektura i projektowanie oprogramowania.<\/li>
- Integracja i rozw\u00f3j oprogramowania.<\/li>
- Weryfikacja jednostki SW.<\/li>
- Weryfikacja integracji oprogramowania.<\/li>
- Artefakty SW i ich przegl\u0105d.<\/li><\/ul>\n\n\n\n
W wyniku tych krok\u00f3w powstaj\u0105 artefakty, kt\u00f3re mo\u017cna nast\u0119pnie wykorzysta\u0107 jako cz\u0119\u015b\u0107 procesu certyfikacji oprogramowania dla cz\u0119\u015bci wi\u0119kszego systemu.<\/p>\n\n\n\n
ISO26262<\/strong><\/h3>\n\n\n\nNorma ISO26262 zosta\u0142a wydana w 2012 roku i jest przeznaczona do wielkoseryjnej produkcji samochod\u00f3w o maksymalnej masie ca\u0142kowitej do 3,5t. Wywodzi si\u0119 z normy IEC61508, kt\u00f3ra jest szersz\u0105 norm\u0105 bezpiecze\u0144stwa przemys\u0142owego. Norma ISO26262 ma koncentrowa\u0107 si\u0119 na pojazdach wyposa\u017conych w uk\u0142ady elektroniczne, kt\u00f3re mog\u0105 wp\u0142ywa\u0107 bezpo\u015brednio na bezpiecze\u0144stwo pojazdu.<\/p>\n\n\n\n
Sk\u0142ada si\u0119 z kilku cz\u0119\u015bci, kt\u00f3re obejmuj\u0105:<\/p>\n\n\n\n
- koncepcj\u0119 bezpiecze\u0144stwa,<\/li>
- bezpiecze\u0144stwo systemu,<\/li>
- rozw\u00f3j sprz\u0119tu i oprogramowania dla bezpiecze\u0144stwa,<\/li><\/ul>\n\n\n\n
a tak\u017ce<\/p>\n\n\n\n
- weryfikacj\u0119 wymaga\u0144 i bezpiecze\u0144stwa na wszystkich tych poziomach.<\/li><\/ul>\n\n\n\n
Specyficzne standardy oprogramowania i ich g\u0142\u00f3wny nacisk znajduj\u0105 si\u0119 w cz\u0119\u015bci ISO26262-6.<\/p>\n\n\n\n
Wytyczne dotycz\u0105ce rozwoju procesu ISO26262 s\u0105 bardziej szczeg\u00f3\u0142owym zestawem procedur rozwojowych ni\u017c w przypadku normy DO-178. Procedury te s\u0105 zgodne z poni\u017cszym cyklem rozwoju, maj\u0105 przebiega\u0107 r\u00f3wnolegle i s\u0105 zintegrowane ze standardowym cyklem tworzenia oprogramowania. Pierwszy wymieniony element pochodzi z element\u00f3w systemu zdefiniowanych w sekcji 4 normy ISO26262.<\/p>\n\n\n\n
- Wp\u0142yw systemu na oprogramowanie (sekcja 4).<\/li>
- Wymagania dotycz\u0105ce oprogramowania i cele bezpiecze\u0144stwa.<\/li>
- Architektura jednostki oprogramowania.<\/li>
- Szczeg\u00f3\u0142owy projekt jednostki i analiza.<\/li>
- Kodowanie oprogramowania jednostkowego.<\/li>
- Testowanie i weryfikacja jednostkowa.<\/li>
- Integracja i testowanie.<\/li>
- Weryfikacja wymaga\u0144 bezpiecze\u0144stwa i zada\u0144.<\/li><\/ul>\n\n\n\n
Por\u00f3wnanie norm: DO-178 i ISO26262<\/strong><\/h2>\n\n\n\n![\"Graf](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2022\/10\/Ryc.-1.png\")
<\/a>Ryc. 1. Graf procesu projektowania dla normy DO178 i normy ISO26262<\/figcaption><\/figure><\/div>\n\n\n\nJak pokazano w dotychczasowym por\u00f3wnaniu i na Ryc. 1, te dwa standardy maj\u0105 podobny przebieg procesu, kt\u00f3ry mo\u017cna ze sob\u0105 powi\u0105za\u0107. Ka\u017cdy ze standard\u00f3w r\u00f3\u017cni si\u0119 terminologi\u0105 i rezultatami, a jednocze\u015bnie jest zgodny z t\u0105 sam\u0105 metodologi\u0105 i procesami<\/strong>, kt\u00f3re mo\u017cna wykorzysta\u0107 w opracowywaniu oprogramowania pojazdu z perspektywy bezpiecze\u0144stwa, zar\u00f3wno w przypadku system\u00f3w sterowanych przez operatora, jak i system\u00f3w pojazd\u00f3w autonomicznych.<\/p>\n\n\n\nJednak przy stosowaniu zar\u00f3wno normy DO-178, jak i normy ISO26262 w odniesieniu do wi\u0119kszych i autonomicznych pojazd\u00f3w naziemnych, nale\u017cy w obu przypadkach bra\u0107 pod uwag\u0119 dodatkowe ryzyko i wp\u0142yw system\u00f3w niekontrolowanych przez operatora, a tak\u017ce wi\u0119kszych i bardziej skomplikowanych system\u00f3w, kt\u00f3re stanowi\u0105 dodatkowe zagro\u017cenie dla bezpiecze\u0144stwa. <\/p>\n\n\n\n
Metodologia norm zorientowana na bezpiecze\u0144stwo ma zastosowanie do wszystkich system\u00f3w, poniewa\u017c s\u0105 one podobne, jednak szczeg\u00f3\u0142y dla ka\u017cdego konkretnego przypadku bezpiecze\u0144stwa musz\u0105 by\u0107 ocenione w odniesieniu do konkretnego systemu transportowego i \u015brodowiska.<\/p>\n\n\n\n
Adaptacja funkcji bezpiecze\u0144stwa oprogramowania w lotnictwie do proces\u00f3w motoryzacyjnych<\/strong><\/h2>\n\n\n\nRozwini\u0119ta kultura wykorzystywania przez dziesi\u0119ciolecia proces\u00f3w rozwoju bezpiecze\u0144stwa oprogramowania w lotnictwie stanowi mocne podstawy zastosowania ich w rozwoju oprogramowania do pojazd\u00f3w naziemnych. Wyci\u0105gni\u0119te wnioski, rozw\u00f3j cyklu \u017cycia bezpiecze\u0144stwa oprogramowania i metody weryfikacji okaza\u0142y si\u0119 skuteczne w zmniejszaniu ryzyka w przemy\u015ble lotniczym<\/strong>. Do\u015bwiadczenie te mo\u017cna z \u0142atwo\u015bci\u0105 przenie\u015b\u0107 na systemy motoryzacyjne i autonomiczne, kt\u00f3re przechodz\u0105 na platformy sterowania oparte g\u0142\u00f3wnie na elektronice i oprogramowaniu.<\/p>\n\n\n\nPlanowanie oprogramowania<\/strong><\/h3>\n\n\n\nPocz\u0105tkow\u0105 cz\u0119\u015bci\u0105 procesu tworzenia oprogramowania DO-178 jest rzeczywiste planowanie samego procesu. Szczeg\u00f3\u0142owy opis rzeczywistego cyklu rozwoju oprogramowania musi obejmowa\u0107 pe\u0142ny cykl \u017cycia oprogramowania, zdefiniowanie relacji mi\u0119dzy procesami projektowania i mechanizmami informacji zwrotnej, \u015brodowiskiem tworzenia oprogramowania i standardami rozwoju.<\/p>\n\n\n\n
Projektowanie tych plan\u00f3w rozwoju dla rozwoju oprogramowania prowadzi do powstania artefakt\u00f3w, kt\u00f3re s\u0105 u\u017cywane przez ca\u0142y cykl rozwoju i aktualizowane na ka\u017cdym etapie. Definicja tych standard\u00f3w i proces\u00f3w wdro\u017cy\u0142a infrastruktur\u0119 dla systemu bezpiecze\u0144stwa, kt\u00f3ry ma by\u0107 zarz\u0105dzany i przestrzegany. Do wst\u0119pnych artefakt\u00f3w nale\u017c\u0105:<\/p>\n\n\n\n
- Plan aspekt\u00f3w oprogramowania certyfikacji.<\/li>
- Plan rozwoju oprogramowania.<\/li>
- Plan weryfikacji oprogramowania.<\/li>
- Plan zarz\u0105dzania konfiguracj\u0105 oprogramowania.<\/li>
- Plan kontroli jako\u015bci oprogramowania.<\/li>
- Standardy wymaga\u0144 oprogramowania.<\/li>
- Standardy projektowania oprogramowania.<\/li>
- Standardy kodu oprogramowania.<\/li><\/ol>\n\n\n\n
Norma ISO26262-6 jest zgodna z metodologi\u0105 lotnicz\u0105, ale ma bardziej zdefiniowany cykl tworzenia oprogramowania<\/strong>. Wiele pozycji, w tym pozycje 3-8 z powy\u017cszej listy, maj\u0105 zastosowanie do normy motoryzacyjnej, aby spe\u0142ni\u0107 niezb\u0119dne schematy bezpiecze\u0144stwa konkretnego opracowywanego produktu.<\/p>\n\n\n\nISO26262-6 ma wst\u0119pnie bardziej zdefiniowany plan samego rozwoju oprogramowania w por\u00f3wnaniu do DO-178. Podej\u015bcie rozwojowe zaczyna od ko\u0144ca wymaga\u0144 z poziomu systemu i przechodzi kaskadowo w d\u00f3\u0142 przez projekt, podczas gdy stron\u0105 powrotn\u0105 jest weryfikacja i integracja do szczytu po\u0142\u0105cze\u0144 systemowych.<\/p>\n\n\n\n
Definicja bezpiecze\u0144stwa i wymaga\u0144<\/strong><\/h2>\n\n\n\nPo procesie planowania, w przypadku DO-178 i ISO26262, ju\u017c zdefiniowane wymagania systemowe sp\u0142ywaj\u0105 do definicji wymaga\u0144 dla wymaga\u0144 na poziomie oprogramowania.<\/p>\n\n\n\n
Dla DO-178 wymagania systemowe pochodz\u0105 ze \u017ar\u00f3de\u0142 spoza procesu rozwoju DO-178. Rzeczywiste wymagania musz\u0105 zosta\u0107 ocenione pod k\u0105tem sp\u00f3jno\u015bci, informacji zwrotnych do systemu wy\u017cszego poziomu, identyfikowalno\u015bci i zdolno\u015bci do weryfikacji pe\u0142nej funkcjonalno\u015bci i bezpiecze\u0144stwa. Poszczeg\u00f3lne wymagania musz\u0105 r\u00f3wnie\u017c uwzgl\u0119dnia\u0107 niezb\u0119dne aspekty bezpiecze\u0144stwa, kt\u00f3re zosta\u0142y zdefiniowane na poziomie systemu. Nale\u017cy przeanalizowa\u0107 wp\u0142yw ka\u017cdego wymagania na bezpiecze\u0144stwo systemu, podobnie jak ich wp\u0142yw na inne wymagania. Ocen\u0119 DO-178 klasyfikacji bezpiecze\u0144stwa lub zagro\u017cenia przeprowadza si\u0119 na etapie wymaga\u0144.
W ramach normy ISO26262 wymagania bezpiecze\u0144stwa s\u0105 kaskadowane od sekcji 3, w kt\u00f3rej zdefiniowana jest koncepcja bezpiecze\u0144stwa, i sekcji 4, w kt\u00f3rej zdefiniowano system i podzielono go na sprz\u0119t i oprogramowanie. Wynikiem obu standard\u00f3w jest dokumentacja wymaga\u0144, a tak\u017ce aktualizacje wszelkich plan\u00f3w oprogramowania i plany weryfikacji opracowane w ramach pierwotnego planowania oprogramowania.<\/p>\n\n\n\n
Kaskadowanie wymaga\u0144 systemowych i planu oprogramowania na wymagania funkcjonalne i bezpiecze\u0144stwa ni\u017cszego poziomu jest kluczowym elementem ka\u017cdego cyklu projektowego dla zintegrowanego oprogramowania i bezpiecze\u0144stwa.<\/p>\n\n\n\n
Wraz z rozwojem autonomicznych i coraz szybszych pojazd\u00f3w naziemnych kluczowe znaczenie ma uwzgl\u0119dnienie etap\u00f3w w procesach takich jak te oraz pe\u0142na weryfikacja nowych potencjalnych zagro\u017ce\u0144 z ca\u0142kowitym uzale\u017cnieniem od system\u00f3w elektronicznych, pojazd\u00f3w, kt\u00f3re stanowi\u0105 wi\u0119ksze zagro\u017cenie dla bezpiecze\u0144stwa w okre\u015blonych sytuacjach, oraz z\u0142o\u017cono\u015b\u0107 integracji z systemami zewn\u0119trznymi, kt\u00f3re mog\u0105 wp\u0142ywa\u0107 na sterowanie pojazdem.<\/p>\n\n\n\n
Klasyfikacja zagro\u017ce\u0144<\/strong><\/h2>\n\n\n\nPodczas definiowania klasyfikacji zagro\u017ce\u0144, u\u017cywanej w fazie wymaga\u0144, istniej\u0105 r\u00f3\u017cne poziomy krytyczno\u015bci bezpiecze\u0144stwa, kt\u00f3re wp\u0142ywaj\u0105 na spos\u00f3b projektowania, diagnozowania i weryfikacji oprogramowania.<\/p>\n\n\n\n
Tabela 1 wyszczeg\u00f3lnia te r\u00f3\u017cnice, poniewa\u017c poziomy klasyfikacji s\u0105 odwr\u00f3cone w zale\u017cno\u015bci od normy. Oceny wp\u0142ywaj\u0105 na wymagania, kt\u00f3re musz\u0105 by\u0107 stawiane w ka\u017cdym module oprogramowania w zakresie projektowania, wykrywania i zapobiegania b\u0142\u0119dom oraz testowania weryfikacyjnego.<\/p>\n\n\n\nWp\u0142yw na bezpiecze\u0144stwo<\/strong><\/strong><\/td>DO-178<\/strong><\/strong><\/td>ISO26262<\/strong><\/strong><\/td><\/tr>Katastrofalny<\/td> A<\/td> D<\/td><\/tr> Niebezpieczny<\/td> B<\/td> C<\/td><\/tr> Powa\u017cny<\/td> C<\/td> B<\/td><\/tr> Drobny<\/td> D<\/td> A<\/td><\/tr> Bez znaczenia<\/td> E<\/td> Zarz\u0105dzanie jako\u015bci\u0105<\/td><\/tr><\/tbody><\/table>Tab. 1 Por\u00f3wnanie wp\u0142ywu bezpiecze\u0144stwa dla normy DO-178 i ISO26262<\/figcaption><\/figure>\n\n\n\nISO26262 wprowadza koncepcj\u0119 kontroli do klasyfikacji zagro\u017ce\u0144. Obejmuje to zdolno\u015b\u0107 operatora do z\u0142agodzenia skutk\u00f3w wypadku w przypadku awarii systemu.<\/p>\n\n\n\n
Pojazdy autonomiczne dodaj\u0105 nowy wymiar ranking\u00f3w bezpiecze\u0144stwa i kategoryzacji, poniewa\u017c nie ma operatora, kt\u00f3ry zapewnia\u0142by tak\u0105 kontrol\u0119. Funkcje bezpiecze\u0144stwa, kt\u00f3re mo\u017cna wykorzysta\u0107 do interakcji operatora, aby wprowadzi\u0107 pojazd w bezpieczny stan, zosta\u0142y usuni\u0119te. Konieczne by\u0142oby opracowanie nowego systemu klasyfikacji, aby oceni\u0107 wska\u017anik awaryjno\u015bci, wp\u0142yw na \u017cycie i zdrowie oraz uszkodzenia wi\u0119kszego ekosystemu wok\u00f3\u0142 pojazdu.<\/p>\n\n\n\n
Podstawowe zasady oceny aspekt\u00f3w bezpiecze\u0144stwa nadal obowi\u0105zuj\u0105 w odniesieniu zar\u00f3wno do lotnictwa jak i motoryzacji. Co wi\u0119cej, obecne normy nie dotycz\u0105 rzekomych wielopojazdowych system\u00f3w wsp\u00f3\u0142pracuj\u0105cych, kt\u00f3re s\u0105 u\u017cywane zar\u00f3wno w przypadku system\u00f3w pojazd\u00f3w u\u017cytkowych, jak i zautomatyzowanych.<\/p>\n\n\n\n
Architektura oprogramowania, projektowanie i wdra\u017canie<\/strong><\/h2>\n\n\n\nPo spe\u0142nieniu wymaga\u0144 proces DO-178 wykorzystuje system kaskadowy do faktycznego przebiegu rozwoju oprogramowania. Proces rozpoczyna si\u0119 od architektury wysokiego poziomu opartej na wymaganiach, kt\u00f3re zosta\u0142y okre\u015blone na wcze\u015bniejszym etapie. Po opracowaniu architektury proces przechodzi do opracowania wymaga\u0144 niskiego poziomu dla ka\u017cdej jednostki architektury, kt\u00f3ra musi zosta\u0107 podzielona na mniejsze. Te mniejsze jednostki s\u0105 nast\u0119pnie oceniane pod k\u0105tem klasyfikacji zagro\u017ce\u0144 jako mniejsze jednostki w oparciu o wp\u0142yw na wi\u0119ksz\u0105 architektur\u0119. Po opracowaniu wymaga\u0144 ni\u017cszego poziomu mo\u017cna wygenerowa\u0107 kod \u017ar\u00f3d\u0142owy, kt\u00f3ry jest powi\u0105zany z tym konkretnym wymaganiem.<\/p>\n\n\n\n
ISO26262-6 opiera si\u0119 na podobnej metodologii kaskadowania wymaga\u0144 w architekturze i projekcie. Wysokie wymagania dotycz\u0105ce bezpiecze\u0144stwa s\u0105 przenoszone do projektu architektonicznego, a nast\u0119pnie do jednostki oprogramowania do rzeczywistego projektowania, implementacji, analizy i symulacji. Ka\u017cda z jednostek oprogramowania b\u0119dzie mia\u0142a w\u0142asn\u0105 ocen\u0119 bezpiecze\u0144stwa, kt\u00f3r\u0105 nale\u017cy wzi\u0105\u0107 pod uwag\u0119 podczas projektowania, dokumentacji i weryfikacji jednostki.<\/p>\n\n\n\n
Dane wyj\u015bciowe tych dw\u00f3ch standard\u00f3w to:<\/p>\n\n\n\n
- kod \u017ar\u00f3d\u0142owy,<\/li>
- szczeg\u00f3\u0142y opisu projektu,<\/li>
- problemy aplikacji zwi\u0105zane z bezpiecze\u0144stwem, kt\u00f3re nale\u017cy rozwi\u0105za\u0107,<\/li>
- wszelkie aktualizacje plan\u00f3w weryfikacji, kt\u00f3re zosta\u0142y dodane podczas projektowania.<\/li><\/ul>\n\n\n\n
Kod \u017ar\u00f3d\u0142owy nale\u017cy przejrze\u0107, aby upewni\u0107 si\u0119, \u017ce spe\u0142nia zamierzon\u0105 funkcjonalno\u015b\u0107 w zakresie wymaga\u0144.<\/p>\n\n\n\n
Weryfikacja jednostki i poziomu integracji<\/strong><\/h2>\n\n\n\nWeryfikacja jest niezb\u0119dn\u0105 cz\u0119\u015bci\u0105 procesu, kt\u00f3ra ma na celu sprawdzenie czy oprogramowanie dzia\u0142a zgodnie z przeznaczeniem. Ocena wyj\u015b\u0107 w DO-178 jest dokonywana poprzez weryfikacj\u0119 na wielu poziomach, w tym:<\/p>\n\n\n\n
- Weryfikacja czy funkcjonalno\u015b\u0107 oprogramowania spe\u0142nia wymagania systemowe.<\/li>
- Weryfikacja czy projekt i architektura oprogramowania spe\u0142niaj\u0105 wymagania i standardy oprogramowania.<\/li>
- Weryfikacja czy dane wyj\u015bciowe kodu \u017ar\u00f3d\u0142owego spe\u0142niaj\u0105 standardy i architektur\u0119.<\/li>
- Testowanie oprogramowania z wyj\u015bciami potwierdzaj\u0105cymi funkcjonalno\u015b\u0107 i bezpiecze\u0144stwo.<\/li>
- Weryfikacja wynik\u00f3w test\u00f3w ze \u015bledzeniem.<\/li><\/ul>\n\n\n\n
Kilka z tych element\u00f3w wymaga niezale\u017cno\u015bci programisty w celu przegl\u0105du i weryfikacji. Ta niezale\u017cno\u015b\u0107 pozwala na dok\u0142adn\u0105 analiz\u0119 i lepsze uwzgl\u0119dnienie potencjalnych problem\u00f3w, kt\u00f3re mo\u017cna dostrzec w wynikach.<\/p>\n\n\n\n
Rzeczywisty plan weryfikacji i analizy jest opracowywany od fazy planowania, a gdy projekt staje si\u0119 bardziej szczeg\u00f3\u0142owy, do planu dodawane s\u0105 dodatkowe elementy. Plan musi obejmowa\u0107 identyfikowalno\u015b\u0107, aby wykaza\u0107, \u017ce wszystkie wymagania i jednostki s\u0105 w pe\u0142ni przetestowane. Ilo\u015b\u0107 test\u00f3w jest doprecyzowana przez wymagania bezpiecze\u0144stwa, a tak\u017ce wymagania okre\u015blone w celu zapewnienia zaufania do oprogramowania. Testy nale\u017cy przeprowadza\u0107, zaczynaj\u0105c od poziomu jednostki, a nast\u0119pnie przechodzi\u0107 do wy\u017cszego poziomu integracji, a\u017c do przetestowania i zweryfikowania ca\u0142ego systemu.<\/p>\n\n\n\n
W przypadku normy ISO26262 procedury weryfikacji s\u0105 podobne do procedur lotniczych. Plan weryfikacji jest pisany wcze\u015bniej, a nast\u0119pnie szczeg\u00f3\u0142y s\u0105 dodawane w miar\u0119 post\u0119pu projektu. Testowanie rozpoczyna si\u0119 na poziomie jednostki. Pewne poziomy test\u00f3w s\u0105 wymagane na podstawie poziomu bezpiecze\u0144stwa i prawdopodobie\u0144stwa modeli potencjalnych awarii. Norma ta wymaga r\u00f3wnie\u017c niezale\u017cno\u015bci w pewnych obszarach do przegl\u0105du.<\/p>\n\n\n\n
Dane wyj\u015bciowe obu tych standard\u00f3w weryfikuj\u0105 raporty z test\u00f3w, dokumentuj\u0105ce stany i wyniki test\u00f3w, a tak\u017ce raporty z weryfikacji.<\/p>\n\n\n\n
Weryfikacja architektury, projekt i wdro\u017cenie na poziomie jednostki oraz integracja wy\u017cszego poziomu w celu spe\u0142nienia wymaga\u0144 bezpiecze\u0144stwa i funkcjonalno\u015bci ma kluczowe znaczenie dla lotnictwa i motoryzacji, ale nabiera nowego wymiaru w przypadku pojazd\u00f3w autonomicznych<\/strong>. Gdy system jest autonomiczny, potencjalne niewiadome interakcje zewn\u0119trzne i wewn\u0119trzne musz\u0105 zosta\u0107 dok\u0142adnie przeanalizowane i zweryfikowane, aby sprawdzi\u0107 czy uzyskano w\u0142a\u015bciwy zakres weryfikacji.<\/p>\n\n\n\nArtefakty i organy zarz\u0105dzaj\u0105ce<\/strong><\/h2>\n\n\n\nJe\u015bli przestrzegane s\u0105 w\u0142a\u015bciwie, zar\u00f3wno DO-178 jak i ISO-2626, wytworz\u0105 artefakty, kt\u00f3re mog\u0105 zosta\u0107 poddane przegl\u0105dowi przez organ zarz\u0105dzaj\u0105cy jako wi\u0119kszy przegl\u0105d certyfikacji.<\/p>\n\n\n\n
FAA (ang. Federal Aviation Association<\/em>) wymaga u\u017cycia DO-178 do tworzenia oprogramowania, ale post\u0119powanie zgodnie z procesem nie gwarantuje certyfikacji. Wykorzystywane dokumenty s\u0105 oceniane w ramach wi\u0119kszego procesu certyfikacji ca\u0142ego statku powietrznego.<\/p>\n\n\n\nW przypadku motoryzacji nie ma zewn\u0119trznych organ\u00f3w zarz\u0105dzaj\u0105cych. Producenci OEM s\u0105 odpowiedzialni za bezpiecze\u0144stwo produkowanych przez siebie system\u00f3w pojazdu.
Ryc. 2 przedstawia por\u00f3wnanie artefakt\u00f3w opracowanych na podstawie dw\u00f3ch standard\u00f3w.<\/p>\n\n\n\n
![\"Por\u00f3wnanie](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2022\/10\/Ryc.-2.png\")
<\/a>Ryc. 2 Por\u00f3wnanie artefakt\u00f3w opracowanych na podstawie dw\u00f3ch standard\u00f3w<\/figcaption><\/figure><\/div>\n\n\n\nNarz\u0119dzia wsparcia<\/strong><\/h2>\n\n\n\nW przypadku ka\u017cdego ze standard\u00f3w programistycznych wszelkie narz\u0119dzia i procesy pomocnicze, kt\u00f3re s\u0105 u\u017cywane, musz\u0105 zosta\u0107 ocenione i certyfikowane pod k\u0105tem powtarzalno\u015bci i znanych wynik\u00f3w narz\u0119dzi. Systemy zapewniania jako\u015bci, plany kwalifikacji narz\u0119dzi, zarz\u0105dzanie zmian\u0105, standardy i procesy \u0142\u0105czno\u015bci z certyfikacj\u0105 s\u0105 cz\u0119\u015bci\u0105 tego zestawu narz\u0119dzi pomocniczych. Ryc. 3 przedstawia por\u00f3wnanie mi\u0119dzy dwoma standardami.<\/p>\n\n\n\n![\"\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2022\/10\/Ryc.-3.png\")
Ryc. 3 Por\u00f3wnanie mi\u0119dzy dwoma standardami<\/figcaption><\/figure>\n\n\n\nPodsumowanie<\/strong><\/h2>\n\n\n\nZautomatyzowane pojazdy obiecuj\u0105 znaczne korzy\u015bci dzi\u0119ki usuni\u0119ciu operatora. Rezygnacja z cz\u0142owieka oznacza jednak, \u017ce bezpiecze\u0144stwo tych system\u00f3w b\u0119dzie zale\u017ce\u0107 od oprogramowania zapewniaj\u0105cego t\u0119 funkcj\u0119.<\/p>\n\n\n\n
Oprogramowanie zwi\u0105zane z bezpiecze\u0144stwem dla przysz\u0142ych system\u00f3w pojazd\u00f3w naziemnych, zar\u00f3wno cywilnych jak i wojskowych, mog\u0142oby wykorzystywa\u0107 wskazane standardy jako wytyczne dotycz\u0105ce opracowywania standard\u00f3w. Ustalenie szczeg\u00f3\u0142owych plan\u00f3w wst\u0119pnych, wymaga\u0144 zwi\u0105zanych z bezpiecze\u0144stwem, projektowanie wok\u00f3\u0142 tych wymaga\u0144 oraz proces weryfikacji maj\u0105 zastosowanie niezale\u017cnie od okre\u015blonych norm. Dobra metodologia i zaplanowany rozw\u00f3j proces\u00f3w pozwalaj\u0105 na dopracowanie solidnych system\u00f3w i oprogramowania, kt\u00f3re minimalizuj\u0105 ryzyko dla ludzi w \u015bwiecie rzeczywistym.<\/p>\n\n\n\n
Bibliografia<\/strong><\/h2>\n\n\n\n- International Standards Organization, \u201dISO26262 \u2013 Road Vehicles Functional Safety\u201d Sections 1,3,4,6, 2011 (ISO 26262:2011(E)<\/li>
- RTCA, Inc, \u201cSoftware Considerations in Airborne Systems and Equipment Certification\u201d, December 13, 2011 (RTCA DO-178C)<\/li>
- Matthias Gerlach, \u201cCan Cars Fly? From Avionics to Automotive \u2013 Comparability of Domain Specific Safety Standards\u201d, VirtualOS Embedded World, 2011.<\/li><\/ol>\n\n\n\n
***<\/p>\n\n\n\n
Je\u015bli interesuje Ci\u0119 tematyka ISO, norm i standard\u00f3w, polecamy inne artyku\u0142y naszych ekspert\u00f3w np. Functional Safety ISO 26262 \u2013 ASIL i metryki<\/a>, Introduction to Risk Management for embedded Medical Device software (IEC 62304:2006\/AMD 1:2015)<\/a> oraz Agile w procesach regulowanych<\/a>.<\/p>\n\n\n
Przemys\u0142 lotniczy wykorzystuje norm\u0119 DO-178 w procesach rozwoju oprogramowania od 30 lat. Wprowadzono kilka aktualizacji tych standard\u00f3w, z kt\u00f3rych ostatni\u0105 jest DO-178C wydana w 2011 roku przez Radiotechniczn\u0105 Komisj\u0119 ds. Lotnictwa \u2013 RTCA (ang. Radio Technical Commission for Aeronautics<\/em>).<\/p>\n\n\n\n Norma ta zapewnia ramy i wytyczne dotycz\u0105ce zar\u00f3wno opracowywania procesu tworzenia oprogramowania, jak i integracji identyfikowalno\u015bci opartej na wymaganiach i zarz\u0105dzania w jego ramach.<\/p>\n\n\n\n Wytyczne dotycz\u0105ce procesu rozwoju DO-178, kt\u00f3re u\u017cywane s\u0105 jako cz\u0119\u015b\u0107 normalnego cyklu rozwoju oprogramowania, sk\u0142adaj\u0105 si\u0119 z nast\u0119puj\u0105cych krok\u00f3w:<\/p>\n\n\n\n W wyniku tych krok\u00f3w powstaj\u0105 artefakty, kt\u00f3re mo\u017cna nast\u0119pnie wykorzysta\u0107 jako cz\u0119\u015b\u0107 procesu certyfikacji oprogramowania dla cz\u0119\u015bci wi\u0119kszego systemu.<\/p>\n\n\n\n Norma ISO26262 zosta\u0142a wydana w 2012 roku i jest przeznaczona do wielkoseryjnej produkcji samochod\u00f3w o maksymalnej masie ca\u0142kowitej do 3,5t. Wywodzi si\u0119 z normy IEC61508, kt\u00f3ra jest szersz\u0105 norm\u0105 bezpiecze\u0144stwa przemys\u0142owego. Norma ISO26262 ma koncentrowa\u0107 si\u0119 na pojazdach wyposa\u017conych w uk\u0142ady elektroniczne, kt\u00f3re mog\u0105 wp\u0142ywa\u0107 bezpo\u015brednio na bezpiecze\u0144stwo pojazdu.<\/p>\n\n\n\n Sk\u0142ada si\u0119 z kilku cz\u0119\u015bci, kt\u00f3re obejmuj\u0105:<\/p>\n\n\n\n a tak\u017ce<\/p>\n\n\n\n Specyficzne standardy oprogramowania i ich g\u0142\u00f3wny nacisk znajduj\u0105 si\u0119 w cz\u0119\u015bci ISO26262-6.<\/p>\n\n\n\n Wytyczne dotycz\u0105ce rozwoju procesu ISO26262 s\u0105 bardziej szczeg\u00f3\u0142owym zestawem procedur rozwojowych ni\u017c w przypadku normy DO-178. Procedury te s\u0105 zgodne z poni\u017cszym cyklem rozwoju, maj\u0105 przebiega\u0107 r\u00f3wnolegle i s\u0105 zintegrowane ze standardowym cyklem tworzenia oprogramowania. Pierwszy wymieniony element pochodzi z element\u00f3w systemu zdefiniowanych w sekcji 4 normy ISO26262.<\/p>\n\n\n\n Jak pokazano w dotychczasowym por\u00f3wnaniu i na Ryc. 1, te dwa standardy maj\u0105 podobny przebieg procesu, kt\u00f3ry mo\u017cna ze sob\u0105 powi\u0105za\u0107. Ka\u017cdy ze standard\u00f3w r\u00f3\u017cni si\u0119 terminologi\u0105 i rezultatami, a jednocze\u015bnie jest zgodny z t\u0105 sam\u0105 metodologi\u0105 i procesami<\/strong>, kt\u00f3re mo\u017cna wykorzysta\u0107 w opracowywaniu oprogramowania pojazdu z perspektywy bezpiecze\u0144stwa, zar\u00f3wno w przypadku system\u00f3w sterowanych przez operatora, jak i system\u00f3w pojazd\u00f3w autonomicznych.<\/p>\n\n\n\n Jednak przy stosowaniu zar\u00f3wno normy DO-178, jak i normy ISO26262 w odniesieniu do wi\u0119kszych i autonomicznych pojazd\u00f3w naziemnych, nale\u017cy w obu przypadkach bra\u0107 pod uwag\u0119 dodatkowe ryzyko i wp\u0142yw system\u00f3w niekontrolowanych przez operatora, a tak\u017ce wi\u0119kszych i bardziej skomplikowanych system\u00f3w, kt\u00f3re stanowi\u0105 dodatkowe zagro\u017cenie dla bezpiecze\u0144stwa. <\/p>\n\n\n\n Metodologia norm zorientowana na bezpiecze\u0144stwo ma zastosowanie do wszystkich system\u00f3w, poniewa\u017c s\u0105 one podobne, jednak szczeg\u00f3\u0142y dla ka\u017cdego konkretnego przypadku bezpiecze\u0144stwa musz\u0105 by\u0107 ocenione w odniesieniu do konkretnego systemu transportowego i \u015brodowiska.<\/p>\n\n\n\n Rozwini\u0119ta kultura wykorzystywania przez dziesi\u0119ciolecia proces\u00f3w rozwoju bezpiecze\u0144stwa oprogramowania w lotnictwie stanowi mocne podstawy zastosowania ich w rozwoju oprogramowania do pojazd\u00f3w naziemnych. Wyci\u0105gni\u0119te wnioski, rozw\u00f3j cyklu \u017cycia bezpiecze\u0144stwa oprogramowania i metody weryfikacji okaza\u0142y si\u0119 skuteczne w zmniejszaniu ryzyka w przemy\u015ble lotniczym<\/strong>. Do\u015bwiadczenie te mo\u017cna z \u0142atwo\u015bci\u0105 przenie\u015b\u0107 na systemy motoryzacyjne i autonomiczne, kt\u00f3re przechodz\u0105 na platformy sterowania oparte g\u0142\u00f3wnie na elektronice i oprogramowaniu.<\/p>\n\n\n\n Pocz\u0105tkow\u0105 cz\u0119\u015bci\u0105 procesu tworzenia oprogramowania DO-178 jest rzeczywiste planowanie samego procesu. Szczeg\u00f3\u0142owy opis rzeczywistego cyklu rozwoju oprogramowania musi obejmowa\u0107 pe\u0142ny cykl \u017cycia oprogramowania, zdefiniowanie relacji mi\u0119dzy procesami projektowania i mechanizmami informacji zwrotnej, \u015brodowiskiem tworzenia oprogramowania i standardami rozwoju.<\/p>\n\n\n\n Projektowanie tych plan\u00f3w rozwoju dla rozwoju oprogramowania prowadzi do powstania artefakt\u00f3w, kt\u00f3re s\u0105 u\u017cywane przez ca\u0142y cykl rozwoju i aktualizowane na ka\u017cdym etapie. Definicja tych standard\u00f3w i proces\u00f3w wdro\u017cy\u0142a infrastruktur\u0119 dla systemu bezpiecze\u0144stwa, kt\u00f3ry ma by\u0107 zarz\u0105dzany i przestrzegany. Do wst\u0119pnych artefakt\u00f3w nale\u017c\u0105:<\/p>\n\n\n\n Norma ISO26262-6 jest zgodna z metodologi\u0105 lotnicz\u0105, ale ma bardziej zdefiniowany cykl tworzenia oprogramowania<\/strong>. Wiele pozycji, w tym pozycje 3-8 z powy\u017cszej listy, maj\u0105 zastosowanie do normy motoryzacyjnej, aby spe\u0142ni\u0107 niezb\u0119dne schematy bezpiecze\u0144stwa konkretnego opracowywanego produktu.<\/p>\n\n\n\n ISO26262-6 ma wst\u0119pnie bardziej zdefiniowany plan samego rozwoju oprogramowania w por\u00f3wnaniu do DO-178. Podej\u015bcie rozwojowe zaczyna od ko\u0144ca wymaga\u0144 z poziomu systemu i przechodzi kaskadowo w d\u00f3\u0142 przez projekt, podczas gdy stron\u0105 powrotn\u0105 jest weryfikacja i integracja do szczytu po\u0142\u0105cze\u0144 systemowych.<\/p>\n\n\n\n Po procesie planowania, w przypadku DO-178 i ISO26262, ju\u017c zdefiniowane wymagania systemowe sp\u0142ywaj\u0105 do definicji wymaga\u0144 dla wymaga\u0144 na poziomie oprogramowania.<\/p>\n\n\n\n Dla DO-178 wymagania systemowe pochodz\u0105 ze \u017ar\u00f3de\u0142 spoza procesu rozwoju DO-178. Rzeczywiste wymagania musz\u0105 zosta\u0107 ocenione pod k\u0105tem sp\u00f3jno\u015bci, informacji zwrotnych do systemu wy\u017cszego poziomu, identyfikowalno\u015bci i zdolno\u015bci do weryfikacji pe\u0142nej funkcjonalno\u015bci i bezpiecze\u0144stwa. Poszczeg\u00f3lne wymagania musz\u0105 r\u00f3wnie\u017c uwzgl\u0119dnia\u0107 niezb\u0119dne aspekty bezpiecze\u0144stwa, kt\u00f3re zosta\u0142y zdefiniowane na poziomie systemu. Nale\u017cy przeanalizowa\u0107 wp\u0142yw ka\u017cdego wymagania na bezpiecze\u0144stwo systemu, podobnie jak ich wp\u0142yw na inne wymagania. Ocen\u0119 DO-178 klasyfikacji bezpiecze\u0144stwa lub zagro\u017cenia przeprowadza si\u0119 na etapie wymaga\u0144. Kaskadowanie wymaga\u0144 systemowych i planu oprogramowania na wymagania funkcjonalne i bezpiecze\u0144stwa ni\u017cszego poziomu jest kluczowym elementem ka\u017cdego cyklu projektowego dla zintegrowanego oprogramowania i bezpiecze\u0144stwa.<\/p>\n\n\n\n Wraz z rozwojem autonomicznych i coraz szybszych pojazd\u00f3w naziemnych kluczowe znaczenie ma uwzgl\u0119dnienie etap\u00f3w w procesach takich jak te oraz pe\u0142na weryfikacja nowych potencjalnych zagro\u017ce\u0144 z ca\u0142kowitym uzale\u017cnieniem od system\u00f3w elektronicznych, pojazd\u00f3w, kt\u00f3re stanowi\u0105 wi\u0119ksze zagro\u017cenie dla bezpiecze\u0144stwa w okre\u015blonych sytuacjach, oraz z\u0142o\u017cono\u015b\u0107 integracji z systemami zewn\u0119trznymi, kt\u00f3re mog\u0105 wp\u0142ywa\u0107 na sterowanie pojazdem.<\/p>\n\n\n\n Podczas definiowania klasyfikacji zagro\u017ce\u0144, u\u017cywanej w fazie wymaga\u0144, istniej\u0105 r\u00f3\u017cne poziomy krytyczno\u015bci bezpiecze\u0144stwa, kt\u00f3re wp\u0142ywaj\u0105 na spos\u00f3b projektowania, diagnozowania i weryfikacji oprogramowania.<\/p>\n\n\n\n Tabela 1 wyszczeg\u00f3lnia te r\u00f3\u017cnice, poniewa\u017c poziomy klasyfikacji s\u0105 odwr\u00f3cone w zale\u017cno\u015bci od normy. Oceny wp\u0142ywaj\u0105 na wymagania, kt\u00f3re musz\u0105 by\u0107 stawiane w ka\u017cdym module oprogramowania w zakresie projektowania, wykrywania i zapobiegania b\u0142\u0119dom oraz testowania weryfikacyjnego.<\/p>\n\n\n\n ISO26262 wprowadza koncepcj\u0119 kontroli do klasyfikacji zagro\u017ce\u0144. Obejmuje to zdolno\u015b\u0107 operatora do z\u0142agodzenia skutk\u00f3w wypadku w przypadku awarii systemu.<\/p>\n\n\n\n Pojazdy autonomiczne dodaj\u0105 nowy wymiar ranking\u00f3w bezpiecze\u0144stwa i kategoryzacji, poniewa\u017c nie ma operatora, kt\u00f3ry zapewnia\u0142by tak\u0105 kontrol\u0119. Funkcje bezpiecze\u0144stwa, kt\u00f3re mo\u017cna wykorzysta\u0107 do interakcji operatora, aby wprowadzi\u0107 pojazd w bezpieczny stan, zosta\u0142y usuni\u0119te. Konieczne by\u0142oby opracowanie nowego systemu klasyfikacji, aby oceni\u0107 wska\u017anik awaryjno\u015bci, wp\u0142yw na \u017cycie i zdrowie oraz uszkodzenia wi\u0119kszego ekosystemu wok\u00f3\u0142 pojazdu.<\/p>\n\n\n\n Podstawowe zasady oceny aspekt\u00f3w bezpiecze\u0144stwa nadal obowi\u0105zuj\u0105 w odniesieniu zar\u00f3wno do lotnictwa jak i motoryzacji. Co wi\u0119cej, obecne normy nie dotycz\u0105 rzekomych wielopojazdowych system\u00f3w wsp\u00f3\u0142pracuj\u0105cych, kt\u00f3re s\u0105 u\u017cywane zar\u00f3wno w przypadku system\u00f3w pojazd\u00f3w u\u017cytkowych, jak i zautomatyzowanych.<\/p>\n\n\n\n Po spe\u0142nieniu wymaga\u0144 proces DO-178 wykorzystuje system kaskadowy do faktycznego przebiegu rozwoju oprogramowania. Proces rozpoczyna si\u0119 od architektury wysokiego poziomu opartej na wymaganiach, kt\u00f3re zosta\u0142y okre\u015blone na wcze\u015bniejszym etapie. Po opracowaniu architektury proces przechodzi do opracowania wymaga\u0144 niskiego poziomu dla ka\u017cdej jednostki architektury, kt\u00f3ra musi zosta\u0107 podzielona na mniejsze. Te mniejsze jednostki s\u0105 nast\u0119pnie oceniane pod k\u0105tem klasyfikacji zagro\u017ce\u0144 jako mniejsze jednostki w oparciu o wp\u0142yw na wi\u0119ksz\u0105 architektur\u0119. Po opracowaniu wymaga\u0144 ni\u017cszego poziomu mo\u017cna wygenerowa\u0107 kod \u017ar\u00f3d\u0142owy, kt\u00f3ry jest powi\u0105zany z tym konkretnym wymaganiem.<\/p>\n\n\n\n ISO26262-6 opiera si\u0119 na podobnej metodologii kaskadowania wymaga\u0144 w architekturze i projekcie. Wysokie wymagania dotycz\u0105ce bezpiecze\u0144stwa s\u0105 przenoszone do projektu architektonicznego, a nast\u0119pnie do jednostki oprogramowania do rzeczywistego projektowania, implementacji, analizy i symulacji. Ka\u017cda z jednostek oprogramowania b\u0119dzie mia\u0142a w\u0142asn\u0105 ocen\u0119 bezpiecze\u0144stwa, kt\u00f3r\u0105 nale\u017cy wzi\u0105\u0107 pod uwag\u0119 podczas projektowania, dokumentacji i weryfikacji jednostki.<\/p>\n\n\n\n Dane wyj\u015bciowe tych dw\u00f3ch standard\u00f3w to:<\/p>\n\n\n\n Kod \u017ar\u00f3d\u0142owy nale\u017cy przejrze\u0107, aby upewni\u0107 si\u0119, \u017ce spe\u0142nia zamierzon\u0105 funkcjonalno\u015b\u0107 w zakresie wymaga\u0144.<\/p>\n\n\n\n Weryfikacja jest niezb\u0119dn\u0105 cz\u0119\u015bci\u0105 procesu, kt\u00f3ra ma na celu sprawdzenie czy oprogramowanie dzia\u0142a zgodnie z przeznaczeniem. Ocena wyj\u015b\u0107 w DO-178 jest dokonywana poprzez weryfikacj\u0119 na wielu poziomach, w tym:<\/p>\n\n\n\n Kilka z tych element\u00f3w wymaga niezale\u017cno\u015bci programisty w celu przegl\u0105du i weryfikacji. Ta niezale\u017cno\u015b\u0107 pozwala na dok\u0142adn\u0105 analiz\u0119 i lepsze uwzgl\u0119dnienie potencjalnych problem\u00f3w, kt\u00f3re mo\u017cna dostrzec w wynikach.<\/p>\n\n\n\n Rzeczywisty plan weryfikacji i analizy jest opracowywany od fazy planowania, a gdy projekt staje si\u0119 bardziej szczeg\u00f3\u0142owy, do planu dodawane s\u0105 dodatkowe elementy. Plan musi obejmowa\u0107 identyfikowalno\u015b\u0107, aby wykaza\u0107, \u017ce wszystkie wymagania i jednostki s\u0105 w pe\u0142ni przetestowane. Ilo\u015b\u0107 test\u00f3w jest doprecyzowana przez wymagania bezpiecze\u0144stwa, a tak\u017ce wymagania okre\u015blone w celu zapewnienia zaufania do oprogramowania. Testy nale\u017cy przeprowadza\u0107, zaczynaj\u0105c od poziomu jednostki, a nast\u0119pnie przechodzi\u0107 do wy\u017cszego poziomu integracji, a\u017c do przetestowania i zweryfikowania ca\u0142ego systemu.<\/p>\n\n\n\n W przypadku normy ISO26262 procedury weryfikacji s\u0105 podobne do procedur lotniczych. Plan weryfikacji jest pisany wcze\u015bniej, a nast\u0119pnie szczeg\u00f3\u0142y s\u0105 dodawane w miar\u0119 post\u0119pu projektu. Testowanie rozpoczyna si\u0119 na poziomie jednostki. Pewne poziomy test\u00f3w s\u0105 wymagane na podstawie poziomu bezpiecze\u0144stwa i prawdopodobie\u0144stwa modeli potencjalnych awarii. Norma ta wymaga r\u00f3wnie\u017c niezale\u017cno\u015bci w pewnych obszarach do przegl\u0105du.<\/p>\n\n\n\n Dane wyj\u015bciowe obu tych standard\u00f3w weryfikuj\u0105 raporty z test\u00f3w, dokumentuj\u0105ce stany i wyniki test\u00f3w, a tak\u017ce raporty z weryfikacji.<\/p>\n\n\n\n Weryfikacja architektury, projekt i wdro\u017cenie na poziomie jednostki oraz integracja wy\u017cszego poziomu w celu spe\u0142nienia wymaga\u0144 bezpiecze\u0144stwa i funkcjonalno\u015bci ma kluczowe znaczenie dla lotnictwa i motoryzacji, ale nabiera nowego wymiaru w przypadku pojazd\u00f3w autonomicznych<\/strong>. Gdy system jest autonomiczny, potencjalne niewiadome interakcje zewn\u0119trzne i wewn\u0119trzne musz\u0105 zosta\u0107 dok\u0142adnie przeanalizowane i zweryfikowane, aby sprawdzi\u0107 czy uzyskano w\u0142a\u015bciwy zakres weryfikacji.<\/p>\n\n\n\n Je\u015bli przestrzegane s\u0105 w\u0142a\u015bciwie, zar\u00f3wno DO-178 jak i ISO-2626, wytworz\u0105 artefakty, kt\u00f3re mog\u0105 zosta\u0107 poddane przegl\u0105dowi przez organ zarz\u0105dzaj\u0105cy jako wi\u0119kszy przegl\u0105d certyfikacji.<\/p>\n\n\n\n FAA (ang. Federal Aviation Association<\/em>) wymaga u\u017cycia DO-178 do tworzenia oprogramowania, ale post\u0119powanie zgodnie z procesem nie gwarantuje certyfikacji. Wykorzystywane dokumenty s\u0105 oceniane w ramach wi\u0119kszego procesu certyfikacji ca\u0142ego statku powietrznego.<\/p>\n\n\n\n W przypadku motoryzacji nie ma zewn\u0119trznych organ\u00f3w zarz\u0105dzaj\u0105cych. Producenci OEM s\u0105 odpowiedzialni za bezpiecze\u0144stwo produkowanych przez siebie system\u00f3w pojazdu. W przypadku ka\u017cdego ze standard\u00f3w programistycznych wszelkie narz\u0119dzia i procesy pomocnicze, kt\u00f3re s\u0105 u\u017cywane, musz\u0105 zosta\u0107 ocenione i certyfikowane pod k\u0105tem powtarzalno\u015bci i znanych wynik\u00f3w narz\u0119dzi. Systemy zapewniania jako\u015bci, plany kwalifikacji narz\u0119dzi, zarz\u0105dzanie zmian\u0105, standardy i procesy \u0142\u0105czno\u015bci z certyfikacj\u0105 s\u0105 cz\u0119\u015bci\u0105 tego zestawu narz\u0119dzi pomocniczych. Ryc. 3 przedstawia por\u00f3wnanie mi\u0119dzy dwoma standardami.<\/p>\n\n\n\n Zautomatyzowane pojazdy obiecuj\u0105 znaczne korzy\u015bci dzi\u0119ki usuni\u0119ciu operatora. Rezygnacja z cz\u0142owieka oznacza jednak, \u017ce bezpiecze\u0144stwo tych system\u00f3w b\u0119dzie zale\u017ce\u0107 od oprogramowania zapewniaj\u0105cego t\u0119 funkcj\u0119.<\/p>\n\n\n\n Oprogramowanie zwi\u0105zane z bezpiecze\u0144stwem dla przysz\u0142ych system\u00f3w pojazd\u00f3w naziemnych, zar\u00f3wno cywilnych jak i wojskowych, mog\u0142oby wykorzystywa\u0107 wskazane standardy jako wytyczne dotycz\u0105ce opracowywania standard\u00f3w. Ustalenie szczeg\u00f3\u0142owych plan\u00f3w wst\u0119pnych, wymaga\u0144 zwi\u0105zanych z bezpiecze\u0144stwem, projektowanie wok\u00f3\u0142 tych wymaga\u0144 oraz proces weryfikacji maj\u0105 zastosowanie niezale\u017cnie od okre\u015blonych norm. Dobra metodologia i zaplanowany rozw\u00f3j proces\u00f3w pozwalaj\u0105 na dopracowanie solidnych system\u00f3w i oprogramowania, kt\u00f3re minimalizuj\u0105 ryzyko dla ludzi w \u015bwiecie rzeczywistym.<\/p>\n\n\n\n ***<\/p>\n\n\n\n Je\u015bli interesuje Ci\u0119 tematyka ISO, norm i standard\u00f3w, polecamy inne artyku\u0142y naszych ekspert\u00f3w np. Functional Safety ISO 26262 \u2013 ASIL i metryki<\/a>, Introduction to Risk Management for embedded Medical Device software (IEC 62304:2006\/AMD 1:2015)<\/a> oraz Agile w procesach regulowanych<\/a>.<\/p>\n\n\nISO26262<\/strong><\/h3>\n\n\n\n
Por\u00f3wnanie norm: DO-178 i ISO26262<\/strong><\/h2>\n\n\n\n
<\/a>Adaptacja funkcji bezpiecze\u0144stwa oprogramowania w lotnictwie do proces\u00f3w motoryzacyjnych<\/strong><\/h2>\n\n\n\n
Planowanie oprogramowania<\/strong><\/h3>\n\n\n\n
Definicja bezpiecze\u0144stwa i wymaga\u0144<\/strong><\/h2>\n\n\n\n
W ramach normy ISO26262 wymagania bezpiecze\u0144stwa s\u0105 kaskadowane od sekcji 3, w kt\u00f3rej zdefiniowana jest koncepcja bezpiecze\u0144stwa, i sekcji 4, w kt\u00f3rej zdefiniowano system i podzielono go na sprz\u0119t i oprogramowanie. Wynikiem obu standard\u00f3w jest dokumentacja wymaga\u0144, a tak\u017ce aktualizacje wszelkich plan\u00f3w oprogramowania i plany weryfikacji opracowane w ramach pierwotnego planowania oprogramowania.<\/p>\n\n\n\nKlasyfikacja zagro\u017ce\u0144<\/strong><\/h2>\n\n\n\n
Wp\u0142yw na bezpiecze\u0144stwo<\/strong><\/strong><\/td> DO-178<\/strong><\/strong><\/td> ISO26262<\/strong><\/strong><\/td><\/tr> Katastrofalny<\/td> A<\/td> D<\/td><\/tr> Niebezpieczny<\/td> B<\/td> C<\/td><\/tr> Powa\u017cny<\/td> C<\/td> B<\/td><\/tr> Drobny<\/td> D<\/td> A<\/td><\/tr> Bez znaczenia<\/td> E<\/td> Zarz\u0105dzanie jako\u015bci\u0105<\/td><\/tr><\/tbody><\/table> Architektura oprogramowania, projektowanie i wdra\u017canie<\/strong><\/h2>\n\n\n\n
Weryfikacja jednostki i poziomu integracji<\/strong><\/h2>\n\n\n\n
Artefakty i organy zarz\u0105dzaj\u0105ce<\/strong><\/h2>\n\n\n\n
Ryc. 2 przedstawia por\u00f3wnanie artefakt\u00f3w opracowanych na podstawie dw\u00f3ch standard\u00f3w.<\/p>\n\n\n\n<\/a>Narz\u0119dzia wsparcia<\/strong><\/h2>\n\n\n\n
Podsumowanie<\/strong><\/h2>\n\n\n\n
Bibliografia<\/strong><\/h2>\n\n\n\n