Oprogramowanie awioniki

Oprogramowanie awioniki jest oprogramowaniem wbudowanym z prawnie uzasadnionymi kwestiami bezpieczeństwa i niezawodności , używanym w awionice . Główna różnica między oprogramowaniem lotniczym a konwencjonalnym oprogramowaniem wbudowanym polega na tym, że proces rozwoju jest wymagany przez prawo i jest zoptymalizowany pod kątem bezpieczeństwa. Twierdzi się, że proces opisany poniżej jest tylko nieznacznie wolniejszy i bardziej kosztowny (być może 15 procent) niż normalne procesy ad hoc stosowane w oprogramowaniu komercyjnym . Ponieważ większość oprogramowania zawodzi z powodu błędów, eliminowanie błędów na najwcześniejszym możliwym etapie jest również stosunkowo niedrogim i niezawodnym sposobem tworzenia oprogramowania. Jednak w niektórych projektach błędy w specyfikacjach mogą zostać wykryte dopiero po wdrożeniu. W tym momencie ich naprawa może być bardzo kosztowna.

Podstawową ideą każdego modelu tworzenia oprogramowania jest to, że każdy krok procesu projektowania ma wyniki zwane „produktami dostarczanymi”. ^{[ Potrzebne źródło ]} Jeśli wyniki są sprawdzane pod kątem poprawności i naprawiane, zwykłe ludzkie błędy nie mogą łatwo przerodzić się w niebezpieczne lub kosztowne problemy. Większość producentów ^{[ potrzebne źródło ]} stosuje model kaskadowy , aby koordynować projektowany produkt, ale prawie wszyscy wyraźnie zezwalają na rewizję wcześniejszych prac. Rezultat jest częściej bliższy modelowi spiralnemu .

Aby zapoznać się z przeglądem oprogramowania wbudowanego, zobacz systemy wbudowane i modele rozwoju oprogramowania . W dalszej części tego artykułu założono znajomość tych informacji i omówiono różnice między komercyjnymi systemami wbudowanymi a komercyjnymi modelami programistycznymi.

Przegląd ogólny

Ponieważ większość producentów awioniki postrzega oprogramowanie jako sposób na zwiększenie wartości bez dodawania wagi, rośnie znaczenie oprogramowania wbudowanego w systemach awioniki.

Większość nowoczesnych samolotów komercyjnych z autopilotami wykorzystuje komputery pokładowe i tak zwane systemy zarządzania lotem (FMS), które mogą latać statkiem powietrznym bez aktywnej interwencji pilota podczas niektórych faz lotu. W trakcie opracowywania lub produkcji są również pojazdy bezzałogowe: pociski i drony, które mogą startować, krążyć i lądować bez interwencji pilota w powietrzu.

W wielu z tych systemów awaria jest niedopuszczalna. O niezawodności oprogramowania działającego w pojazdach latających (cywilnych lub wojskowych) świadczy fakt, że większość wypadków lotniczych ma miejsce z powodu błędów manualnych. Niestety niezawodne oprogramowanie niekoniecznie jest łatwe w użyciu lub intuicyjne, a zły projekt interfejsu użytkownika jest przyczyną wielu wypadków i zgonów w przemyśle lotniczym. ^{[ potrzebne źródło ]}

Kwestie regulacyjne

Ze względu na wymogi bezpieczeństwa większość krajów reguluje awionikę lub przynajmniej przyjmuje standardy używane przez grupę sojuszników lub unię celną. Trzy organizacje regulacyjne, które mają największy wpływ na rozwój lotnictwa międzynarodowego, to Stany Zjednoczone, UE i Rosja.

W Stanach Zjednoczonych awionika i inne podzespoły statków powietrznych podlegają normom bezpieczeństwa i niezawodności nałożonym przez federalne przepisy lotnicze, część 25 dla samolotów transportowych, część 23 dla małych samolotów oraz części 27 i 29 dla wiropłatów. Normy te są egzekwowane przez „wyznaczonych przedstawicieli inżynieryjnych” FAA, którzy są zwykle opłacani przez producenta i certyfikowani przez FAA.

W Unii Europejskiej IEC opisuje „zalecane” wymagania dla systemów o krytycznym znaczeniu dla bezpieczeństwa, które są zwykle przyjmowane bez zmian przez rządy. Bezpieczna, niezawodna awionika posiada „znak CE”. Układ regulacyjny jest niezwykle podobny do bezpieczeństwa przeciwpożarowego w USA i Kanadzie. Rząd certyfikuje laboratoria badawcze, a laboratoria certyfikują zarówno wytwarzane przedmioty, jak i organizacje. Zasadniczo nadzór nad inżynierią jest zlecany z rządu i producenta do laboratorium badawczego.

Aby zapewnić bezpieczeństwo i niezawodność, krajowe organy regulacyjne (np. FAA , CAA lub DOD ) wymagają standardów tworzenia oprogramowania. Niektóre reprezentatywne standardy obejmują MIL-STD-2167 dla systemów wojskowych lub RTCA DO-178B i jego następcę DO-178C dla cywilnych statków powietrznych.

Wymagania prawne dotyczące tego oprogramowania mogą być kosztowne w porównaniu z innymi programami, ale zwykle stanowią minimum wymagane do zapewnienia niezbędnego bezpieczeństwa.

Proces rozwoju

Główna różnica między oprogramowaniem awioniki a innymi systemami wbudowanymi polega na tym, że rzeczywiste standardy są często znacznie bardziej szczegółowe i rygorystyczne niż standardy komercyjne, zwykle opisywane w dokumentach liczących setki stron. Zwykle działa w systemie operacyjnym czasu rzeczywistego.

Ponieważ proces ten jest prawnie wymagany, większość procesów ma dokumenty lub oprogramowanie do śledzenia wymagań od ponumerowanych akapitów w specyfikacjach i projektach do dokładnych fragmentów kodu, z dokładnymi testami dla każdego i polem na końcowej liście kontrolnej certyfikacji. Ma to w szczególności na celu udowodnienie zgodności z prawnie wymaganym standardem.

Odstępstwa od konkretnego projektu do opisanych tutaj procesów mogą wynikać z zastosowania alternatywnych metod lub niskich wymagań bezpieczeństwa.

Prawie wszystkie standardy tworzenia oprogramowania opisują, jak wykonywać i ulepszać specyfikacje, projekty, kodowanie i testowanie (patrz model tworzenia oprogramowania ). Jednak standardy rozwoju oprogramowania awioniki dodają kilka kroków do rozwoju bezpieczeństwa i certyfikacji:

Interfejsy ludzkie

Projekty z istotnymi interfejsami ludzkimi są zwykle prototypowane lub symulowane. Taśma wideo jest zwykle zachowywana, ale prototyp wycofano natychmiast po testach, ponieważ w przeciwnym razie kierownictwo wyższego szczebla i klienci mogą uwierzyć, że system jest kompletny. Głównym celem jest znalezienie problemów z interfejsem człowieka, które mogą mieć wpływ na bezpieczeństwo i użyteczność.

Analiza zagrożeń

Awionika o krytycznym znaczeniu dla bezpieczeństwa ma zwykle analizę zagrożeń . Wczesne etapy projektu mają już przynajmniej mgliste pojęcie o głównych częściach projektu. Następnie inżynier bierze każdy blok schematu blokowego i rozważa rzeczy, które mogą pójść nie tak z tym blokiem oraz ich wpływ na system jako całość. Następnie ocenia się dotkliwość i prawdopodobieństwo wystąpienia zagrożeń. Problemy stają się następnie wymaganiami, które są uwzględniane w specyfikacjach projektu.

Projekty związane z wojskowym bezpieczeństwem kryptograficznym zwykle obejmują analizę bezpieczeństwa, przy użyciu metod bardzo podobnych do analizy zagrożeń.

Instrukcja konserwacji

Gdy tylko specyfikacja techniczna jest kompletna, można rozpocząć pisanie podręcznika konserwacji. Instrukcja konserwacji jest niezbędna do naprawy, a jeśli system nie może zostać naprawiony, nie będzie bezpieczny.

Większość standardów ma kilka poziomów. Produkt o niskim poziomie bezpieczeństwa, taki jak pokładowy system rozrywki (latający telewizor), może ujść ze schematem i procedurami instalacji i regulacji. System nawigacyjny, autopilot lub silnik mogą mieć tysiące stron procedur, inspekcji i instrukcji montażu. Dokumenty są obecnie (2003) rutynowo dostarczane na płytach CD-ROM w standardowych formatach zawierających tekst i obrazy.

Jednym z dziwniejszych wymagań dotyczących dokumentacji jest to, że większość umów handlowych wymaga zapewnienia, że dokumentacja systemu będzie dostępna przez czas nieokreślony. Normalną komercyjną metodą zapewnienia tego zabezpieczenia jest utworzenie i sfinansowanie małej fundacji lub trustu. Trust utrzymuje następnie skrzynkę pocztową i zdeponuje kopie (zwykle w ultrafisze ) w bezpiecznym miejscu, takim jak wynajęta przestrzeń w bibliotece uniwersyteckiej (zarządzanej jako kolekcja specjalna) lub (teraz rzadziej) zakopana w jaskini lub na pustyni.

Dokumenty projektowe i specyfikacyjne

Są one zwykle bardzo podobne do tych w innych modelach tworzenia oprogramowania . Zasadniczą różnicą jest to, że wymagania są zwykle śledzone w sposób opisany powyżej. W dużych projektach identyfikowalność wymagań jest tak dużym kosztownym zadaniem, że do zarządzania nim potrzebne są duże, drogie programy komputerowe.

Tworzenie i przeglądanie kodu

Kod jest napisany, a następnie zwykle sprawdzany przez programistę (lub grupę programistów, zwykle niezależnie), który nie napisał go oryginalnie (kolejny wymóg prawny). Organizacje specjalne również zwykle przeprowadzają przeglądy kodu z listą kontrolną możliwych błędów. Gdy zostanie znaleziony nowy typ błędu, jest on dodawany do listy kontrolnej i naprawiany w całym kodzie.

Kod jest również często badany przez specjalne programy analizujące poprawność ( Statyczna analiza kodu ), takie jak egzaminator SPARK dla SPARK (podzbiór języka programowania Ada) lub lint dla rodziny języków programowania C (głównie jednak C) . Kompilatory lub specjalne programy sprawdzające, takie jak „lint”, sprawdzają, czy typy danych są zgodne z operacjami na nich, a także takie narzędzia są regularnie używane do egzekwowania ścisłego stosowania prawidłowych podzbiorów języka programowania i stylów programowania . Inny zestaw programów mierzy metryki oprogramowania , szukając części kodu, które mogą zawierać błędy. Wszystkie problemy zostały rozwiązane lub przynajmniej zrozumiane i dokładnie sprawdzone.

Niektóre kody, takie jak filtry cyfrowe , graficzne interfejsy użytkownika i systemy nawigacji bezwładnościowej , są tak dobrze poznane, że opracowano narzędzia programowe do ich pisania. W takich przypadkach opracowywane są specyfikacje i automatycznie tworzone jest niezawodne oprogramowanie.

Testów jednostkowych

Kod „testu jednostkowego” jest napisany tak, aby przynajmniej raz wykonać każdą instrukcję kodu, aby uzyskać 100% pokrycia kodu . Narzędzie „pokrycia” jest często używane do sprawdzenia, czy każda instrukcja została wykonana, a następnie udokumentowane jest również pokrycie testowe ze względów prawnych.

Ten test należy do najpotężniejszych. Wymusza szczegółowy przegląd logiki programu i wykrywa większość błędów w kodzie, kompilatorze i niektóre błędy projektowe. Niektóre organizacje piszą testy jednostkowe przed napisaniem kodu, wykorzystując projekt oprogramowania jako specyfikację modułu. Kod testu jednostkowego jest wykonywany i wszystkie problemy są naprawione.

Testy integracyjne

Gdy fragmenty kodu stają się dostępne, są dodawane do szkieletu kodu i testowane na miejscu, aby upewnić się, że każdy interfejs działa. Zwykle najpierw należy zakończyć wbudowane testy elektroniki, aby rozpocząć testy wypalenia i emisji radiowej elektroniki.

Następnie integrowane są najcenniejsze funkcje oprogramowania. Jest to bardzo wygodne dla integratorów, że mają sposób na uruchamianie małych wybranych fragmentów kodu, być może z prostego systemu menu.

Niektórzy menedżerowie programów próbują zorganizować ten proces integracji w taki sposób, aby po osiągnięciu pewnego minimalnego poziomu funkcjonalności system mógł być dostarczany w dowolnym późniejszym terminie, a wraz z upływem czasu zwiększała się liczba funkcji.

Czarna skrzynka i testy akceptacyjne

W międzyczasie inżynierowie testowi zwykle rozpoczynają składanie platformy testowej i udostępnianie wstępnych testów do użytku przez inżynierów oprogramowania. W pewnym momencie testy obejmują wszystkie funkcje specyfikacji inżynierskiej. W tym momencie rozpoczynają się testy całej jednostki awionicznej. Celem badań odbiorczych jest wykazanie, że urządzenie jest bezpieczne i niezawodne w eksploatacji.

Pierwszym testem oprogramowania i jednym z najtrudniejszych do zrealizowania w napiętym harmonogramie jest realistyczny test emisji radiowych jednostki. Zwykle należy to rozpocząć na wczesnym etapie projektu, aby zapewnić czas na wprowadzenie niezbędnych zmian w projekcie elektroniki. Oprogramowanie poddawane jest również strukturalnej analizie pokrycia, podczas której przeprowadzane są testy oraz zbierane i analizowane jest pokrycie kodu.

Orzecznictwo

Każdy krok generuje produkt końcowy, dokument, kod lub raport z testu. Gdy oprogramowanie przejdzie wszystkie testy (lub wystarczająco, aby można je było bezpiecznie sprzedawać), są one dołączane do raportu certyfikacyjnego, który może mieć dosłownie tysiące stron. Wyznaczony przedstawiciel techniczny, który dążył do ukończenia, decyduje następnie, czy wynik jest do zaakceptowania. Jeśli tak, podpisuje to, a oprogramowanie awioniki jest certyfikowane.

Zobacz też

Linki zewnętrzne

Ogólna specyfikacja oprogramowania awioniki z Software Engineering Institute (SEI)