Katastrofa B737 MAX: Jak stare komputery wpłynęły na nowoczesny samolot?

Wed Apr 29, 2020 6:59 pm   

Przeczytałem ciekawy blog, autor widac wi o czym pisze więc przyjmuję że
to nie fake_new. Więc do rzeczy

Jest sobie w usa duża firma samolotowa której główny konkurent w europie
w pewnym momencie zrobił lepszy samolot, więc jest wielka panika i praca
na szybko, samolot nowy się długo robi i testuje więc bierzemy to co już
jest i poprawiamy, co się może nie udać?
okazuje się że prawie wszystko.
Silniki za słabe, no to dajemy mocniejsze,
nie mieszczą się w gondolach no to przesuńmy je,
samolot stracił stateczność, no to sztucznie ją naprawmy, dajmy komputer,
co mamy? stare z '96 16bitowe jednostki,
za słabe? no to dajmy dwa,
Co się może nie udać?
Wszystko, dwa rozwalone samoloty i 346 ofiar zmusiło ich w końcu
do uziemienia wszystkich B737MAX.
https://antyweb.pl/dwa-16-bitowe-komputery-z-1996-maja-naprawic-konstrukcyjne-bledy-boeinga-737-max-nie-wiem-jak-wy-ale-ja-do-takiego-samoloty-nie-wsiade/

--
Janusz

Wed Apr 29, 2020 7:15 pm   

On 29/04/2020 20:59, Janusz wrote:

Pomijając projektowanie przez księgowych, akurat stare komputery w
samolocie - tak, to ma sens.

Po piersze zapewne mają certyfikaty.

Po drugie może nawet są zweryfikowane formalnie.

Po trzecie im starsza technoogia tym lepiej, jesli latasz wysoko z uwagi
na promieniowanie.

Po czwarte, skoro latają od N lat to wszelakie problemy zostały już
dawno znalezione i wykluczone. Choćby taki detal jak wibracje, kiedyś
czytałem jak w dużych kawałkach krzemu pojawił się rezonans mechaniczny,
z drganiami obudowy, ze skutkiem którego już nie pamietam (ale fatalnym).

Moc obliczeniowa tego co lata w kosmos jest znikoma, bo wazniejsze jest
aby się bity nie przestawiały same. W samolotach może zagrożenie
mniejsze, ale ciągle większe niż na ziemii.

Ponadto prawda jest taka że wole jesli sterownik krytycznego urządzenia
zawiera minimalną ilośc kodu który został przetesowany (w tym
formalnie), natomiast wolałbym nie być podpinany pod respirator
napędzany Linuxem. Jakoś tak wszystko teraz migruje do dupnych
procesorów z okolic Cortex N+1 w celu migania diodą. Może więc decyzja
nie miała podłoża ekonomicznego, tylko ktos miał w tym Boeningu resztkę
mózgu.

Wed Apr 29, 2020 7:34 pm   

heby wrote on 29.04.2020 21:15:


A co takiego dupnego w nich jest?

Wed Apr 29, 2020 7:44 pm   

Wed Apr 29, 2020 7:46 pm   

On 29/04/2020 21:34, Zbych wrote:

Do migania diodą? Wszystko. Ba, często widuje w urządzeniach wypasione
FPGA które robią trywialne rzeczy. Znajomy aktywnie piszący IP cores
(FPGA/Asic) stwierdził kiedyś że wzieli do jakiegoś projektu Zynq tylko
dlatego że mieli zespół i narzędzia do niego, choć prawda jest taka że
dało się task zrealizować troszke bardziej wypasionym AVRem. Co z
automatu oznacza że będą mieli biliard elementów biernych, duży krzem w
który łatwo trafić jakiąś zapierniczającą cząstką i znacznie większy
problem jak coś padnie. Ale tak chciał klient. Nie wiem dlaczego to
wszystki migruje w tą stronę, ale mam nadzieje że w kosmos dalej będa
latać stare RISCy czy inne MIPSy z małymi zegarami a nie najnowsze i9. W
samolotach też bym wolał sprawdzony software niż wypasiony software.

Wed Apr 29, 2020 7:55 pm   

Wed Apr 29, 2020 8:05 pm   

heby wrote on 29.04.2020 21:46:

A tak konkretnie?


No super, ale ja pytałem o te dupne Cortexy i nic się nie dowiedziałem.

Wed Apr 29, 2020 8:37 pm   

On 29/04/2020 22:05, Zbych wrote:

A tak konkretnie to np. interfejs Renault Clip. W gruncie rzeczy musisz
przerzucic kilka bajtów z USB na CAN lub inny protokół samochodowy. W
jedne z wersji to sporej wielkosci metalowe pudło które w środku miało
kilkanascie scalaków, w tym FPGA [1].

Obecnie z tego co widzę wypruwając sobie żyły udało im się dojść do
przesadnie skomplikowanego uC. Jak by to jeszcze autonomiczne było w
jakimś stopniu, a to współpracuje z żenujacej jakosci oprogramowniem na
komputerze ...


Jesli ktoś bierze Cortexa w celu miganioa diodą to jest to dupny
procesor do prostego zadania. Cena mikrokontolerów o dużej komplikacji
spada do wartosci przy której *równie* dobrze można brać Cortexa do
migania diodą jak i dwa tranzystory. Problem tylko w tym czy aby na tym
Cortexie nie znajdziesz FreeRTOSa, bo akurat programista tylko to
potrafił ... co może być piękniejszego niż deadlock wątków na preemptive
multitasking, przy zadaniu z okolicy migania diodą? Takich faili bedzie
coraz więcej ponieważ pojemności i wydajności mikrokontrolerów rosną a
ceny spadają. Miałem w ręku fabryczny konwerter rs485 na ethernet. W
środku miał linuxa (podobno). Od podpięcia zasilania do zadziałania
potrzebował koło 30 sekund. Uwierzyłem na słowo w tego Linuxa, nijak
inaczej tego nie dało się wytłumaczyć.

[1] na necie nie ma już zdjęc starego Clip-a. Są tylko te nowe z
wielgachnym CPU. Nie mogę więc podeprzeć się tym przykładem w formie
graficznej.

Wed Apr 29, 2020 8:57 pm   

On 29.04.2020 22:37, heby wrote:


A co w tym dziwnego?
To na czym byś to zrobił?

--
Mirek.

Wed Apr 29, 2020 9:11 pm   

heby wrote on 29.04.2020 22:37:

No i dalej nic o tym dupnym Corteksie.


Wreszcie coś na temat.


I powinieneś się cieszyć, że masz tam porządnie napisany stos tcp, który
przeszedł niejeden chrzest bojowy a nie kolejne dzieło wystrugane na
kolanie.

Wed Apr 29, 2020 9:38 pm   

heby <heby@poczta.onet.pl> napisał(a):

OK, czyli dajmy programistom procki z 1 kB ROM i 64 bajtami RAM. Wtedy nie
będą popełniać błędów.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

Thu Apr 30, 2020 2:28 am   

Janusz <janusz_kk@o2.pl> wrote:

O B737MAX sporo napisano. Ten tytul wyraznie wskazuje ze autor
malo wie o dostepnych informacjach (albo celowo chce propagowac
swoje pomysly). Krotko:

1) podstawowy problem to kierownictwo. System ktory spowodawal katastrofy
zakwalifikowano jako "niekrytyczny", ot mala pomoc dla pilota, jak
sie go wylaczy to samolot bez problemu dalej bedzie lecial
2) bez korekty komputera B737MAX latal OK, ale inaczej niz B737. To
wymagaloby przeszkolenia pilotow. Z korekta komputerowa B737MAX
niby byl zgodny z B737...
3) jedna (a moze nawat obie) katastrofy zaczely sie od awarii czujnika.
Kazdy komputer mial swoj czujnik i nie mial dostepu do drugiego.
Jak czujnik nawalil to komputer probowal korygowac "bledny" kat
natarcia i rabnal w ziemie. Zaloga miala kilkadziesiat sekund
by wylaczyc "korekte". Bylo doniesienie o przynajmniej jednym
niedoszlym wypadku gdzie zaloga zdazyla... Wiekszosc zalog nie
wiedziala jak sie wylacza "korekte".
4) byla mowa o sporej ilosci decyzji kierownictwa gdzie probowano
obnizac koszty i ktore sie przyczynialy do nizszej jakosci.

Gdyby nie 1) to system wymagalby pelnej procedury dopuszczenia, z
rozsadna szansa na wylapanie problemow. Wymagalby tez nadmiarowych
czujnikow.

Mozna powiedzic ze technicznie glownym problemem bylo oprogramowanie,
np. korekta miala byc rzedu 2 stopni a oprogamowanie bez zastanowienia
walilo 70.

Ograniczona wydajnosc starych komputerow to tylko jeden czynnik,
ja bym powiedzial ze najmniej istotny.

--
Waldek Hebisch

Thu Apr 30, 2020 6:40 am   

On 29/04/2020 22:57, Mirek wrote:

"Dzięki" linuxowi dodano przeogromną warstwę zbędnego software.

Zaznaczam że urządzenie ma otworzyć port TCP i przesyłać bajty z prawa
na lewo. I nic więcej. Nie ma tam nawet konfiguracji przez jakiegoś
weba, tylko stosuje się aplikację na komputer do zmian, a tych zmian
jest aż jedna: czy adres z dhcp czy stały.


Na małych biblitekach TCP które nie wymagają Linuxa. Wstawał by w
milisekundę, używałby mniejszego CPU, byłby łatwiej ogarnialny
softwareowo, ufałbym mu bardziej.

To nie jest problem wyssany z palca, byłem przekonany że problem braku
działania jest w moim kodzie. Dopiero właściciel tego cuda oświecił mnie
że potrzebuje 30 sek na wystartowanie.

Thu Apr 30, 2020 6:45 am   

On 29/04/2020 23:11, Zbych wrote:

Bo to było o FPGA.


Innymi słowy aby mieć porządny stos TCP/IP musisz mieć solidny procesor
z MMU, kilkadziesiąt MB biblitek do obsługi preemptive mutitaskingu,
filesystemu, logowania, praw dostępu, obsługi eventów, oopsy do kompletu
i koniecznie jakiegoś backdoora. I to wszystko aby przesłać kilka bajtów
z lewa na prawo.

Tak, właśnie o tym mówie. Cortexy do migania diodą.

Thu Apr 30, 2020 6:52 am   

On 29/04/2020 23:38, Grzegorz Niemirowski wrote:

Błedy które przyszły z Linuxem, są wyeliminowane, zostajesz z milion
razy mniejszą bazą kodu nad którym masz kontrolę, który można poddać
audytowi, można zweryfikować formalnie, pokryć w 100% coverage testowym.
W przypadku aplikacji krytycznych to może być kluczowe do dopuszczenia z
zastowoaniach typu "samoloty".

Dodatkowo 64 bajty ramu to zdecydowanie za dużo na miganie diodą.

Nie wykluczam jednak że gdzieś znajdę projekt migania odiodą na R-Pi. No
bo czemu w zasadzie nie ...