Orientierungslos am Hindukusch: Das sagt Eurocopter
Nach den gestrigen Berichten über den Komplettausfall des Navigationssystems in den NH90-Hubschraubern der Bundeswehr, die vor allem als Rettungshubschrauber in Afghanistan eingesetzt werden, hatte ich die Herstellerfirma Eurocopter um eine Stellungnahme gebeten. Die ist gerade eingetrudelt, hier komplett im Wortlaut:
Eurocopter leistet der Bundeswehr starke Unterstützung beim Einsatz dieses modernen Hubschraubers. Durch die enge Zusammenarbeit im Systemunterstützungszentrum haben wir gemeinsam mit der Bundeswehr eine Modifikation erarbeitet, die in den nächsten Wochen qualifiziert wird. Die NH90 können dann mit der neuen Lösung ausgestattet werden.
Hm, bisschen sparsam, oder?
Davon abgesehen: eine Modifikation, die in den nächsten Wochen qualifiziert wird. Also frühestens im Oktober. Die Mängel-Meldung stammte vom Juni, und darin war schon erwähnt, dass dieses Problem bereits zuvor bekannt war – bereits im März dieses Jahres habe es Versuche gegeben, das zu lösen.
Nun, in der Tat bestätigt EC damit das Vorliegen eines systemischen Problems, das wohl so gravierend ist, dass man eine „Modifikation“ zusammen mit den Systemunterstützern erarbeiten muß. Das Problem ist also nicht trivial. Natürlich muß die Modifikation „qualifiziert“ werden, soll wohl heißen: zertifiziert ! Das dauert natürlich, denn wer will denn bitte das Risiko eingehen (von Zuständigkeiten mal abgesehen) eine nicht-triviale Modifikation des Avionik-Systems zu zertifizieren…………
ich Frage mich ob das Problem nur bei den deutschen ist oder haben auch andere Länder die NH90 benutzen auch die gleichen Probleme?
von den hab ich noch keine Beschwerden oder ähnliches gehört.
ich finde ja schon „eingetrudelt“ tendenziös :-)
„Qualifiziert“ heißt als vertragsgemäße Lösung vom Auftraggeber akzeptiert. Ob diese Lösung dann noch zugelassen werden muss ( ist wahrscheinlich so) wird wohl noch bekannt werden. Jedenfalls wird noch auf Wochen hinaus mit diesem Mangel gelebt werden müssen.
Ein NH 90 so schwer beschädigt, dass er nach Hause transportiert werden musste. Ein NH 90 für den ein Spezialistenteam zur Reparatur anreisen musste. Und alle leiden unter Ausfällen der Navigationsanlage unter bestimmten Bedingungen.
Das Los von „Beta-Testern“.
Da fällt mir nur die Reaktion des Ministeriums auf die Kritik an der Beschaffung des NH 90 für die Marine ein: „Die vergleichenden Untersuchung sind schon älter und zwischenzeitlich sind Veränderungen vorgenommen worden.“
Da kann sich die Marine auf diesen Hubschrauber freuen. Langweilig wird es damit nicht.
Wieviele von den Vögeln sind denn eigentlich in Afghanistan stationiert?
Und wieviele davon sollen länger als 2014 bleiben?
Nach den Berichten hier auf AgA scheint es ja so, dass die Anzahl langsam abnimmt, und wenn ab 2014 die Amerikaner weg sein sollten, bzw. mit einem noch nicht genauer ausgewählten Kontingent doch da bleiben sollten wäre es doch wichtig gerade Rettungseinsätze (an die Abkürzungen trau ich mich nicht ran) fliegen zu können.
Kann hier jemand was dazu sagen?
Werferfehler
Mit der Aussage von @Lippe65 „bezüglich des RHM – das Gerät hat sich seit Jahren auch ggü. anderen nutzenden WaSys nicht verändert – dort arbeitet es aber Stand-alone. Im NH90 ist es in die Avionik integriert und da schlagen die Grundsätze der Regelungstechnik gnadenlos zu – never touch a runing System!“ scheint mir @klabautermann mit seiner Feststellung „Der altbekannte interrupt conflict Teufel bei hybriden Systemen“ den Nagel auf den Kopf getroffen zu haben. Dafür spricht auch, daß nach dem manuellen Resetten das System wieder voll funktionsfähig ist.
Mit anderen Worten, es scheint an einer HW-/SW-Lösung zu fehlen, die eine Unterbrechungsanforderung genereriert („hallo Rechner, ich, der RHM spinne wahrscheinlich gerade, weil das Gelände so durchschnitten ist“). Ferner an einer SW-Lösung, welche die Unterbrechungsanforderung erkennt und einen „Überbrückungsalgorithmus“ auslöst, so daß das restliche System nicht abstürzt. Das Ganze muss natürlich aus Flugsicherheitsgründen zeitlich überwacht werden (der Überflug von Waldrändern, Klippe und Bergflanken erfolgt in einem relativ kleinem Zeitfenster) und wenn die Unterbrechungsanforderung innerhalb eines bestimmten Zeitfensters negiert wird (d.h. der RHM mitteilt “hallo Rechner, ich bin wieder voll da“), muß der Überbrückungsalgorithmus beendet und der „Normalmodus“ wieder aufgenommen werden (vgl. http://en.wikipedia.org/wiki/Interrupt_request). Auch sollte man vielleicht darüber nachdenken, wie sieht denn das „Notprogramm“ des Nav-Systems aus, wenn tatsächlich ein Teil der Sensorik bzw. der Input-Signale ausfallen.
Sprich, sicherlich in der Umsetzung keine kleine Baustelle – wie auch @schleppi ausführt -, aber von der Regelungstechnik her m.M.n. von relativ geringer Komplexität. Gretchenfrage wird sein, in wie weit ist das in HW und SW betagte Gesamt-Nav-System des NH90 „umerziehungsfähig“ bzw. sind überhaupt auch hier noch „Aufwuchspotentiale“ vorhanden? Oder stehen da umfänglichere Modifkationen und Nachrüstungen zur Konfliktlösung an?
Eurocopter schreibt ja von „Modifikation erarbeitet“, „qualifiziert“ und „mit der Lösung ausgestattet“.
@fiete
Der Vergleich der NH90 TTH/NTH/NFH/NFH NGEN… der einzelnen Nationen geht so nicht. Ich glaube, dass es da nicht zwei wirklich identische gibt (Hardware/Software/Technisch-Logistische Konzepte….).
Von daher ist der Hinweis auf die erfolgreiche Nutzung auch nicht unbedingt passend (Wobei „Erfolgreich“ auch immer im Auge des Betrachters liegt).
@ schleppi – und wie die sich „freut“….
leicht OT: und zu Hause hat der Bo 105 den letzten Schuss abgegeben: http://www.deutschesheer.de/portal/a/heer/!ut/p/c4/NYu7CsJAEEX_aCYJLKKdEgSbWMbYbXaHZGAfYZiYxo93t_AeOM3h4hsLyX54sco52YAvnBxf5gNWIoG4B-VIni3MHPyR3Uo41pMncDmRVisl5eJFrGaBLYuGWnaRUoA9Tk3b3xrT_Nd-T8PYm3PXmcdwf-IW4_UHBajn4g!!/
noch mehr OT: der EGV Bonn wurde heute auch i.D. gestellt
@GNY4742: (Zitat) „Der Vergleich der NH90 TTH/NTH/NFH/NFH NGEN… der einzelnen Nationen geht so nicht. Ich glaube, dass es da nicht zwei wirklich identische gibt (Hardware/Software/Technisch-Logistische Konzepte….)“.
Könnte mir vorstellen, daß ist die genau die Aussage, auf die man in Brüssel bei der Wettbewerbskommision aufgrund einer angeblichen Wettbewerber-Beschwerde im Sinne des § 100c GWB i.V.m. RL 2009/81/EG wartet, sodaß die ursprünglich geschlossenen Entwicklungsverträge zum NH90 TTH und NH90 NFH für die 18 SEA LION nicht mehr greifen können und erneut ausgeschrieben bzw. das Marinehubschrauber-Vergabeverfahren aus 2010/11 wieder aufgegriffen werden muß.
Völlig losgelöst von den intern sicherlich auf den Arbeitsebenen diskutierten technischen, funktionalen und operativen Aspekten, sehen viele Politiker der vier maßgeblichen Fraktionen und Mitglieder des Verteidigungsausschusses, des Haushaltsausschusses und dessen Rechnungsprüfungsausschusses den „Marine-Hubschrauber-Sack“ noch lange nicht als zu. Man wartet nach der immer noch nicht beendeten und nervenraubend intensiven Detailarbeit in Sachen EuroHawk in gewisser Gelassenheit ab, wie das MoU bis ins letzte Detail – speziell beim SEA LION samt dessen Ausrüstung endgültig umgesetzt werden soll. Das MoU zwischen BMVg und EC soll nämlich eine Klausel enthalten, die besagt, daß im Falle der Nichtumsetzbarkeit auch nur eines einzigen der Eckpunkte der Vereinbarung, das gesamte MoU für das BMVg und die Eurocopter S.A.S. unwirksam ist.
„Eckpunkte“ sind wiederum die Neuverhandlungen der Lieferungs- und Leistungsverträge, auch für den SEA LION mit der NAHEMA und NHI. Ungeachtet vergabe- und wettbewerbsrechtlicher Aspekte, bedeutet dies u.a., daß z.B. bei einer Überschreitung des Gesamtpakets (NH90TTTH, UH TIGER und SEA LION) i.H.v. 25 Mio. € oder auch nur beim SEA LION bei einer Überschreitung der 915 Mio. € um z.B. 2,75 % eine neue „25 Mio. € Vorlage“ des BMF erforderlich ist, welche erst einmal den VgA und den HA passiert haben will. Also bei enem „ohne Moos nichts los“ wäre damit das gesamte MoU geplatzt, welches nicht nur Vielen der Politik, sondern auch dem Bundesrechnungshof ein Dorn im Auge ist!
Vielleicht hat man dafür mit einer SEA LION EQMT-Streichliste längst den Grundstein gelegt, falls diese sich nicht in toto umsetzen lässt?
Ich versuch mich mal …
> Mit anderen Worten, es scheint an einer HW-/SW-Lösung zu fehlen, die eine Unterbrechungsanforderung genereriert („hallo Rechner, ich, der RHM spinne wahrscheinlich gerade, weil das Gelände so durchschnitten ist“). Ferner an einer SW-Lösung, welche die Unterbrechungsanforderung erkennt und einen „Überbrückungsalgorithmus“ auslöst, so daß das restliche System nicht abstürzt.
Naja, so einfach dürfte es dann wieder nicht werden. Dem Text entnehme ich, dass das RHM ein Navi ist, dass Daten liefert für irgend eine Steuerung.
Weiter oben hieß es:
> Und alle leiden unter Ausfällen der Navigationsanlage unter bestimmten Bedingungen.
Ein solcher Fehler ist in der Regel sehr einfach zu korrigieren. Man erstellt ein Testfallszenario und dann kann ein Softwareentwickler diesen Fehler auf einem Entwicklungssystem bewusst erzeugen und mit entsprechenden Maßnahmen dann diesen Fehler vermeiden.
Wenn hier von einer erforderlichen Qualifizierung geredet wird, dann bedeutet dass, dass eine solche Maßnahme nicht greift.
Zu den militärischen Geräten kann ich nichts sagen, aber bei den zivilen Navis gibt es ein Zentralproblem, das diese für eine Steuerung ungeeignet macht. Diese Dinger brauchen nämlich immer wieder mal einen Reset. Meines führt dies automatisch durch während der Fahrt, der Vorgänger blieb irgendwann hängen und ich musste den Reset-Knopf drücken. Irgendwann taucht das Gerät ab, dann kommt der Begrüßungsbildschirm und dann die ersten Begrüßungsdialoge usw.
Das hängt damit zusammen, dass die interne Garbage-Collection eines Programms nicht sauber arbeitet. Einzelne Programmteile fordern für bestimmte Berechnungen Speicherplatz an und geben den kurz danach wieder frei. Da die Anforderungen und Freigaben asynchron verlaufen wird der freie Speicher zunehmend fragmentiert. Programmentwicklungen unter .net und die Java haben eine relativ sicher funktionierende Garbage Collection, alte C bis C++ haben dagegen definitiv keine, zu der Zeit musste der Programmierer sich ggf. selbst drum kümmern und das machte die Programmentwicklung aufwändig und die Software störanfällig.
Wenn in Spezialsituationen der Speicherplatz des Navis angefordert und nicht mehr zurückgegeben wird, dann führt das zu sehr unschönen und unkontrollierbaren Crashs. Wenn das Zeug schon Jahre unverändert im Einsatz ist, dann ist die eigentliche Entwicklermannschaft (Beim einem Navi dürften das über 20 Leute gewesen sein) nicht mehr greifbar und nur noch eine Pflegetruppe (vielleicht 3-5 Leute) vorhanden. Die können aber solche Probleme nicht mehr stemmen. Selbst wenn sie die Qualifikation haben (und das ist eigentlich anzunehmen), die sind nicht mehr dafür ausgestattet. Solche Fehler einzugrenzen und auszumerzen ist sehr aufwändig. Wenn man die Software an solchen Stellen ändert, dann braucht man eine neue Zulassung!
Im normalen Alltag erzeugt das Ding nur Positionsangaben und da mag das dann alles gehen und das erklärt, wieso das Gerät allgemein funktioniert. Wenn man das dann aber in die Steuerung packt, dann werden unübliche APIs dauernd aufgerufen und dann hat man das Problem.
Wenn da eine Avionik hinter hängt, dann ist genau besehen das Navi unbrauchbar für diesen Zweck. Wo will ich Ersatzwerte herbekommen, wenn dieser Sensor ausfällt und ich mich gerade in einem abenteuerlichen Manöver befinde? Von der Theorie her werden die aktuellen Bewegungsdaten extrapoliert, doch in speziellen Manövern steigt der Fehler in solchen Berechnungen extrem schnell an. Ersatzwerte sind daher in relativ kurzer Zeit unbrauchbar.
„Qualifizierung“ deutet darauf an, dass man alternative Wege zu gehen gedenkt. Das kann alles Mögliche sein, die folgende Liste ist keineswegs vollständig:
a) Berechnungen des RHM werden nicht mehr genutzt, sondern von der Regelung übernommen
b) Man setzte mehrere RHM parallel ein, im Zweifel kann man bei drei Geräten immer eines als Defekt erkennen.
c) Man installiert einen größeren Speicher und einen Prozess, der die Fragmentierung überwacht und ggf. in ungefährlichen Situationen autark resettet.
> Der Vergleich der NH90 TTH/NTH/NFH/NFH NGEN… der einzelnen Nationen geht so nicht. Ich glaube, dass es da nicht zwei wirklich identische gibt (Hardware/Software/Technisch-Logistische Konzepte….).
Naja, es gibt noch einen weiteren Punkt, der einen Vergleich ausschließt. Ein Franzose würde einfach das „spinnerte Gerät“ ausschalten und per Hand weiter fliegen und danach das Gerät wieder einschalten. Warum das die Deutschen nicht hinbekommen, das weiß ich nicht.
@Wolfgang-2
macht alles Sinn, was Sie da schreiben……es können allerdings mehrere „Instabilitäten“ vorliegen, so stellt sich mir zBsp die Frage, wie denn konkret die Vernetzung des Systems aussieht, will sagen: wie sieht der Datenbus im NH90 aus? Falls das ein integriertes Bordnetz ist (wie z.Bsp bei der K130), so dass auch die Comms-Daten über das selbe Netz laufen wie die Avionik-Daten, dann Prost Mahlzeit.
@Werferfehler:
Der Einsatz ist bis Mitte 2014 geplant.
Personell und materiell war nicht mehr möglich.
Aber ab Ende Oktober 2013 konzentrieren wir uns auf Mazar und kehren den Ereignissen draußen (endgültig) den Rücken zu – der Krieg der Anderen.
Da braucht man dann auch kein MedEvac mehr.
@Klaubautermann: Die Bus-Vernetzung dürfte http://www.pk-avionics.ch/ppt/Avionicpower.pdf entsprechen, siehe dort Folie 3, denn der CH 53 hat das NH90-Cockpit und dessen Avioniksystem von Eurocopter eingerüstet bekommen.
@Wolfgang-2: Der „RMH“ ist ein Radio-Altimeter und mißt nicht wie der barometrische Höhenmesser die Höhe über Normal-Null, sondern die effektive Höhe über Grund. Die Flughöhe wird aus der Signallaufzeit der ausgesendeten und vom Terrain bzw. der Wasseroberfläche reflektierten und wieder empfangenen Radarimimpulse berechnet. die Messung erreicht in Bodennähe eine Genauigkeit von weniger als 1 m, aus großen Höhen von ca. 1,5 % bis 2%.
Offenbar kann das RMH-System bzw. das nachgeschaltete NAV-System beim NH90 keine steilen Impulsflanken „leiden“, wie diese beim Überfliegen von Waldrändern, Klippen, steilen Bergflanken und Schluchten auftreten.
Es stellt sich evt. die Frage, ob die verfügbaren „Inputs“ barometrische Höhe und GPS-Höhe zur Plausibilitätsprüfung für das Nav-System bzw. für einen „Überbrückungs-Algorythmus“ nutzbar sind.
> Aber ab Ende Oktober 2013 konzentrieren wir uns auf Mazar und kehren den Ereignissen draußen (endgültig) den Rücken zu – der Krieg der Anderen.
Ein Grund mehr, einfach mit Handbetrieb zu fliegen.
> Falls das ein integriertes Bordnetz ist (wie z.Bsp bei der K130), so dass auch die Comms-Daten über das selbe Netz laufen wie die Avionik-Daten, dann Prost Mahlzeit.
Netzwerkfehler führen in der Regel nicht dazu, dass einzelne Geräte ausfallen, sondern nur dass die Kommunikatoin zusammenbricht. Dann meldet jedes einzelne Gerät „Cannot find the rest of the world“, es läuft aber für sich autark weiter. Aber dazu gibt es hier keine Anzeichen.
@Vtg-Amtmann
> Offenbar kann das RMH-System bzw. das nachgeschaltete NAV-System beim NH90 keine steilen Impulsflanken “leiden”, wie diese beim Überfliegen von Waldrändern, Klippen, steilen Bergflanken und Schluchten auftreten.
Naja, diese Erkenntnis ist auch nicht wirklich neu. Ich stehe in meinem Wohzimmer, die Türe zum Arbeitszimmer ist geöffnet und ich messe den Abstand zur Wand in meinem Arbeitszimmer – von einem Punkt im Wohnzimmer aus. Nehme ich das Gerät aus dem Aldi – das ist ein Ultraschallentfernungsmesser – dann bekomme ich den Abstand zur Tür, denn die Türahmen reflektieren bereits. Messe ich mit einem Bosch-Entfernungsmesser – das ist ein Laser – dann bekomme ich den Abstand zur Wand.
Wenn man von einem Hubschrauber aus misst mit einer Welle, die sich Kugelförmig ausbreitet, dann zählt in der Regel die erste Reflektion. Da genügen einfache Taumelbewegungen und das Ding hat einmal eine Höhe von 30 Metern und dann wieder 100 usw. Bei sowas wirft jeder Regelalgorithmus irgendwann die „DuHastEineMeiseExeption“. Aber das hätte man m.E. auch vorher wissen können und ich bin davon überzeugt, dass man das auch wußte. Wahrscheinlich hat wieder einer aus der Abteilung „Creativbürokratisches Problemmanagement“ zugeschlagen und das Problem als „Nicht vorhanden“ deklariert.
> Es stellt sich evt. die Frage, ob die verfügbaren “Inputs” barometrische Höhe und GPS-Höhe zur Plausibilitätsprüfung für das Nav-System bzw. für einen “Überbrückungs-Algorythmus” nutzbar sind.
Das kann ich nicht beurteilen. Die GPS-Daten sind m.E. nur nutzbar, wenn es eine gute Karte von der Gegend gibt. Dann weiß das System von der Klippe und kann die Sprünge erklären resp. korrigieren. Dass es nun Karten gibt von Afghanistan auf denen jeder Baum eingezeichnet ist, das bezweifle ich.
Eigentlich braucht man aber Messungen mit einer anderen Physik. Man muss ein Bodenprofil messen. Sowas muss man entwickeln und sowas kostet Geld. Deswegen war eben das creativbürokratische Problemmanagement erfolgreich. Man muss es nur in den Beipackzettel schreiben, dann wäre alles gut.
Wie gesagt: Aussschalten und von Hand fliegen. Richtige Piloten sollten das hinbekommen.
@ Vtg-Amtmann
Es stellt sich evt. die Frage, ob die verfügbaren “Inputs” barometrische Höhe und GPS-Höhe zur Plausibilitätsprüfung für das Nav-System bzw. für einen “Überbrückungs-Algorythmus” nutzbar sind.
Das hängt wohl vor allem davon ab wo dieser Abgleich stattfinden soll.
Die meisten Anordnungen dürften naturgemäß in irgendeiner Form hierarchisch oder sequentiell aufgebaut sein:
– hierarchisch: Sensoren werden in übergeordnete Komponenten eingebunden, von denen sie konfiguriert/überwacht werden, und an die sie ihre Daten liefern
– sequentiell: Ergibt sich bei Sensoren fast von selbst: Aufnahme, Auswertung, Anzeige
Wenn der Datenabgleich „oben“ bzw. „hinten“ stattfinden soll ist das ziemlich unkritisch umzusetzen. Wenn die Komponenten ausreichend stabil und modular, dann ist es an der Stelle auch vergleichsweise gut möglich Komponenten „abzuklemmen“ und neuzustarten bzw. auszutauschen. Auch wenn klar sein sollte dass das nicht in Nullzeit geschieht, und je nachdem was man gerade macht können einige hundert Millisekunden eine verdammt lange Zeit sein.
Richtig frickelig (und teis innerhalb der zeitlichen Anforderungen unmöglich) wird es, wenn die „oben“/“hinten“ gewonnenen Daten „unten“/“vorne“ dringend und zwingend benötigt werden um die Komponente am Funktionieren zu halten. Hin und wieder mal nachjustieren ist vergleichsweise unkritisch, weil es nur um bessere Werte und nicht die Funktionsfähigkeit insgesamt geht (und meist auch zeit-unkritisch ist). Aber die Notwendigkeit ständigen Feedbacks um das System am Laufen zu halten verkompliziert die Sache gewaltig (zusätzliche Fehleranfälligkeit, zusätzliche zeitliche Anforderungen an das Gesamtsystem).
Um ehrlich zu sein: Eine so kritisch-störanfällige Komponente ist angesichts der womöglich tödlichen Folgen eines Systemversagens hier ziemlich fehl am Platz. (Irgendwie erinnert mich das grad die Tornardo-Abstürze, wo die Maschinen meines Wissens urplötzlich nach oben zogen.)
Vielleicht liegt bei der ganzen Sache auch ein bestimmter Denkfehler zu grunde: Dass militärisches Gerät, dass seit Jahren im Einsatz ist, ja so toll sei.
Dem menschlichen Benutzer ist es ziemlich egal wenn die Datenpunkte mit 50ms Verspätung ankommen, oder das Gerät in 10% der Fällen gar keine Daten liefert, oder in den Datenpunkte oft oder teils heftige Ausreißer drin sind. Das kriegt ein Mensch der auf sein Anzeigegerät schaut gar nicht mit.
Wenn aber jetzt mehrere Komponenten zeitkritisch zusammengeschaltet werden, dann sind die benötigten Qualitätsstandards deutlich andere.
Simplisitisches Beispiel: Drei Komponenten, die jeden 5. Datenpunkt nicht zeitgemäß liefern, würden jede für sich einem menschlichen Beobachter wahrscheinlich gar nicht auffallen: Position stimmt, Höhe stimmt, Zeit stimmt. Vernetzt (Kurs im dreidimensionalen Raum) ergäbe sich aber eine Fehlerquote von etwa 50%. Und hier wäre es außerdem wesentlich, ob die Sensoren melden dass ein Fehler vorliegt, oder nicht. Schlimmer als ein Fehler ist ein unerkannter Fehler.
Jetzt kann man natürlich mit entsprechender Nachbearbeitung noch einiges rausholen (fehlende Datenpunkte extrapolieren, Ausreißer rausfiltern etc.), und in der Praxis wird man oft nicht darum herumkommen. Aber es sollte klar sein, dass ein solches System immer noch anfällig ist, da hier letztlich oft Erfahrungswerten gearbeitet wird. Ändern sich die Umstände unvorhergesehen kann das die Nachbereitung überfordern. Und (auch abhängig davon wie darauf reagiert wird) ist das ist dann halt der Unterschied zwischen „das Design ist stabil“ und „funktioniert ohne Fehler im bisherigen Umfeld“. ;)
Und „stürzt in unbekannter Umgebung einfach ab“ ist da glaub schwer zu unterbieten.
Als fliegerischer Laie verstehe ich nach all der Diskussion um Nav-Anlage, Karte, Kompass, etc. immer noch nicht, ob es weiterhin ein Funkproblem beim NH90 gibt.
Mhhhhh.
OTTAWA — Canadian air force engineers and flight-certification officials are grappling with serious concerns related to the electronics aboard the CH-148 Cyclone helicopters that are supposed to replace the geriatric Sea Kings.
That’s the word from defence sources with intimate knowledge of the troubled program.
The federal government has refused to accept four test helicopters, currently parked at the Canadian Forces facility in Shearwater, N.S., on the basis they are „non-compliant“ — and most of the public explanation has related to software issues.
http://www.ctvnews.ca/canada/cyclone-chopper-technical-concerns-are-potential-show-stoppers-sources-1.1452160#ixzz2esw9Rdx8
@Memoria: Wenn man in beiden Threads zwischen den Zeilen ließt, gibt es Funkprobleme ‚en masse‘,sowohl zur Einsatzunterstützungszentrale, als auch zwischen fliegerierischer und medizinischer Crew. Über Crypto-Probleme wollen wir erst gar nicht reden.
Mitteilung des BMVg Presse- und Informationsstab:
In der Vorabmeldung „Bundeswehr-Hubschrauber haben schwere technische Mängel“
bezieht sich der Spiegel auf einen Sachstandsbericht des Einsatzgeschwaders Masari
Sharif aus dem Juni 2013, über den bereits die FAZ am 12.09.2013 berichtet hat.
Es ist schlichtweg falsch zu behaupten, dass aufgrund dieser technischen Mängel der
Einsatz des Fluggeräts bei einigen Missionen unmöglich sei und er nur eingeschränkt
einsetzbar wäre. Zwar gab es im Rahmen der Einweisungsflüge des NH90 in
Afghanistan im Juni 2013 technische Probleme, diese stellen aber keinen Grund für
einen Missionsabbruch dar. Es gibt keine Einschränkungen bei der Auftragserfüllung
Forward AirMedEvac in Afghanistan. Der NH90 hat seine volle Einsatzbereitschaft
bereits seit dem 23.06.2013 und erfüllt seitdem zuverlässig seinen Auftrag.