Aktywne Wpisy
Bavarczyk +20
giga_jablecznik +73
#facebookcontent #heheszki
Dołączyłem do grupy Zielarki, Szeptuchy, Wiedźmy, Wiedźmini na fb i świetnie się bawię
Dołączyłem do grupy Zielarki, Szeptuchy, Wiedźmy, Wiedźmini na fb i świetnie się bawię
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.