|

Nyolc F-22-es érkezett Japánba

Egy Raptor-pilóta sem jelentett oxigénhiányos tüneteket abból a nyolcból, akik múlt szombaton áttelepültek Japánba, a Kadena légitámaszpontra. Mint ismeretes, az Amerikai Egyesült Államok Légiereje egy századnyi F-22-est telepít át a szigetországba, annak ellenére, hogy a típus fedélzeti oxigénellátó rendszerével sokak szerint még mindig nem oldódott meg a probléma. Norton Schwartz vezérezredes, a USAF vezérkari főnöke nemrég a Combat Edge anti-G ruha egyik szelepének rendellenes működését, valamint az oxigénáramlást befolyásoló szűrők egyikének hibáját nevezte meg, mint a hypoxia-tünetek okozói. Miután ezt Leon Panetta védelmi miniszterrel is tudatta, utóbbi számos repüléskorlátozást feloldott a Raptorokra vonatkozólag, így lehetségessé vált azok átrepülése Japánba.

Az első körben 12 gép áttelepítéséről döntöttek, ezek közül nyolc már gond nélkül megérkezett, a többi négy a napokban követi őket. A bevetéstervezők a szokásosnál alacsonyabb repülési magasságot határoztak meg ez alkalommal, valamint úgy alakították ki az útvonalat, hogy egy esetleges hypoxia-tünet esetén mindig legyen a közelben egy repülőtér, hogy a kényszerleszállást ne vízre kelljen végrehajtani. Ha pedig mégis erre került volna sor, a haditengerészet kutató-mentői folyamatosan készültségben álltak a körzetben. Szerencsére semmi ilyesmi nem történt, a pilóták gond nélkül teljesítették a távot.

http://youtu.be/Ovf4LIMAPtA
Az F-22-esek érkezése Kadenára

Idén egyébként nem ez volt az első, hogy a folyamatosan korlátozásokkal sújtott Raptor-flotta néhány gépe áttelepült egy másik kontinensre: áprilisban az Egyesült Arab Emírségekben található Al Dafra támaszpontra érkezett egy század F-22-es. Akkor még a mostaninál is többen kételkedtek benne, hogy baleset nélkül ússzák meg a kalandot, de szerencsére akkor sem történt semmilyen különös esemény. Schwartz vezérezredes akkor is, és most is hangsúlyozta: bármennyire is valósak a problémák, az F-22-es a legmodernebb harci repülőgépük, amivel gyakorlatozni kell, és fent kell tartani a pilóták képzettségi szintjét, ehhez pedig szükséges az efféle áttelepülések végrehajtása.

A hajózók és műszakiak körében ettől függetlenül még mindig nem örvend túl nagy népszerűségnek a Raptor.
„Egy valamiben biztos vagyok: nem a Combat Edge a tettes.” – nyilatkozta egy neve elhallgatását kérő pilóta.

A Raptor problémájával foglalkozó USAF-kutatólabor szakértői stábja hamarosan hosszabb terjedelemben szándékozik tudatni a világgal, hogy mire jutottak az elmúlt időszakban a hypoxia-tünetekkel kapcsolatban.

59 hozzászólás “Nyolc F-22-es érkezett Japánba”

  1. Hans: Én egy cikkben azt olvastam “F-22s fly ing from Okinawa” ebből következtetem hogy ott állomásoztak. Ez egy viszonylag régi cikk,2010-es.
    http://thediplomat.com/2010/06/28/why-allies-need-okinawa-base/
    Bár lehet hogy a cikkben lévő kép nem ott készült csak szemléltetésül volt ott. Minden esetre Okinawa szigetén lévő légibázis képe a Google térképen csaknem üres. Gyanúsan. De lehet hogy tévedek.

  2. Azonban most hogy ide beírtam még egyszer megnéztem és láss csodát a Google térképen a bunker előtt ott pózol egy F22. De nem is egy hanem 6 darab. Elég elmosódott a kép de ott vannak. Bár lehet hogy tévedek, de a cikk képe ráillik a helyre.Szélesség 26.355999° magasság:127.778939°

  3. Egyébként ez a dolog a miatt izgatott és azért van a cikk elmentve, mert most már nyilvánosságra került az oxigénrendszer hibája az F22 esetében. Ha a gépek ott tartósan állomásoztak, (1-2 évig) akkor előfordulhatott hogy gépet vesztettek és ez a Kínaiak kezébe került. Nos én nem adtam volna vissza. Azt olvastam hogy a kínaiak lelőttek egy F22 gépet. De az is lehet hogy a pilóta magatehetetlen volt, így már akár könnyű préda még egy kínai gépnek is. Néha a képtelen dolgok is igazak lehetnek.

  4. “Azt olvastam hogy a kínaiak lelőttek egy F22 gépet. De az is lehet hogy a pilóta magatehetetlen volt, így már akár könnyű préda még egy kínai gépnek is. Néha a képtelen dolgok is igazak lehetnek.”

    Nevetséges, meg az is, hogy, ezen valaki el is gondolkodik. Ezen tényleg jót derültem.

  5. Lényeg az hogy hogy amit leírtam azt mindenki ellenőrizheti, a megadott helyen a gépek az adott időpontban ott voltak. A cikk 2010-es a kép 2009 állapotot tükrözi. A fotó és a koordinátán lévő kép egy adott helyen van. A lényeg ez. Az hogy történt -e valami azt senki sem tudja, és ma már teljesen mindegy. Tény és való hogy a kínaiak a semmiből előálltak egy új géppel. Nos a dátumok kb 3 évvel ezelőttiek. Mindenki azt gondol amit akar. De egy ország amelyik még tisztességes hajtóművet sem gyártott addig (” egyesek szerint még ma sem”)(de az is igaz hogy nem a nulláról indultak, köszönhetően a betelepült cégeknek)) kicsit túl nagy evolúciós ugrásnak tűnik.

  6. commandate: kérném az anyag nevét és díler címét, köszönöm

    Japánban már voltak Raptorok, igaz, csak második nekifutásra ment a dolog, először a dátumváasztó átlépésekor a navigációs rendszer kifagyott.
    Wiki szerint: 2007 februárjában mintegy öt hónapra az egész 27. FS áttelepült Japánba, az Okinawán található Kadena AFB-re, ahol elsősorban japán repülőgépek ellen folytattak légiharc-gyakorlatot (az első hét után a kiváló 140:0 lelövési arányt és szintén kitűnő 97%-os hadrafoghatóságot elérve)

  7. Én is kérdeznék. A napfényre került oxigén ellátó rendszeren mit változtattak a rendszerbeállítás és a sorozatgyártás során vajon? Mivel ezt senki sem tudja valószínűleg, de az eddig olvasott sajtó alapján valószínűleg semmit, mert akkor már lenne megoldás. Ha nem, akkor a hiba már a kezdetek óta fenn állt. Mint ahogy a cikk szerint ma is.

    “dátumváasztó átlépésekor a navigációs rendszer kifagyott.” Ez egy vicc?

  8. dátum:
    nemtudom volt e ilyen de el tudom képzelni. anno nagyon komoly problémák voltak ilyen és ehez hasonló dolgok miatt még nagygépes környeteben is anno 2000ben. De ha jól emlékszem a google/MS felhő ugy amblokk kiesett pl idén 4-5hra egy hasonló eset miatt. Amikor 4-5hig nincs pl Gdrive üzleti felhasználók felé az azért irtózatosan durva hiba.
    Szóval nem lepődnék meg ha azért mert visszapörgött az idő 1napot hirtelen a program nem tudná értelmezni és lefagyna/msgwre… futna.

  9. Terminátor: Igen ez az amit próbálok jelezni. Ezt a cikket már olvastam. Nos mivel az ilyen TESCO-s szöveg ami a belinkelt cikkbe van már a saját régebbi életemben is a könyökömön szokott kijönni, ezért erősen allergiás vagyok rá, és legtöbb esetben az állt elő a valóságban hogy a gyártónak fogalma sincs mit kéne tenni vagy mi a hiba oka, ezért pótcselekvéseket csinál és igyekszik megnyugtatni a kedélyeket. Azt sugallja hogy minden rendben de a valóságban nincs megoldás és nem is lesz egyhamar. Legnegatívabb esetben lövésük sincs mi a kiváltó ok.

    Mondok egy példát kicsit torzítva ne hogy ráismerjünk a márkára:

    “Visszahívási akció neves autógyártónál: Értesítjük kedves Ügyfelünket hogy a gyártás fokozatos ellenőrzése során megállapítottuk hogy bizonyos sorozatszámú autóknál a kormánykerék rögzítő csavarját elfelejtették meghúzni. Emiatt az autó legrosszabb esetben kormányozhatatlanná válhat. Az Ön autója is érintett lehet ezért kérjük és keresse fel szervizünket hogy a hibát kijavíthassuk.”

    Hogy erre a hibára hogyan lehet rájönni, az olvasó fantáziájára bízom. “kb mint az F22 hibájára (kell egy roncs vagy túlélő)”

  10. Ha tényleg lenne ilyen dátum probléma azért nem kellett volna japánba menni hogy felfedezzék elég ha csak az USA légterébe repül át egy időzónából a másikba… Az meg hogy a 2000 es évnél gondok voltak … egy adott évbe való lépésnél a számítógépnek tök mind1 hogy 1999ből 2000 be lép át vagy 2011 ből 2012 be mert neki az csak egy számkombináció 0val és 1el. (aki nemhiszi álicsa át a gépét most 1999 dec 31 11:59 re és várjon 1 percet) nem fog lefagyni a gép. Az F-22 dátumváltásánál mégegyszer hangsúlyozom ha problémák lettek volna már az már usa légtérbe feltünt vólna ugyanis ott is 5 időzóna van. Tehát ha keletről nyugatra halad egy F-22 és átlép 1ik időzónából a másikba máris -1 óra (amivel ha igaz lenne a dátumváló probléma se tudna megküzdeni mert -1 óra vagy -1 nap nem számítana)

  11. De mondjuk ha ez igaz lenne meglenne az új csodafegyver ha megtámadnak egy országot akkor a vezetők csak hirtelen hoznak egy törvényt hogy ÓRA ÁTÁLÍTÁS és már potyog ropog minden le az égből az ellenség komunikációs rendszere hírtlen összeomlik a harckocsik megvadulnak a kilőtt rakéták nem robbannak várnak egy órát a katonák meg hazasétálnak a bázisra mert a támadás csak egy óra múlva lesz.

  12. @szittya88:
    kérlek ne bagatellizáld az y2k problémát, és ne osszad az észt olyan témában, amihez láthatóan lövésed sincs. A processzornak valóban csak számok, de a progranak már jelentéssel bírnak. És a gépek nem csak vasból, de kódból is állnak (legalábbis amikor használjuk is őket). A dátumkezelés nehézsége meg többek közt abból fakad, hogy igen organikusan fejlődött és sokféle az időszámítások halmaza, és ezeket mindet hibátlanul kezelni nehéz feladat. Ezt azért többé-kevésbé megoldották már, nagy keretrendszerekben, ezért jó a kódujrahaszosítás, és ha valaki ezt nem alkalmazza, akkor jön a pofára esés. Lásd: a tavaszi Azure leállás. Valaki jobban kezelte a dátumokat mint a keretrendszer: a február 29.-e + 1 évnél cask az evszémhoz adott egyet, és összecsinálta magát a rendszer, mert más helyeken a rendes megvalósítást használták, és ők 2013 febr. 29.-ét érvénytelen dátumnak találták. (ezután az érvénytelen dátumot tartalmazó titkosítási kulcsot kizárták, ami után pedig, mivel az az egész számítógép hálózat vezérlőgépének kulcsa volt, elveszett a vezérlés a rendszer felett) Képzeld ezt el mondjuk egy barát/ellenség rendszerrel, ahol a barát vagyok jel időkódja érénytelen a másik fél szerint. Repül a rakéta, megvan a friendly fire!

    A dátumválasztó vonalad dolgot meg elég ha elolvasod, hogy hogy van, és elsőre te is belezavarodsz szerintem, szóval lehet könnyen viccelődni, de nem triviális problémák ezek, és így szinte biztos is, hogy hiba is előfordulhat bennük. Az viszont rossz fényt vet az kivitelezőkre, hogy nem tesztelték le ezeket a minden safety-critical computing szakkönyvben triviálisan ellenőrizendő hibákként felsorolt dolgokat, és még rosszabbat, ha letesztelték, de átcsúszott a teszten!

  13. “Az viszont rossz fényt vet az kivitelezőkre, hogy nem tesztelték le ezeket a minden safety-critical computing szakkönyvben triviálisan ellenőrizendő hibákként felsorolt dolgokat, és még rosszabbat, ha letesztelték, de átcsúszott a teszten!”

    Az elmult ket evben haromszor volt nyari-teli idoatallitos moka miatt problemank (a problema szo itt eufemizmus). Ebbol a harombol ketto ugyanaz a kod, a kedves kollega a tel->nyar valatast kijavitotta az elso hibara, aztan a nyar->telnel kiderult, hogy azzal is illett volna foglalkozni. Es ez se egy kis ceg, elvileg profi programozokkal, cutting edge technologiaval.
    Csak az a franya human faktor.

  14. 1999 december 31 a világ Gergely naptárt használó része végveszélybe került az emberek az utcákon hordákba összeverődve fogyasztják az alkoholt (Tudják hogy itt a világvége csak pár perc és mindennek vége.)
    De nincs még minden veszve informatikusok egy maréknyi csoportja készen áll megmenteni a világot (AKÁR A SZILVESZTERE ÁRÁN IS.)
    A tét nem kicsi a világ sorsa forog kockán (vált vagy nem vált az óra.)
    Vajon meg birkóznak a gonddal. Vagy elbukik az egész nyugati civilizáció?
    -Már csak másodpercek vannak visz. (Eddig még soha senki nem próbálkozott a világon átállítani az órát a dátumot a 2000 évek utánra.) Kivétel a föld lakosságának 99%át. Ők tudják a választ hogy mi fog történni…………
    Megtörtént a váltás 99.9999999999% sikeres volt.
    De történtek katasztrófák Ausztráliában egy tucat buszjegy automata nem bírt megbirkózni az új dátummal (vagy csak nem volt a 2es bilengyű a nyomtatóba? a választ senkise tudja) a világ dátum pecsételőinek nagyrésze is odalett hiszen nem vólt 2000 év a pecséten.
    Egy bank is sajnos áldozatáúl esett és milliókat kaszált végűl.
    A szoftvercégek erőltetett tempóba új szoftvert állítottak elő amit sajnos csak pénzért értékesíthettek.
    Szerencsétlenek akik nem vették meg másnap amikor bekapcsolták internet nélküli gépüket amire a az új korekciós szoftver se lett megvéve telepítve MŰKÖDÖTT működött………

  15. szittya88:

    a dátumvonalnál nem +/- 1 óra váltás van….

    Helyi idő szerint 2012.08.01-én szerdán 14:00-kor felszállsz Midway-ről és 3 óra repülés után leszállsz Wake szigetén. Hány óra van a leszálláskor Wake szigetén? És melyik nap?

  16. Igen a dátum vonalnál nem +- 1 óra de az hogy +- 1 óra vagy +-1 nap teljesen lényegtelen ha a szoftver hibás.
    De a legegyszerűbb dolog lenne az amerikaiaknak ha az össze harceszközt állandó Washingtoni időre állítanák be (a pilóta legfeljebb nem nézegetné hogy milyen nap van ma vagy mennyi a pontos idő afölött a terület fölött ami fölött repül ) a helyi idő végülis lényegtelen számára hisz parancsra cselekszik akkor amikor parancsba kapja.

  17. Rákerestem az IFF kódkiosztására csak a példa miatt és egységesen kerül kiosztásra az új kód helyi időtől függetlenül (ami logikus mert pont az dátumvonal miatt lenne kiskapu a rendszerben ha ezt nem egységes idő szerint osztanák ki hanem helyi idők szerint).
    Terminator a dátumváló helye valójában bárhol lehetne a földön csak egy kijelölt vonal (Grinics miatt lett a 180 fok az) annyi a lényeg hogy a 180. hosszúsági fok egyik oldalán mondjuk 1.van a képzeletbeli vonal másik felén meg már 2.a pontosan éjfélkor (persze ez a vonal valójában nem teljesen egyenes) és ahogy mozog a tengely úgy lép be a mögötte lévő terület az új napba.

  18. Ja és az usa vadászgépei központi számítógépe is washingtoni időre vannak beállítva (tehát bárhol legyenek a föld bármely pontján a gép úgy érzékeli az időt mintha a fővárosba lenne.) Mondjuk írtam is hogy szerintem ez a logikus és a legegyszerűbb.

  19. Nincs az ebbe semmi bonyolult ebbe a dátumvonal dologba amit elsőre ne lehetne megérteni ugyan az mindha átrepülne egy szimpla időzónán éjfélkor csak ennek más a neve. ugyanúgy +-1 óra a különbség tehát a vonal egyik felén elhelyezkedő időzónába január 1. 23:01 van addig az dátumvonal másik felén január 2. 00:01 (de ugyan ez a helyzet az összes időzóna vonalnál is) csak ennek adtak egy nevet és ezt használják kiindulási pontnak.

  20. A dátumvonal grinics miatt van ott ahol mert grinics a nulla annak a túloldala a dátumvonal.
    Egy példa hogy ez máshol is van (mert a főld forog ha) és ezért az időzónák közt minden nap van dátumkülömbség.
    Amikor a amikor a közép európai idő szerint Magyarországon 23:01 óra van aadig a meletünk lévő Kelet európai időzónába Romániába már másnap 00:01 van. (itt is itt a dátumbeli különbség) semmi extra ugyanúgy 1 óra a különbség a szomszédos időzónával. Csak Veér István csinál úgy mintha atomfizika lenne pedig ehhez nem kell egyetem.

  21. molnibalage szerint: 2012. augusztus 2. csütörtök @ 00:14

    De a gps navigációnak mindegy hogy augusztus 1 vagy augusztus 2 van, nem?
    Atomórák, távolság és időmérés alapján meghatározott helyzet, de mi köze ehhez a dátumváltás problémájának?

    (Valahol egyszer már lement ez a beszélgetés, de nem emlékszem hol.)

  22. Valójábban semmi köze ezt próbálom magyarázni. (mert a mi általun mért idő nem pontos idő mert nem minden nap delel 12:00 kor. Sőt valójában egy évben csak egyszer delel délben a nap)
    ezért használnak egységes időt a az ilyen eszközökhöz tök mind1 hogy a világ meky pontján vagy (egy angliába vásárolt GPS is működik máshol is a proceszor órája egységesen van belőve helyi időtől fügetlen az hogy te funkcióként beálítod a pontos időt rajta 1 dolog a proceszor órájához nem tudsz hozzáférni) (vagy hát hozzá lehetne de akkor kukázhatod a készüléket)

  23. az olcsó GPS ek azért pontatlanok mert az órájuk nem pontos (a katonai gps eknél is amikor aztakarod hogy pontos legyen akár dm-re megkapja a pontos időt azt ami a műholdnak a pontos idő.) A gps vezérlésű bombák rakéták azért drágák mert a bennük lévő óra nagyon pontosan “jár” és pontosan azon az időn mint a műholdak ez az idő titkos ha nem lenne titkos bárki tudna dm pontos gps-t gyártani aki megfelelően pontos időmérőt is tud gyártani.

  24. Szittya88:
    Az időkezelés a szoftverekben egyáltalán nem triviális probléma.
    Ahogy már valaki említette, például a szökőévek kezelése is okozhat problémát, de akár hiszed, akár nem, a szökőmásodpercek is. Ezek teljesen véletlenszerűen kerülnek néha beiktatásra, így algoritmikus módszerekkel az időpontjukat lehetetlen megállapítani.

    Az Y2K probléma sem vicc, a lényege az, hogy az évszámokat sok program csak két tizedesjegyig tárolta, mivel amikor megírták (akár 30-40 évvel korábban), minden eszközzel próbáltak spórolni az akkor még nagyon drága memórián, ugyanakkor fel sem merült, hogy ezek még az ezredfordulókor is futni fognak valahol.
    A problémát tovább tetézi, hogy ezek jellemzően nem PC-s desktop alkalmazások voltak, hanem beágyazott rendszereken futó kódok illetve nagy (pl banki) rendszerek, tehát a lecserélésük, “újratelepítésük” is komoly nehézségekbe tudott ütközni, illetve a kód átírását is nehezítette az, hogy (mint a legacy szoftvereknél általában) a forráskód gyakran elveszett, vagy ha meg is volt, a módosítást végző fejlesztők számára átláthatatlan volt, az eredeti fejlesztők pedig (akik 30-40 éve megírták) már jó eséllyel halottak, vagy elérhetetlenek.
    Természetesen a problémára nem szilveszter éjjel jöttek rá, a kérdéses időpontra nagyjából elkészültek a javítások, ezért nem okozott nagyobb összeomlást 2000. Január 1.

    Raptor:
    Az amerikai fegyver-és navigációs rendszerek (és talán az egész NATO, de ebben nem vagyok biztos) egységes időt használ, ez a greenwich-i idő (szokás “Zulu time”-nak is hívni), függetlenül attól, hogy éppen hol van a földön, ezért az időzónák határain való átlépés nem okoz gondot.
    Viszont éppen ezért a fedélzeti órán “ugrasztani” kell 24 órát előre vagy hátra a dátumválasztó átlépésekor.
    Ha ez elmarad, mert a szoftver elkészítésekor nem foglalkoztak vele (ami abszolút lehetséges, a szoftverek 99,999999999999%-ánál semmi szükség erre, hiszen várhatóan soha nem fog a dátumválasztón átmozogni futás közben, de ettől persze még itt hibának számít, ami viszont más időzónák határainak átlépésekor az egységes idő miatt nem jelentkezett), az okozhat problémákat.
    Hogy pontosan mi történt, az egy jó kérdés, ismerni kellene hozzá a gép számítógépes rendszerének felépítését.

  25. A számítógép számára majdnem mindegy mi a dátum, és az amúgy se változik meg automatikusan, csak nem gondolták egypáran, hogy a gép leblokkol mert átrepül egy földrajzi hely felett?!
    Hiba akkor jelentkezik amikor a helyi időre állított rendszerek direkt gépek közötti kommunikációt folytatnak a repülőgépekkel (pl transzponderrel) és akkor is csak akkor ha az időnek akkor jelentősége van. Másik, ha a pilóta manuálisan beállítja az új helyi időt és ezt nem tudja értelmezni a repülőgépe.

  26. Az dátumvonal egyik vagy másik felén nem 24 órával van több hanem ugyan úgy 1 óra a különbség ugyanis az dátumvonal egy szimpla időzóna határ aminek adtak egy nevet és hozzárendelték az új nap kezdetét (mert egy kiindulási pont egy kezdet kell és azért a 180. fokra esett a választás mert viszonylag ritkán lakott és grinicshez viszonyítva pont a föld másik oldalán van mert a főld ugyebár 360fok a nulla grinics a 360 fele 180.)

Fórum hozzászólások

There are no comments in the forum topic that is associated with this post.