Forum-Sicherheitspolitik

(12.07.2024, 06:45)DorJur schrieb: [ -> ]Ist da schon etwas zum Grund bekannt? Machen die USA Druck?

CMS-330 mit AEGIS zu verknuepfen hatte sich als komplexer herausgestellt als gedacht, Integrationsrisiken und Leistungseinbussen potentiell zu hoch, und daher verworfen. Betrachtet es als Geruecht, da es dazu wie gesagt nichts offizielles gibt. Aber das ist der Grund, warum da auf einmal RAM fuer River-Klasse steht und eben nicht mehr Sea Ceptor.

Daher nehme ich eben an, dass man in Berlin darauf auch keinen Appetit mehr hat (dass man fuer F127 evtl SPY-6 vs SPY-7 praeferiert, wenn A-400 AMD Grafik so aussagekraeftig ist, ist noch mal ne andere Angelegenheit, aber auch spekulativ bis jetzt).

(12.07.2024, 11:26)Turin schrieb: [ -> ]CMS-330 mit AEGIS zu verknuepfen hatte sich als komplexer herausgestellt als gedacht, Integrationsrisiken und Leistungseinbussen potentiell zu hoch, und daher verworfen. Betrachtet es als Geruecht, da es dazu wie gesagt nichts offizielles gibt.

Wir haben also auf der einen Seite ein CMS, dass bewusst auf offene Schnittstellen zur einfachen Integration weiterer Module bzw. zur Verknüpfung mit anderen Systemen setzt, und auf der anderen Seite eine aufgespaltetes und modularisiertes CMS, dass inzwischen bewusst auch als aufgesetztes System angeboten wird, beides von einem Hersteller, und es funktioniert nicht vernünftig?

Die exakten technischen Aspekte bleiben spekulativ. Zur Kenntnis sollten wir nehmen, dass CMS-330 unter Lockheed Martin Kanada-Fuehrung fuer Kanada entworfen wurde, und dass zum Beispiel Spanien bei seiner nationalen Loesung (SCOMBA) zumindest oeberflaechlich betracht besser voranzukommen scheint. Ob es daher an umfangreicheren Anforderungen fuer CMS-330 oder an anderen Aspekten nationaler Praeferenzen hakt, ist zumindest mir unklar.

(12.07.2024, 13:05)Helios schrieb: [ -> ]Wir haben also auf der einen Seite ein CMS, dass bewusst auf offene Schnittstellen zur einfachen Integration weiterer Module bzw. zur Verknüpfung mit anderen Systemen setzt, und auf der anderen Seite eine aufgespaltetes und modularisiertes CMS, dass inzwischen bewusst auch als aufgesetztes System angeboten wird, beides von einem Hersteller, und es funktioniert nicht vernünftig?

Das aufgesetzte System kann hier das entscheide Problem sein. Wenn Lockheed Martin Kanada nicht den Aegis Quellcode zur Verfügung hat und CMS und Aegis von der Basis nicht kompatible sind, dann wäre das durchaus denkbar. Mit Emulationen irgendwie lösbar, aber halt unter Leistungs- und Sicherheitseinbußen. Die Spanier haben bei ihrem CMS von vornherein mit der Integration von AEGIS Componenten geplant. Bei CMS 330 ist das nicht der Fall. Das gleiche Problem wird es vermutlich bei Tacticos geben und bezogen auf 9LV scheint bei der Hunter Klasse Saab nur das Interface, quasi die Benutzeroberfläche, bereitzustellen, die technische Basis ist komplett AEGIS. Mit 9LV hat das eig. nicht viel zu tun.

(12.07.2024, 14:43)Kul14 schrieb: [ -> ]Das aufgesetzte System kann hier das entscheide Problem sein. Wenn Lockheed Martin Kanada nicht den Aegis Quellcode zur Verfügung hat und CMS und Aegis von der Basis nicht kompatible sind, dann wäre das durchaus denkbar.

Es geht mir nicht darum, dass ich mir nicht vorstellen kann wo Fehler auftreten könnten (denkbar ist da vieles). Ich halte es nur bemerkenswert, so es stimmt, dass ein inzwischen modulares CMS mit offener Architektur nicht mit einem modularen, bewusst auf Kompatibilität ausgelegten CMS mit offener Architektur sinnvoll kombiniert werden kann, obwohl beides vom gleichen Hersteller stammt.

Modular und offen sind ja am Ende nur Marketingbegriffe und ich gleube heir beziehen die sich eher auf Subsysteme und nicht darauf zwei CMS miteinander zu kreuzen. Nur weil der Boxer modular aufgebaut ist heißt es nicht, dass auf dem Boxer ein M1 Turm drauf passt. Und nur weil "Linux" Open Source ist heißt es nicht das man Mac-Software darauf laufen lassen kann... Am Ende natürlich alles möglich, aber wollten wir nicht eine einfache, zuverlässige und schnell verfügbare Lösung?

Wir kaufen uns mit diesem Aegis-Ansatz so viele Probleme ein und versuchen ja doch wieder die Goldrandlösung zu entwickeln. Verlängerte F126 mit TRS-4D LR anstatt TRS-4D, zusätzliche VLS Zellen, PAC-3 MSE integrieren und fertig ist die AAW Fregatte.

(12.07.2024, 17:07)Kul14 schrieb: [ -> ]Wir kaufen uns mit diesem Aegis-Ansatz so viele Probleme ein und versuchen ja doch wieder die Goldrandlösung zu entwickeln. Verlängerte F126 mit TRS-4D LR anstatt TRS-4D, zusätzliche VLS Zellen, PAC-3 MSE integrieren und fertig ist die AAW Fregatte.

Also ist dein Vorschlag, ein nicht einsatzreifes und erprobtes Radar, welches seine BMD-Fähigkeit erst noch nachweisen muss, mit einem Flugkörper zu koppeln, dessen Zusammenspiel mit diesem Radar ebenfalls nicht erprobt ist?

Welches Feuerleitradar darf es denn neben TRS-4D/LR noch sein? Welches FüWES sollte dann zum Einsatz kommen? Hoffentlich nicht die nachgewiesen nicht einsatztauglichen FüWES der F125 sowie K130 2. Los...

In Deutschland gibt es derzeit keinen FüWES-Lieferanten, der so ein Projekt national stemmen könnte. Atlas hat sich doch mit der Performance bei F125 und K130 2. Los selbst disqualifiziert.

Mit der Marine-"FüWES"-Eigenentwicklung MESE möge mir bitte keiner kommen, mir graut ehrlich gesagt davor, den alten "SATIR-Geist", den man aus meiner Sicht aus gutem Grund in einer Flasche verkorkt hat, wieder rauszuholen.

Diese Gespinst um das CMS 330 riecht doch förmlich danach, dass manche Altvorderen mit Hilfe der Industrie genau diese "erfolgreiche" Zusammenarbeit wiederbeleben möchten. Auch bei SATIR hat die Industrie den Löwenanteil programmiert und geleistet sowie mir das aus diesen Zeiten noch in Erinnerung ist. Will mal wer raten, wer hinter SATIR steckte als Industriepartner?

Dann lieber Saab 9LV + AEGIS wie auf den neuen australischen Schiffen...

(12.07.2024, 17:07)Kul14 schrieb: [ -> ]Modular und offen sind ja am Ende nur Marketingbegriffe

Und das weißt du woher? Ernstgemeinte Frage, denn klar werden die Begriffe auch gern als Schlagworte für schöne Präsentationen verwendet, deshalb lassen sie sich aber nicht darauf reduzieren. Was öffentlich bekannt ist deutet für mich nicht darauf hin, dass dies in dem Fall so ist, ich lasse mich da aber gern eines besseren belehren. Nur bitte nicht mit irgendwelchen Spekulationen.

(12.07.2024, 17:14)DeltaR95 schrieb: [ -> ]Mit der Marine-"FüWES"-Eigenentwicklung MESE möge mir bitte keiner kommen, mir graut ehrlich gesagt davor, den alten "SATIR-Geist", den man aus meiner Sicht aus gutem Grund in einer Flasche verkorkt hat, wieder rauszuholen.

Ich bitte dich, was hat denn MESE mit SATIR wirklich gemein? Weder die Entstehungsgeschichte, noch die grundsätzliche Auslegung, noch die tatsächlichen Möglichkeiten aufgrund des Konzepts sind in meinen Augen in irgendeiner Form vergleichbar. Was ich bisher gesehen habe fand ich jedenfalls sehr überzeugend, was fehlt ist in meinen Augen eine breitere Unterstützung ohne größere Einflussnahme. Mir ist durchaus klar, dass du direkt eine Eigenentwicklung unter Generalverdacht stellst, aber ich halte MESE tatsächlich für den richtigen Ansatz für die mittelfristige Zukunft. Für die F127 dürfte es allerdings zu knapp werden, sofern nicht wesentliche Module von der Industrie kämen.

(12.07.2024, 17:14)DeltaR95 schrieb: [ -> ]Also ist dein Vorschlag, ein nicht einsatzreifes und erprobtes Radar, welches seine BMD-Fähigkeit erst noch nachweisen muss, mit einem Flugkörper zu koppeln, dessen Zusammenspiel mit diesem Radar ebenfalls nicht erprobt ist?

Welches Feuerleitradar darf es denn neben TRS-4D/LR noch sein? Welches FüWES sollte dann zum Einsatz kommen? Hoffentlich nicht die nachgewiesen nicht einsatztauglichen FüWES der F125 sowie K130 2. Los...

In Deutschland gibt es derzeit keinen FüWES-Lieferanten, der so ein Projekt national stemmen könnte. Atlas hat sich doch mit der Performance bei F125 und K130 2. Los selbst disqualifiziert.

Mit der Marine-"FüWES"-Eigenentwicklung MESE möge mir bitte keiner kommen, mir graut ehrlich gesagt davor, den alten "SATIR-Geist", den man aus meiner Sicht aus gutem Grund in einer Flasche verkorkt hat, wieder rauszuholen.

Diese Gespinst um das CMS 330 riecht doch förmlich danach, dass manche Altvorderen mit Hilfe der Industrie genau diese "erfolgreiche" Zusammenarbeit wiederbeleben möchten. Auch bei SATIR hat die Industrie den Löwenanteil programmiert und geleistet sowie mir das aus diesen Zeiten noch in Erinnerung ist. Will mal wer raten, wer hinter SATIR steckte als Industriepartner?

Dann lieber Saab 9LV + AEGIS wie auf den neuen australischen Schiffen...

Die Alternative zum erprobten AEGIS is doch der Erstkunde irgendeinen anderes Landes zu sein, welches Argument gibt es so etwas zu tun? Irgendwelche Entwicklungen, sei es national oder bi bzw. multinational hätte man 20 Jahre vorher beginnen müssen - inklusive einer eigenen Raketenfamilien, hat man aber nicht daher kann man nur ein passendes System einzukaufen.

(12.07.2024, 18:06)Helios schrieb: [ -> ]Ich bitte dich, was hat denn MESE mit SATIR wirklich gemein? Weder die Entstehungsgeschichte, noch die grundsätzliche Auslegung, noch die tatsächlichen Möglichkeiten aufgrund des Konzepts sind in meinen Augen in irgendeiner Form vergleichbar. Was ich bisher gesehen habe fand ich jedenfalls sehr überzeugend, was fehlt ist in meinen Augen eine breitere Unterstützung ohne größere Einflussnahme. Mir ist durchaus klar, dass du direkt eine Eigenentwicklung unter Generalverdacht stellst, aber ich halte MESE tatsächlich für den richtigen Ansatz für die mittelfristige Zukunft.

"Technisch" liegen zwischen SATIR und MESE "Lichtjahre", das steht und stand auch meinerseits niemals zur Debatte.

Beiden gemein ist jedoch der Geist, es als Deutsche Marine allein "besser" zu können, als alle anderen Hersteller der Welt, die seit Jahrzehnten im Geschäft sind. Im derzeitigen Zustand unserer Bundeswehr spreche ich ihr sogar die Fähigkeit ab, einen belastbaren Anforderungskatalog oder gar eine Systemspezifikation allein zu erstellen.

Allein schon die Verwendung von Java (gemäß öffentlich bekanntem) stößt bei mir auf wenig bis gar keine Gegenliebe, da Java niemals als "Programmiersprache für (harte) Echtzeitanwendungen", obgleich es mehrere RTSJ Erweiterungen gibt, es es Echtzeit-fähiger machen, gedacht war.

Oder an diesem Beispiel "bildlich" beschrieben: Die US Navy hat es bei AEGIS versucht, auf Java zu portieren und hat bei den "non-mission critical" scheinbar nach öffentlichen Informationen aufgehört. In der US Navy arbeiten n.m.K. rund 350 Menschen an AEGIS, die es nicht hinbekommen haben, aber unsere Marine mit einem Team in einer Stärke, dass man an einer Hand abzählen kann, will es geschafft haben? Das klingt für mich zu gut um wahr zu sein, sorry, vielleicht bin ich einfach Berufsskeptiker...

Natürlich könnte MESE "das" FüWES der Deutschen Marine werden, aber das wird a) verdammt teuer, da Insellösung, b) woher sollen die ganzen Informatiker und Programmierer kommen, wenn der öffentliche Dienst so unattraktiv ist und c) woher soll das Wissen in der Marine kommen, wie man moderne FüWES entwickelt, wenn man in den Fähigkeiten Dekaden zurück hängt?

Die Idee von MESE mit seinen "Standardkonnektoren" klingt auf dem Papier super, wenn aber plötzlich jeder Hersteller, z.B. Hensoldt neben seiner Standardschnittstelle noch diesen Konnektor bedienen soll, bleiben wir wieder allein auf den Kosten sitzen, da diese sonst keiner verwendet. Wenn das Radar z.B. keinen MESE-Konnektor hat, muss wieder ein Übersetzer gebaut werden und genau dann ist man wieder bei der FüWES-Struktur, die man nicht haben will, weil übermäßig komplex.

MESE funktioniert doch wie AEGIS nur, wenn man gleichzeitig auch den Wildwuchs an angeschlossenen Subsystemen einhegt und da nicht auf jeder Schiffsklasse das Rad neu erfindet. Damit wird der Ansatz "Standard-FüWES der Marine" eher ein gesamter Ansatz für die Rüstungs- und Zulieferindustrie und DAS mag ich mir beim engen finanziellen Korsett der Bundeswehr bei aller Liebe nicht vorstellen.

Dann lieber mit einer anderen europäischen Nation eine gemeinschaftliche Entwicklung...

Die Frage lautet also am Ende:
Kauft man ein verfügbares FÜWES (AEGIS) OHNE Option auf leicht zu integrieren D/EU Radare und FK, wo am Ende ein Trum auch IMMER den Finger drauf hat?
(Die NATO ist unter dem eh am Ende... Putin weiß das..)

https://www.focus.de/kultur/kino_tv/gesp...32669.html

Oder reißen sich Hensoldt/Diehl und LM Kanada zusammen und versuchen dennoch ein ITAR freies modulares System zu bauen?

Und es bleibt immer noch meine Lösung :
2 FÜWES einbauen :
AEGIS nur für BMD und ESSM.... Wenn Trump. zickt wird BMD abgeschaltet..
(Aber der Rest geht, wenn IRIS T SLM und X Serien reif sind. In 2027/28?... Und CMS geht auch für ALLES Andere (ASW etc)
Das wird extrem teuer.... Aber dann, was NICHT BMD betrifft, 100% USA Veto sicher, denn von denen müssen wir, bzw Europa so oder so konventionell unabhängig werden (außer UK, die pennen ja mit denen)

F/UK/NL wissen schon, warum sie( zwar um einiges schlechtere) aber US unabhängige Radar, FÜWES und FK einbauen...

Ich bin für :
NEUES FÜWES unter deutscher Kontrolle für alle zukünftigen Schiffs Neubautrn, QUELLOFFEN... Ggf. auch für UK/F Radsre und Raketen... und mit dem Bau der F-127 drei Jahre warten, bis das funktioniert.

(12.07.2024, 18:43)Milspec_1967 schrieb: [ -> ]Ich bin für :
NEUES FÜWES unter deutscher Kontrolle für alle zukünftigen Schiffs Neubautrn, QUELLOFFEN... Ggf. auch für UK/F Radsre und Raketen... und mit dem Bau der F-127 drei Jahre warten, bis das funktioniert.

Quelloffen ist wohl der falsche Begriff, denn der bedeutet:

Zitat:Open Source ist Englisch für „Quelloffen“, was in der Softwareentwicklung bedeutet, dass der Quellcode von Open-Source-Software öffentlich zugänglich ist und von jeder Person vervielfältigt und verändert werden kann.

Warum sollte die Marine ihren FüWES-Quellcode der Öffentlichkeit preisgeben?

Es reicht doch schon völlig aus, nicht proprietäre offene Standards zu verwenden - das ist aber kein Alleinstellungsmerkmal von MESE, das machen (fast) alle FüWES-Hersteller inzwischen so. Saab nennt das im Kontext 9LV Mk 4 auch "Naval Open Architecture", was ein Konzept der US Navy aus den Anfängen der 2000er ist, also wirklich neu nun auch nicht.

Ich frage mich sowieso immer wieder, warum alle scheinbar davon ausgehen, dass wenn die Deutsche Marine einen Hersteller, z.B. Thales, beauftragt, alles "in die Hose gehen muss", aber wenn die Deutsche Marine dann irgendeine Firma mit der Programmierung einer selbst spezifizierten Software (genannt FüWES) beauftragt, alles wieder "tutti" sein soll. Das ist absolut kontradiktorisch.

Die Frage muss doch eher sein: Es gibt so viele FüWES am Markt, warum ist scheinbar KEINES davon geeignet, die Anforderungen der Deutschen Marine zu erfüllen? Oder ist vielleicht der "Kunde" das Problem?

Das wäre nicht mal überraschend, wenn man sich mal die Mühe, die Zeitungsarchive aus den 1960er bis 1980er z.B. für SATIR der LÜTJENS zu durchforsten - die damaligen Projekte liefen genauso wenig reibungslos, wie F123 FAP, F124 bzw. F125. Wenn man die Name der Schiffsklassen austauscht, könnte man die fast 1:1 heutzutage wieder verwenden.

Die Nostalgie verklärt vieles, auch der Blick auf SATIR, PALIS und AGIS - der Weg, bis die mal liefen, war ein ebenso teurer, steiniger und langer, wie heute. Nur das diese alten FüWES erheblich weniger komplex waren, als die heutigen...

(12.07.2024, 18:27)DeltaR95 schrieb: [ -> ]Beiden gemein ist jedoch der Geist, es als Deutsche Marine allein "besser" zu können, als alle anderen Hersteller der Welt, die seit Jahrzehnten im Geschäft sind.

SATIR wurde doch Anfangs in sehr enger Kooperation mit der USN entwickelt und anschließt vor allem von oben nach unten weitergepflegt (wenn man das überhaupt so nennen will). Ich sehe da einen ganz anderen Geist als bei MESE, mir geht es weniger um die technische Basis. Und wie gut die anderen Hersteller dieser Welt, die seit Jahrzehnten im Geschäfts sind, es hinbekommen ist doch hinlänglich bekannt und zeigt sich immer wieder. Oder wäre es dir völlig egal, wer es macht, Hauptsache er ist schon lange dabei? Ich denke nicht, wenn ich so manche Aussage von dir hinsichtlich der vergangenen Erfahrungen rückblickend betrachte.

Dabei geht es mir gar nicht um MESE, auch wenn ich den Ansatz weiterhin für gut und richtig halte. Wir brauchen ein Kernsystem unter eigener Kontrolle, hardwareunabhängig und flexibel erweiterbar, mit standardisierten Schnittstellen. In meinen Augen muss es nicht darum gehen, irgendetwas besser zu machen als andere, sondern vor allem diese in meinen Augen Kernfähigkeit in die Bundeswehr zu holen und dort als echten Standard zu etablieren. Ja, das kostet, ja, das dauert, ja, das erfordert eine besondere Kraftanstrengung, aber das gleiche gilt doch für den aktuellen Flickenteppich mit allen damit einhergehenden Opportunitätskosten genauso, vor allem wenn das ganze universelle betrachtet wird. Nur die Nachteile oder den Aufwand zu bewerten, und die potenziellen Vorteile außen vor zu lassen ist für mich die falsche Betrachtungsweise. Da wo die eigenen Grenzen erreicht werden lassen sich andere Systeme andocken. AEGIS für IAMD und BMD? Warum nicht als Modul, hier muss das Rad nicht neu erfunden werden. Funktionieren kann das, wenn man denn wollte. Und es wäre so viel sinnvoller, als den aktuellen Gemischtwarenladen immer weiter und weiter auszubauen.

(12.07.2024, 18:06)Helios schrieb: [ -> ]Und das weißt du woher? Ernstgemeinte Frage, denn klar werden die Begriffe auch gern als Schlagworte für schöne Präsentationen verwendet, deshalb lassen sie sich aber nicht darauf reduzieren. Was öffentlich bekannt ist deutet für mich nicht darauf hin, dass dies in dem Fall so ist, ich lasse mich da aber gern eines besseren belehren. Nur bitte nicht mit irgendwelchen Spekulationen.

Weil mit Modular nicht gesagt wird auf welcher Ebene das Sytem modular ist und ob diese Module unabhängig voneinander sind. Theoretisch ist jede Software auf der untersten Ebene Modular und besteht wenn man so will nur aus nullen und einsen. Na gut das haben sie damit sicherlich nicht gemeint, aber eine erste Stufe der (sinvollen) Modularität wäre die Schaffung von gewissen Bibliotheken. Da ist am Ende die Frage, wie die Abhängigkeiten der einzelnen Bibliotheken aussehen. Sind sie alle voneinander abhängig, dann kann ich schlecht eine einzelne Bibliothek herausreißen und in einem anderen Programm verwenden. Wenn jedoch alle Bibliotheken unabhängig sind, dann bedeutet das viel unnötige extra Programmierung eine schlechtere performance. Eine Änderung an einer Bibliothek würde hier auch immer ein Update des ganzen Systems bedeuten, da wir immer noch von einem monolithischem Programm ausgehen. Auch ist hier dann die Frage wie dieser Bibliotheken zur Verfügung stehen, als Quellcode oder Binär. Falls Binär, dann muss das zur Prozessorarchitektur passe. Nächster Schritt wäre das System aus verschiedenen einzelnen Programmen aufzubauen, welche dann Module darstellen. Hier muss dann wieder Prozessorarchitektur und je nachdem welche Bibliotheken verwendet werden auch das Betriebssystem (auch ein Modul) passen, damit man diese Module in einem anderen System verwenden kann. Dazu kommen wieder die eventuellen Abhängigkeiten von anderen Programmen.

@Kul14:
Also lange Rede kurzer Sinn, du weißt es schlicht nicht. Das ist in Ordnung, damit erübrigt sich aber die weitere Diskussion.