NX Open für Defence: die Kurzfassung
NX Open für Defence heißt: Siemens NX aus Code heraus steuern — Python, C#, C++ oder Java — sodass Variantenkonstruktion, Konfigurationsdatensätze und Prüfdaten erzeugt statt getippt werden. inteliScience baut diese Automatisierungen so, dass sie on-premise oder vollständig air-gapped in exportkontrollierten Netzen laufen. In unseren Projekten sinken die manuellen Stunden pro Konfigurationsänderung um 50–70%.
| Interaktiver NX-Workflow | NX-Open-Automatisierung | |
|---|---|---|
| Variante einer bestehenden Baugruppe | Stunden manuelles Editieren | Minuten, gesteuert über eine Spezifikationsdatei |
| Konfigurationsnachweis | Nachträglich von Hand zusammengestellt | Beim Speichern geschrieben, je Bauteil |
| Wo die KI läuft | Hersteller-Cloud, wenn überhaupt | Auf Ihrer Hardware, kein Egress |
Das Problem: Ein Produktionshochlauf, angeschraubt an 30 Jahre Konfigurationskontrolle
Europa kauft in einem Tempo, für das seine Engineering-Abteilungen nie ausgelegt waren. Der NATO-Gipfel in Den Haag ersetzte das 2%-Ziel durch 5% des BIP bis 2035 — 3,5% Kernverteidigung plus 1,5% verteidigungsnahe Ausgaben — und für 2026 budgetieren die europäischen Alliierten und Kanada rund 634 Milliarden USD, etwa 2,53% des gemeinsamen BIP. Der EU-Plan Readiness 2030 stellt bis zu 800 Milliarden € hinter dieselbe Kurve, und am 3. Juli 2026 schlug die Europäische Kommission fünf großformatige Defence Projects of Common Interest vor, um direkt an der Kapazitätsseite anzusetzen.
Die physische Seite dieses Hochlaufs ist sichtbar: Die EU-Munitionsproduktion stieg von rund 300.000 Schuss pro Jahr im Jahr 2022 auf geschätzte zwei Millionen bis Ende 2025. Die Engineering-Seite ist bei Weitem nicht so schnell mitgezogen, und die wiederkehrende Klage aus den Programmbüros betrifft keine Werkzeugmaschinen. Es sind qualifizierte Ingenieure, Programmmanager und der Papierkram, den ein Änderungsauftrag in Defence hinter sich herzieht.
Das ist der Teil, den niemand einplant. Eine einzige Toleranzänderung an einer im Feld befindlichen Baugruppe berührt das Modell, die Zeichnung, den Prüfplan, die Austauschbarkeitserklärung, die Konfigurations-Baseline und das Nachweispaket, das dem Kunden geschuldet ist. Multiplizieren Sie das mit einem Variantenbaum, der dreißig Jahre lang prüffähig bleiben muss, und der Engpass ist nicht die Konstruktionsarbeit. Es ist das Abschreiben.
Und genau dafür gibt es eine API.
Was NX Open tatsächlich ist
NX Open ist die Programmierschnittstelle von Siemens zu NX — derselben Plattform, die Siemens umbenannt hat in Designcenter mit dem Release im Juni 2026, allgemein verfügbar seit dem 23. Juni 2026. Die Umbenennung hat das Etikett geändert, nicht die API-Oberfläche, und unsere Siemens-NX-Leistungen basieren weiterhin auf genau dieser Schnittstelle. Jede Entität, die Sie von Hand erzeugen können — ein Körper, ein Ausdruck, eine PMI-Annotation, eine Baugruppenkomponente, eine CAM-Operation — können Sie aus Code erzeugen, lesen und ändern.
Für Defence-Arbeit zählen vier Dinge besonders:
Sprachabdeckung. NX Open bringt Bindings für C++, C# und VB.NET, Java und Python mit. Python ist der schnellste Weg zu einer funktionierenden Automatisierung und braucht keinen Compiler auf dem Zielrechner — was zählt, wenn der Zielrechner in einer akkreditierten Enklave steht, in der man nicht mal eben eine Toolchain installiert. C++ bleibt relevant für rechenintensive Geometriearbeit und für Code, den Sie als kompiliertes Artefakt statt als lesbaren Quelltext verteilen wollen.
Journaling. NX zeichnet Ihre interaktive Sitzung als Quellcode auf. Führen Sie die Operation einmal von Hand mit eingeschaltetem Journaling aus, und Sie erhalten ein lauffähiges Skript, das sie reproduziert. Das ist die meistunterschätzte Funktion der gesamten Plattform: Sie macht aus einem Fachexperten, der keine Software schreibt, jemanden, der in zehn Minuten den ersten Entwurf einer Automatisierung liefert. Unsere Ingenieure starten fast jedes NX-Open-Projekt so — aufzeichnen, dann die Aufzeichnung in etwas Parametrisiertes und Belastbares umbauen.
Block UI Styler. Eine Automatisierung, die nur von der Kommandozeile läuft, benutzen drei Leute. Der Block UI Styler baut native NX-Dialoge — dieselben Widgets, dieselbe Optik — sodass die Automatisierung als Schaltfläche im Ribbon erscheint statt als Skript, an das sich jemand erinnern muss. Wenn Sie Akzeptanz in einer Konstruktionsabteilung wollen, planen Sie den Dialog ein.
Knowledge Fusion. Regelbasiertes Engineering, eingebettet im Bauteil selbst. Während NX Open prozeduraler Code ist, den Sie ausführen, sind Knowledge-Fusion-Regeln deklarativ, leben bei der Geometrie und werten sich bei geänderten Eingangswerten neu aus. Für Defence ist das der Weg, einen Konstruktionsstandard so zu kodieren, dass er nicht stillschweigend verletzt werden kann: Die Regel wandert mit dem Modell ins nächste Programm, zum nächsten Auftragnehmer, ins nächste Jahrzehnt.
Unsere klare Position: Fangen Sie mit Journaling und Python an, nicht mit einem Architekturdokument. Die Projekte, die stehenbleiben, sind die, die sechs Wochen mit der Sprachauswahl verbringen, bevor irgendetwas automatisiert ist.
Konfiguration und Nachverfolgbarkeit: Nachweise erzeugen, nicht tippen
Die wertvollste erste Automatisierung in einer Defence-Konstruktionsabteilung ist fast nie ein Geometriegenerator. Es ist das, was aufschreibt, was gebaut wurde.
STANAG- und DEF-STAN-Rahmenwerke und die NATO-konforme Konfigurationsmanagement-Praxis drumherum verlangen alle dasselbe: Sie müssen zu jedem Zeitpunkt eines dreißigjährigen Lebenszyklus nachweisen können, welche Revision welchen Teils in welche seriennummerierte Baugruppe ging — und warum. Die meisten Organisationen erfüllen das mit einer Tabelle, die parallel zum CAD gepflegt wird. Aus dieser Tabelle kommen die Audit-Feststellungen.
Ein NX-Open-Skript, das die Baugruppe durchläuft und den Datensatz direkt aus dem Modell schreibt, macht die Parallelkopie überflüssig:
# NX Open (Python) - emit a configuration record for the open assembly.
# Run with the assembly open as work part (Developer tab > Journal > Play).
# For nightly runs, open each assembly first and start the journal with run_journal.
import csv
import NXOpen
ATTRS = ["DB_PART_NO", "DB_PART_REV", "MATERIAL", "NATO_STOCK_NUMBER", "EXPORT_CLASS"]
def attr(obj, title):
"""Return a user attribute as text, or an explicit gap marker."""
try:
return obj.GetStringUserAttribute(title, -1)
except NXOpen.NXException:
return "<missing>"
def walk(component, level, rows):
for child in component.GetChildren():
proto = child.Prototype # the Part behind the occurrence
rows.append([level, child.DisplayName] + [attr(proto, a) for a in ATTRS])
walk(child, level + 1, rows)
def main():
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
root = work_part.ComponentAssembly.RootComponent
if root is None:
session.ListingWindow.Open()
session.ListingWindow.WriteLine("Not an assembly - nothing to record.")
return
rows = []
walk(root, 0, rows)
out = work_part.FullPath.replace(".prt", "_config.csv")
with open(out, "w", newline="", encoding="utf-8") as fh:
writer = csv.writer(fh)
writer.writerow(["level", "component"] + ATTRS)
writer.writerows(rows)
gaps = sum(r.count("<missing>") for r in rows)
session.ListingWindow.Open()
session.ListingWindow.WriteLine("%d components written to %s" % (len(rows), out))
session.ListingWindow.WriteLine("%d attribute gaps flagged for review" % gaps)
if __name__ == "__main__":
main()Zwei Details machen das nützlich statt dekorativ. Es kann headless laufen: Gestartet mit run_journal bei geöffneter Baugruppe, kann es als Nachtlauf über das gesamte Programmverzeichnis laufen, statt etwas zu sein, an dessen Klick sich ein Ingenieur erinnern muss. Und es meldet Lücken, statt stillschweigend Leerfelder zu schreiben, sodass fehlende Exportklassifizierungen als Zahl auf einem Dashboard auftauchen und nicht als Feststellung im Audit.
Schreiben Sie denselben Datensatz nach Teamcenter, wird die CSV überflüssig: NX Open und die Teamcenter-Integration lassen die Automatisierung die Attribute an die Item Revision zurückschreiben — das PLM-System hält die Baseline, das Modell bleibt die einzige Quelle. Diese Variante bauen wir für Kunden, die Teamcenter bereits betreiben; die dateibasierte Variante ist für Programme, die noch nicht so weit sind.
Sitzen Sie auf einem Variantenbaum, den niemand vollständig belegen kann? Das ist der normale Ausgangspunkt, kein Geständnis. Wir kartieren ihn und automatisieren zuerst die Nachweisebene — mehr dazu unter Konfiguration und Nachverfolgbarkeit für STANAG-Programme.
MBD und PMI: maschinenlesbare Definition unter Exportkontrolle
Model-based Definition ist in Defence kein Projekt zur Zeichnungsreduktion. Sie ist der Mechanismus, der eine Automatisierung die Konstruktionsabsicht überhaupt erst lesen lässt.
PMI in NX ist strukturierte Produktdefinition nach ASME Y14.41, keine an eine Ansicht geheftete Annotation. Maße, Toleranzen und Bezugsangaben sind Objekte mit Werten, die ein Skript abfragen kann. Das US-Verteidigungsministerium hat zeichnungslose technische Datenpakete 2013 mit MIL-STD-31000A kodifiziert; praktisch heißt das: Ein 3D-Modell allein kann die vertragliche Fertigungs- und Prüfgrundlage sein — vorausgesetzt, die PMI ist vollständig und konsistent.
Vollständig und konsistent — dort verdient die Automatisierung ihr Geld. Eine Regel, die jedes freigegebene Bauteil auf ein Bezugssystem, eine Oberflächenangabe und ein Werkstoffattribut prüft, ist mit NX Open an einem Nachmittag geschrieben und läuft in Sekunden pro Teil. Beim Release erzwungen, müssen die nachgelagerten Automatisierungen — Prüfplanung, CAM, der Konfigurationsdatensatz von oben — nie raten.
Es gibt noch einen unspektakulären Grund, warum MBD in Defence zählt: Verteilungskontrolle. Ein Zeichnungs-PDF verlässt das System und ist ab da ungesteuert. Ein Modell in Teamcenter mit PMI und einem Exportklassifizierungs-Attribut trägt seine Handhabungsregeln mit sich. Wenn Sie nachweisen müssen, dass ITAR- oder EU-Dual-Use-kontrollierte Definition nie ins falsche Netz gelangt ist, schlägt ein gesteuertes Artefakt vier Kopien.
KI innerhalb des Zauns betreiben
Das Designcenter-Release vom Juni 2026 brachte Designcenter Copilot, einen Assistenten mit natürlicher Sprache, verankert in der Siemens-Dokumentation, in empfohlenen Vorgehensweisen und in der aktuellen Tätigkeit des Nutzers. Er ist wirklich nützlich für die “Wie mache ich X in NX”-Frage, die einen erfahrenen Ingenieur derzeit zwanzig Unterbrechungen pro Woche kostet.
Für ein Defence-Programm wirft er auch die einzige Frage auf, die zählt: Wohin geht der Prompt?
Unsere Haltung ist hier eindeutig, und wir vertreten sie gegenüber jedem Defence-Kunden. Hersteller-Copilots sind für Plattformwissen in Ordnung. Sie sind nicht der Ort für Ihre Bauteilgeometrie, Ihre Konfigurations-Baselines oder Ihre Programmdokumentation. Alles, was kontrollierte technische Daten berührt, läuft auf Hardware, die Ihnen gehört, in einem Netz, das Sie kontrollieren, ohne Egress — und wenn die Akkreditierung air-gapped sagt, dann heißt air-gapped: Die Modellgewichte liegen auf der Maschine, nicht hinter einem VPN.
Das ist heute baubar, und die Form ist angenehm langweilig:
- Open-Weight-Modelle on-premise — Llama 3.3 70B für Retrieval und Entwürfe, Qwen2.5-Coder-32B, wenn NX-Open-Code erzeugt werden soll — bereitgestellt auf einem GPU-Knoten in der Enklave.
- Ein Retrieval-Index über das Material, in dem die Antworten tatsächlich stecken: Konstruktionsstandards, Programmspezifikationen, frühere Konfigurationsentscheidungen, historische Änderungsbegründungen.
- Jede Antwort nennt Quelldokument und Revision, denn ein Assistent, der seine Belege nicht zeigen kann, ist in einem regulierten Umfeld unbrauchbar.
- Ein Mensch gibt alles frei, was ins Modell oder ins PLM-System schreibt. Die KI schlägt das NX-Open-Skript vor; ein Ingenieur liest es und führt es aus.
Wo Cloud erlaubt ist — Schulungsmaterial, nicht kontrollierte interne Werkzeuge, Code, der nie Programmdaten sieht — schreiben Frontier-Modelle wie claude-opus-5-5 besseres NX Open als alles, was Sie auf einem einzelnen Knoten betreiben können — und genau dafür setzen wir sie ein. Die Grenze verläuft an den Daten, nicht an der Technik.
Eine Warnung aus der Praxis: LLMs halluzinieren NX-Open-API-Aufrufe mit voller Überzeugung. Methoden, die es nicht gibt, Argumente in der falschen Reihenfolge, Klassen aus einem anderen Namespace. Jede generierte Automatisierung durchläuft eine Compile- oder Import-Prüfung und einen Lauf gegen ein Referenzteil, bevor ein Mensch sie überhaupt inhaltlich reviewt. Ohne diese Schleife sparen Sie keine Zeit, Sie verschieben sie.
Obsoleszenz und das Dreißig-Jahre-Datenproblem
Programme mit langem Lebenszyklus haben einen zweiten, leiseren Automatisierungsfall: das Archiv.
DMSMS — versiegende Fertigungsquellen und Materialengpässe — gilt in der Defence-Instandhaltung als unvermeidlich, nicht als Ausnahme, und die aktualisierte DoDI 4245.15 (Change 1, September 2025) hat sie weiter weg von “Ersatz suchen, wenn etwas ausfällt” hin zu proaktivem Lebenszyklus-Risikomanagement geschoben. Europäische OEMs unter STANAG und DEF STAN tragen gleichwertige Pflichten zur Versorgungskontinuität.
Proaktives Management braucht ein abfragbares Bild dessen, was Sie tatsächlich haben. In den meisten Marine- und Landprogrammen besteht dieses Bild aus dreißig Jahren gescannter Zeichnungen, einem zweimal geänderten Teilenummernschema und drei Ingenieuren, die den Rest im Kopf haben.
Die Automatisierung ist hier eine zweistufige Pipeline, kein Skript. Vision-Modelle lesen die Altzeichnungen und extrahieren Teilenummern, Werkstoffe, Spezifikationen und referenzierte Normen; NX Open gleicht diese Extraktion gegen die aktuellen NX- und Teamcenter-Daten ab und markiert die Abweichungen. Heraus kommt eine Liste — Komponenten, deren spezifizierter Werkstoff nicht mehr produziert wird, Teile mit Verweis auf zurückgezogene Normen, Baugruppen, bei denen Modell und archivierte Zeichnung sich widersprechen. Diese Liste ist der Input für die Obsoleszenzplanung, und sie existierte vorher nicht, weil sie sich von Hand niemand leisten konnte. Unsere Pipeline zum Mining von Altzeichnungen und Obsoleszenz setzen wir für Marineprogramme genau so um.
Realistische erste 90 Tage
Von einem Plattformprogramm würden wir abraten. Automatisierung im Defence-Engineering gelingt, indem man eine eng geschnittene Sache in Produktion bringt und den nächsten Anwendungsfall von den Leuten ziehen lässt, die sie benutzt haben.
| Weeks | Was passiert | Was am Ende existiert |
|---|---|---|
| 1–2 | Journale über die drei am häufigsten wiederholten Workflows aufzeichnen; manuelle Stunden messen | Eine priorisierte Liste mit Stunden, keine Meinungen |
| 3–6 | Die wertvollste Automatisierung als Block-UI-Styler-Befehl bauen; nachts im Batch laufen lassen | Ein Werkzeug im Ribbon, ein Nachtlauf |
| 7–10 | PMI- und Attributprüfungen zum Release ergänzen; Ergebnisse nach Teamcenter verdrahten | Schlechte Daten kommen nicht mehr in die Baseline |
| 11–13 | Den On-Premise-Retrieval-Index über Normen und Programmdokumente aufsetzen | Ein Assistent mit Quellenangaben, innerhalb des Zauns |
Die Reihenfolge ist Absicht. Prüfungen vor Generatoren, denn Varianten aus inkonsistenten Quelldaten zu erzeugen industrialisiert die Inkonsistenz. Und die KI-Schicht zuletzt, denn ein Retrieval-Index über Dokumente, denen niemand traut, liefert Antworten, denen niemand traut.
Zwei Dinge bringen solche Projekte verlässlich um. Erstens ein Skript, das ein Ingenieur geschrieben hat, der danach das Team wechselt — daher Block UI Styler, Versionskontrolle und eine zweite Person, die den Code lesen kann. Zweitens das Automatisieren eines Prozesses, der vorher hätte vereinfacht werden müssen. Wenn ein Workflow elf Schritte hat, weil es eine Freigabe gibt, an deren Einführung sich niemand erinnert, und Sie zehn davon automatisieren, haben Sie den falschen Prozess schneller gemacht.
Häufig gestellte Fragen
Läuft NX Open in einem Air-Gapped-Netzwerk?
Ja. NX Open läuft lokal im NX-Prozess oder über run_journal auf derselben Maschine — kein externer Dienst ist beteiligt, eine akkreditierte Enklave ändert also nichts daran, wie die Automatisierung läuft. Die einzige Komponente, die Planung braucht, ist die KI-Schicht: Sie verlangt Modellgewichte und einen GPU-Knoten innerhalb der Grenze statt eines API-Endpunkts.
Was kostet ein NX-Open-Automatisierungsprojekt?
Eine einzelne, sauber abgegrenzte Automatisierung — ein Workflow, ein Block-UI-Styler-Dialog, Batch-Fähigkeit und Übergabedokumentation — liegt in der Regel zwischen 8.000 € und 25.000 €, je nachdem, wie viel der Quelldaten vorher bereinigt werden muss. Programme mit einem großen Altbestand kosten in der Discovery-Phase mehr als im Coding. Wir dimensionieren das nach der Journaling-Übung, nicht davor.
NX Open oder Knowledge Fusion — was sollten wir nutzen?
Unterschiedliche Aufgaben. Knowledge Fusion hält Regeln, die mit dem Bauteil mitwandern und sich bei geänderten Eingangswerten neu auswerten — genau das, was Sie für Konstruktionsstandards über eine Lieferkette hinweg brauchen. NX Open ist für prozedurale Arbeit: Batch-Verarbeitung, Dokumente erzeugen, mit Teamcenter oder einem Fremdsystem sprechen. Die meisten Defence-Automatisierungen, die wir bauen, nutzen beides — Knowledge Fusion trägt die Randbedingungen, NX Open orchestriert.
Schreibt ein LLM unsere NX-Open-Skripte einfach für uns?
Teilweise — und nicht unbeaufsichtigt. Aktuelle Modelle liefern einen soliden ersten Entwurf eines NX-Open-Skripts und erfinden dann API-Aufrufe, die es im angegebenen Namespace gar nicht gibt. Das tragfähige Muster: generieren, gegen die echte API import-prüfen, gegen ein Referenzteil laufen lassen, dann menschliches Review. Das ist immer noch deutlich schneller als von Hand — nur eben nicht freihändig.
Wirkt sich die Automatisierung von NX auf Exportkontrolle oder Akkreditierung aus?
Meistens verbessert sie beides, weil generierte Nachweise konsistenter sind als handgepflegte. Die Kontrollen, die bleiben müssen, sind die üblichen: Automatisierungen unter Versionskontrolle, Änderungen reviewt, nichts schreibt ohne Freigabe in eine freigegebene Baseline, und keine Komponente der Toolchain ruft aus dem Netz heraus. Wir dokumentieren die Datenflüsse als Teil der Lieferung, damit das Akkreditierungsgespräch eine Grundlage hat.
Nächster Schritt
Sie brauchen keine Strategie, um herauszufinden, ob das auf Sie zutrifft. Sie brauchen eine Stunde mit den drei Workflows, die Ihre Ingenieure am häufigsten wiederholen.
Sprechen Sie mit unseren Ingenieuren über NX-Open-Automatisierung für Ihr Programm