'Geheugentekort leidde tot uitval luchtverkeerssysteem'

Een systeem om het Amerikaanse luchtverkeer aan te sturen is diverse malen op hol geslagen doordat het zogeheten eram-systeem over te weinig werkgeheugen beschikte. Vooral complexe vliegplannen zouden leiden tot herstartende systemen.

Begin deze maand raakten eram-systemen van de luchtverkeersleiding ontregeld, met honderden vertragingen en annuleringen van vluchten tot gevolg. Oorzaak bleek een U2-spionagevliegtuig. Het vliegtuig zou met zijn grote hoogte en complexe vliegplan de eram-software op hol hebben doen slaan. Om de veiligheid te garanderen werd besloten om tijdelijk geen luchtverkeer toe te laten in het luchtruim rond Los Angeles.

Uit verder onderzoek is gebleken dat de problemen met eram, dat is gebouwd door Lockheed Martin, deels veroorzaakt worden door te weinig computergeheugen. Als de software te complexe vliegplannen moet verwerken, raakt het werkgeheugen vol en kunnen de systemen vastlopen, waarna automatisch herstarts worden uitgevoerd, zo meldt Reuters op basis van twee anonieme bronnen. Bovendien bestaat het risico dat de eram-systemen in een loop terechtkomen.

De problemen met het eram-systeem zouden kunnen worden misbruikt door een vijand om zo ongemerkt het Amerikaanse luchtruim te penetreren, maar deskundigen stellen dat een dergelijke aanvalsmethode erg complex is om uit te voeren. Er zou inmiddels gewerkt worden aan de nodige bugfixes om de problemen met eram te verhelpen.

Reacties (95)

Hou er rekening mee dat ATC (Air Traffic Control) systemen zoals deze niet in één jaar ontwikkeld worden.
ERAM is in 2006 opgeleverd, waarschijnlijk zijn er enkele jaren aan ontwikkeling aan voor gegaan.

In de vroege jaren 2000 werd in ATC systemen heel veel gebruik gemaakt van UNIX systemen met PA RISC processoren. Anno 2014 zijn er maar weinig OS'en meer die overweg kunnen met de PA RISC architectuur waardoor er geen nieuwe hardware te vinden is waarop de software kan draaien.

Het is dus niet even snel een module geheugen inprikken in de servers om dit probleem op te lossen.

Mogelijke oplossingen zijn:

• De software herschrijven zodat het werkt op X64, waardoor je eigenlijk oude software krijgt op nieuwe hardware
• Nieuwe software ontwikkelen, wat weer enkele jaren ontwikkeling met zich meebrengt
• De software met een emulator laten draaien op Itanium CPU's, wat uitstel van executie is aangezien Intel al aangegeven heeft deze CPU's niet meer verder te ontwikkelen

Als ze er dan al in slagen om snel iets te knutselen moet dat nog maandenlang getest worden om bugs uit te sluiten. Wie wil er afhangen van een ATC systeem dat niet stabiel is?

Tuurlijk hebben ze tools om hun systemen te monitoren maar als de bug zich manifesteert in enkele seconden tijd hebben ze de tijd niet gehad om te reageren.

[Reactie gewijzigd door christoforius op 12 mei 2014 12:58]

Complexe vliegplannen? Hoe complex kan dat zijn? Databases met vectoren.

ERAM will increase capacity and improve efficiency in our skies. En Route controllers will be able to track 1,900 aircraft at a time instead of the current 1,100 flight capability. Additionally, coverage will extend beyond facility boundaries, enabling controllers to handle traffic more efficiently. This extended coverage is possible because ERAM will process data from 64 radars versus the 24 radar processing with the Host system.

Bron : FAA.
We hebben dus data van minder dan 1900 real time threads met minder dan een MB actuele dynamische meta-data per thread in een vier dimensionale factorruimte. Er wordt data gedeeld met lokale Air Trafic systemen. Zie de factsheet van Lockheed Martin:
http://www.lockheedmartin...ments/ERAM%20Brochure.pdf

Het ontwerp was van 2008 en ernstig overgedimensioneerd. Wat is er gebeurd dat het systeem zich nu verslikt? Ik ben namelijk niet zo onder de indruk van de omvang van dit systeem en je zou toch verwachten dat een dergelijk systeem voldoende schaalbaar zou zijn...?
Zie ook: http://www.disca.upv.es/j...OLeary-Srivastava_FAA.pdf
En 't was duur genoeg...

[Reactie gewijzigd door mrlammers op 12 mei 2014 22:57]

Ongelofelijk. Dat dit anno 2014 nog kan. Je hebt hier gewoon over mensenlevens die in gevaar zijn. Waarom? Paar geheugenbankjes..

Misschien zijn het systemen / architecturen die maar maximaal X GB aan geheugen kunnen hebben?
Zoals bij Windows: 32-bit, max 4 GB per systeem, max 2 GB per process?

Ahem, de 4GB limiet heeft niets te maken met het operating systeem.
Het is het maximaal adresseerbaar geheugen dat met 32 bits kan worden geadresseerd.
Dit is een puur hardwarematig maximum die heeft te maken met het aantal fysieke adreslijnen die de CPU heeft.

De huidige 64 bit emulatie CPU's van AMD en iNTEL (x64 classificatie) kunnen zelfs niet het maximum geheugen aanspreken dat met 64 bits theoretisch kan omdat de meeste x64 CPU's maar 48 of 56 adreslijnen hebben. Het zijn dan ook geen volwaardige 64 bit CPU's.

Ahem, de 4GB limiet heeft niets te maken met het operating systeem.

Nee, maar 2 GB limiet waar hij het over heeft wel.

De huidige 64 bit emulatie CPU's van AMD en iNTEL (x64 classificatie) kunnen zelfs niet het maximum geheugen aanspreken dat met 64 bits theoretisch kan omdat de meeste x64 CPU's maar 48 of 56 adreslijnen hebben. Het zijn dan ook geen volwaardige 64 bit CPU's.

Het zijn wel degelijk volwaardige 64-bit CPU's. dat ze geen 64 adreslijnen hebben doet daar niks aan af. Ten eerste omdat we als we over 8/16/32/64-bit CPU's praten het over het algemeen over de word-size van de CPU hebben, en die is wel degelijk 64-bits. De word-size, adress-size, en datapaden in een x86-64 CPU zijn allemaal gewoon 64-bit breed.

Dat er geen 64 adreslijnen zijn is gewoon uit praktische overwegingen, waarom zou je onnodige adreslinnen toevoegen ? Op het moment is de grootste geheugenmodule 32GB. Dat houdt in dat als je 'maar' 48 adreslijnen hebt je met de grootst mogelijke geheugenmodule die nu verkrijgbaar is 8192 bankjes nodig hebt om die 48-bit vol te krijgen voor een totaal van 256TB geheugen. Met 56-bit heb je het over 64PB geheugen in 2,097,152 bankjes.

Waarom zou je extra pinnen en silicium verspillen aan ongebruikte adreslijnen ?

[Reactie gewijzigd door Aaargh! op 12 mei 2014 12:26]

was het niet zo dat winxp32 max 3 1/2 kon adresseren ?? wel een os limitatie dus

Klopt ongeveer. In elk geval meer waar dan wat daarvoor verkondigd wordt. Het ligt iets ingewikkelder, maar is wel degelijk met name een limitatie van Windows 32 client systemen:

In Microsoft's "non-server", or "client", x86 editions of Microsoft Windows: Windows XP, Windows Vista, Windows 7, Windows 8, and Windows 8.1, the 32-bit (x86) versions of these are able to operate x86 processors in PAE mode, and do so by default as long as the CPU present supports the NX bit.[11] Nevertheless, these operating systems do not permit addressing of physical memory above the 4 GB address boundary. This is not an architectural limit; it is a limit imposed by Microsoft as a workaround for device driver compatibility issues that were discovered during testing.[16]

bron: http://en.wikipedia.org/wiki/3_GB_barrier
Maar iedereen hier op tweakers weet dit soort bronnen wel te raadplegen voor wat waarheidsvinding me dunkt.

Klopt ongeveer. In elk geval meer waar dan wat daarvoor verkondigd wordt. Het ligt iets ingewikkelder, maar is wel degelijk met name een limitatie van Windows 32 client systemen:

[...]

bron: http://en.wikipedia.org/wiki/3_GB_barrier
Maar iedereen hier op tweakers weet dit soort bronnen wel te raadplegen voor wat waarheidsvinding me dunkt.

We hebben het over hardware, software word gemaakt voor hardware, het is de hardware die de beperkende factor is, de software word voor die beperkende factor geschreven. Hadden net zo goed 128bit software van kunnen maken, geen beperkende factor aan die kant namelijk. Zo kunnen we nu ook al 1024bit software schrijven, niks wat me tegenhoud.

En natuurlijk moet je de software afgestemd op je hardware, 32bit software op 64bit chip zal niet werken, en vice versa. En ja x86-64 kan ook 32bit maar is dan ook zowel 32bit als 64bit, geen 64bit only.

[Reactie gewijzigd door mad_max234 op 12 mei 2014 12:48]

Videokaarten, geluidskaarten, HDD controllers, Nics, USB etc. etc. gebruik(t)en het geheugen gebied tussen 3.5GB en 4GB om hun ROM in te mappen.

Zo lang je niet het maximum geheugen in de 32 bit PC had zitten was dat geen probleem, maar toen RAM geheugen goedkoop werd en systemen werden volgestopt liep je wel tegen dit issue aan.

Dus ook in Linux op een 32 bit CPU systeem met 32 fysieke adreslijnen is maar maximaal 3.5GB aan geheugen beschikbaar voor applicaties omdat hardware ROM de rest gebruikt.

De 3.5GB limiet is dus geen limiet opgelegd door het OS.
WindowsXP meldt het daadwerkelijk beschikbare geheugen voor applicaties in plaats van het aanwezige fysieke geheugen.

Nope.. Fysieke kaarten hebben dedicated mem aanwezig.. en zullen nooit mappen van het systeem..

Daarnaast zit er daadwerkelijk wel een fysiek limiet aan door MS opgelegd.. ivm problemen met drivers e.d. die 3,5 is gewoon een vast limiet van MS.. en kan geen geheugen aanspreken boven de 4Gb fysieke adress (MMIO)

Nee, dat was dus de 4GB 32-bit limiet. Die ~3.5 komt dan uit het feit dat er van de 4GB een deel afgesnoept wordt doordat eerst alle andere hardware wat adresruimte krijgt, waarbij dus ook de grofweg 512MB van videokaarten die veel tweakers hadden.

Wel heeft Windows vaak licentietechnisch beperkingen:
http://msdn.microsoft.com...op/aa366778(v=vs.85).aspx

Windows XP 32-bit kon tot 4GB (want ja, 32-bit beperking) en de 64-bit tot 128GB

[Reactie gewijzigd door GENETX op 12 mei 2014 11:58]

die 3,5 was een 32Bit limiet.

Als ik een dedicated geluidskaart en Videokaart heb dan gaat er echt geen memory naar die systemen.. die 3,5 was gewoon een harde limiet van de software..

De techniek kon wel 4Gb Fysiek aan.. Maar als jij meer dan 4Gb Fysiek in je systeem duwde.. Dan starte het systeem niet eens op.. mooi blauw scherm als gevolg..

Licentie technisch was er geen beperking. je had ook een licentie voor 1 systeem met 1 of 2 CPu's

Had je een systeem met meerdere core's werdt dat gewoon niet ondersteund en je systeem starte niet door..

De techniek kon wel 4Gb Fysiek aan.. Maar als jij meer dan 4Gb Fysiek in je systeem duwde.. Dan starte het systeem niet eens op.. mooi blauw scherm als gevolg..

BSOD in deze situatie nooit meegemaakt, systeem liet gewoon 3,5 zien ook al stopte je er 4 in.

Inderdaad, had een 64bits machine met 8gb ram, dualboot XP-Pro erop (Xp64 was op het begin echt erg slecht), en je kreeg gewoon 3,5gb van de 8 beschikbaar.

Eerdere versies van XP kreeg ik wel een BSOD.. Daarna nooit meer geprobeerd.. ook Windows 98 deed vreemd

Zou fijn zijn als je een bron hebt, tot dusver weet ik dat adresruimte wordt opgesnoept door andere apparatuur:

How graphics cards and other devices affect memory limits

Devices have to map their memory below 4 GB for compatibility with non-PAE-aware Windows releases. Therefore, if the system has 4GB of RAM, some of it is either disabled or is remapped above 4GB by the BIOS. If the memory is remapped, X64 Windows can use this memory. X86 client versions of Windows don’t support physical memory above the 4GB mark, so they can’t access these remapped regions. Any X64 Windows or X86 Server release can.

Bron: http://msdn.microsoft.com...op/aa366778(v=vs.85).aspx

en http://en.wikipedia.org/wiki/3_GB_barrier

[Reactie gewijzigd door GENETX op 12 mei 2014 13:31]

Niet "opgesnoept", maar gereserveerd. Ook als de hardware geen geheugen nodig heeft, of zelfs niet aanwezig is, is 512MB gereserveerd. En omdat XP geen remapping doet, is die 512MB gewoon "weg".

Wederom, graag een bron...

Ach als je ervan uitgaat dat een 32bit systeem gewoon 64Gb mem kan draaien. ja dan heb je gelijk maar laat Windows en ook Linux in non PEA modus draaien.

Echter door MMIO conflicten moet meer dan 4GB remmaped worden. doordat remapping dan een fysiek adress zou krijgen boven de 4GB kon het systeem dit geheugen niet zien..

Somige systemen zullen dan 3,25 Gb te zien zijn en andere 3,5Gb..

Maar dat heeft ook echt niets te maken dat Video kaarten en geluidskaarten met dedicated mem die 512MB toch opsnoepte.. Dit zou tevens een naar effect geven gezien het geheugen van een Video kaart een stuk sneller is dan het RAM in je PC..

Lees je eigen bron maar eens goed. Het klopt wat munters zegt. En met PAE was het ook mogelijk om meer dan 4GB te adresseren op Windows XP. Wel moet de CPU het supporten.

In Microsoft's "non-server", or "client", x86 editions of Microsoft Windows: Windows XP, Windows Vista, Windows 7, Windows 8, and Windows 8.1, the 32-bit (x86) versions of these are able to operate x86 processors in PAE mode, and do so by default as long as the CPU present supports the NX bit.[11] Nevertheless, these operating systems do not permit addressing of physical memory above the 4 GB address boundary.

Bron (dezelfde):
http://en.wikipedia.org/wiki/3_GB_barrier

Helaas kon mijn analoge TV-Kaart uit die tijd daar niet mee overweg, hierdoor moest ik het met 3,2GB doen i.p.v. 4GB doen (bron ikzelf).

Ahem, de 4GB limiet heeft wel degelijk iets te maken met het operating systeem.

Een 32 bit OS kan wel degelijk meer dan 4GB gebruiken, door gebruik te maken van PAE.

Alleen:
Microsoft Windows supports PAE if booted with the appropriate option, but according to Geoff Chappell, Microsoft may limit 32-bit versions of Windows to 4 GB as a matter of its licensing policy.

Wat betreft linux:
The Linux kernel includes full PAE mode support starting with version 2.3.23

Dus.

Dat een 32bit systeem maximaal 4GB ram kan gebruiken is een fabeltje, in het geval van windows heeft het gewoon te maken met de licentie, sommige 32bit server varianten ondersteunen meer dan 4GB.

hoezo 2GB?

vista / windows 7:
To enable the 3GB switch on Windows Vista, Windows 7, or Windows 8:
1. Right-click Command Prompt in the Accessories program group of the Start menu. Click Run as Administrator.
2. At the command prompt, enter "bcdedit /set IncreaseUserVa 3072"
3. Restart the computer.

xp:
To enable the 3GB switch on Windows XP:
1. Right-click My Computer. Click Properties.
2. In the System Properties dialog box, click the Advanced tab.
3. On the Advanced tab, under Startup and Recovery, click Settings.
4. In the Startup and Recovery dialog box, under System startup, click Edit. The Windows boot.ini file will be opened in Microsoft® Notepad.
5. Create a backup copy of the boot.ini file. Note: Boot.ini files may vary from computer to computer.
6. Select the following line in the boot.ini file:
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional" /fastdetect
Press Ctrl+C to copy the line and then press Ctrl+V to paste it immediately below the original line.
Note: Your text string may be different from the text string in this solution, so be sure to copy the text string from your boot.ini file, and not the text string included here.
7. Modify the copied line to include “ /3GB”, as shown in the following example:
multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional 3GB" /3GB /fastdetect
Note: Do not overwrite any existing lines.
8. Save and close the boot.ini file.
9. Click OK to close each dialog box.
10. Restart your computer.
11. During startup, select the 3GB option. If you do not select the 3GB option, the system will default to the 2GB total memory setting.
Note: If problems occur during startup, you may try to resolve the issue by updating some of your drivers. However, recall the notice at the beginning of this solutions that note all Windows update or hardware and graphics drivers work with the 3GB switch enabled.

De 3GB switch zorgde inderdaad voor de mogelijkheid om 3GB binnen een proces te gebruiken. Wel moet de executable er geschikt voor zijn (geheugen management) en de IMAGE_FILE_LARGE_ADDRESS_AWARE flag moet gezet zijn in de exe header.

Ja, maar wat als je kernel space en user space allebei veel geheugen wil geven? Wat dan?

in vista/7 kun je de verdeling zelf regelen tussen 2048 en 3072 MB samen maximaal 4GB. heb je meer nodig dan zul je naar 64 bits os'en moeten.

Je mag toch hopen dat zulke belangrijke software niet op een ms platform draait maar iets wat veilig en open voor audits is, zoals linux

Dat is wel heel simplistisch gezegd. Oplossingen voor routerings en planning problemen kunnen al snel een NP-harde complexiteit hebben. Dit houdt simpel gezegd in (hoewel niet helemaal correct) dat problemen exponentioneel toenemen naarmate de invoer groter wordt. Exponentieel geheugen toevoegen valt niet mee in de praktijk. Het is dus belangrijker om de gebruikte algoritmen efficienter te maken of te behoeden van te grote invoer tijdens het verwerken.

Ehh maar als de problemen exponentieel veel geheugen nodig hebben, dan hebben ze ook exponentieel veel tijd nodig. Onwaarschijnlijk dus.

Dat is alleen waar als het probleem niet paralleliseerbaar is. Voor dit soort problemen hebben we distributed computing, waarbij we er gewoon wat hardware tegenaan gooien ipv tijd.

Zoals je al zegt, moet het probleem wel paralleliseerbaar zijn. en ook zo geprogrammeerd zijn.

En dan nog, daar zit ook een eind aan. gewoon wat hardware er tegen aan gooien is ook niet altijd de oplossing.

Ik heb aan een stuk software gewerkt dat maar voor de helft paralleliseerbaar is. En het stuk dat niet paralleliseerbaar is heeft de helft van de totale processing tijd nodig.
De helft is dus altijd single threaded, dus hoeveel threads je er verder ook tegen aan gooit voor het andere deel, dit stukje software word nooit meer dan 2 keer zo snel ten opzichte van de single-threaded versie.

Parallelliseerbaarheid heeft er niet mee te maken, aangezien je de hoeveelheid hardware als een constante kunt beschouwen.

Zie: http://en.wikipedia.org/wiki/Computational_complexity_theory

Dit wordt zo een hele flauw metadiscussie. In welke praktijk zijn resources ooit een constante? je /kunt/ het dus als constante beschouwen ja, in een theoretische omgeving voor een theoretische wetenschapper ongetwijfeld, maar in de praktijk nooit. Een complex probleem heeft een grotere waarde om op te lossen en dus de mogelijkheid tot inzet van meer resources.
Als er ook maar iets in de praktijk van waar was, had Google, HFS en Hadoop nooit kunnen ontstaan. Allemaal voorbeelden van florerende technologie die leeft bij de gratie van de mogelijkheid tot het vergroten van resources.

Verdiep je eerst eens in de theorie van computational complexity zou ik zeggen. Het heeft niets maar dan ook niets te maken met "dan gooien we er even wat extra hardware tegenaan". Ik heb nog nooit een artikel gelezen waarin de hoeveelheid hardware toeneemt volgens een exponentiele functie.

Dat is waar, maar misschien was de invoer van ERAM tot opheden altijd zodanig dat de exponentiele groei nooit tot uiting kwam of in ieder geval nooit een praktische bottleneck vormde.

Daar is het ook exponentieele groei voor: na stap x past het nog prima in je geheugen en na stap x+1 is het opeens y keer zo groot als je geheugen, terwijl het na stap x+2 opeens y^2 keer zo groot is.

Niet gezegd dat dat hier het geval was, maar het ligt wel voor de hand dat er iets soortgelijks speelt.

[Reactie gewijzigd door mae-t.net op 12 mei 2014 12:26]

Dat is wel heel simplistisch gezegd. Oplossingen voor routerings en planning problemen kunnen al snel een NP-harde complexiteit hebben. Dit houdt simpel gezegd in (hoewel niet helemaal correct) dat problemen exponentioneel toenemen naarmate de invoer groter wordt. Exponentieel geheugen toevoegen valt niet mee in de praktijk. Het is dus belangrijker om de gebruikte algoritmen efficienter te maken of te behoeden van te grote invoer tijdens het verwerken.

Dit systeem werkt echt niet volgens het TSP (Travelling Sales Person) principe wat jij beschrijft. Dat is inderdaad bekend om exponentieel te groeien naarmate er meer zaken berekend moeten worden.

Het is echt niet zo dat alle vliegtuigen hun begin en eindpunt ingeven, en ERAM dan maar gaat berekenen hoe die vliegtuigen moeten vliegen. Het is nog steeds aan de piloot zelf om aan te geven welke airways hij gaat gebruiken en welke hoogte (waar hij al dan niet approval voor krijgt). Hij/zij geeft dit ook zo aan in het vliegplan (dit zal in de praktijk wel de snelste of kortste route zijn).

De taken van ERAM worden hier goed omschreven: http://en.wikipedia.org/wiki/ERAM

[...]


Dit systeem werkt echt niet volgens het TSP (Travelling Sales Person) principe wat jij beschrijft. Dat is inderdaad bekend om exponentieel te groeien naarmate er meer zaken berekend moeten worden.

Ik heb dan ook nooit beweerd dat het een klassiek TSP probleem zou zijn (ik heb het zelfs nooit over TSP gehad?!), TSP is toevallig 1 NP-hard probleem, er zijn echter heel veel plannings problemen al dan niet in NP-hard,

Het is echt niet zo dat alle vliegtuigen hun begin en eindpunt ingeven, en ERAM dan maar gaat berekenen hoe die vliegtuigen moeten vliegen. Het is nog steeds aan de piloot zelf om aan te geven welke airways hij gaat gebruiken en welke hoogte (waar hij al dan niet approval voor krijgt). Hij/zij geeft dit ook zo aan in het vliegplan (dit zal in de praktijk wel de snelste of kortste route zijn).

De taken van ERAM worden hier goed omschreven: http://en.wikipedia.org/wiki/ERAM

Het systeem mag dan wel misschien wel geen kortste pad algoritmen gaan gebruiken, echter gaat het wel aan de slag met de routes en hoogte informatie, om bijvoorbeeld vliegtuigen te herkennen die te dicht bij elkaar vliegen.

Ergo, we kunnen alleen maar gissen hoe de implementatie de gewenste functionaliteit bereiken van ERAM, maar het ging mij erom dat er genoeg problemen zijn die exponentieel kunnen groeien en dus geheugen bij plaatsen niet altijd een oplossing is.

Software blijft ingewikkeld voor de mens. Ik denk dat we een stuk slechter slapen als we weten wat voor fouten er allemaal zitten in systemen waar mensenlevens van afhangen.

Deze persoon vertelt hoe software vaak in elkaar gezet wordt en waarom alle software verschrikkelijk is. http://stilldrinking.org/

Ik denk dat het zeer aannemelijk is dat het oude computers zijn met vaste geheugen chips.
Een bankje vervangen zal dan niet lukken.
Het zou me niet verbazen als er af en toe wel nieuwe software op word gezet. En ik zie het om me heen dat steeds minder programmeurs rekening houden met beperkt geheugen. En als ze dan bewust zijn van het probleem, weten ze er niet altijd mee om te gaan. Testen is ook zeer belangrijk, iets dat evenveel aandacht aan zou moeten worden gegeven als ontwikkelen. En dat gebeurt bijna nooit. Het motto is steeds meer: Ontwikkeling loopt uit, dan maar minder testen, want het moet wel op tijd de deur uit. Dan fixen we het later wel met een update.
Een slechte zaak. vooral als mensenlevens op het spel staan.

ANNO 2014? Deze systemen zullen wss enkele tientallen jaren oud zijn wss uit een tijdperk van het begin van de commerciële luchtvaart dus dat is niet zomaar even te migreren.

Ongelofelijk?... Er gebeuren zo veel dingen die menselevens in gevaar brengen terwijl ze misschien wel makkelijk te verhelpen of voorkomen zijn. Welkom op planeet Aarde 2014...
Voor als je 't nog niet duidelijk is; We wonen nog steeds in een primitieve wereld.

nee, wat wil je dan, oh, we hebben een onbekend vliegtuig op grote hoogte, zet even uit, dan stoppen we er wat ram bij ??????

Of gewoon meer werkgeheugen er in steken?
Het kan nooit kwaad om een beetje overhead te hebben met dit soort dingen ipv altijd tegen het plafond aan te zitten.
Bugfixes en optimalisaties zorgen natuurlijk ook voor verbeteringen maar die zijn vaak duurder/lastiger te implementeren dan wat geheugen/servers bijschakelen.

Was alles maar zo simpel, dan hadden ze dit probleem in no time opgelost.

Als jij op deze manier ontwikkelt, zou ik je niet in mijn team willen hebben.
Net zoiets van de meest populaire manier om windows problemen op te lossen: even rebooten.
Dan stel je het meestal alleen maar even uit voordat het probleem weer terugkeert.

Ik zeg niet dat het DE oplossing is (dat zijn de bugfixes/optimalisaties) maar als iemand met ervaring in missie kritieke systemen die door bijvoorbeeld de overheid gebruikt worden kan ik je wel vertellen dat altijd tegen het plafond aan te zitten niet handig is aangezien dan dit soort problemen ontstaan.

Als er (waarde in dit geval uit de lucht gegrepen) 10% extra power aanwezig was geweest hadden de admins in de logs gezien dat er iets aan het misgaan was zonder dat de boel daadwerkelijk platging en even een prio1 ticket bij de devs neergelegd.
Verder als ik zo naar mijn salaris en dat van anderen kijk weet ik vrij zeker dat wat extra hardware bijschakelen een stuk goedkoper is dan onze services (alhoewel dit in Amerika misschien anders is).

Offtopic want dit heeft niets met windows te maken maar: Verder is "Have you tried turning it off and on again" een redelijk beproefde methode die in veruit de meeste gevallen meer goed dan kwaad doet

En hoe weet je dat ze al tegen het plafond aan zatten?
En nu ga je er van uit dat ze het gezien hadden als er meer geheugen is zat. Maar checken admins continue de logs? of checken ze die pas als het mis gaat? Waarom hebben ze het niet eerder gezien?

En het is geen website of datacenter. En er zijn ook veel systemen waar je gewoon geen server of geheugen bij kunt schakelen omdat het niet op die manier ontworpen is. Je hebt misschien alleen kast met een paar racks vol met computers en dat is het.

Je zult toch eerst een gedegen analyse moeten doen voordat je er zomaar wat geheugen/servers bijschakeld en hoopt dat dat het probleem oplost. Misschien loopt het geheugen opeens wel heel snel vol door een bug en/of een geheugen lek.

Enkel mijn ervaring met bureaucratie en administratieve rompslomp in de I(C)T zeggen dat

En als admin hoef je natuurlijk niet continue de logs te checken (al is dat bij dit soort systemen vaak gebruikelijk) maar kan je zelf natuurlijk markers instellen die je alarmeren op het moment er iets scheef gaat lopen.
Mijn vermoeden is dat het intern bekend was maar dat het eerst fout moest gaan voordat de managers het nut inzagen.
Is denk ik het meest veelvoorkomende I(C)T probleem wat er is, dat hogerop geen flauw benul heeft wat wel en niet noodzakelijk is.

Van wikipedia over de FAA's Eram systemen:
The open system architecture enables the use of future capabilities to efficiently handle traffic growth and ensure a more stable and supportable system.

Klinkt niet als een kast met een paar racks en harde limieten maar je hebt gelijk, ik heb geen hands-on experience met deze systemen

En simpelweg het geheugen vergroten is geen optie?

java.lang.OutOfMemoryError

Schijnt op Ada te draaien.

[Reactie gewijzigd door Schnoop op 12 mei 2014 11:22]

Zonder wat te weten over dit systeem, ik kan je vertellen dat high performance, high throughput, en high integrity computing een uitdaging kan zijn om te programmeren. Je hebt wel frameworks die het leven makkelijk kunnen maken, maar geheugen addreseren zeker in zulke zware threaded live applicaties kan erg lastig zijn!

Dat ligt aan het hardware ontwerp van de computers. Soms is het een optie, soms niet.
Soms zit er al het maximale in, soms zijn de chips vastgesoldeerd en kun je zie niet of niet makkelijk upgraden.

Soms word er dan compleet nieuwe computers in systemen gezet, maar dat vergt een wat grotere investering in geld en tijd. In het ergste geval moet de software geport en compleet opnieuw getest worden.

De problemen met het eram-systeem zouden kunnen worden misbruikt door een vijand om zo ongemerkt het Amerikaanse luchtruim te penetreren, maar deskundigen stellen dat een dergelijke aanvalsmethode erg complex is om uit te voeren.

Maar toch gebeurde het, ongeplanned, omdat er een 'random' vliegtuig voorbij vloog... Nou wil ik best aannemen dat dit soort vliegtuigen schaars zijn, en de kans erg klein is, maar het baat me toch zorgen.

Ik ga er ook van uit dat er voldoende beveiliging in dit systeem zit, maar als dit per ongelijk kan gebeuren, hoeveel meer van dit soort ongelukken (of "ongelukken") kunnen er nog meer verwacht worden? Klink IMO gewoon als de "shh, niet aan denken".

[Reactie gewijzigd door Martijn.C.V op 12 mei 2014 11:16]

Het kwam toch door een complex vliegplan? Ongemerkt binnendringen betekent geen vliegplan, dus geen geheugenprobleem?

Of iemand moet eerst een complex vliegplan in dienen om vervolgens met een ander vliegtuig binnen dringen. Dan moet je wel een goed tijdsplan hebben

Volgens mij gaat het niet om een ingedient vliegplan, maar een vliegplan die de computer bedenkt, om zo veilig mogelijk door het betreffende luchtruim te kunnen vliegen. Rekening houdende met alle overige vluchten, waar van het vliegplan ook eventueel aangepast moet worden.

Klopt ongeveer. In dit geval werd het vluchtplan van het U2 vliegtuigje op FL400 (40.000ft) omgezet van IFR naar VFR. In combinatie met de luchtruimspecificatie en de route van de vlucht volgens het vluchtplan gaf dat problemen, want de vlucht moest dan door luchtruim met een andere classificatie waar VFR niet is toegestaan boven een bepaalde hoogte (meestal 1500ft of 3000ft). Het systeem moest dus een route berekenen volgens VFR van FL400 naar de destination, zonder dat daarbij luchtruim met een andere classificatie gekruist werd EN daarbij rekening houden met alle andere verkeer. Als je dan half de USA door moet is het niet gek dat zoiets vastloopt...

Noem mij gek maar is het hele idee van een spionage vliegtuig niet dat hij juist niet word gezien en al helemaal niet standaard word meegenomen in vluchtplannen ?

trm0001 dacht overigens dat die U2 uit de jaren 50/60 was en daarmee dus antiek.
Dus waarom dat ding uberhaupt nog rondvliegt......

De U2 was oorspronkelijk een spionage vliegtuig uit de jaren 50. Omdat dit toestel op zeer grote hoogte kan opereren was de tactiek simpel: op grote hoogte vliegen waar de toenmalige raketten hem simpelweg niet konden raken. Toen een aantal jaren later de russen de technologie van de luchtdoelraktten hadden verbeterd en er eentje hadden neergehaald durfde de VS hem niet meer boven russisch grondebied inzetten. Maar sinsdien is het toestal nog gebruikt voor verkenningsvluchten tijdens verscheidene conflicten. Ook wordt het toestel nu nog steeds gebruikt om andere vluchten te coördineren wanneer het op korte termijn niet mogelijk is om een satelliet daarvoor te gebruiken. De NASA heeft er ook een aantal ter beschikking om er wetenschappelijk onderzoek mee te doen op grote hoogte.

Veel militair materiaal stamt nog uit de koude oorlog. Daarnaast zijn er niet veel vliegtuigen die op 20km hoogte kunnen opereren. De SR71 blackbird uit 1964 is in 1998 uitgefaseerd: http://nl.wikipedia.org/wiki/Lockheed_SR-71_(Blackbird).

The U-2 remains in front-line service more than 50 years after its first flight despite the advent of surveillance satellites. This is due primarily to its ability to direct flights to objectives at short notice, something that satellites cannot do. The U-2 has outlasted its Mach 3 SR-71 replacement, which was retired in 1998.

http://en.wikipedia.org/w...d_U-2#Operational_history

Nederlandse F16's stammen ook uit 1979 .

[Reactie gewijzigd door sdk1985 op 12 mei 2014 17:22]

Het is gebruikelijk dat militaire vliegtuigen in civiele delen van het luchtruim gevolgd worden door de radar. Wil niet zeggen dat er een compleet vluchtplan van start tot landing moet zijn, maar wel genoeg om ongelukken te voorkomen.

Nou vind ik mezelf niet echt een doemdenker, maar bij dit soort situaties denk ik toch altijd met een klein stemmetje "mja, dat zéggen ze."

Maar stel dit is dus echt het probleem. Dan ga ik me weer afvragen "wat nou als ze een insider hebben? Zou dat haalbaar zijn. Gezien de gevolgen lijkt dit me als bad-guy een interresant concept."

Edit: Misschien moet ik maar gewoon luisteren naar wat ze zeggen, en er niet aan denken

[Reactie gewijzigd door Martijn.C.V op 12 mei 2014 11:21]

Het zou me niet verbazen dat dit al intern bekend was,
maar dat het nu bekend is bij partijen waar je liever hebt dat ze die kennis niet hebben.

Theoretisch kun je deze techniek ook gebruiken bij andere luchthavens waar je dezelfde problemen kunt veroorzaken. En het lijkt me niet onmogelijk dat er gelijk een ander aantal zaken worden meegenomen in de update waarover verder niet wordt gesproken.

Bij de aanbesteding van het systeem zal wel rekening gehouden zijn met de minimale geheugen eisen bij een gevraagde capaciteit... dit soort dingen komen veel vaker voor.

Er zou inmiddels gewerkt worden aan de nodige bugfixes om de problemen met eram te verhelpen.

Dit is de oorzaak niet de hoeveelheid geheugen, er zaten memory leaks in, er zijn niet eens hele complexe vluchten bij gekomen of zoveel meer vliegtuigen.

In de luchtvaart wordt alles tot in den treure getest voordat iets toegelaten wordt. Zo hebben de meeste vliegtuigen computers aan boord die qua snelheid minder zijn dan een Pentium 3. Ook mochten vliegtuigen heel lang op alleen op GPS vliegen omdat het systeem nog niet goedgekeurd was voor het gebruik in de luchtvaart. Die goedkeuringen kunnen soms gerust 10-tallen jaren duren.

Bij de vluchtsystemen kan me voorstellen dat er daarom ook niet 'zomaar' even een geheugenbankje bijgeprikt kan worden zonder het tot het idiote toe te testen. Ik kan me ook voorstellen (maar dat is een aanname) dat deze systemen al erg oud zijn en dat deze beperkingen nu aan het licht komen door het steeds drukkere en complexe luchtruim.

Kortom, het zal waarschijnlijk lang niet zo simpel zijn als 'een bankje geheugen' erbij prikken.

Ik ben eigenlijk wel benieuwd wat de hardware specificaties zijn voor de ERAM systemen. Er is erg weinig over te vinden.