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.
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.
Wszystko prawda ale, moc obliczeniowa za mała i błędy w oprogramowaniu zawiniły w katastrofach. "Problem w tym, że jak się wydaje, Boeing tę „miarę” znacznie przekroczył, obciążając leciwe komputery masą nowych zadań związanych z naprawą niedociągnięć fizycznych 737 Max. " "Błędy w oprogramowaniu i przeliczaniu danych doprowadziły do dwu katastrof, w których zginęli wszyscy pasażerowie i załogi rozbitych Boeingów."
No nie "Oczywiście nie był to jedyny czynnik prowadzący do tragedii. Kolejnym kamykiem do ogródka Boeinga była „udana” próba zaoszczędzenia czasu i pieniędzy na szkolenie pilotów dla nowych maszyn. Aby przyśpieszyć wprowadzenie samolotu na rynek, akceptowano uprawnienia pilotów poprzednich wersji 737, o ile Ci przerobili… godzinną lekcję na iPadzie."
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.
Niedostatecznie testowano. Albo używano technik typowych dla "młodych i dynamicznych zespołów programistów", czyli żadnych.
Problem spadku jakosci kody dotyczy chyba całego świata. Niby masz programistę który od 10 lat pisze kod, a po chwili okazuje się że napierniczał javascript. Taki odpowiednik pistoletu na wodę. I właśnie go zatrudnili w embedded. "Bo ma doświadczenie w programowaniu".
Więc winien nie jest hardware tylko zespół dyletantów którzy nie przetestowali kodu.
Przydało my się dowiedzieć, dokładnie, gdzie te błedy były. Może się okazać, że jak w przypadku Toyoty, jedyne co można było zrobić to facepalm kiedy audytor zobaczył kod którego powstydził by się student pierszego roku informatyki.
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.
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.
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.
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ą.
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 ...
Jeśli ten procesor i RAM kosztuje grosze to czemu nie? Wolę mieć przetestowany soft, który pracuje na milionach serwerów 24/7 i który nie klęknie po dostaniu kilku niezakończonych handshaków, albo stada pofragmentowanych pakietów. A także taki, który będzie można rozbudować o szyfrowanie transmisji, VPN jeśli będzie to konieczne.
Ponieważ każda z tych zbędnych warstw wprowadza dodatkowe miejsca gdzie: a) czają sie błędy b) nie da się czegoś zweryfikować c) zwiększają czasy reakcji d) zwiększają złożoność setki razy powyżej spodziewanej
W sytuacji gdy chcesz to wsadzić do urządzenia podlegającego jakiejś certyfikacji każda z tych rzeczy jest kłopotliwa bądź niemożliwa do przepchnięcia.
Czyli Linux odpada. Chyba że zakładasz że "przetestowany" oznacza milion instalcji Ubuntu do oglądania porno na pecetach. Obawiam się że "przetestowany" może nie dotyczyć konkretnego niszowego rdzenia uC.
A one zaś wszystkie pracują na Twoich mikrokontolerach ...
Zaznaczam że fakt odpalenia się Linuxa na jakimś rdzeniu CPU nie oznacza że będzie "przetestowany". W zasadzie błedy krytyczne spotykane są do dzisiaj, a im mniej popularna platforma tym jest ich więcej. A że platformy dla linuxa są skomplikowane z definicji, no to wiadomo że łatwo nie będzie ...
Z drugiej strony jeśli weźmiesz jakiś procesor o prostej konstrukcji, szanse na błędy w obsłudze hardware maleją. Możesz pisać na odpierdol i zakładać że jak coś padnie to się najwyżej zrestartuje, ale są miejsca gdzie jak coś padnie to spadnie. Na da się pisać bezbłednie, ale znamy metody eliminacji błędów na etapie produkcji kodu, zdecydowana większosc z nich nie jest w stanie ogarność złożonych systemów jak linux.
Za to klęknie bo kto zapomniał wyłaczyc loga aż zajechało cały filesystem. Albo klęknie bo masz buga w preemptive multitaskingu który wysoczył dopiero po 40 miesiącach nieprzerwanej pracy bo się hardwareowy licznik przekręcił. Albo okazało się że to przerwanie nigdy nikomu nie przyszło w tym samym momencie co operacja na Flashu, a Ty jesteś pionierem. Możesz pozerkać na grupy dysusyjne OpenWRT gdzie ludzie miewali dokładnie takie zabawne problemy z tym "przetestowanym linuxem" jak przerwania rebootujące system, problemy z koherencją cache itd itp. I oni w zasadzie implementują linuxa na takich małych pizdrykach, SoC. I jakimś trafem fakt że milion instancji Ubuntu do oglądania porno nijak nie poprawia stabilności jajka w SoC Atherosa.
Co akurta jest oczywistym problemem do rozwiązania jak się pisze stos TCP. Oczywiście można napisać kiepski stos TCP. Ale szczęśliwie lata
60te w programowaniu minęły, teraz mamy techniki zapewniajace jakość i pilnujące specyfikacji.
Ale tu nie było konieczne. Ot, ktoś wsadził napisany na odpierdol w perlu serwer tcp->rs485 i skasował za "nowoczesny design". Dzień jak co dzień.
Coś podobnego widuję u siebie. Router Drayteka wstaje w kilka, góra kilkanaście sekund. Natomiast różne acery, tp-linki czy inne podobne potrzebują nierzadko ponad dwie minuty, pomimo, że ich funkcjonalność jest kilkukrotnie mniejsza od najprostszego drayteka.
Ostatnio, co zobaczyłem: iluminofonię robiło się na kilku tranzystorach. Włączało się i działała natychmiast. Teraz do tego zaprząga się komputery jednoukładowe albo inne dziwolągi. Startuje to długo, pokazuje czasem nie wiadomo co, potrafi się zawiesić.
Ostatnio oglądałem fajną prezentację włamania do SoC odpowiedzialnego za deszyfrowanie strumienia video. W środku klon prostego 6502, któremu wystarczyło wstrzyknąć kod do pamięci RAM i "potrząsnąć" trochę zasilaniem, żeby się wykrzaczył i zaczął wykonywać ten kod z RAMu. Ta sama sztuczka nawet na Cortexie-M0 ma małą szansę powodzenia, dzięki wykrywaniu dostępu do nieistniejących adresów i dużej przestrzeni adresowej. Nie wspominając już o większych prockach z MMU.
I oczywiście potrafisz udowodnić, że problemem była ta część linuksa, która jest wspólna dla miliona instalacji ubuntu a nie specyficzna dla SoC Atherosa?
To, że ty nie potrzebowałeś, to nie znaczy że producent tych przejściówek nie ma klientów, którzy tego nie potrzebują.
OK, ale ja się do Linuksa nie odnosiłem tylko do tych nieszczęsnych Cortexów. Nie mówimy też o miganiu diodą. Nie uważam, żeby możliwość programowania bardziej wypasionego mikrokontrolera miała prowadzić do przerośniętego i bardziej zabugowanego kodu. Starszy, prostszy mikrokontroler ma różne ograniczenia, które utrudniają programowanie, mogą zwiększać ryzyko błędu i wydłużają czas tworzenia kodu.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.