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.
@kotbehemoth: czy Twoim zdaniem można dalej ze spokojem wsiadać do tych samolotów czy jednak do czasu wyjaśnienia sprawy i wprowadzenia niezbędnych zmian należy ich w miarę możliwości unikać?
@Swieta_Apostazja: myślę, że ryzyko zawsze jest. Bo nawet jeśli Boeing wie już dokładnie co się stało na 100% i wydał jakieś zalecenia jak ten problem zniwelować to wszystko w rekach linii lotniczych (żeby upewnili się, że piloci są przeszkoleni) oraz samych pilotów, którzy muszą być przygotowani na taką okazję i odpowiednio zidentyfikować i zareagować w krytycznym momencie.
@themarvin nie mnie zawołałeś, ale zgaduję, że o mnie chodzi. No więc wyobraź sobie, że masz zespół programistów (którzy piszą oprogramowanie) i testerów (którzy testują oprogramowanie). Jeśli np oba zespoły miałby tego samego kierownika, to istnieje szansa, że mógłby on naciskać na np testerów, żeby szybko przepchnęli soft. Jeśli zespoły mają różnych kierowników to każdy z nich ma inne cele, więc każdy będzie dążył, żeby jego zespół zrobił swoją pracę najlepiej jak
@themarvin: pewnie chodzi o to, że główny manager programistów nie podlega nikomu (poza np. CEO firmy) i przez to redukuje się przypadki typu bierze szefu na słowo kierownika i mówi mu na czym ma przyoszczędzić bo braknie mu na nową s-klasę ;)
@kotbehemoth: Komentarz byłego inżyniera Boeinga w tym temacie:
Made a throw-away for this...
I was a test engineer and was involved in the design/build/test of the MAX cockpit in the Boeing test lab. While I am not sure how their real avionics are coded, I do know in the lab we had a lot of trouble in the initial test phase because all the software was built on the old FORTRAN
Zastanawiam się w ogóle czy takie warstwowe kodowanie nie odbija się znacząco wydajności
Wydajność nie ma absolutnie żadnego znaczenia. Zgaduję, że w większości systemów samolotowych do przetworzenia danych wymagana jest moc obliczeniowia, z którą poradziłby sobie twój smartwatch. A pakują tam mocne procki. Dodawanie warstw nie musi być problemem jeśli jest dobrze zrobione. Ale zwiększa 'technical debt' (nie wiem jak się to tłumaczy). Widząc jak to działa w jednej dużej firmie
@kotbehemoth najlepiej napisany soft nie pomoże jak czujniki kąta natarcia skrzydła szwankują te z zeszłego roku miały rozjazd o 20 stopni między stanowiskiem kapitana a drugiego pilota i według zapisu lotu to był rollercoaster, czyli soft nos w dół, manualnie wyciągają do góry po kilku sekundach znowu automat pikuje bo myśli, że samolot jest na skraju przeciągnięcia, a wyłączyć tego gówna nie ma jak oprócz odłączenia bezpiecznika, tylko nawet nie szkolił Boeing
@erajwa jeżeli jest taki rozjazd w czujnikach dlaczego system sam się nie wyłączy? Zakładam, że jest więcej niż jeden czujnik kąta natarcia. Obsługa błędów hardwaru chyba powinna być zaimplementowana.
Akurat pracuje w branży związanej z tworzeniem flight planów i to jak wszystko działa tutaj woła o pomstę do nieba.
@kotbehemoth tylko dług techniczny trzeba redukować, jeżeli istnieje. Jeżeli firma skupiła się jedynie na dodawaniu nowych funkcji bez równoległego zajmowania się tech investmentem, prędzej czy później jebnie.
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
@KotBehemot, mógłbyś jakoś to rozwinąć? nie do końca jest to dla mnie jasne. dzięki!
No więc wyobraź sobie, że masz zespół programistów (którzy piszą oprogramowanie) i testerów (którzy testują oprogramowanie). Jeśli np oba zespoły miałby tego samego kierownika, to istnieje szansa, że mógłby on naciskać na np testerów, żeby szybko przepchnęli soft.
Jeśli zespoły mają różnych kierowników to każdy z nich ma inne cele, więc każdy będzie dążył, żeby jego zespół zrobił swoją pracę najlepiej jak
@KotBehemot sorry, chodziło mi o @kotbehemoth XD
@kotbehemoth: W sumie do takiego podejścia idealnie pasuje czysto funkcyjny paradygmat.
A wpis bardzo fajny, z tego wynika, że MAXy jeszcze długo mogą pozostać uziemione.
Wydajność nie ma absolutnie żadnego znaczenia. Zgaduję, że w większości systemów samolotowych do przetworzenia danych wymagana jest moc obliczeniowia, z którą poradziłby sobie twój smartwatch. A pakują tam mocne procki.
Dodawanie warstw nie musi być problemem jeśli jest dobrze zrobione. Ale zwiększa 'technical debt' (nie wiem jak się to tłumaczy). Widząc jak to działa w jednej dużej firmie
@kotbehemoth: Dług techniczny. Tak to 15kprogramiści nazywają. Nikt się nie przyznaje, każdy się z tym spotkał.
@kotbehemoth: Metodologia to nauka. Chodziło Ci chyba o metodykę :P
Dziękuję pan @kotbehemoth i pan @tomosano
Akurat pracuje w branży związanej z tworzeniem flight planów i to jak wszystko działa tutaj woła o pomstę do nieba.