Wenn wir einen Blick in die Zukunft des Engineering, der Entwicklung und Konstruktion von Fahrzeugen werfen, müssen wir nicht unbedingt Doc Emmett Brown mit seinem Fluxkompensator oder den legendären Q mit seinen Bond-Gimmicks bemühen (ob ein Auto mit Raketenwerfer eine Straßenzulassung bekäme, ist ohnehin fraglich). Es reicht, ein reales Vorbild zu bemühen: Charles Franklin Kettering.
Ein berühmtes Zitat von ihm lautet: „Ich interessiere mich sehr für die Zukunft, denn ich werde den Rest meines Lebens in ihr verbringen“. Kettering war 27 Jahre lang Entwicklungschef von General Motors. Er machte den elektrischen Anlasser serientauglich und auf sein Konto geht auch die elektrische Fahrzeugbeleuchtung. Wenn wir sehr großzügig sind, ist er damit einer der Vorväter der E/E-Plattformen. Zudem war sein Credo, dass Innovationen durch den Blick über den Tellerrand entstehen; heute nennt man das wohl interdisziplinäre Zusammenarbeit.
Die Situation in der Automobilentwicklung heute nutzt eher den Ansatz, den „Elefanten zu zerteilen“, um dann in spezialisierten Silos – auch und vor allem bei Zulieferern – einzelne Fahrzeugbestandteile zu konstruieren, die der OEM dann als Systemintegrator zum fertigen Auto komponiert. Das war in den letzten Jahrzehnten ein funktionstüchtiger und effizienter Ansatz – die Kunst des Autobaus bestand darin, die vielen Einzelfäden zusammen zu halten, um ein innovatives Auto zu erhalten, das zeitgetreu zur Markteinführung bereitstand und sich den vielfältigen Kundenwünschen leicht anpassen ließ.
Eine aktuelle Bestandsaufnahme zeigt aber deutlich auf: So wird es nicht weitergehen. Schon heute erzeugen arbeitsteilige Fertigungs- und Entwicklungsnetzwerke, Modell- und Variantenfülle, oder Personalisierungsmöglichkeiten des Kunden eine große Komplexität in der Automobilentwicklung, die bei gleichzeitig immer kürzeren Entwicklungszyklen und beschränkten Budgets zu einer Herausforderung für das Engineering wird. Nun kommen noch die Einflüsse der sogenannten CASE-Ära (Connected, Autonomous, Shared, Electrified) mit dem Anstieg der Software-Dominanz im Auto hinzu. Neue Technologien wie die künstliche Intelligenz müssen darüber hinaus in der Entwicklung beherrscht werden – und zudem eine wesentlich intensivere Interaktion aller Systembestandteile untereinander. Und als Kirsche auf dem Kuchen kommen noch erweiterte Nachweispflichten hinzu, z.B. aufgrund steigender Umweltanforderungen – siehe WLTP-Tests – oder weil hochautomatisierte Fahrzeuge immer mehr sicherheitskritische Fahrfunktionen übernehmen – Stichwort ISO 26262 zur Absicherung solcher Funktionen.
Ob die etablierten Silo-Ansätze in der Konstruktion und Entwicklung diesen Entwicklungen gewachsen sind, darf bezweifelt werden. Das haben Automobilbauer auch schon längst erkannt. Sie arbeiten aktuell daran, neue Methoden wie das Systems Engineering und neue Formen der Zusammenarbeit in der Fahrzeugentwicklung einzuführen. Mit einer neuen Methodik wird aber nur die Basis gelegt. Insgesamt sind es vier Komponenten, mit denen ein Engineering der Zukunft umgesetzt werden muss.
Die erste Komponente ist das Systems Engineering. Das Systems Engineering ist eine in einigen Industrien etablierte Methodik, die beispielsweise im Flugzeugbau, der Raumfahrt aber auch bei z.B. großen Infrastrukturvorhaben eingesetzt wird. Sie wurde gezielt entwickelt, um Komplexität zu beherrschen. Im Gegensatz zum Denken in Silos favorisiert sie ein interdisziplinäres Vorgehen. Der Fokus im Systems Engineering liegt dabei sehr stark auf der Ableitung einer Gesamtsystemarchitektur aus den Kundenanforderungen bzw. der „Mission“ eines Systems. Erst ausgehend von dieser übergreifenden Architektur werden einzelne Arbeitspakete geschnürt, für die wiederum in einem strukturierten und nachvollziehbaren Ansatz jeweils weiter verfeinerte bzw. immer technischer werdende Anforderungen definiert werden. Letzten Endes kann auf diese Weise jederzeit gezeigt und abgesichert werden, dass auch wirklich jede Komponente eines Systems wie erwartet zur Erfüllung der Mission beiträgt.
Letzten Endes bedeutet das Systems Engineering einen Kulturwandel für das Engineering, der dazu führt, dass auch komplexeste Systeme noch wie gewünscht funktionieren können, und im Übrigen dabei hilft, massiv Kosten in der Entwicklung einzusparen bzw. unerwünschte Budgetüberschreitungen zu vermindern, wie eine Analyse von Werner Gruhl bei der NASA schon in den 90er Jahren gezeigt hat.
Und zum Schluss dieses Segments noch eine weitere gute Nachricht für Ingenieure: Textlastige und nicht immer eindeutig interpretierbare Lastenhefte könnten durch Systems Engineering bald der Vergangenheit angehören, da das Systems Engineering in neuerer Zeit auch neue Techniken wie das „Model Based Systems Engineering“ (MBSE) hervorgebracht hat, die es ermöglichen, Systeme in Form von klar strukturierten, eindeutigen und parametrisierten Modellen abzubilden, die sogar die Intelligenz mitbringen, Systemverhalten zu simulieren und so frühzeitig Probleme aufzuzeigen und zu lösen.
Die zweite Komponente des zukünftigen Engineering kennzeichnet eine Zäsur – weg von der Applikationszentrierung hin zur Datenzentrierung in der Engineering IT. Tatsache ist, dass auch in Zukunft viele spezialisierte IT-Werkzeuge entlang des Entwicklungsprozesses benötigt werden. Damit unterscheidet sich die Zukunftsperspektive zumindest in diesem Punkt nicht grundsätzlich von der heutigen Situation, auch wenn der Trend generell von großen, monolithischen IT-Systemen zu kleineren Werkzeugen – sogenannten Microservices – geht, die jeweils für einen begrenzten Aufgabenumfang die bestmögliche Unterstützung bereitstellen.
Bislang kam dem Product Lifecycle Management (PLM) in der Welt des Engineering die Aufgabe zu, eine Klammer für diese Vielfalt von IT-Werkzeugen zu schaffen. Doch die meisten „One-Size-Fits-All“-Ansätze, in denen PLM-Systeme für alle Gewerke übergreifend aufgebaut werden sollten, scheiterten an dem hohen Spezialisierungsgrad der Fachabteilungsprozesse und -datenmodelle. Die verfügbaren PLM-Systeme waren historisch typischerweise zu stark auf die Belange mechanischer Entwicklung ausgelegt, so dass sich daneben sogenannte ALM-Systeme (Application Lifecycle Management) für z.B. Softwarebereiche etablierten und weitere spezialisierte Lösungen für Elektrik und Elektronik, Simulationsdaten usw.. Für eine übergreifende Sicht auf das Gesamtsystem wurde wiederum die mehr oder weniger lose Kopplung bzw. Synchronisation solcher Systeme über verschiedenste Schnittstellen erforderlich, mit durchaus unterschiedlichem Erfolg und wiederum eigener Komplexität.
Der neue Ansatz, um jenseits der Legion der Applikationen Struktur und Transparenz zu schaffen, ist eine Rückbesinnung auf die Daten. Der Ansatz des Semantic Web, der auf Tim Berners Lee, den Erfinder des Internet, zurückgeht, zielte ursprünglich darauf ab, das Internet besser für Maschinen nutzbar zu machen, indem die Bedeutung eines Begriffes über spezielle Beschreibungssprachen gleich mitgeführt wird. So kann z.B. eine semantische Suchmaschine direkt ableiten, dass es sich bei „Paris“ wahlweise um eine Stadt in Frankreich oder auch einen trojanischen Prinzen handelt, und auf dieser Schlußfolgerung basierende Kontextinformationen (z.B. „in Paris gilt französisches Recht“ oder „Paris hat Helena entführt“) gleich mitliefern. In den vergangenen Jahren hat sich der Semantic-Web-Ansatz daher in der Wissenschaft gut etabliert, um Wissensnetzwerke aufzubauen und auszuwerten, etwa in der Krankheitsdiagnostik oder in der Biologie.
Angewandt auf die Welt des Ingenieurs, lässt sich über ein semantisches Web auf Basis der existierenden Applikationssilos und der darin enthaltenen Informationen ein einheitlicher Datenpool schaffen, der alle „Sprachen“ der verschiedenen Konstruktions- und Entwicklungsdisziplinen versteht. Sozusagen der Babelfisch des Engineering. Jeder am Entwicklungsprozess Beteiligte kann sich entsprechend seiner Anforderungen aus diesem Pool bedienen, und mehr noch: mit kommenden Generationen semantischer Plattformen lassen sich aufgrund der Maschinenlesbarkeit, die die Informationen und ihre Zusammenhänge nun auszeichnet, Algorithmen und symbolische künstliche Intelligenzen schaffen, die dem Engineering bei der Konsistenzwahrung aller Informationen, bei der Steuerung der Projekte oder auch bei der Extraktion notwendiger Dokumentation aus dem Wissensnetzwerk unter die Arme greifen können.
Die dritte Komponente setzt auf diesem einheitlichen, semantischen Datenpool auf: Mit Hilfe von Systems Engineering entsteht ein Netz von Informationen, das quasi ein erstes Bild des Fahrzeugs aus Sicht des Engineering darstellt. Sie ahnen schon, wohin die Reise geht: zum Digitalen Zwilling. Der Digitale Zwilling wird zum Wegbegleiter der Entwickler. Er erlaubt ihnen, die Auswirkungen von Änderungen und Entwicklungsschritten auf das Gesamtsystem Auto zu simulieren und zu beurteilen. Er reift mit dem Entwicklungsprozess heran und erspart mehr und mehr die Anfertigung physischer Prototypen. Das spart immens Zeit und Kosten. Bevor ein Prototyp für teures Geld angefertigt wird, ist der Digital Twin schon „virtuell“ getestet.
Der digitale Zwilling stirbt aber nicht, wenn die Entwicklung abgeschlossen ist. Läuft die Produktion an, so wird aus dem „Engineering Zwilling“ für jedes individuelle Fahrzeug ein Digitaler Zwilling abgeleitet, der z.B. mit Daten aus Produktion, Qualität und Dokumentation angereichert wird. Während seines (hoffentlich) langen Lebens auf der Straße wird das Fahrzeug dann kontinuierlich selbst Daten, z.B. aus Sensoren, aufgrund von Wartungsvorgängen oder der Nutzung verbundener Diensteerzeugen. So entwickelt sich der digitale Zwilling ständig weiter, und über das semantische Wissensnetzwerk lassen sich die Informationen überall nutzen.
Und damit kommen wir zur vierten Komponente: Der Digitale Zwilling ist keine Einbahnstraße. Mit den zurückgespielten Betriebsdaten gewinnen die Ingenieure Einblicke, wie sich die von ihnen entwickelten Produkte oder Komponenten im realen Betrieb verhalten. Diese Daten können in die weitere Entwicklung von Nachfolgemodellen, in Modellpflegemaßnahmen oder auch in Ad-hoc-Qualitätssicherungsmaßnahmen einfließen. Dabei werden sich Konstrukteure nicht für Einzeldaten interessieren, sondern eher für statistische Aussagen, z. B. bezüglich der Zuverlässigkeit einer Komponente. IoT-Plattformen werden also die Daten der Betriebs-Zwillinge der Einzelfahrzeuge systematisch sammeln und mit Datenanalysewerkzeugen statistisch auswerten. Solche Auswertungen und ihr Kontext werden dann über die semantische Wissensvernetzung wiederum den Ingenieuren zur Verfügung stehen. Diese Mehrwert-Dienste des Digitalen Zwilling erlauben eine zielorientierte Entwicklung im Sinne von „Design to Cost“, „Design to Reliability“ und „Design to Usage“; sie vermeiden ein Over- oder Underengineering und unterstützen kontinuierliche Verbesserung.
Dass der Digital Twin auch dem Fahrer und den Passagieren Mehrwerte bietet – etwa indem er auch die Voraussetzungen für Over-the-Air-Updates, On-Demand-Entertainment oder das Teilen von Fahrzeugen schafft – wissen wir. Aber hier geht es schließlich um die Zukunft des Engineering. Und für das Engineering ist das optimale Funktionieren des Autos im Straßenverkehr noch immer der wichtigste Prüfstein.
Eine Zusammenfassung dieses Posts finden Sie in unserem White Paper „Future Engineering – der neue Weg des Autodesigns“. Laden Sie es sich herunter. Und dann träumen wir gemeinsam vom Fluxkompensator.
