Das Engineering hat nicht etwa ein Problem, weil die einzelnen Fachbereiche ihre Aufgaben nicht zu bewältigen wüssten. Im Gegenteil: Nie war die Lösung von einzelnen Aufgaben einer Produktentwicklung besser zu lösen, werden die Prozesse besser beherrscht – gleichgültig, ob es um Mechanik, Elektronik, Elektrotechnik oder um Software geht. Viele Entwickler betrachten aber ihre Aufgabe mehr oder weniger isoliert und denken zu wenig „im Gesamtsystem“. Die Folge sind viele, für sich genommen perfekte Entwicklungsergebnisse, die jedoch selten kompatibel zu den Lösungen der anderen Beteiligten sind.

Obwohl moderne Maschinen und Anlagen ebenso wie ein Fahrzeug, Flugzeug oder Schiff längst nur noch als komplexe Systeme betrachtet werden können, erfolgt ihre Entwicklung, als ginge es immer noch in erster Linie darum, die physikalischen Verbindungen und Schnittstellen zwischen den Komponenten zu beherrschen. Im Automobilbau werden zwar Lenkung, Antrieb, Fensterheber und Hunderte anderer Funktionalitäten als Subsysteme angesehen, die in einer Vielzahl von Steuergeräten versteckt sind. Für die Definition und Abgrenzung von Funktionen und logischen Beziehungen auf Basis einer gemeinsamen Systemarchitektur gibt es aber kein einheitliches Vorgehen, oft nicht einmal ein gemeinsames Verständnis von der Notwendigkeit. Von einer gemeinsamen Sprache ganz zu schweigen.

CAD-Kopplung greift zu kurz

Die Komplexität ist inzwischen zum Normalfall geworden. Deshalb geht es beim Management von Entwicklungsteams nicht mehr nur um den Datenaustausch zwischen verschiedenen CAD-Systemen. Wenn sich eine Projektgruppe aus verschiedenen Ab­teilungen aus dem eigenen Haus, ex-ternen Entwicklungspartnern und Zulieferern unterschiedlichster Dis­ziplinen und Organisationen zusammensetzt, spielt die Synchronisation von Fachbereichen und ihrer Arbeits-ergebnisse über eine Vielzahl von IT-Systemen hinweg eine ebenso wichtige Rolle. Genau dafür wird Systems-En-gineering gebraucht.

Die in der Studie herausgearbeiteten Handlungsfelder lassen sich in einem abstrahierten V-Modell abbilden. Die klassischen mechatronischen Aspekte (Hardware- und Software-Entwicklung sowie Mechanik) sind dabei nur ein Teilaspekt.

© Prostep

Nach der Definition der deutschen Gesellschaft für Systems-Engineering (GfSE) umfasst Systems-Engineering die wesentlichen Ingenieurtätigkeiten, die zur Entwicklung komplexer Produk- te notwendig sind. Um eine Vielzahl von Funktionen erfolgreich zu einem beherrschbaren und kostengünstigen System zu integrieren, sind unterschiedlichste Anforderungen über den gesamten Systemlebenszyklus hinweg zu berücksichtigen. Dazu muss der multi- und interdisziplinären Natur der Systemgestaltung zum Beispiel durch interdisziplinäre Entwicklungsteams Rechnung getragen werden. Diese abstrakte Umschreibung wirft in der Praxis einige Fragen auf:

• Was ist unter einer multidisziplinären Systemarchitektur zu verstehen und wer definiert diese?
• Wie lassen sich daraus Funktionen ableiten, die das System erfüllen soll?
• Worin besteht der Unterschied zwi­schen einem Lastenheft im Maschinenbau und den Systemanforderungen?
• Was ist ein V-Modell und welches ist das richtige?
• Was unterscheidet Mechatronik-Entwicklung vom Systems-Engineering?

Hier eine einheitlichere Begrifflichkeit und eine größere Übereinstimmung im Verständnis zu erreichen sowie Empfehlungen für die Umsetzung in der Praxis zu erarbeiten, hat sich die Initiative Smart-Systems-Engineering zum Ziel gesetzt.

System-Engineering – mehr Wunsch als Wirklichkeit

Dazu wurde 2011 in Zusammenarbeit mit dem Fraunhofer Institut für Produk-tionsanlagen und Konstruktionstechnik (IPK) eine Feldstudie durchgeführt, um die größten Herausforderungen zu iden-tifizieren und festzustellen, welche Anforderungen am dringendsten ein einheitliches Vorgehen verlangen. 50 Experten aus der Industrie haben sich in Interviews und Workshops zu ihren Anforderungen geäußert. Die Teilnehmer kamen unter anderem von Thyssen-Krupp, Continental, MAN und Airbus. Von den IT-An-bietern waren Dassault Systèmes, IBM, PTC und Siemens PLM Software beteiligt. Die Studie förderte bereits eine Reihe interessanter Ergebnisse zutage:

Projektplan der Initiative Smart-Systems-Engineering: Bis Ende 2012 soll die erste Empfehlung stehen, welche die Begrifflichkeiten und die wichtigsten Handlungs­felder einheitlich beschreibt.

© Prostep

• Methoden zum Systems-Engineering werden im Elektrik/Elektronik- sowie im Software-Umfeld eingesetzt. Was fehlt, ist ein durchgängiger Einsatz über alle Disziplinen hinweg.
• Die verfügbaren Tools und Methoden werden nur von wenigen Beteiligten wirklich ganzheitlich verstanden.
• Anwender sind heute bereits damit ausgelastet, zu testen, ob die spezifizierten Anforderungen an „ihr Produkt“ tatsächlich erfüllt werden. Es fehlt oft die Zeit, sich mit neuen Ansätzen auseinanderzusetzen.
• Bei Validierung und Tests von Sys­temeigenschaften fehlt es häufig am Wissen um disziplinübergreifende Verfahren. Die Konsequenz: Erst sehr spät im Entwicklungsprozess erfolgen Tests. Sprich dann, wenn Änderungen hohe Kosten verursachen und die Produktion bereits auf die finalen Ergebnisse wartet.
• Auf die Nachverfolgbarkeit von Abhängigkeiten zwischen verschiedenen Anforderungen, Sub-Systemen oder Komponenten wird zu Dokumentationszwecken geachtet. Die Bedeutung als strategisches Instrument wird derzeit nicht gesehen.

Es wundert demnach nicht, dass Systems-Engineering in der Industrie inzwischen ein gängiges Schlagwort ist, es aber nur wenige Ansätze gibt, Systems-Engineering praktisch anzuwenden.
Neben technischen Herausforderungen wurde in der Studie deutlich, dass es zudem Problemfelder auf organisatorischer Ebene gibt. Es scheint logisch, den Weg des Systems-Engineerings zu gehen, die quälende Frage des Managements nach dem „Business-Case“ kann aber kaum jemand hinreichend beantworten.

Systems-Engineering ist eine strategische Entscheidung in Richtung Wahrung der Zukunftsfähigkeit eines Unternehmens.

Von den Anwendern in der Studie angeführten Kernanforderungen an Systems-Engineering sind vor allem die Möglichkeiten zur frühen Validierung der Systemspezifikation und Simulation des Gesamtsystems. Eine Umsetzung wird bislang aber durch fehlendes Dis­ziplinen-übergreifendes Know-how behindert. Zudem ermöglichen die be­stehenden Methoden und Tools die Nachverfolgbarkeit von Abhängigkeiten (Traceability) noch nicht hinreichend.

Die Aufgaben Schritt für Schritt lösen

Die bisherige Herangehensweise für ein Systems-Engineering scheiterten daran, dass versucht wurde, alle Handlungs­felder von der Anforderungsdefinition über Engineering bis hin zur Simulation auf einmal anzugehen. Sinnvoller ist es, schrittweise vorzugehen und darauf zu fokussieren, wer im Prozess welche Informationen wann, in welcher Quantität und Qualität benötigt. Einen pragmatischen Lösungsansatz eröffnet die Abkehr von allumfassenden „Super-Standards“ hin zu kleinen, überschaubaren und definierbaren Systems-Engineer-ing-Objekten, die bedarfsgerecht ausgetauscht werden können. Um umsetzbare Konzepte zu erhalten, sollten die Handlungsfelder nacheinander angegangen werden – unter Berücksichtigung der jeweiligen Abhängigkeiten:

• Systemarchitektur des Produkts,
• Anforderungen,
• Nachverfolgbarkeit,
• und Systemsimulation.

Auf Grundlage der Umfrage-Ergebnisse haben 70 Vertreter aus Industrie-Unternehmen sowie IT- und Dienstleistungsanbieter Ende 2011 das Projekt Smart-Systems-Engineering initiiert. Dessen Ziele sind:

• Ein gemeinsames Verständnis von Systems-Engineering schaffen, einschließlich der Fachbereiche, die noch nicht „in Systemen“‘ denken.
• Empfehlungen zu erarbeiten für die Definition multidisziplinärer und firmenübergreifender Produktsystemarchitekturen und für die Nachverfolgbarkeit der darin definierten Anforderungen.
• Empfehlungen für die effiziente Unterstützung firmenübergreifender Systems-Engineerings einschließlich organisatorischer Aspekte.
• Definition eines neutralen Datenmodells für eine Produkt-Systemarchitektur mit Fokus auf Schnittstellen zwischen den Disziplinen, um ihre Zusammenarbeit zu verbessern.
• Der Aufbau eines Demonstrators für Produktsystemarchitekturen.

Wesentliches Ergebnis des Kick-off-Meetings Ende Februar 2012 ist die De-finition von Interaktions-Szenarien, die künftig Fokus und Richtschnur für alle weiteren Aktivitäten im Projekt darstellen: Validierung und Simulation. Die Szenarien beschreiben die Schritte aller Beteiligten und die zu erfüllenden Bedingungen, um das jeweilige Ziel zu erreichen. Dabei unterscheidet man zwischen prozess- und datenorientierten Interaktions-Szenarien. Während die einen auf die Verbesserung der Zusammenarbeit zielen, erschließen die anderen die Möglichkeit zu einem interoperablen Datenaustausch. Bis Ende 2013 soll das Projekt mit einem Demons-trator abgeschlossen werden.

Autor: Steven Vettermann ist Geschäftsführer von Prostep iViP e.V. in Darmstadt