Z racji niedawnej katastrofy…

Z racji niedawnej katastrofy samolotu 737 serii MAX Etiopskich linii lotniczych napiszę dziś parę zdań o tym jak tworzone jest oprogramowanie w lotnictwie cywilnym.

Na chwilę obecną software w lotnictwie, jak każda część statku powietrznego, musi przejść odpowiednią certyfikację, uzyskać tzw. airworthness certificate, czyli certyfikat zdolności do lotu. W różnych miejscach na świecie są różne jednostki certyfikujące – np w Europie jest to EASA, a w USA jest to FAA. Każda z nich ma inne kryteria i wytyczne, ale koniec końców samolot by miał rację bytu na rynku musi spełniać wytyczne wszystkich większych jednostek.

Jeśli chodzi o soft to istnieje nieformalny standard, który jest stosowany przy projektowaniu, implementacji i testowaniu oprogramowania – jest to standard oznaczony jako DO-178 C (wcześniej był B, który wciąż jest w użyciu). Mówię nieformalny, bo nie ma nic na przeszkodzie, żeby jakaś firma zrobiła soft po swojemu, byleby spełniał wytyczne ww organizacji. Niemniej jednostki certyfikujące znają DO-178 B/C od lat tak więc jest to najszybsza droga uzyskania certyfikatu.

Podejście jest trochę takie – soft robiony w oparciu o DO-178 lata od wielu lat i działa dobrze, po co więc wprowadzać jakiekolwiek modyfikacje. Na pierwszy rzut oka standard ten mocno trąci myszką. Można powiedzieć, że tworzenie oprogramowania lotniczego to domena leśnych dziadków. Niewiele się tam zmienia, zmiany są niechętne i często blokowane przez starszych pracowników. Skoro samoloty latają i nie spadaj to najlepszy dowód, że ta metodologia działa – takie jest zawsze tłumaczenie. I sumie po części jak najbardziej prawidłowe.

Nie opiszę tu dokładnie standardu, bo nawet na szkoleniu za zylion cebulionów jedynie liznąłem temat. Potem tylko ogólniki.
Najistotniejszą rzeczą jest identyfikowalność (traceability) wszystkiego co się dzieje w kodzie. Każda linia kodu musi wynikać bezpośrednio z opisanych wymagań lub z wymagań im pochodnych (derived). Wszystko po to, żeby dało się udowodnić, że 1) soft robi to co ma robić, 2) nie ma żadnego kodu, który robi coś co nie jest wymagane.

Kolejną rzeczą są poziomy bezpieczeństwa przyznawane w zależności od tego jaki potencjalny wpływ ma dane oprogramowanie na bezpieczeństwo. Jest ich 4 + 1. 4 główne to od katastroficznego (catastriphical) – oznaczającego, że błędne działanie oprogramowania może skutkować utratą maszyny i śmiercią pasażerów, aż po pomniejszy (minor) – oznaczającego tylko niewygodę pasażerów (np zmianę trasy lub opóźnienie). Ostatni (5.) poziom oznacza brak wpływu na bezpieczeństwo (no effect) i z tego co pamiętam w ogóle nie wymaga stosowania normy.

Oczywiście w zależności od poziomu są różne wymagania co do np. testowania. I tak dla poziomu katastroficznego wymagania są m.in. takie, że testowanie musi odbywać się fizycznie w innej lokalizacji niż implementacja. Np w innym mieście, kraju. Do tego struktura organizacji powinna być taka, że drabinka zatrudnienia dla programistów i testerów łączy się na najwyższym poziomie w firmie. Wszystko po to, żeby nie było żadnego wpływu lub nacisków podczas weryfikacji.

Wszytko to sprawia, że zmiany w sofcie na poziomie katastroficzny wymagają długiego czasu, nie da się nic zrobić w ciągu tygodnia, a nawet miesiąca. A taki na 100% jest poziom dla oprogramowania sterującego automatycznym opuszczaniem dziobu samolotu w przypadku wykrycia zagrożenia przeciągnięcia.

Wybaczcie jeśli coś przekręciłem lub uprościłem. Miałem tylko dość małą styczność z oprogramowaniem lotniczym i to dość dawno temu.

#ciekawostki #lotnictwo #samoloty #technologia #programowanie