Analiza porównawcza standardów rozwoju oprogramowania w odniesieniu do lotnictwa i pojazdów naziemnych

Integracja oprogramowania z systemami transportowymi nieustannie rośnie, a to wymaga przyjęcia standardów bezpieczeństwa oraz systemów rozwoju oprogramowania. Istnieje wiele norm bezpieczeństwa, które można zastosować w zależności od ich konkretnej kategorii użytkowania. Podstawowe metodologie stosowane w tych normach można wykorzystać również w odniesieniu do dowolnego systemu transportowego, w tym także do systemów naziemnych.

Niniejszy artykuł opisuje dwa różne standardy rozwoju bezpieczeństwa i zapewnia ich porównanie na wysokim poziomie pomiędzy powszechnie stosowanym standardem dla lotnictwa a nowszym standardem powstałym dla motoryzacji. Ten ostatni można również z powodzeniem zastosować w innych systemach transportowych, które aktualnie nie posiadają takich norm.

Potrzeba standaryzacji w lotnictwie i przemyśle motoryzacyjnym

Przemysł lotniczy od dawna przyjmuje normy, które obejmują planowanie bezpieczeństwa i opracowywanie specyficznych procesów. Wraz z przyjęciem normy DO-178 w latach 80-tych, procesy te odpowiadają za rozwój oprogramowania związanego z bezpieczeństwem. Przemysł motoryzacyjny dopiero od roku 2012 zaczął przyjmować standard ISO26262 jako system rozwoju oparty na bezpieczeństwie. Standard definiuje projektowanie w oparciu o bezpieczeństwo w procesie tworzenia oprogramowania dla pojazdów produkowanych na dużą skalę.

Wykorzystanie oprogramowania w transporcie samochodowym w ciągu ostatnich trzydziestu lat ukazało potrzebę standaryzacji procesów zorientowanych na bezpieczeństwo. Systemy stają się coraz bardziej złożone, z milionami linii kodu i znajdują coraz częściej zastosowanie w autonomicznych systemach transportowych. Bardzo złożone oprogramowanie i systemy elektroniczne stosowane w transporcie, czy to lotniczym, cywilnym czy wojskowym, mają bezpośredni wpływ na bezpieczeństwo.

Zauważa się duże zainteresowanie potencjalnymi korzyściami, jakie niesie ze sobą technologia zautomatyzowanych pojazdów w zastosowaniach zarówno komercyjnych jak i wojskowych. Ponieważ zautomatyzowane systemy pojazdów przenoszą bezpośrednio odpowiedzialność z kierowcy na oprogramowanie, systemy te muszą być zaprojektowane od podstaw jako systemy krytyczne dla bezpieczeństwa, o wystarczającym poziomie nadmiarowości i odporności na uszkodzenia. Przyjęcie tych norm zarówno do załogowych, jak i bezzałogowych systemów pojazdów naziemnych ma na celu zastosowanie dobrych praktyki rozwojowych, skutkujących poprawą bezpieczeństwa i minimalizacji ryzyka.

Przegląd standardów wykorzystywanych w lotnictwie i pojazdach naziemnych

DO-178

Przemysł lotniczy wykorzystuje normę DO-178 w procesach rozwoju oprogramowania od 30 lat. Wprowadzono kilka aktualizacji tych standardów, z których ostatnią jest DO-178C wydana w 2011 roku przez Radiotechniczną Komisję ds. Lotnictwa – RTCA (ang. Radio Technical Commission for Aeronautics).

Norma ta zapewnia ramy i wytyczne dotyczące zarówno opracowywania procesu tworzenia oprogramowania, jak i integracji identyfikowalności opartej na wymaganiach i zarządzania w jego ramach.

Wytyczne dotyczące procesu rozwoju DO-178, które używane są jako część normalnego cyklu rozwoju oprogramowania, składają się z następujących kroków:

• Ocena wpływu systemu na oprogramowanie.
• Proces planowania oprogramowania – SW (ang. Software),
• Wytyczne dotyczące projektowania i kodowania oprogramowania komputerowego.
• Proces wymagań oprogramowania.
• Architektura i projektowanie oprogramowania.
• Integracja i rozwój oprogramowania.
• Weryfikacja jednostki SW.
• Weryfikacja integracji oprogramowania.
• Artefakty SW i ich przegląd.

W wyniku tych kroków powstają artefakty, które można następnie wykorzystać jako część procesu certyfikacji oprogramowania dla części większego systemu.

ISO26262

Norma ISO26262 została wydana w 2012 roku i jest przeznaczona do wielkoseryjnej produkcji samochodów o maksymalnej masie całkowitej do 3,5t. Wywodzi się z normy IEC61508, która jest szerszą normą bezpieczeństwa przemysłowego. Norma ISO26262 ma koncentrować się na pojazdach wyposażonych w układy elektroniczne, które mogą wpływać bezpośrednio na bezpieczeństwo pojazdu.

Składa się z kilku części, które obejmują:

• koncepcję bezpieczeństwa,
• bezpieczeństwo systemu,
• rozwój sprzętu i oprogramowania dla bezpieczeństwa,

a także

• weryfikację wymagań i bezpieczeństwa na wszystkich tych poziomach.

Specyficzne standardy oprogramowania i ich główny nacisk znajdują się w części ISO26262-6.

Wytyczne dotyczące rozwoju procesu ISO26262 są bardziej szczegółowym zestawem procedur rozwojowych niż w przypadku normy DO-178. Procedury te są zgodne z poniższym cyklem rozwoju, mają przebiegać równolegle i są zintegrowane ze standardowym cyklem tworzenia oprogramowania. Pierwszy wymieniony element pochodzi z elementów systemu zdefiniowanych w sekcji 4 normy ISO26262.

• Wpływ systemu na oprogramowanie (sekcja 4).
• Wymagania dotyczące oprogramowania i cele bezpieczeństwa.
• Architektura jednostki oprogramowania.
• Szczegółowy projekt jednostki i analiza.
• Kodowanie oprogramowania jednostkowego.
• Testowanie i weryfikacja jednostkowa.
• Integracja i testowanie.
• Weryfikacja wymagań bezpieczeństwa i zadań.

Porównanie norm: DO-178 i ISO26262

Jak pokazano w dotychczasowym porównaniu i na Ryc. 1, te dwa standardy mają podobny przebieg procesu, który można ze sobą powiązać. Każdy ze standardów różni się terminologią i rezultatami, a jednocześnie jest zgodny z tą samą metodologią i procesami, które można wykorzystać w opracowywaniu oprogramowania pojazdu z perspektywy bezpieczeństwa, zarówno w przypadku systemów sterowanych przez operatora, jak i systemów pojazdów autonomicznych.

Jednak przy stosowaniu zarówno normy DO-178, jak i normy ISO26262 w odniesieniu do większych i autonomicznych pojazdów naziemnych, należy w obu przypadkach brać pod uwagę dodatkowe ryzyko i wpływ systemów niekontrolowanych przez operatora, a także większych i bardziej skomplikowanych systemów, które stanowią dodatkowe zagrożenie dla bezpieczeństwa. 

Metodologia norm zorientowana na bezpieczeństwo ma zastosowanie do wszystkich systemów, ponieważ są one podobne, jednak szczegóły dla każdego konkretnego przypadku bezpieczeństwa muszą być ocenione w odniesieniu do konkretnego systemu transportowego i środowiska.

Adaptacja funkcji bezpieczeństwa oprogramowania w lotnictwie do procesów motoryzacyjnych

Rozwinięta kultura wykorzystywania przez dziesięciolecia procesów rozwoju bezpieczeństwa oprogramowania w lotnictwie stanowi mocne podstawy zastosowania ich w rozwoju oprogramowania do pojazdów naziemnych. Wyciągnięte wnioski, rozwój cyklu życia bezpieczeństwa oprogramowania i metody weryfikacji okazały się skuteczne w zmniejszaniu ryzyka w przemyśle lotniczym. Doświadczenie te można z łatwością przenieść na systemy motoryzacyjne i autonomiczne, które przechodzą na platformy sterowania oparte głównie na elektronice i oprogramowaniu.

Planowanie oprogramowania

Początkową częścią procesu tworzenia oprogramowania DO-178 jest rzeczywiste planowanie samego procesu. Szczegółowy opis rzeczywistego cyklu rozwoju oprogramowania musi obejmować pełny cykl życia oprogramowania, zdefiniowanie relacji między procesami projektowania i mechanizmami informacji zwrotnej, środowiskiem tworzenia oprogramowania i standardami rozwoju.

Projektowanie tych planów rozwoju dla rozwoju oprogramowania prowadzi do powstania artefaktów, które są używane przez cały cykl rozwoju i aktualizowane na każdym etapie. Definicja tych standardów i procesów wdrożyła infrastrukturę dla systemu bezpieczeństwa, który ma być zarządzany i przestrzegany. Do wstępnych artefaktów należą:

1. Plan aspektów oprogramowania certyfikacji.
2. Plan rozwoju oprogramowania.
3. Plan weryfikacji oprogramowania.
4. Plan zarządzania konfiguracją oprogramowania.
5. Plan kontroli jakości oprogramowania.
6. Standardy wymagań oprogramowania.
7. Standardy projektowania oprogramowania.
8. Standardy kodu oprogramowania.

Norma ISO26262-6 jest zgodna z metodologią lotniczą, ale ma bardziej zdefiniowany cykl tworzenia oprogramowania. Wiele pozycji, w tym pozycje 3-8 z powyższej listy, mają zastosowanie do normy motoryzacyjnej, aby spełnić niezbędne schematy bezpieczeństwa konkretnego opracowywanego produktu.

ISO26262-6 ma wstępnie bardziej zdefiniowany plan samego rozwoju oprogramowania w porównaniu do DO-178. Podejście rozwojowe zaczyna od końca wymagań z poziomu systemu i przechodzi kaskadowo w dół przez projekt, podczas gdy stroną powrotną jest weryfikacja i integracja do szczytu połączeń systemowych.

Definicja bezpieczeństwa i wymagań

Po procesie planowania, w przypadku DO-178 i ISO26262, już zdefiniowane wymagania systemowe spływają do definicji wymagań dla wymagań na poziomie oprogramowania.

Dla DO-178 wymagania systemowe pochodzą ze źródeł spoza procesu rozwoju DO-178. Rzeczywiste wymagania muszą zostać ocenione pod kątem spójności, informacji zwrotnych do systemu wyższego poziomu, identyfikowalności i zdolności do weryfikacji pełnej funkcjonalności i bezpieczeństwa. Poszczególne wymagania muszą również uwzględniać niezbędne aspekty bezpieczeństwa, które zostały zdefiniowane na poziomie systemu. Należy przeanalizować wpływ każdego wymagania na bezpieczeństwo systemu, podobnie jak ich wpływ na inne wymagania. Ocenę DO-178 klasyfikacji bezpieczeństwa lub zagrożenia przeprowadza się na etapie wymagań.

W ramach normy ISO26262 wymagania bezpieczeństwa są kaskadowane od sekcji 3, w której zdefiniowana jest koncepcja bezpieczeństwa, i sekcji 4, w której zdefiniowano system i podzielono go na sprzęt i oprogramowanie. Wynikiem obu standardów jest dokumentacja wymagań, a także aktualizacje wszelkich planów oprogramowania i plany weryfikacji opracowane w ramach pierwotnego planowania oprogramowania.

Kaskadowanie wymagań systemowych i planu oprogramowania na wymagania funkcjonalne i bezpieczeństwa niższego poziomu jest kluczowym elementem każdego cyklu projektowego dla zintegrowanego oprogramowania i bezpieczeństwa.

Wraz z rozwojem autonomicznych i coraz szybszych pojazdów naziemnych kluczowe znaczenie ma uwzględnienie etapów w procesach takich jak te oraz pełna weryfikacja nowych potencjalnych zagrożeń z całkowitym uzależnieniem od systemów elektronicznych, pojazdów, które stanowią większe zagrożenie dla bezpieczeństwa w określonych sytuacjach, oraz złożoność integracji z systemami zewnętrznymi, które mogą wpływać na sterowanie pojazdem.

Klasyfikacja zagrożeń

Podczas definiowania klasyfikacji zagrożeń, używanej w fazie wymagań, istnieją różne poziomy krytyczności bezpieczeństwa, które wpływają na sposób projektowania, diagnozowania i weryfikacji oprogramowania.

Tabela 1 wyszczególnia te różnice, ponieważ poziomy klasyfikacji są odwrócone w zależności od normy. Oceny wpływają na wymagania, które muszą być stawiane w każdym module oprogramowania w zakresie projektowania, wykrywania i zapobiegania błędom oraz testowania weryfikacyjnego.

ISO26262 wprowadza koncepcję kontroli do klasyfikacji zagrożeń. Obejmuje to zdolność operatora do złagodzenia skutków wypadku w przypadku awarii systemu.

Pojazdy autonomiczne dodają nowy wymiar rankingów bezpieczeństwa i kategoryzacji, ponieważ nie ma operatora, który zapewniałby taką kontrolę. Funkcje bezpieczeństwa, które można wykorzystać do interakcji operatora, aby wprowadzić pojazd w bezpieczny stan, zostały usunięte. Konieczne byłoby opracowanie nowego systemu klasyfikacji, aby ocenić wskaźnik awaryjności, wpływ na życie i zdrowie oraz uszkodzenia większego ekosystemu wokół pojazdu.

Podstawowe zasady oceny aspektów bezpieczeństwa nadal obowiązują w odniesieniu zarówno do lotnictwa jak i motoryzacji. Co więcej, obecne normy nie dotyczą rzekomych wielopojazdowych systemów współpracujących, które są używane zarówno w przypadku systemów pojazdów użytkowych, jak i zautomatyzowanych.

Architektura oprogramowania, projektowanie i wdrażanie

Po spełnieniu wymagań proces DO-178 wykorzystuje system kaskadowy do faktycznego przebiegu rozwoju oprogramowania. Proces rozpoczyna się od architektury wysokiego poziomu opartej na wymaganiach, które zostały określone na wcześniejszym etapie. Po opracowaniu architektury proces przechodzi do opracowania wymagań niskiego poziomu dla każdej jednostki architektury, która musi zostać podzielona na mniejsze. Te mniejsze jednostki są następnie oceniane pod kątem klasyfikacji zagrożeń jako mniejsze jednostki w oparciu o wpływ na większą architekturę. Po opracowaniu wymagań niższego poziomu można wygenerować kod źródłowy, który jest powiązany z tym konkretnym wymaganiem.

ISO26262-6 opiera się na podobnej metodologii kaskadowania wymagań w architekturze i projekcie. Wysokie wymagania dotyczące bezpieczeństwa są przenoszone do projektu architektonicznego, a następnie do jednostki oprogramowania do rzeczywistego projektowania, implementacji, analizy i symulacji. Każda z jednostek oprogramowania będzie miała własną ocenę bezpieczeństwa, którą należy wziąć pod uwagę podczas projektowania, dokumentacji i weryfikacji jednostki.

Dane wyjściowe tych dwóch standardów to:

• kod źródłowy,
• szczegóły opisu projektu,
• problemy aplikacji związane z bezpieczeństwem, które należy rozwiązać,
• wszelkie aktualizacje planów weryfikacji, które zostały dodane podczas projektowania.

Kod źródłowy należy przejrzeć, aby upewnić się, że spełnia zamierzoną funkcjonalność w zakresie wymagań.

Weryfikacja jednostki i poziomu integracji

Weryfikacja jest niezbędną częścią procesu, która ma na celu sprawdzenie czy oprogramowanie działa zgodnie z przeznaczeniem. Ocena wyjść w DO-178 jest dokonywana poprzez weryfikację na wielu poziomach, w tym:

• Weryfikacja czy funkcjonalność oprogramowania spełnia wymagania systemowe.
• Weryfikacja czy projekt i architektura oprogramowania spełniają wymagania i standardy oprogramowania.
• Weryfikacja czy dane wyjściowe kodu źródłowego spełniają standardy i architekturę.
• Testowanie oprogramowania z wyjściami potwierdzającymi funkcjonalność i bezpieczeństwo.
• Weryfikacja wyników testów ze śledzeniem.

Kilka z tych elementów wymaga niezależności programisty w celu przeglądu i weryfikacji. Ta niezależność pozwala na dokładną analizę i lepsze uwzględnienie potencjalnych problemów, które można dostrzec w wynikach.

Rzeczywisty plan weryfikacji i analizy jest opracowywany od fazy planowania, a gdy projekt staje się bardziej szczegółowy, do planu dodawane są dodatkowe elementy. Plan musi obejmować identyfikowalność, aby wykazać, że wszystkie wymagania i jednostki są w pełni przetestowane. Ilość testów jest doprecyzowana przez wymagania bezpieczeństwa, a także wymagania określone w celu zapewnienia zaufania do oprogramowania. Testy należy przeprowadzać, zaczynając od poziomu jednostki, a następnie przechodzić do wyższego poziomu integracji, aż do przetestowania i zweryfikowania całego systemu.

W przypadku normy ISO26262 procedury weryfikacji są podobne do procedur lotniczych. Plan weryfikacji jest pisany wcześniej, a następnie szczegóły są dodawane w miarę postępu projektu. Testowanie rozpoczyna się na poziomie jednostki. Pewne poziomy testów są wymagane na podstawie poziomu bezpieczeństwa i prawdopodobieństwa modeli potencjalnych awarii. Norma ta wymaga również niezależności w pewnych obszarach do przeglądu.

Dane wyjściowe obu tych standardów weryfikują raporty z testów, dokumentujące stany i wyniki testów, a także raporty z weryfikacji.

Weryfikacja architektury, projekt i wdrożenie na poziomie jednostki oraz integracja wyższego poziomu w celu spełnienia wymagań bezpieczeństwa i funkcjonalności ma kluczowe znaczenie dla lotnictwa i motoryzacji, ale nabiera nowego wymiaru w przypadku pojazdów autonomicznych. Gdy system jest autonomiczny, potencjalne niewiadome interakcje zewnętrzne i wewnętrzne muszą zostać dokładnie przeanalizowane i zweryfikowane, aby sprawdzić czy uzyskano właściwy zakres weryfikacji.

Artefakty i organy zarządzające

Jeśli przestrzegane są właściwie, zarówno DO-178 jak i ISO-2626, wytworzą artefakty, które mogą zostać poddane przeglądowi przez organ zarządzający jako większy przegląd certyfikacji.

FAA (ang. Federal Aviation Association) wymaga użycia DO-178 do tworzenia oprogramowania, ale postępowanie zgodnie z procesem nie gwarantuje certyfikacji. Wykorzystywane dokumenty są oceniane w ramach większego procesu certyfikacji całego statku powietrznego.

W przypadku motoryzacji nie ma zewnętrznych organów zarządzających. Producenci OEM są odpowiedzialni za bezpieczeństwo produkowanych przez siebie systemów pojazdu.
Ryc. 2 przedstawia porównanie artefaktów opracowanych na podstawie dwóch standardów.

Narzędzia wsparcia

W przypadku każdego ze standardów programistycznych wszelkie narzędzia i procesy pomocnicze, które są używane, muszą zostać ocenione i certyfikowane pod kątem powtarzalności i znanych wyników narzędzi. Systemy zapewniania jakości, plany kwalifikacji narzędzi, zarządzanie zmianą, standardy i procesy łączności z certyfikacją są częścią tego zestawu narzędzi pomocniczych. Ryc. 3 przedstawia porównanie między dwoma standardami.

Podsumowanie

Zautomatyzowane pojazdy obiecują znaczne korzyści dzięki usunięciu operatora. Rezygnacja z człowieka oznacza jednak, że bezpieczeństwo tych systemów będzie zależeć od oprogramowania zapewniającego tę funkcję.

Oprogramowanie związane z bezpieczeństwem dla przyszłych systemów pojazdów naziemnych, zarówno cywilnych jak i wojskowych, mogłoby wykorzystywać wskazane standardy jako wytyczne dotyczące opracowywania standardów. Ustalenie szczegółowych planów wstępnych, wymagań związanych z bezpieczeństwem, projektowanie wokół tych wymagań oraz proces weryfikacji mają zastosowanie niezależnie od określonych norm. Dobra metodologia i zaplanowany rozwój procesów pozwalają na dopracowanie solidnych systemów i oprogramowania, które minimalizują ryzyko dla ludzi w świecie rzeczywistym.

Bibliografia

1. International Standards Organization, ”ISO26262 – Road Vehicles Functional Safety” Sections 1,3,4,6, 2011 (ISO 26262:2011(E)
2. RTCA, Inc, “Software Considerations in Airborne Systems and Equipment Certification”, December 13, 2011 (RTCA DO-178C)
3. Matthias Gerlach, “Can Cars Fly? From Avionics to Automotive – Comparability of Domain Specific Safety Standards”, VirtualOS Embedded World, 2011.

***

Jeśli interesuje Cię tematyka ISO, norm i standardów, polecamy inne artykuły naszych ekspertów np. Functional Safety ISO 26262 – ASIL i metryki, Introduction to Risk Management for embedded Medical Device software (IEC 62304:2006/AMD 1:2015) oraz Agile w procesach regulowanych.