Keynote Martin Eigner: Mechanik, Elektronik und Software gemeinsam entwickeln

Auf der diesjährigen ALM Future hielt Prof. Dr. Martin Eigner die Keynote. Eigner gehört zu den prägenden Persönlichkeiten im deutschsprachigen Systems Engineering und hat über Jahrzehnte die Entwicklung von PLM- und Engineering-Methoden begleitet. Keine Frage, dass ich mir das anhören musste, zumal die Veranstaltung lediglich zehn Minuten von meinem Büro entfernt war.

Seine Keynote stellte eine zentrale Frage: Wie verändert Software die Produktentwicklung und welche Rolle spielt Application Lifecycle Management (ALM) dabei?

Martin Eigner

Martin Eigner zählt zu den Pionieren des Product Lifecycle Management. Er war Professor an der TU Kaiserslautern und gründete dort das Institute for Virtual Product Engineering (VPE). Viele seiner Arbeiten prägten das Verständnis integrierter Engineering-Prozesse über Disziplingrenzen hinweg.

Eigner beschäftigte sich früh mit der Integration von Mechanik, Elektronik und Software. Seine Forschung konzentriert sich auf PLM-Architekturen, modellbasierte Entwicklung und durchgängige Engineering-Prozesse. Ein zentrales Anliegen ist die Verbindung von Methoden, Werkzeugen und Organisationsstrukturen. Also alles Themen, die ich seit über zehn Jahren bei SE-Trends bearbeite.

Vom Produkt zum Service

Ein zentrales Thema der Keynote war der Wandel der Geschäftsmodelle. In klassischen Industrien verkauften Unternehmen ein Produkt und verloren danach weitgehend den Kontakt zum Kunden. Wartung oder Ersatzteile bildeten die einzigen verbleibenden Interaktionen.

Digitale Produkte verändern dieses Modell grundlegend. Vernetzte Systeme bleiben dauerhaft mit dem Hersteller verbunden. Software-Updates, Nutzungsdaten und digitale Services schaffen neue Wertschöpfungsketten.

Eigner beschrieb diese Entwicklung am Beispiel der Automobilindustrie. Fahrzeuge entwickeln sich zunehmend zu Plattformen für digitale Dienste. Funktionen lassen sich nachträglich freischalten oder zeitlich begrenzt nutzen. Kunden bezahlen nicht mehr nur für das Produkt selbst, sondern für dessen Nutzung oder zusätzliche Funktionen. Einige Hersteller gehen davon aus, dass künftig ein erheblicher Anteil der Fahrzeuge im Sharing-Modell betrieben wird.

Dieses Geschäftsmodell verändert die Rolle der Produktentwicklung. Produkte bleiben während ihres gesamten Lebenszyklus Teil eines digitalen Systems. Entwicklung, Betrieb und Service verschmelzen.

Cybertronische Produkte

Eigner beschreibt moderne technische Systeme als cybertronische Produkte. Sie bestehen aus den drei Bausteinen Mechanik, Elektronik und Software. Software wirkt dabei als Katalysator. Sie verbindet die einzelnen Disziplinen und ermöglicht neue Funktionen. Gleichzeitig steigt dadurch die Komplexität der Systeme erheblich.

Viele Innovationen entstehen heute durch Elektronik und Software. Mechanische Innovationen spielen weiterhin eine Rolle, doch der größte Teil neuer Funktionen entsteht durch digitale Komponenten.

Diese Entwicklung führt zu einer engen Kopplung zwischen Engineering-Disziplinen. Mechanik, Elektronik und Software müssen gemeinsam entwickelt werden. Klassische Organisationsstrukturen mit getrennten Abteilungen geraten dabei an ihre Grenzen.

System-of-Systems

Mit der zunehmenden Vernetzung entsteht eine weitere Ebene: System-of-Systems. Einzelne Produkte agieren nicht mehr isoliert, sondern als Teil größerer Systeme.

Ein Beispiel ist die Infrastruktur einer Smart City. Verkehrssysteme, Energienetze, Gebäude und Kommunikationssysteme greifen ineinander. Jedes einzelne System funktioniert eigenständig, gleichzeitig entsteht eine übergeordnete Interaktion.

Für die Entwicklung bedeutet das neue Anforderungen. Produkte müssen nicht nur innerhalb ihres eigenen Systems funktionieren. Sie müssen mit anderen Systemen interoperabel sein.

Diese Perspektive verschiebt den Fokus von einzelnen Produkten hin zu Plattformen und Ökosystemen.

Die Herausforderung der Komplexität

Die Integration mehrerer Disziplinen und Systeme führt zu drastisch steigender Komplexität. Eigner illustriert dies anhand moderner Fahrerassistenzsysteme. Ein Advanced Emergency Braking System umfasst zahlreiche Ebenen, von Anforderungen über Funktionen, Mechanik, Elektronik und Software bis zu Simulationen, Tests und Produktionsdaten.

Jede dieser Ebenen wird in unterschiedlichen Werkzeugen und Datenmodellen verwaltet. Anforderungen liegen häufig in ALM-Systemen, Hardwaredaten in PLM-Systemen und Produktionsinformationen in ERP- oder Manufacturing-Systemen. Eine vollständige Sicht auf das System entsteht nur durch Integration dieser Datenquellen.

Grenzen der „Single Source of Truth“

In vielen Diskussionen über Engineering-Werkzeuge taucht der Begriff Single Source of Truth auf. Anbieter von PLM-, ALM- oder ERP-Systemen verwenden ihn häufig als zentrales Verkaufsargument.

Eigner äußerte dazu eine klare Position. Kein einzelnes System kann alle Informationen eines Produkts enthalten. Unterschiedliche Domänen benötigen unterschiedliche Werkzeuge und Datenmodelle.

PLM is talking about the single source of truth. ALM is talking about the single source of truth. But even the Pope is not the single source of truth.

Martin Eigner

Statt einer einzigen Datenquelle braucht man ein integriertes Datenmodell über mehrere Systeme hinweg. Erst diese Integration ermöglicht konsistente Entscheidungen.

Das V-Modell neu gedacht

Eigner kritisiert die klassische Interpretation des V-Modells. Ursprünglich entstand das Modell im Softwareengineering (was ich persönlich nicht so sehe). Es beschreibt eine lineare Entwicklung von Spezifikation, Implementierung und Test (auch hier bin ich leicht anderer Meinung).

Wie dem auch sei, für cybertronische Produkte reicht dieses Modell nicht aus. Mechanische und elektronische Systeme benötigen andere Entwicklungsabläufe. Simulation spielt eine zentrale Rolle und findet bereits sehr früh im Prozess statt.

Um dies zu berücksichtigen, erweitert Eigner das V-Modell um zusätzliche Elemente:

• Frühe Simulationen auf Systemebene
• Virtuelle Tests mit digitalen Modellen
• Physische Tests in späteren Phasen

Damit entsteht ein iterativer Entwicklungsprozess, der Simulation und reale Tests miteinander verbindet.

Die Rolle von ALM

Application Lifecycle Management nimmt in dieser Architektur eine besondere Rolle ein. ALM bildet den Backbone der Softwareentwicklung und verbindet mehrere Phasen des Lebenszyklus, von Anforderung bis Betrieb. Softwarewerkzeuge unterstützen diesen Prozess heute bereits sehr gut. Entwickler können Anforderungen direkt mit Code, Tests und Releases verknüpfen.

Für Hardware existiert eine solche durchgängige Integration bisher kaum. Deshalb entsteht eine Lücke zwischen Software- und Hardwareentwicklung.

Anforderungen über Disziplinen hinweg

Ein Beispiel für diese Unterschiede ist der Umgang mit Anforderungen. In Softwareprojekten besteht oft eine direkte Beziehung zwischen einer Anforderung, einem Softwaremodul und einem Test.

In der Hardwareentwicklung funktioniert dieses Modell nicht. Tests beziehen sich dort meist auf Funktionen oder Systemverhalten, nicht auf einzelne Komponenten. (Auch hier bin ich nicht ganz seiner Meinung: Hier verändert sich im Moment enorm viel)

Deshalb benötigt interdisziplinäre Entwicklung eine Systemarchitektur, die Anforderungen mit Funktionen und physischer Architektur verbindet. Erst diese Architektur ermöglicht konsistente Traceability.

Versionen, Änderungen und Konfiguration

Ein weiteres Problem entsteht beim Versionsmanagement. Software nutzt meist Semantic Versioning mit Major-, Minor- und Patch-Versionen. Hardware verwendet dagegen andere Konzepte wie Revisionen oder Iterationen. Diese Unterschiede erschweren die Integration von PLM- und ALM-Systemen.

Wenn Software- und Hardwareänderungen zusammenwirken, müssen Versionen synchronisiert werden. Ohne abgestimmtes Konfigurationsmanagement entstehen Inkonsistenzen zwischen Softwareständen und physischer Hardware.

Eigner betrachtet Change Management als entscheidenden Prozess in komplexen Entwicklungsumgebungen. Änderungen entstehen in allen Disziplinen und müssen über Systemgrenzen hinweg bewertet werden. Der schwierigste Schritt bleibt die Impact-Analyse. Änderungen wirken sich selten nur auf ein einzelnes System aus. Sie betreffen Funktionen, Softwaremodule, Hardwarekomponenten und Tests gleichzeitig.

Ohne durchgängige Traceability lässt sich dieser Zusammenhang kaum analysieren.

Herausforderungen der digitalen Transformation

Technische Integration allein reicht nicht aus. Viele Probleme entstehen durch Organisationsstrukturen und Unternehmenskultur. Disziplinen arbeiten häufig in getrennten Abteilungen mit eigenen Werkzeugen und Prozessen. Diese Silos erschweren die Zusammenarbeit.

It’s not only to connect hardware with software. There are different tools, different methods, different processes, and different speed. So this is not only a technical problem – it is a cultural one.

Martin Eigner

ALM- und PLM-Einführungen scheitern daher selten an der Technologie. Der schwierigere Teil liegt im Change Management der Organisation. Eigner identifiziert mehrere Risiken für Unternehmen, die cybertronische Produkte entwickeln:

• Zunehmende Systemkomplexität
• Fachkräftemangel im Systems Engineering
• Sicherheitsrisiken vernetzter Systeme
• Regulatorische Anforderungen

Vernetzte Produkte eröffnen neue Geschäftsmodelle, schaffen aber gleichzeitig neue Angriffsflächen. Sicherheits- und Compliance-Aspekte müssen daher früh im Entwicklungsprozess berücksichtigt werden.

Fazit

Martin Eigner zeichnete auf der ALM Future ein klares Bild der aktuellen Transformation. Produkte entwickeln sich zu vernetzten cybertronischen Systemen. Software wird zum zentralen Treiber von Innovation. Viele der Herausforderungen sind nicht neu. Er hat sie jedoch für das Zielpublikum der Veranstaltung gut aufgearbeitet und die Größe der Herausforderungen dargestellt

ALM und PLM bilden wichtige Bausteine dieser Transformation. Ihr Erfolg hängt jedoch nicht nur von Werkzeugen ab. Entscheidend sind integrierte Datenmodelle, durchgängige Traceability und funktionierende interdisziplinäre Prozesse. Damit weist Eigner auf genau die Herausforderungen hin, welche mit Product Velocity gelöst werden können.

Auf der Veranstaltung hatte ich eine Gelegenheit gefunden, mich mit Martin Eigner auszutauschen und insbesondere, ihm die Velocity Loop vorzustellen. Die Darstellung traf auf positive Resonanz, insbesondere, da dort explizit das Business als wichtiger Gesprächspartner mit eingebunden ist.

Wir waren uns einig, die zentrale Herausforderung bleibt organisatorisch: Unternehmen müssen lernen, komplexe Systeme gemeinsam zu entwickeln. Nur so lassen sich die Chancen digitaler Produkte nutzen, ohne an ihrer Komplexität zu scheitern.