Der Begriff englisch Systems Engineering (SE) ‚Systemtechnik‘ bezeichnet ein ingenieurwissenschaftliches Fachgebiet sowie einen interdisziplinären Ansatz, um technische Systeme zu entwickeln, zu beschreiben oder modellieren, zu simulieren, zu verifizieren und zu testen. SE ist eng mit dem Model-Based Systems Engineering (MBSE) verbunden.

SE dient der Definition, dem Aufbau oder der Struktur, der Nachvollziehbarkeit, der Abbildung der Funktionen und vieles mehr von komplexen Systemen oder Produkten.^[1][2] Es findet Anwendung bei Echtzeitsystemen, bei Systemen von Systemen (SoS) sowie bei sicherheitsbezogenen Systemen. SE kann dabei Systeme für Anwendungen an Land, in der Luft oder auf dem Wasser nachbilden.

SE basiert auf der Annahme, dass ein System mehr ist als die Summe seiner Subsysteme (bzw. Teile) und versucht daher die Gesamtzusammenhänge und Wirkketten zu betrachten. Es bietet ein organisiertes und formelles Vorgehen, um die Herausforderungen und Probleme von Systemen systematischer zu bewältigen.^[3] Im umgekehrten Fall, d. h. ohne SE-Ansatz, besteht nach der Entwicklung und Herstellung eines Geräts, Bauteils, einer Maschine oder einer Anlage zwar die Möglichkeit, die einzelnen Elemente zu verstehen. Die Möglichkeit, die Interaktion dieser Elemente zu analysieren, ist jedoch stark reduziert. In diesem Zusammenhang wird auch vom sogenannten „emergenten Verhalten“ des Systems gesprochen.^[4][5] Dabei ist Emergenz das Phänomen, dass aus einfachen Interaktionen innerhalb eines Systems komplexes Verhalten entsteht.

SE kommt meist in technischen Branchen zum Einsatz, beispielsweise in der Automobil-, Luft- & Raumfahrt, oder Rüstungsindustrie (vgl. auch Wehrtechnik).^[6] Weitere, synonyme Bezeichnungen sind das englisch Systems Design, das englisch Systems Design Engineering und auch englisch Systems Modelling.

Systems Engineering (SE) ist eine digitale Entwicklungsmethodik, die dazu dient, ein System zu entwickeln. „Digital” bedeutet in diesem Fall, dass spezielle SE-Software zum Design von SE genutzt wird. Dabei ist SE generell ein Mittel zum Zweck, kein Selbstzweck. Bei diesem Design kann es sich um ein Gesamtsystem oder um Teilsysteme handeln. SE wird beispielsweise für ein neues Produkt, einen neuen Service oder eine bestehende Applikation angewendet. Dies kann im Rahmen eines Auftrags durch einen Auftraggeber (auch Kunde) oder bei allen anderen Entwicklungstätigkeiten, -projekten oder -programmen erfolgen. Die Systeme oder Produkte können kleine Geräte (vgl. Smartphone) oder auch große Geräte (vgl. Raumsonden in der Raumfahrt) sein. Häufig ist SE eng verzahnt mit eingebetteten Systemen.

In vielen Fällen spielen dabei das Anforderungsmanagement (vgl. auch Lasten- und Pflichtenheft) und weitere Fachgebiete eine begleitende Rolle. Bei den zu entwickelnden Systemen konzentriert sich das SE auf einen hierarchischen bzw. integrierten Aufbau über mehrere Ebenen. Die folgende Liste beginnt beim Produkt und arbeitet sich linear zu den kleinsten („atomaren“) Einheiten vor. Dies ist vergleichbar mit dem V-Modell:

1. Eine systematische und nachvollziehbare Analyse der Aufgabenstellung
2. Es wird versucht die Funktionalitäten und Nichtfunktionalitäten des Systems abzuleiten
3. Es wird eine logische Systemarchitektur aufgebaut
4. Das Gesamtsystem wird in Sub- bzw. Teilsysteme oder Komponenten oder Module zerlegt
5. Diese Subsysteme sind z. B. die Hardware (einschließlich Mechanik) bestehend aus Elektronik/Elektrik (E/E) und Software
6. Die Einzelteile oder Komponenten werden spezifiziert, implementiert und untereinander verbunden
7. Die Einzelteile mit der physischen Systemarchitektur verbunden
8. Es werden Einzelteile oder das Gesamtsystem hinsichtlich der Modellierung untersucht und gegebenenfalls simuliert
9. Es wird eine Verifizierung durch Tests und falls möglich Validierung der Komponenten und Einzelebenen angestrebt
10. Die gesamte Struktur wird kontrolliert (vgl. auch Versionskontrolle) und dokumentiert
11. Die Berücksichtigung anderer, angrenzender Fachdisziplinen (siehe unten)

Bei den o. g. Schritten, Aktivitäten und Ebenen soll stets der Produktlebenszyklus berücksichtigt werden, wobei der Fokus auf dem „Lebenszyklus des Systems” liegt. Wie angedeutet arbeitet das SE über mehrere Ebenen, die sich nach der Komplexität des Systems und den Anforderungen des Auftraggebers richten. SE versucht die verschiedenen Teilgebiete (Maschinenbau, Software, Elektrik und Elektronik (E/E)) und Fähigkeiten in einen einheitlichen und strukturierten Prozess zu integrieren. Der das SE begleitende Entwicklungsprozess wird von der Konzeption über die Produktion oder Fertigung bis hin zum Betrieb und in manchen Fällen bis zum Abbau beziehungsweise zur Wiederverwertung angewandt. Zudem werden für jeden Prozessschritt eigene Methoden verwendet, die systematisch angewendet werden sollen.

Im erweiterten Sinne berücksichtigt SE neben technischen auch wirtschaftliche, rechtliche oder soziale Aspekte, sofern diese mittels der SE-Methodik erfasst und abgebildet werden können. Für einige Fragen bieten sich jedoch spezielle Methoden und Werkzeuge an, beispielsweise eine Business Process Modeling Language (BPML). Letztere ist zwar kein Teil des SE, eine Organisation oder ein Unternehmen kann jedoch auch als „System“ betrachtet werden. Im besten Fall kann SE die Grenzen oder andere Merkmale des Systems aufzeigen, die dann mit dem Prozessmanagement, dem Risikomanagement (vgl. auch Risikobewertung), dem Kostenmanagement, dem Produktionsprozess usw. in Wechselwirkung treten können.

Systems Engineering (SE) ist in der Regel Teil einer Organisation oder Division. Es kann in einer Matrixorganisation angewendet werden. Die Tätigkeit als SE wird teilweise auch von Ingenieuren oder Experten in angrenzenden Gebieten ausgeübt. Die entsprechende Rolle wird in der Regel als Systemingenieur bezeichnet. Der Systemingenieur arbeitet meist mit Softwareentwicklern, Hardwareentwicklern, Qualitätsingenieuren usw. zusammen. Der sogenannte Systemintegrator übernimmt dabei eine spezielle Aufgabe bei der Integration des Systems. Der Systemtester übernimmt dabei eine Aufgabe des Systemtest usw. Da das Fachgebiet umfangreich ist und viel Erfahrung bedarf, sind Fachleute im Bereich SE auch als Berater (vgl. Dienstleistung und Entwicklungsdienstleister) tätig.

Wird SE auf ein Projekt bzw. Produkt angewendet, so obliegt die Verwaltung des Projekts jedoch dem Projektmanager und die Verwaltung von Programmen dem Programmmanager. Es kann einen Projektleiter für das SE-Projekt geben, der sich um die Eigenheiten des SE-Projekts kümmert. Bei komplexen Systemen und Entwicklungsprojekten sollte ein SE-Team aus mehreren Systemingenieuren gebildet werden.

Zu den Methoden und Aufgaben des Systems Engineering (SE) können gezählt werden:

• Definition und Planung der SE-Aufgaben
• Fortschrittsbewertung und Berichterstattung an Stakeholder
• SE-nahe Anforderungsanalyse, -definition sowie Spezifikation
• Design und Entwicklung des Systems oder der Subsysteme
• Systemdesignoptimierung (Modellbildung, Simulation und Bewertung)
• Systemdokumentation (Funktionsbeschreibungen, Zeichnungen und Handbücher)
• Systemintegration (Schnittstellen), um eine perfekte Einbindung in das nächstgrößere System zu gewährleisten;
• Systemverifikation und eingeschränkt auch -validierung, um sicherzustellen, dass die Anforderungen erfüllt wurden;
• Nachhaltige Entwicklung, falls an das System diese Anforderung gestellt wird

SE hat weiterhin die Schnittstellen zu den folgenden Fachdisziplinen zu berücksichtigen: Konfigurationsmanagement, Produktentwicklung, Qualitätsmanagement bzw. Qualitätssicherung, Releasemanagement, Risikomanagement, Variantenmanagement uvm. Je nach Komplexität und Projektphase des zu entwickelnden Systems unterscheiden sich die Aufgabenschwerpunkte und Inhalte.

Es gibt eine Vielzahl von SE-Normen, z. B. die ISO/IEC 15288 Systems and Software Engineering.^[7]

Der erste bedeutende Einsatz des „Systems Engineering“ (SE) fand 1940 in den Bell Telephone Laboratories bei der Entwicklung der Telefonie statt.^[8] Die verschiedenen Teile des Telekommunikationssystems mussten interagieren, was nur durch ein umfangreiches Systemverständnis und genaue Spezifikation der Anforderungen möglich wurde.^[9] In den 1950er Jahren entwickelte der US-amerikanische Informatiker Jay W. Forresters die „System Dynamics“ Methoden zur Untersuchung von Systemen.

Die neue Disziplin wurde nach dem Zweiten Weltkrieg in der US-amerikanischen Raumfahrt u. a. beim Apollo-Programm (1960–1970er Jahre) und bei der Entwicklung des Space Shuttle weiter erprobt und eingesetzt. Dabei wurde der Ansatz und die Methode des SE durch die NASA weiterentwickelt, welche heute noch das NASA Systems Engineering Handbook kostenfrei zur Verfügung stellt, siehe die Literaturangaben.^[10]

SE wurde in der europäischen Raumfahrt (vgl. European Space Agency (ESA)) nach den Fehlschlägen um die Europa-Raketen verstärkt eingesetzt. Zu den Fehlschlägen kam es, da die verschiedenen Raketenstufen ohne gemeinsame Koordination (viz. ohne Systems Engineering) entwickelt wurden und diese somit nicht aufeinander abgestimmt waren. Daher wurde beschlossen bei der Entwicklung der Ariane-Rakete die Nutzung des SE zu intensivieren, was schließlich mit zu dem großen Erfolg der Rakete beitrug. Seitdem ist es in der Raumfahrt Standard, Systemingenieure einzusetzen.

Des Weiteren ist SE eine der begleitenden Methodiken bei der Entwicklung sicherheitsrelevanter Systeme, z. B. für Schienenfahrzeuge, Flugzeuge und Fahrzeuge. Es findet auch bei großen Infrastrukturprojekten wie der Endlagerung radioaktiver Abfälle Anwendung.^[11] Auch die betriebs- wie volkswirtschaftliche Relevanz für die Kreislaufwirtschaft zur Bewältigung der hohen Komplexität von Produktentwicklung, Liefer- und Recyclingketten wird vermehrt diskutiert.^[12][13]

Spätestens seit Beginn des Informationszeitalters und der digitalen Revolution – also der Verfügbarkeit von Elektronik und spezieller Mikroelektronik (Rechnertechnik, Speichertechnik, Mikrocontroller, Sensortechnik uvm.) – werden Neuentwicklungen technischer Produkte immer anspruchsvoller. Genauer gesagt ist es nicht mehr möglich, die Systeme klassisch zu konstruieren (vgl. auch Konstruktion). Diese klassische Herangehensweise ist heute das Systems Engineering (SE).

Gleichzeitig steigt die Anzahl der Anforderungen – beispielsweise technische, kundenbezogene, umweltrechtliche und sicherheitsrelevante – sodass Systeme in einer Umgebung von Tausenden Anforderungen entstehen. SE ist eine moderne Methodik, um diese Komplexität zu erfassen. Dabei ist SE grundsätzlich ein Mittel zum Zweck und kein selbstständiges Ziel.

Dabei kann SE helfen, das Verhalten, die Effekte oder Auswirkungen eines Systems besser zu untersuchen. Dies ist besonders wichtig, wenn das System zu Beginn der Entwicklung noch viele Unbekannte aufweist und am Ende typischerweise im Rahmen des Testings und der Qualitätssicherung (vgl. auch Total Quality Management) Defekte gefunden und beseitigt werden müssen. Die Kosten für diese späten Probleme sind zehnmal höher als die Kosten für eine Investition in das Systemdesign mittels SE. Ein besonderes Augenmerk liegt dabei auf der Durchgängigkeit und Nachvollziehbarkeit der Anforderungen. Das SE ist jedoch nicht für das Management der Anforderungen zuständig, sondern erarbeitet, verbessert und prüft die Spezifikationen der einzelnen Systemelemente zusammen mit der Systemarchitektur und anderen Teilbereichen. Ein hoher Qualitätsstandard innerhalb des SE wird auch durch solides Projektmanagement und die Unterstützung des Topmanagements (und auch Mittelmanagement) gewährleistet.

Es ist offensichtlich, dass viele spezielle Bereiche innerhalb des Produktentstehungsprozess mit den Teilbereichen des Systems Engineering in Berührung kommen. Die steigende Anzahl von komplexen und sehr unterschiedlichen Systemen erwirkt immer größere Überschneidung zwischen diesen Bereichen. Viele Teilbereiche begreifen ihre eigenen Leistungen nur als Teil der größeren Gebiete, sie tragen jedoch auch zur Weiterentwicklung und Forschung des Systems Engineering bei.

Im Folgenden werden einige Disziplinen beschrieben. Weitere Fachgebiete sind Dokumentenmanagement, Konfigurationsmanagement, Produktentwicklung, Prozessmanagement, Qualitätsmanagement bzw. Qualitätssicherung, Releasemanagement, Variantenmanagement uvm.

Die Softwareentwicklung hat jüngst geholfen, Systems Engineering weiterzuentwickeln. Techniken, die ursprünglich entwickelt wurden, um mit komplexer Software intensive Systeme umgehen zu können, haben geholfen, große Änderungen bei den eingesetzten Tools, Methoden und Prozessen im Systems Engineering zu verwirklichen, zum Beispiel SysML, CMMI, objektorientierte Analyse und Design, Anforderungsmanagement, Formale Methoden und Formale Sprachen.

Sicherheitstechnik wird heute überall dort angewandt, wo Menschen große komplexe Ereignisse absichern wollen, damit diese Systeme keine Schäden auslösen können. Die meisten dieser Sicherheitstechniken dienen dazu, geplant mit Fehlern umzugehen.

Relevante Safety-Standards der Automobilindustrie sind z. B. ISO 26262 Funktionale Sicherheit und ISO 21448 (SOTIF). Dabei wird häufig ein Safety-by-Design Ansatz gewählt, womit schon in der frühen Phase der Entwicklung Sicherheitstechniken angewandt werden.

Die momentanen Entwicklungsstandards definieren Risikokategorien und Modelle für Sicherheitsebenen oder Sicherheitsanforderungsstufen und leiten daraus Anforderungen an die Entwicklung sowie die Qualitätssicherung ab. Ein weiterer Bereich ist die Fehlerbaumanalyse (FTA), diese auf das gesamte System und deren Domänen wie Software anzuwenden, ist trotz der Komplexität der Systeme, ein mögliches Ziel in der Entwicklung des Systems Engineering.

Die Informationssicherheit (Security Engineering) wird im Zeitalter der Digitalisierung, insbesondere bei der Entwicklung sicherheitsrelevanter Systeme, immer wichtiger. Ziel dabei ist es potentielle Angriffsvektoren auf das System zu identifizieren, Sicherheitsziele und Schutzmaßnahmen zu definieren. Dabei wird häufig ein Security-by-Design Ansatz gewählt, womit schon in der frühen Phase der Entwicklung der Informationssicherheit ein hoher Stellenwert zukommt.

Betriebssicherheit (Ausfallsicherheitsentwicklung bzw. englisch Reliability Engineering) ist eine Teilgebiet um sicherzustellen, dass ein System die Nutzererwartungen oder die Fehlerfreiheit während des Produktlebens erfüllt. Reliability Engineering wird für das ganze System mit seiner Hard- und Software angewandt. Es ist stark mit der Wartbarkeit und der Logistik verknüpft. Reliability Engineering wird oft mit Teilbereichen der Sicherheitstechnik angewandt, wie Ausfallverhalten und Fehlerbäume. Reliability Engineering vertraut stark auf Statistiken, Wahrscheinlichkeitstheorie und Betriebssicherheitstheorie mit seinen Tools und Vorgängen.

Schnittstellendesign beschäftigt sich damit, die Teile eines Systems miteinander zu verbinden. So werden z. B. Kommunikationsprotokolle bestimmt, um die Interaktionen der Systeme bzw. Subsysteme sicherzustellen.

Ein Beispiel hierfür ist, dass Signale die ein System/Gerät verlassen innerhalb einer Toleranz liegen müssen oder der Empfänger eine größere Signaltoleranz haben muss als der Sender, um die Funktionen des Systems aufrechtzuerhalten. Zusätzlich muss definiert werden, wie groß im Fehlerfall z. B. die Spannung am Sender werden darf und wie groß die Toleranz des Empfängers sein muss, damit keine Failure-Propagation eintritt.

Mensch-Computer-Interaktion (englisch human-computer interaction, HCI) ist ein anderer Aspekt des Schnittstellendesigns und ein sehr vitaler Teil des modernen Systems Engineering, wenn dazu der User eines Systems betrachtet wird.

Außerdem ist zu beachten, dass jedes System auch ein Subsystem eines anderen ist. Daher sollte sich beispielsweise ein Pumpenhersteller Gedanken darüber machen, wie sein Kunde die Pumpe einsetzen will und die Schnittstellen dementsprechend gestalten.

Kognitives „Systems Engineering“ sieht den Menschen als Teil des Systems. Kognitives Systems Engineering hängt stark mit den Erfahrungen, die über Jahrzehnte in den Anwendungen der beiden Teilbereiche Kognitive Psychologie und Systems Engineering gemacht wurden, zusammen.

Kognitives Systems Engineering hat sich stark auf das Erforschen der Interaktionen zwischen Mensch und Umwelt fokussiert, ebenso sollen Systeme entwickelt werden, die das menschliche Denken integrieren. Kognitives Systems Engineering arbeitet an den Punkten:

• Probleme die durch die Umwelt auftreten
• Notwendigkeit von Vermittlern (Mensch und Software)
• Interaktion der verschiedenen Systeme und Technologien, um die Situation beeinflussen zu können.

Risikomanagement ist in der Raumfahrtindustrie ein notwendiges Hilfsmittel des Systems Engineering, damit mögliche Gefahren von Entwicklungen abschätzbar werden und somit die Systementwicklung erfolgreich durchgeführt werden kann. Bereits vor Abgabe eines Angebots (besonders Festpreisangebote) wird dem Projektleiter die erste Risikobewertung vorgestellt:

• Nichterfüllung von kritischen Anforderungen
• Mangelhafte Weiterleitung von Systemanforderungen an Unterauftragnehmer
• Verzögerungen beim Teamaufbau
• usw.

Hierbei werden zwischen den Definieren der Risiken und der Projektleitung Wahrscheinlichkeiten für das Eintreten diskutiert. Alle identifizierten Risiken werden in Hinsicht auf Kosten- und Zeitplan-Einflüsse bewertet und bei der Abgabe des Angebots berücksichtigt.

Im Verlauf eines Projektes werden die Risiken periodisch überprüft und mit dem fortschreitenden Erkenntnisstand justiert.

Vom Auftraggeber geforderte, periodische Berichte dienen ebenso zum Risikomanagement, wobei bei Anfang des Projektes bestimmte Reserven gefordert werden, die bei den Milestones nicht unterschritten werden dürfen. Zum Beispiel muss die Masse eines Satelliten beim Preliminary Design Review (PDR) mindestens 10 % unter dem spezifizierten Wert liegen. Dieser Wert ist abhängig vom Status der verschiedenen Elemente (z. B. Wiederverwendung eines Solar Arrays 2 % der Masse des Solar Arrays, bei Neuentwicklung mit neuen Zelltypen mit besserem Wirkungsgrad 10 %). Die Budget-Reports werden für viele Parameter verlangt wie Masse, elektrische Leistung, Zuverlässigkeit, Größe der Softwareteile, die im Bordcomputer resident sind, usw.

Für eine durchgängige Beschreibung des zu entwickelnden Systems ist es wichtig, abgestimmte Prozesse, Methoden und Tools (PMT) für Analyse und Entwicklung auf System- und Implementierungsebene zu nutzen. Eine Möglichkeit zur durchgängigen Beschreibung des Verhaltens und der Struktur des Systems besteht in der Nutzung von Konzepten des Model-Based Systems Engineering (MBSE). Es sind die folgenden Modelle und Methodiken bekannt:

Als beschreibende Modellierungssprache kann dabei die SysML dienen, welche in der Version 1 auf Grundlage der UML entwickelt wurde.^[14] Derzeit gibt es eine Reihe von kommerziellen und Open Source Tools die spezifische SysML Implementierungen auf Basis der SysML v1.x anbieten (z. B. Enterprise Architect von SparxSystems, IBM Rational Rhapsody, Eclipse Papyrus, CATIA Magic^[15] etc.). Idealerweise erlaubt die eingesetzte PMT Lösung eine durchgängige und nachvollziehbare Systementwicklung vom Anforderungsmanagement über das System Modell bis hin zur Verifizierung und Validierung.

Mit SysML v2 wird derzeit eine neue Version der Modellierungssprache entwickelt^[16], die eine verbesserte semantische Klarheit auf Basis einer von der UML unabhängigen Kernel Modeling Language (KerML)^[17], maschinenlesbare Modellrepräsentationen und eine standardisierte API für die Interoperabilität mit anderen Engineering-Tools^[18] bietet. SysML wird in den folgenden und anderen Branchen verwendet:

• In der Automobilindustrie bzw. dem Automobilbau integrieren einige Hersteller ihre SysML-Werkzeuge mit anderen Werkzeugen ihrer Engineering-Infrastruktur.^[19]
• Einsätze des No Magic Cameo Systems Modeler und IBM Engineering Rhapsody finden sich im Verteidigungsbereich oder der Wehrtechnik, besonders beim Verteidigungsministerium der Vereinigten Staaten.^[20]

Data Driven Systems Engineering (DDSE) Ansätze fokussieren sich neben der Beschreibung von Systemen, auch auf die Formelzusammenhänge von technischen Daten daraus automatisiert berechnete Eigenschaften von Systemen.^[21] Für die hierbei eingesetzten PMT steht dabei nicht ein einheitliches Datenmodell im Vordergrund, sondern automatisierte Berechnungen, Schnittstellen und die Integration von Werkzeugen. In der Umsetzung schaffen Engineering Information Management (EIM) Systeme damit im Engineering Alltag eine Verbindung und Rückverfolgbarkeit zwischen Daten entlang des V-Modells. Somit können beispielsweise zahlen-basierte Anforderungen direkt in Berechnungen und Simulationen übernommen werden und deren Ergebnisse automatisiert in Dokumenten aktualisiert werden.

DDSE ist nicht mit den Aktivitäten des Data Science zu verwechseln.^[22] Überlappungen der Themengebiete sind jedoch nicht auszuschließen.

Arcadia (Architecture Analysis & Design Integrated Approach) ist eine modell-orientierte Methode des System Engineerings, mit deren Hilfe bei der Planung komplexer Systeme die verschiedenen Teilbereiche (Systemarchitektur) definiert und in MBSE-Modellen beschrieben werden. Sie ist stark von SysML beeinflusst und stellt eine modellier-methodische Weiterentwicklung dar.^[23] Mit ihrer Anwendung sollen die Anforderungen eines Auftraggebers detailliert verstanden werden. Alle Aspekte eines umzusetzenden Produktes sollen für alle beteiligten Ingenieur-Disziplinen (Mechanik, Hydraulik, Elektronik, Elektrik, Software) so beschrieben werden, dass sie einer Lösung zugeführt werden können. Mit dem Open Source Werkzeug Capella werden solche interdisziplinären MBSE-Modelle Arcadia-basiert durchgängig und nachvollziehbar hergestellt. Auch die Integration mit PLM ist abgesichert.^[24] Arcadia wird in den folgenden und anderen Branchen und Zusammenhängen verwendet:

• Arcadia wird gemeinsam mit Capella in einer ganzen Reihe von Branchen eingesetzt. Fallbeispiele beschreiben Arcadia/Capella-Projekte bei Thales Australien, Deutsche Bahn – Digitale Schiene Deutschland, UK Atomic Energy Authority, Rolls Royce, Ariane Group, CNES, Autonomous Train Projekt, Framatome und Continental Automotive.^[25][26] Die European Space Agency (ESA) ist ebenfalls ein Arcadia/Capella Nutzer.^[27][28]
• Den Arcadia/Capella-Einsatz nutzen zudem komplexe Bahnprojekte wie im Bereich der Leit- und Sicherungstechnik für Eisenbahnen in Nordeuropa.^[29] oder beim Großprojekt SmartRail 4.0 der europäischen Bahngesellschaften in diverser Projektarbeit.^[30]
• Ein anderer Anwendungsbereich ist das MBSE-Explorations-Großprojekt mit Arcadia und Capella beim weltgrößten Hersteller für Mikroelektrionik-Herstellungsmaschinen ASML.^[31]
• Darüber hinaus werden Arcadia und Capella bei einer Vielzahl von industriellen Akteuren eingesetzt.^[32] Ein Spezialfall ist dabei die Siemens AG, die gemeinsam mit OBEO^[33] Arcadia und Capella in das Produktportfolio von Siemens Digital Industries Software integriert hat.^[34][35]
• Einmal jährlich wird auf den Capella Days^[36] über neue Arcadia/Capella Projekte aus allen Teilen der Welt berichtet. Zusätzlich finden in regelmäßigen Abständen Webinare statt, wo über Spezialthemen vorgetragen wird.^[37]

In Deutschland gibt es Hochschulen und Universitäten, die Systems Engineering als Präsenz- oder Fernstudiengang anbieten. Ein Beispiel ist die Universität der Bundeswehr München. Die Studierenden lernen dabei verschiedene Ansätze, Methoden und Prozesse des Software Engineering (SE) kennen. Ihnen wird das nötige „Rüstzeug” vermittelt, um komplexe Systeme mit unterschiedlichsten Anforderungen über den gesamten Systemlebenszyklus hinweg zu strukturieren, zu analysieren, zu spezifizieren, zu entwickeln und anzupassen. Weitere Studiengänge werden von der TH Ulm angeboten, z. B. der Master-Studiengang „Systems Engineering and Management“.^[38] Die Hochschule Landshut bietet seit 2009 einen zusätzlich von der Gesellschaft für Systems Engineering (GfSE) akkreditierten Masterstudiengang „Systems Engineering“ an.^[39] Die Hochschulen Augsburg, Kempten und Neu-Ulm bieten den Studiengang Systems Engineering an. In der Schweiz wird SE vorwiegend an der ETH Zürich als im Rahmen der Abteilung Engineering und Systeme (E&S) angeboten.^[40]

Die genauen Details zum Studium sind bei den jeweiligen Hochschulen zu erfragen.

Seit dem Jahr 2012 bietet die Gesellschaft für Systems Engineering (GfSE) in Kooperation mit dem TÜV Rheinland als akkreditierte Zertifizierungsstelle eine berufsbegleitende Personalzertifizierung für Systems Engineers als „Certified Systems Engineer (GfSE)“ an. Die Zertifizierung bietet die drei Zertifizierungsstufen C („Verstehen“), B („Anwenden“) und A („Beherrschen“), wobei A den Experten-Level darstellt.

Die Stufe C dauert fünf Monate, beinhaltet etwa zwölf Präsenztage bei einem lizenzierten Schulungsanbieter und endet mit einer zweistündigen Prüfung durch die SE-TREC GmbH und GfSE-Assessoren. Das verliehene Zertifikat stellt einen unabhängigen Nachweis von Kenntnissen im Systems Engineering dar. Inhaber der SE-Zertifikate Level C und B können auf Antrag das entsprechende INCOSE-Zertifikat beantragen.^[41]

• The International Council on Systems Engineering (INCOSE)
• Gesellschaft für Systems Engineering (German Chapter of INCOSE)
• Swiss Society of Systems Engineering (Swiss Chapter of INCOSE)
• Systems Engineering und Evaluation Centre (SEEC)

• Automotive Systems Engineering
• Systemanalyse

• W. F. Daenzer, F. Huber: Systems Engineering. Methodik und Praxis. 11. Auflage. Verlag Industrielle Organisation, Zürich 1999, ISBN 3-85743-998-X. 
• Rainer Züst: Einstieg ins Systems Engineering, kurz und bündig. 3. Auflage. 2004, ISBN 3-85743-721-9. 
• Reinhard Haberfellner, Olivier L. de Weck, Ernst Fricke, Siegfried Vössner: Systems Engineering. 12. Auflage. Orell Füssli, Zürich 2012, ISBN 978-3-280-04068-3. 
• Tim Weilkiens: Systems Engineering with SysML/UML: Modeling, Analysis, Design. Morgan Kaufmann OMG Press/Elsevier, Amsterdam Boston 2007, ISBN 978-0-12-374274-2 (englisch, archive.org). 
• Oliver Alt: Modellbasierte Systementwicklung mit SysML. Carl Hanser Verlag GmbH & Co. KG, München 2012, ISBN 978-3-446-43066-2, doi:10.3139/9783446431270. 
• Collective: NASA Systems Engineering Handbook. NASA SP-2016-6105 Rev2 Auflage. NASA, Washington, D.C. 2016 (nasa.gov [PDF]). 

Fachspezifische Wikis:

• Advanced Systems Engineering Glossar (ASE-Glossar) von acatech, KIT und Fraunhofer IEM, IPK und IAO
• Guide to the Systems Engineering Body of Knowledge (SEBoK) von INCOSE, IEEE und Stevens Institute

Weiterführende Weblinks:

• OMG Systems Modelling Language
• Systems Engineering Fundamentals. Defense Acquisition University Press, 2001 (PDF-Datei; 1,3 MB)
• Robert Shishko et al.: NASA Systems Engineering Handbook. (PDF; 2,6 MB) NASA Center for AeroSpace Information, 1995
• Systems Engineering Alphabet SEMP Consulting GmbH vertreten durch Dorfner und Schröter, 2024/2025 (kontinuierliche Erweiterung)

1. ↑ Christof Ebert: Global Software and IT: A Guide to Distributed Development, Projects, and Outsourcing. Wiley, Hoboken, NJ 2012, ISBN 978-0-470-63619-0. Fehler in Vorlage:Literatur – *** Parameterproblem: Dateiformat/Größe/Abruf nur bei externem Link
2. ↑ Charles N. Calvano, Philip John: Systems engineering in an age of complexity. In: Systems Engineering. Band 7, Nr. 1, Januar 2004, ISSN 1098-1241, S. 25–34, doi:10.1002/sys.10054 (wiley.com [abgerufen am 17. November 2025]). 
3. ↑ Systems Engineering and Standards | Homeland Security. United States Government, abgerufen am 23. Dezember 2022 (englisch). 
4. ↑ Larry B. Rainey, O. Thomas Holland: Emergent Behavior in System of Systems Engineering: Real-World Applications. 1. Auflage. CRC Press, Boca Raton 2022, ISBN 978-1-00-316081-6, doi:10.1201/9781003160816 (englisch, taylorfrancis.com [abgerufen am 17. November 2025]). 
5. ↑ Thiago J. Inocêncio et al.: Emergent Behavior in System-of-Systems: A Systematic Mapping Study. In: Proceedings of the XXXIII Brazilian Symposium on Software Engineering (= SBES '19). Association for Computing Machinery, New York, NY, USA 2019, ISBN 978-1-4503-7651-8, S. 140–149, doi:10.1145/3350768.3350779 (englisch). 
6. ↑ Hannes Hick, Klaus Küpper, Helfried Sorger (Hrsg.): Systems Engineering for Automotive Powertrain Development (= Powertrain). Springer International Publishing, Cham 2021, ISBN 978-3-319-99628-8, doi:10.1007/978-3-319-99629-5 (englisch, springer.com [abgerufen am 17. November 2025]). 
7. ↑ SE Standards. INCOSE, abgerufen am 17. November 2025 (englisch). 
8. ↑ Dennis M. Buede: The Engineering Design of Systems. Wiley, 2008, ISBN 978-0-470-16402-0, doi:10.1002/9780470413791 (englisch, archive.org [abgerufen am 17. November 2025]). 
9. ↑ History of Systems Engineering. In: INCOSE. Abgerufen am 17. November 2025. 
10. ↑ Garrett Shea: Systems Engineering Handbook. 6. Februar 2019, abgerufen am 6. April 2022. 
11. ↑ Andreas Poller: Exploring and managing the complexity of large infrastructure projects with network theory and model‐based systems engineering—The example of radioactive waste disposal. In: Systems Engineering. Band 23, Nr. 4, Juli 2020, ISSN 1098-1241, S. 443–459, doi:10.1002/sys.21537 (englisch, wiley.com [abgerufen am 7. Februar 2022]). 
12. ↑ Samira Keivanpour: Circular Economy at Micro Level—A System Engineering Perspective. In: Circular Economy in Engineering Design and Production. Springer International Publishing, Cham 2024, ISBN 978-3-03144651-1, S. 1–21, doi:10.1007/978-3-031-44652-8_1 (englisch, springer.com [abgerufen am 7. November 2024]). 
13. ↑ Istvan David, Dominik Bork, Gerti Kappel: Circular systems engineering. In: Software and Systems Modeling. Band 23, Nr. 2, April 2024, ISSN 1619-1366, S. 269–283, doi:10.1007/s10270-024-01154-4 (englisch, springer.com [abgerufen am 7. November 2024]). 
14. ↑ Systems Modeling Language (Wikipedia): Website Mai 2006.
15. ↑ CATIA Magic. 22. Mai 2023, abgerufen am 23. Februar 2025. 
16. ↑ About the OMG System Modeling Language Specification Version 2.0 beta. Abgerufen am 23. Februar 2025. 
17. ↑ About the Kernel Modeling Language Specification Version 1.0 beta 2. Abgerufen am 23. Februar 2025. 
18. ↑ About the Systems Modeling API and Services Specification Version 1.0 beta 2. Abgerufen am 23. Februar 2025. 
19. ↑ sodiuswillert.com
20. ↑ sodiuswillert.com
21. ↑ Denis Tissen, Ingrid Wiederkehr, Christian Koldewey, Roman Dumitrescu: Exploring data-driven model-based systems engineering: a systematic literature review. IEEE, 2023, ISBN 979-83-5031335-2, S. 1–6, doi:10.1109/ICTMOD59086.2023.10438129 (ieee.org [abgerufen am 17. November 2025]). 
22. ↑ Steven L. Brunton, J. Nathan Kutz: Data-Driven Science and Engineering: Machine Learning, Dynamical Systems, and Control. 2. Auflage. Cambridge University Press, 2022, ISBN 978-1-00-908951-7, doi:10.1017/9781009089517 (englisch, cambridge.org [abgerufen am 17. November 2025]). 
23. ↑ eclipse.org
24. ↑ Teamcenter System Modeling Workbench im Siemens Produktportfolio. Abgerufen am 20. Dezember 2022. 
25. ↑ Capella Fallbeispiele (Beschreibungen). Abgerufen am 20. Dezember 2022. 
26. ↑ Capella Fallbeispiele (Videos). Abgerufen am 20. Dezember 2022. 
27. ↑ 1. Fallbeispiel ESA. Abgerufen am 20. Dezember 2022. 
28. ↑ 2. Fallbeispiel ESA. Abgerufen am 20. Dezember 2022. 
29. ↑ Sicherungstechnik bei Eisenbahnen in Nordeuropa. Abgerufen am 20. Dezember 2022. 
30. ↑ Projektarbeit für SmartRail 4.0 der europäischen Bahngesellschaften. (PDF) Abgerufen am 20. Dezember 2022. 
31. ↑ MBSE-Explorationsprojekt bei ASML. Abgerufen am 20. Dezember 2022. 
32. ↑ Weitere industrielle Capella Nutzer. Abgerufen am 20. Dezember 2022. 
33. ↑ Capella Erweiterungen und Ergänzungen. Abgerufen am 20. Dezember 2022. 
34. ↑ Teamcenter System Modeling Workbench. Abgerufen am 20. Dezember 2022. 
35. ↑ Teamcenter System Modeling Workbench im Siemens Produktportfolio. Abgerufen am 20. Dezember 2022. 
36. ↑ Capella Days. Abgerufen am 20. Dezember 2022. 
37. ↑ Capella Webinare. Abgerufen am 20. Dezember 2022. 
38. ↑ Technische Hochschule Ulm. THU, abgerufen am 17. November 2025 (deutsch). 
39. ↑ Systems Engineering Master - Hochschule Landshut. Hochschule Landshut, abgerufen am 17. November 2025. 
40. ↑ Engineering und Systeme. ETH, abgerufen am 17. November 2025. 
41. ↑ GfSE: SE-Zert. Abgerufen am 25. Januar 2018.