Vor 1 Stunde
@DeltaR95
Grundsätzlich hast du zwar recht, man benötigt hierbei das Interface (oder je nach dem einen Klon dessen), das alleine heißt aber nicht, dass somit der weg frei zu einer CMS Integration ist. Denn dafür muss das Lfk-Interface auch in der Lage sein, mit diesem bestimmten CMS zu interagieren.
Ein Interface ist wie ein Steckdosen-Adapter, der Input/Output jeweils zwischen den verschiedenen Kommunikationswege austauscht, sie somit kompatibel macht. Wie bei Steckdosen-Adaptern steht und fällt das aber damit, für was ein Interface gedacht ist, Single line, Dual line, …, bis hin zur universalen Kommunikation.
Und diese Universalauslegung, die wir benötigen, da wir hier nicht von [SM-2 <-> AEGIS] sondern von bspw [SM-2 <-> 9LV] sprechen, hat das Interface der IIIC nicht. Die IIIA hatte das, weshalb diese auch sowohl auf AEGIS wie Non-AEGIS Schiffen Anwendung finden kann. Diese Fähigkeit wurde aus der IIIC aber herausgespart weil es zu wenig Non-AEGIS Interessenten für die IIIA gegeben hatte und ein Universallink mit dem fortschreitenden Integrationsstatus der Baselines zu immer mehr Problemen geführt hat.
Der SM-Toaster den wir uns bestellen wollen hat den falschen Adapter für unsere Steckdose, sozusagen.
Du hast nicht ganz Unrecht dahingehend, dass:
Geht das technisch gesehen? Sicher. Können wir das tun? Nein. Kann Raytheon das tun? Ja, werden sie aber nicht.
Ein System muss dafür erst in der Lage sein, parallel Suchen, Verfolgen und Uplink/Downlink unterhalten zu können, woran es bei den meisten Systemen schon inhärent scheitert. Das sind auch meistens Gründe, die sich nicht durch Softwareupdates lösen lassen, weil die Systemarchitektur (runter bis zur RF-Hardware) hierfür mitspielen muss.
Das ist unter anderem auch der Grund, warum bspw SeaFire und das SM400 parallel existieren, obwohl die reine Radarperformance beider Systeme weitgehend identisch ist.
Grundsätzlich kann man also nicht sagen, ob das SG4A hier für Midcourse Updates infrage kommt.
Kann sein, dass das System dies kann, kann auch sein, dass das System dies nicht kann.
Ich persönlich würde sagen Nein, da die Produktbroschüre nichts dergleichen erwähnt, Midcourse Updates aber üblicherweise ein starkes Verkaufsargument für ein System ist. MMn hätte man das erwähnt, wenn das System über diese Fähigkeiten verfügen würde.
https://www.radartutorial.eu/19.kartei/0...ffe_4a.pdf
Zitat:Kurz gefasst: Nein, da liegst du falsch.Ne, genau das eben nicht.
Wer die SM-2 kauft erhält auch Zugriff auf die Interface-Spezifikationen. Die braucht man schon allein dann, wenn man von einem "Non-AEGIS"-Schiff (siehe F124/LCF) aus dem FüWES den Flugkörper initialisieren möchte.
Anders ist das bei den SM-2 Block IIIA auch nicht gelaufen, die meisten Nationen scheuen nur den Aufwand dafür, weil es halt einfacher ist, einfach AEGIS zu kaufen, aber möglich ist es.
Grundsätzlich hast du zwar recht, man benötigt hierbei das Interface (oder je nach dem einen Klon dessen), das alleine heißt aber nicht, dass somit der weg frei zu einer CMS Integration ist. Denn dafür muss das Lfk-Interface auch in der Lage sein, mit diesem bestimmten CMS zu interagieren.
Ein Interface ist wie ein Steckdosen-Adapter, der Input/Output jeweils zwischen den verschiedenen Kommunikationswege austauscht, sie somit kompatibel macht. Wie bei Steckdosen-Adaptern steht und fällt das aber damit, für was ein Interface gedacht ist, Single line, Dual line, …, bis hin zur universalen Kommunikation.
Und diese Universalauslegung, die wir benötigen, da wir hier nicht von [SM-2 <-> AEGIS] sondern von bspw [SM-2 <-> 9LV] sprechen, hat das Interface der IIIC nicht. Die IIIA hatte das, weshalb diese auch sowohl auf AEGIS wie Non-AEGIS Schiffen Anwendung finden kann. Diese Fähigkeit wurde aus der IIIC aber herausgespart weil es zu wenig Non-AEGIS Interessenten für die IIIA gegeben hatte und ein Universallink mit dem fortschreitenden Integrationsstatus der Baselines zu immer mehr Problemen geführt hat.
Der SM-Toaster den wir uns bestellen wollen hat den falschen Adapter für unsere Steckdose, sozusagen.
Du hast nicht ganz Unrecht dahingehend, dass:
Zitat:Wenn du wirklich willst, kannst du alle Flugkörper der SM-Familie ohne AEGIS betreibenDas ginge aber nur dann, wenn die IIIC in diesem Fall mit einem kompatiblen Interface ausgestattet wird.
Geht das technisch gesehen? Sicher. Können wir das tun? Nein. Kann Raytheon das tun? Ja, werden sie aber nicht.
Zitat:das einzige, was du dafür brauchst, sind die Spezifikationen der Uplink-Telegramme (2T/JUWL, etc.).JUWL hat damit erstmal auch gar nichts zu tun, wie du schon selber sagst ist das hauptsächlich für midcourse Updates in SARH relevant. Bis dahin kommen wir nicht einmal.
Zitat:Eine SG 4A ist als AESA Radar grundsätzlich Software Defined. Alles, was man für den Uplink bräuchte, ist die Beschreibung der Wellenform und Wellenparameter für den Uplink. Die Aufgabe ist für jede "Radar-Bude" ohne weiteres zu lösen.AESA Radare sind keine Systeme die inhärent uplink zur Verfügung stellen können.
Ein System muss dafür erst in der Lage sein, parallel Suchen, Verfolgen und Uplink/Downlink unterhalten zu können, woran es bei den meisten Systemen schon inhärent scheitert. Das sind auch meistens Gründe, die sich nicht durch Softwareupdates lösen lassen, weil die Systemarchitektur (runter bis zur RF-Hardware) hierfür mitspielen muss.
Das ist unter anderem auch der Grund, warum bspw SeaFire und das SM400 parallel existieren, obwohl die reine Radarperformance beider Systeme weitgehend identisch ist.
Grundsätzlich kann man also nicht sagen, ob das SG4A hier für Midcourse Updates infrage kommt.
Kann sein, dass das System dies kann, kann auch sein, dass das System dies nicht kann.
Ich persönlich würde sagen Nein, da die Produktbroschüre nichts dergleichen erwähnt, Midcourse Updates aber üblicherweise ein starkes Verkaufsargument für ein System ist. MMn hätte man das erwähnt, wenn das System über diese Fähigkeiten verfügen würde.
https://www.radartutorial.eu/19.kartei/0...ffe_4a.pdf