Adatok
srip
0 bejegyzést írt és 25 hozzászólása volt az általa látogatott blogokban.
Talán még repülésért rajongónak sem kell lenni ahhoz, hogy valaki mostanában sokat halljon-olvasson az amerikai Boeing repülőgép-gyártóról, a 737 MAX tavalyi indonéz és idei etióp balesete kapcsán. Nem túl gyakori az olyan, repülést érintő katasztrófa, amely ennyire egyértelműen a típus hibájára…..
srip
2019.05.11 22:48:48
@KennyOMG: Érdekes volt a repüléstechnikai gyorstalpaló, egészen jól elmagyaráztad a dolgokat, és azt hiszem, értem az egészet, beleértve a stab felépítését és koncepcióját.
Amibe nem mentél bele részletesen, az az, hogy az MCAS pontosan mit, mikor és miért csinál. Amennyire én értem:
– az MCAS-nak a Boeing által deklarált célja az, hogy a gép kormányozhatósága megegyezzen a régebbi modellével
– ezt azzal éri el, hogy a stabot mozgatja (de a magassági kormányt direkt módon nem)
– a deklarált elvi cél szerint ezek apró, finom mozgások, amelyek egyetlen funkciója az, hogy a pilóta úgy érezze, a régebbi modellt kormányozza,
– viszont egyrészt a stab elmozdítása direkt módon kormányozza a gépet,
– másrészt magassági kormány nullpontja is változik ilyenkor, tehát a magassági kormányra is erőhatás kerül (tekinthetjük ezt indirekt kormányzásnak?)
– tehát technikai értelmeben az MCAS direkt és indirekt(?) módon is képes kormányozni a gépet,
– tényként kezelhetjük, hogy az MCAS (legalábbis hibás működés esetén) olyannyira kormányozni a gépet, hogy zuhanásba is kormányozhatja.
Nem tudom, ez eddig mennyire helyes.
És akkor jön a lényegi kérdés: jól értem, hogy az MCAS beavatkozik átesésközeli helyzetben, a gép orrát lefele nyomva (ezt a hatást a teljes stab, és nem a magassági kormány eltérítésével érve el)?
Ha ezt is jól értem, akkor kezd filozofikussá válni a kérdés, hogy akkor ez mennyiben átesésgátló rendszer. Kizárólag erre hozták létre? Nem, elvileg a régivel megegyező kormányozhatóság volt a cél, de mivel a régi nem volt hajlamos átesésre, az új meg igen, a régivel megegyező kormányozhatóság egyik fontos (mondhatjuk, hogy legfontosabb?) eleme az volt, hogy ugyanúgy ne essen át, mint a régi.
Persze a hagyományos átesésgátló rendszerektől például abban is különbözik, hogy azok a magassági kormánnyal avatkoztak be, míg ez a teljes stabot mozgatja (jól értem?). Kérdés, hogy ettől még mondhatjuk-e, hogy akkor ez nem egy átesésgátló rendszer? Mondhatjuk-e, hogy a Wikipédia és a többi szakember félrebeszél, amikor az MCAS lényegi funkciójának az átesés megakadályzását látják?
Amibe nem mentél bele részletesen, az az, hogy az MCAS pontosan mit, mikor és miért csinál. Amennyire én értem:
– az MCAS-nak a Boeing által deklarált célja az, hogy a gép kormányozhatósága megegyezzen a régebbi modellével
– ezt azzal éri el, hogy a stabot mozgatja (de a magassági kormányt direkt módon nem)
– a deklarált elvi cél szerint ezek apró, finom mozgások, amelyek egyetlen funkciója az, hogy a pilóta úgy érezze, a régebbi modellt kormányozza,
– viszont egyrészt a stab elmozdítása direkt módon kormányozza a gépet,
– másrészt magassági kormány nullpontja is változik ilyenkor, tehát a magassági kormányra is erőhatás kerül (tekinthetjük ezt indirekt kormányzásnak?)
– tehát technikai értelmeben az MCAS direkt és indirekt(?) módon is képes kormányozni a gépet,
– tényként kezelhetjük, hogy az MCAS (legalábbis hibás működés esetén) olyannyira kormányozni a gépet, hogy zuhanásba is kormányozhatja.
Nem tudom, ez eddig mennyire helyes.
És akkor jön a lényegi kérdés: jól értem, hogy az MCAS beavatkozik átesésközeli helyzetben, a gép orrát lefele nyomva (ezt a hatást a teljes stab, és nem a magassági kormány eltérítésével érve el)?
Ha ezt is jól értem, akkor kezd filozofikussá válni a kérdés, hogy akkor ez mennyiben átesésgátló rendszer. Kizárólag erre hozták létre? Nem, elvileg a régivel megegyező kormányozhatóság volt a cél, de mivel a régi nem volt hajlamos átesésre, az új meg igen, a régivel megegyező kormányozhatóság egyik fontos (mondhatjuk, hogy legfontosabb?) eleme az volt, hogy ugyanúgy ne essen át, mint a régi.
Persze a hagyományos átesésgátló rendszerektől például abban is különbözik, hogy azok a magassági kormánnyal avatkoztak be, míg ez a teljes stabot mozgatja (jól értem?). Kérdés, hogy ettől még mondhatjuk-e, hogy akkor ez nem egy átesésgátló rendszer? Mondhatjuk-e, hogy a Wikipédia és a többi szakember félrebeszél, amikor az MCAS lényegi funkciójának az átesés megakadályzását látják?
srip
2019.05.12 14:51:43
@KennyOMG:
„A MCAS nem »atesekozeli« helyzetben avatkozik be. Hiaba ismetelgetik ezt sokan sok helyen, attol meg nem lesz igaz. Egy bizonyos AoA ertek felett mukodik, pont, az atesesi pont azonban meg sok mastol is fugg.”
Nagyon érdekes, hogy különböző források mennyire különbözőképp látják ezt (pedig ez egy IGEN/NEM kérdés, interpretációs lehetőség nélkül). A Wikipédia két forrás alapján állítja, hogy „The system uses airspeed, altitude and angle of attack (AOA) sensor data to understand the aircraft condition and then trims the tailplane nose down to avoid an aerodynamic stall.” A b737 technical site a te verziódat mondja (azaz csak AoA-ról beszél), bár nem látom fehéren-feketén, hogy NEM használ fel semmi más információt.
Na mindegy, ez az aspektus az én mondanivalómat nem igazán érinti. Az eddigiek alapján az tiszta, hogy az AoA bemenet alapján az MCAS a gépet zuhanásba tudja nyomni, tehát egy ilyen funcionalitást egy szenzorra szerelni idiótaság, és szembemegy a szakma elementáris szabályaival.
Hogy ezt tekintjük a katasztrófák elsődleges okának, vagy az MCAS tényét magát, nézőpont kérdése. Lehet, hogy egy szakmabelinek a haja égnek áll a gondolattól, hogy MCAS-t szerelünk egy 737-esre, és önmagában az MCAS-737 párosítást látja az elsődleges szakmai hibának – nem tudom. Abban viszont biztos vagyok, hogy minden hozzáértő mérnöknek égnek áll a haja attól, hogy egy szenzorra szerelték az MCAS-t.
Ezért volt számomra megdöbbentő, hogy az esemény utáni cikkek írói (beleértve a megszólaltatott szakembereket) milyen könnyen siklottak át ezen a kérdésen, és 10 cikkből 8-9 meg sem említette, hogy micsoda elementáris mérnöki baki volt a katasztrófák elsődleges kiváltó oka. Ez a blog is egyike volt ezeknek az írásoknak (hosszan magyarázza a nagyobb motor, megváltozott aerodinamika stb. kérdéseket, a szenzor tematikája elsikkadt).
Egyébként meg köszönöm a részletes leírásokat, sokat tanultam belőlük.
„A MCAS nem »atesekozeli« helyzetben avatkozik be. Hiaba ismetelgetik ezt sokan sok helyen, attol meg nem lesz igaz. Egy bizonyos AoA ertek felett mukodik, pont, az atesesi pont azonban meg sok mastol is fugg.”
Nagyon érdekes, hogy különböző források mennyire különbözőképp látják ezt (pedig ez egy IGEN/NEM kérdés, interpretációs lehetőség nélkül). A Wikipédia két forrás alapján állítja, hogy „The system uses airspeed, altitude and angle of attack (AOA) sensor data to understand the aircraft condition and then trims the tailplane nose down to avoid an aerodynamic stall.” A b737 technical site a te verziódat mondja (azaz csak AoA-ról beszél), bár nem látom fehéren-feketén, hogy NEM használ fel semmi más információt.
Na mindegy, ez az aspektus az én mondanivalómat nem igazán érinti. Az eddigiek alapján az tiszta, hogy az AoA bemenet alapján az MCAS a gépet zuhanásba tudja nyomni, tehát egy ilyen funcionalitást egy szenzorra szerelni idiótaság, és szembemegy a szakma elementáris szabályaival.
Hogy ezt tekintjük a katasztrófák elsődleges okának, vagy az MCAS tényét magát, nézőpont kérdése. Lehet, hogy egy szakmabelinek a haja égnek áll a gondolattól, hogy MCAS-t szerelünk egy 737-esre, és önmagában az MCAS-737 párosítást látja az elsődleges szakmai hibának – nem tudom. Abban viszont biztos vagyok, hogy minden hozzáértő mérnöknek égnek áll a haja attól, hogy egy szenzorra szerelték az MCAS-t.
Ezért volt számomra megdöbbentő, hogy az esemény utáni cikkek írói (beleértve a megszólaltatott szakembereket) milyen könnyen siklottak át ezen a kérdésen, és 10 cikkből 8-9 meg sem említette, hogy micsoda elementáris mérnöki baki volt a katasztrófák elsődleges kiváltó oka. Ez a blog is egyike volt ezeknek az írásoknak (hosszan magyarázza a nagyobb motor, megváltozott aerodinamika stb. kérdéseket, a szenzor tematikája elsikkadt).
Egyébként meg köszönöm a részletes leírásokat, sokat tanultam belőlük.
Vajon minek köszönhető, hogy a minden elképzelhetőnél alacsonyabb morális szinten, teljesen ötlettelenül kampányoló kormánypárt a 2 hét múlva esedékes választások toronymagas esélyese? Pontosítva a kérdést: az ellenzéki oldal miért nem adta meg nekünk, egy rendes országot óhajtó magyar embereknek, a…..
Mekkora teljesítményt buksz az Intel (meg az AMD és az ARM) processzorok nemrég felfedezett hibája miatt? Tényleg 5-30% lesz a bukó, ahogy a gyártók tippelték? Megmértük! ..
srip
2018.01.06 20:53:14
@Papírzsepi: nem értem ezt a másik szálba történő cache átszivárogtatást, amiről beszélsz. El tudnád konkrétan magyarázni, hogyan is működik ez pontosan?
Amennyire én értem:
– a szálaknak semmi közük ehhez az egészhez,
– bár először én is úgy értettem, hogy a cache-be a védett memóriából betöltött adat valamilyen cache zsonglőrködéssel olvashatóvá válik, de nem, az Intel ilyen szempontból korrektül van tervezve, a védett adat nem hozzáférhető,
– a védett adathoz való hozzáférés kizárólag a cache olvasási sebességéből spekulálható vissza.
Rosszul értek valamit?
Amennyire én értem:
– a szálaknak semmi közük ehhez az egészhez,
– bár először én is úgy értettem, hogy a cache-be a védett memóriából betöltött adat valamilyen cache zsonglőrködéssel olvashatóvá válik, de nem, az Intel ilyen szempontból korrektül van tervezve, a védett adat nem hozzáférhető,
– a védett adathoz való hozzáférés kizárólag a cache olvasási sebességéből spekulálható vissza.
Rosszul értek valamit?
srip
2018.01.08 11:56:40
@Papírzsepi: a Meltdown rész tiszta, csak amit @Szabványok-nak is mondtam, azt most is tartom: a ti példátokban egy bájthoz 256 olvasás kell, amiből 255 cache miss, míg az én példámban 1 bithez 2 olvasás kell, amiből 1 cache miss, azaz egy bájthoz 16 olvasás és 8 cache miss kell. Tehát amennyire látom, a bitenkénti hozzáférés gyorsabb, kisebb memóriaigényű, egyszerűbb. Annyi elvi problémája van, hogy ha közben változik az adat, akkor korrupt bit jön le, de ez memóriamező olvasásánál bájt szinten ugyanúgy áll, tehát irreleváns.
A Spectre rész: ezt a részt nagyon nem értem. A Meltdown ugye AMD esetén nem működik. Nem tudom, miért, vagy az access violation ellenőrzés hatékonyabb (tehát védett memóriából kiolvasott adattal NEM történik semmiféle művelet), vagy a cache ürítését végzi okosabban. Ha ez így van, akkor nem értem, hogy tudja a Spectre átverni az AMD-t lényegében egy ugyanolyan trükkel, mint a Meltdown.
A Spectre rész: ezt a részt nagyon nem értem. A Meltdown ugye AMD esetén nem működik. Nem tudom, miért, vagy az access violation ellenőrzés hatékonyabb (tehát védett memóriából kiolvasott adattal NEM történik semmiféle művelet), vagy a cache ürítését végzi okosabban. Ha ez így van, akkor nem értem, hogy tudja a Spectre átverni az AMD-t lényegében egy ugyanolyan trükkel, mint a Meltdown.
srip
2018.01.08 19:54:38
@Papírzsepi: Hát nekem nagyon nem tiszta az egész. Egyrészt ha az utasítások száma a probléma, akkor lényegében 2 utasításból meg lehet hekkelni:
xor eax, eax // töröljük az EAX-et
mov ah, [védett memória] // betöltjük a védett adatot 256-tal szorzott helyre...
mov eax, [edx + eax] // ... és rögtön fel is használjuk, ezzel már a cache-ben van a csali
Tehát lényegében 1 utasítással a védett olvasás után már be is fejeztük a hekket, benn van a csali a cache-ben. Ha az AMD engedne 2-3 utasítást lefutni, akkor a fenti kód menne ott is. Szerintem AMD-n azért nem megy a trükk, mert vagy egyből ellenőrzi, vagy a cache-et üríti.
És akkor megérkeztük a Spectre részhez, ahol ezek szerint AMD-n semmi esély, hogy ezzel a típusú trükkel átverhető lenne. Szerintem a Spectre valami egyebet csinál, csak én nem értettem, hogy mit.
xor eax, eax // töröljük az EAX-et
mov ah, [védett memória] // betöltjük a védett adatot 256-tal szorzott helyre...
mov eax, [edx + eax] // ... és rögtön fel is használjuk, ezzel már a cache-ben van a csali
Tehát lényegében 1 utasítással a védett olvasás után már be is fejeztük a hekket, benn van a csali a cache-ben. Ha az AMD engedne 2-3 utasítást lefutni, akkor a fenti kód menne ott is. Szerintem AMD-n azért nem megy a trükk, mert vagy egyből ellenőrzi, vagy a cache-et üríti.
És akkor megérkeztük a Spectre részhez, ahol ezek szerint AMD-n semmi esély, hogy ezzel a típusú trükkel átverhető lenne. Szerintem a Spectre valami egyebet csinál, csak én nem értettem, hogy mit.
Belépve többet láthatsz. Itt beléphetsz
Hát én kifogásoltam KennyOMG stílusát, de így utólag és a tiédhez képest valójában egy angol úriember volt. Belegondolni se merek, milyen nemi életük lehet azoknak, akikben annyi frusztráció és gyűlölet halmozódik fel, hogy megengednek maguknak ilyen stílust embertársaikkal szemben – még ha azok adott esetben tévednek is.
Ami a konkrétan nekem címzett kritikát illeti, a jelek szerint az Airbus „könyvtárosainak” nem okozott problémát, hogy több AoA szenzort szereljenek a gépeikre, itt van például egy kép az A330 két egymás melleti AoA szenzoráról:
www.aviationcv.com/aviation-blog/wp-content/uploads/2019/03/Airbus-A330-Angle-Of-Attack-Sensors.png
Tehát a kép alapján ez minimum 4 szenzort jelent (mert ugye a gép másik felén is van ugyanígy kettő). Továbbá a kép alapján az is nagyjából világos, hogy volna ott hely még rengeteg szenzornak.
Szóval lehet, hogy én helyedben kétszer elgondolkoznék, mielőtt lehülyézek valakit – mármint hogy legalább ilyenkor ne beszéljek hülyeségeket. Bár még ennél is sokkal jobb nem lehülyézni senkit, hanem civilizáltan és érvekkel vitatkozni, ha valamiben nem értesz egyet.