Airbus náhle svolává tisícovky letadel, musí se jim upravit software
Nová výrobní hala na výrobu A320 v Toulouse. Foto: Airbus
První dopravci už připustili možné dopady na provoz
První dopravci už připustili možné dopady na provoz
Tak kde jsou ti tradiční lynčmobáci a zarytí Airbusáci, co umí jen plivat na Boeing? SW chyba u Airbusu? To přece není možné, že? Všechny stroje Airbusu by okamžitě měly být uzemněny a proveden kompletní audit celé firmy, tohle je nehoráznost! Fuj fuj Airbus! Tohle by se Boeingu nikdy nestalo!
Rozdíl je v chování. Airbus našel závažnou chybu a hned svolal letadla.
Boeing zatloukal i po 2 zničených letadlech a 346 mrtvých.
To je ten rozdíl.
U Boeingu by ses s takovym pristupem nesetkal. A to je rozdil mezi nenazranosti a serioznosti.
Tech rozdilu je pres 300. Mrtvych.
Všechna dotčená letadla byla uzemněna, takže v tomto jste krapet mimo. Boeing by se to snažil, jako obvykle, všechno ututlat.
„neřízeném pruském poklesu výšky“ je půvabný překlep. Můžeme spekulovat, jestli je drsnější než jeho bavorský protějšek.(-:
To zas kluci od pocitacu delali aktialozaci a jedou „Agile“, tzn. ze vydaji libovolny skvar, jen aby se dodrzel termin. A pak se musime slozite vracet k predchozi verzi, jak to zname u automotive a domacich spotrebicu.
Ale holt naplanovany agile sprint je agile sprint, a podle oficialniho kanonu agile nabozenstvi se smycky nerusi…
Svolávání je dost automotive termín. 🙂 Airbus nic nesvolá, ale vydal AOT ( Alert Operators Transmission), kde doporučil nahradit zranitelný software v jednotkách ELAC ovládajících výškovku. EASA pak včera A32x family de facto uzemnila vydáním EAD, pokud nemá letoun doporučenou verzi software, tak do nahrazení nesmí letět, kromě povoleného technického přeletu do servisního střediska. https://ad.easa.europa.eu/blob/EASA_AD_2025_0268_E.pdf/EAD_2025-0268-E_1 Nejde o sluneční záření, ale o sluneční erupce. Díky náhlé změně polohy letounu A320 A320-200 JetBlue na letu B6-1230, kdy náhlým samovolným přechodem do klesání a bylo mnoho zranění, byl nalezena zranitelnost jednotek ELAC, která může vést k nepovelované výchylce výškovky a to v takovém… Číst vice »
Konkrétně se to nicméně týká jedné verze software. Starší ani novější zranitelné nejsou, tak uvodíme, kolik flotil je postižených.
https://avherald.com/files/AOT-A27N022-25-00.pdf
Ta snadnost opravy byl asi hlavní dúvod, proč to EASA nařídila jako okamžitě povinné.
To nevím. Myslím si, že spíše jakékoliv samovolné silové vychýlení řídící plochy letounu může snadno vést až k jeho okamžité destrukci, zejména při letu vysokou rychlostí v letové hladině, kde jsou jinak výchylky naprosto miniaturní, tedy je to extrémně nebezpečná softwarová FBW. To autority vidí nerady.
Štěstí je, že je náhrada jednoduchá a existující.
…. softwarová vada FBW…
Zajímavé. Vzpomněl jsem si na Qantas Flight 72. Pokud vím, nikdy se to úplně do důsledku nevyjasnilo.
QF se vyjasnil. Byla to blbá souhra algoritmu, které se staral o fúzi dat z ADIRU (inerciální navigace), a špatně vymyšlený smoothing mezi hodnotami. Jedna jednotka teda občas dávala nesmyslné a občas částečně pravdivé data kvůli mechanické závadě a počítač střídavě její hodnoty průměroval a střídavě potichu zahazoval, mezi zmatenými warningy pro piloty. Vyřešila oprava SW hlavních počítačů včetně toho algoritmu a lepší postupy pro odhalování a vypínání chybných ADIRU.
Oproti problémů s 737 Maxem by pilotům v QF tenkrát stačilo odpojit všechny ADIRU nebo vypnout počítače a letoun by se stabilizoval i bez diagnostiky, která ADIRU dává vadné data.
Pilotům Maxu by tehdy taky stačilo „jen“ vypnout auto trim.
…resp. stacilo urobit “stabilizer runaway” memory items
Ano píšeš to správně. Jen mě zaráží, že celý média svět ochotně publikuje, že vlivem sluneční erupce (víme, že teď bylo několik enormních s dopadem do naší atmosféry, kdy způsobily polární září viditelnou i v našich zem.šířkách) byl poškozen software ELAC dvojky, což způsobilo přechod do prudkého klesání. A teď mi řekněte, opravdu si myslíte, že by tato sluneční radiace dokázala poškodit SW pouze v počítačích ELAC s jednou konkrétní verzí SW, a ne v dalších verzích nebo dalších třech flight controls computerech SEC a dvou FAC jejichž výpočetní i HW architektura je velmi podobná, a nezpůsobilo by to výpadek… Číst vice »
Flip bit SW / dat nahraných v operační paměti/ nějaké cache úplně klidně. Nevím, do jaké míry se používají ECC paměti, ale ani ty nejsou všespasitelné.
Stejně jako já se jen replikuje zdůvodnění, které 28. 11. napsal Airbus ve vztaženém AOT… Cit: „The subsequent investigation identified a vulnerability with the ELAC B hardware fitted with software L104 in case of exposure to solar flares. Nemám ponětí jaká je architektura ELAC a jejich zdůvodnění je jejich zdůvodnění, je úplně jedno jestli je přesné nebo ne, nikdo tady asi neznáme architekturu ELAC počítače a lepší nemáme a mít nebudeme, pokud to výrobce (nebo EASA) neuvede. Nevíme jak je tam řešeno fail-safe chování v případě nějakého flip bitu a co se v dané verzi firmware nepovedlo, že ten mechanismus… Číst vice »
Fail safe je řešeno tak, že probíhá neustálý data comparison mezi ELAC 1 a 2 a pokud vznikne rozdíl mimo toleranci po odečtu špiček kalman filtrem, tak se ten počítač hodí fail. Pokud byl dán command na výškovku, musel být v souladu s oběma ELACs.
Nehledě na fakt, že pokud by mělo elmag pole slunce takovou energii, že by bylo schopno indukovat bit confusion, jistě by již haprovalo mnohem více autobusů nejen 32F, zejména letící severněji.
Prostě je to divné.
A ta fail-safe reakce na na flip bit na obou ELAC by byla jaká? Oba ty údaje jsou nepoužitelné, na běžném domácím počítači to skončí BSOD v obou případech.
Jednak jaká je pravděpodobnost stejné chyby u dvou počítačů vlivem radiace?
Ale hlavně, ten případ u jetblue popisuje chybu pouze u ELAC 2, kdy po jeho výměně byl letoun uvolněn do provozu.
Viz.
https://avherald.com/h?article=52f1ffc3&opt=0
Rozumím, jasně. Ale (sebe)menší pravděpodobnost ten souběh závad nevylučuje, jen tak nějak „shit happens“ 🤷♂️ Jinak ještě takhle: kdybys jakožto výrobce zjistil závadu u jedné ELAC, vrtal by ses v tom dál, jako jestli neselhaly obě?
To musí být něco jiného než flip bit (prostě chyba) v jednom kanálu. Takové věci to určitě umí řešit by design. Ve dvou kanálech zase nebude ta samá chyba. V té postižené verzi software bude nějaká vada ve vyhodnocení chyby nebo zpětné vazby. Prostě nepozná, že se něco děje špatně.
To se klidně může stát ale ten princip je v tom, že pokud nejsou z ELAC1 a ELAC2 shodné commandy, tak se ten úkon neprovede, následuje fault na ELACu a okamžité odpojení autopilota. To je hlavní fail safe logika FBW řízení u všech kanálů tedy i SEC a FAC.
To jistě, úvaha byla spíše v tom, jaký tak typ chyby v té fail safe logice mohl“pojistky“ překonat. Protože právě to se stalo na letu B6-1230.
Je to divné, naprosto souhlasím. Ale jak jsem psal, u toho QF72 tu upl prvotní příčinu taky zatím nikdo neurčil.
To jsem si našel také, že tam jsou v každém počítači dva kanály, jeden výkonný a jeden kontrolní a neustále probíhá komparace.Podle všeho povel hýbnout výškovkou právě zjevně nebyl v souladu obou ELAC, tuším jen ELAC B se „zvrhnul“, pokud jsem to pochopil správně. Proto to řeší jakoo kritickou chybu. Problém určitě nebude pokud počítač „hodí fail“, na to je to konstruované, ale pokud mimovolně a úspěšně zatáhne za hydrauliku a žádný fail to nevyvolá a akci nezastaví, to je chyba zpětné vazby. Elekromagnetické pole snad při flarech není problém, spíše výron nabitých vysokoenergetických částic, které proletí obvody (na čipu).… Číst vice »
https://www.icas.org/icas_archive/ICAS2006/PAPERS/050.PDF?utm_source=chatgpt.com
Přesně tak… Článek 2.1.1. tohoto dokumentu :
Each channel (Fig. 1a/Fig. 1b) includes one or more processors, associated memories, input/output circuits, a power supply unit and specific software. When the results of one of these two channels diverges significantly, the channel or channels which detected this failure cut the links between the computer and the exterior. The system is designed so that the computer outputs are then in a dependable state
Ano. Akorát že postižená verze tenhle soubor opatření někde prorazila (proto zranitelnost) a došlo k nekontrolovanému pohybu výškovkou.
Bylo by zajímavé vědět, přesně kde se vloudila chyba.
Tady jsem našel něco k té vadné aktualizaci na L104. No, mám z toho dost smíšené pocity… https://www.flightglobal.com/safety/a320-grounding-linked-to-software-update-designed-to-protect-against-in-flight-loss-of-control/165521.article „Airbus introduced the L104 update as part of its ‘Safety Beyond Standard’ initiative, which aims to upgrade A320 capabilities – particularly in abnormal conditions – to a level similar to those of the A350. This initiative is intended to reduce exposure to various threats, including in-flight loss of control – the primary driver behind the L104 standard, which is designed to enhance flight-envelope protection. The new software standard for the ELAC B computer introduces pitch attitude limitation in alternate flight-control law, in… Číst vice »
Aha, to je zajímavé nasměrování. Díky tomu jsem našel i brožuru Airbusu (což je v podstatě taková pěkně provedená sbírka Service Bulletinů), kde lze daný „upgrade“ najít na straně 20 PDF. https://d10x.airbus.com/wp-content/uploads/2024/02/A320-Family-Digest-of-available-enhancements-2024-Digital.pdf Evidentně se snažili zvýšit možnosti ochrany letové obálky v Alternate mode FBW (tedy částečně degradovaném), jak sám máte v citaci toho článku. The ELAC B L104 standard introduces the following main SBS functions: – Addition of the Pitch Attitude Limitation in Alternate Law (PALAL) for all CEO/NEO,except A318: pitch positive angle limitation is available in alternate law, in clean configuration with settings function of altitude. Stall potential situation… Číst vice »
No, mně to právě přijde, že ten upgrade (a logicky i následný downgrade) poměrně zásadně mění chování v některých situacích, o čemž teda diskutované AOT/EAD tak nějak cudně mlčí. Nezdá se mi to úplně dobré. O tom MCASu na Maxech piloti taky neměli ani tušení. :-/
Tak chápu, že účelem EAD je jen revertovat nežádoucí stav a předchozí software byl plně homologovaný. Jakým jak je podmíněn přenos informace o změnách v chování Alternate k posádkám, pokud se vůbec děje, nemám tušení.
Taky netuším, ideální mi to rozhodně nepřijde.
Týká se ten problém jen A320 nebo celé A320 family (320, 321, 319)?
Mic hezky napsany clanek – https://www.aviacionline.com/english/manufacturers-mro/structural-risk–why-easa-just-ordered-an-emergency-fix-for-airbus_a6929ff80714f61d9c33a493b z toho uz chapu tu podstatu. A jo, tohle neni hezka vec.
Celé rodiny.
Celé rodiny, konkrétně se ale spíše jedná o to, jaký software mají nainstalovaný v jednotkách ovládajících výškovku.
Doufám že letadla ukradená do Ruska na svolávací opravu nebudou mít nárok.
Nemusí se jich to týkat, záleží na kombinaci HW (ELAC série B L104) a SW. Navíc zdroje jsou bohužel zmatené (viz i číslo letu má ČTK špatně, je to 1230). Tím bych očekával, že se v nejhorším dá udělat revert (jak uvádějí některé zdroje, některé uvádějí update) a tím se dostáváme k tomu, kdy se tam ta daná verze SW dostala. Jestli náhodou během těch 4 let, nebo je starší a přišlo se na to až teď.
A jelikož jde o kombinaci SW s HW, pořád ti barbaři mohou propašovat, jinou verzi HW
Airbus by jim měl podstrčit nějakou verzi SW, která způsobí že letadlo dvě vteřiny po vzletu vypne oba motory.
RuSSáci pak ta letadla nasadí na běžné komerční spoje pro plebs, a toto rozhodnutí zabije desítky či stovky nevinných lidí.
Jakkoliv nemám RUSSáky rád, tak takto vraždit civilisty se nedělá ani při oficiálně vedené otevřené válce.
A jinak normální?
Je update softwaru považován za náhradní díl a můžou se na něho tím pádem vztahovat sankce?