Digital twin concept. Vritual model exchanging data, system simulation and monitoring. Machine learning. Digital twin characteristics. Smart computers.

Bei einem digitalen Zwilling als System-of-Systems müssen Tools aus verschiedenen Quellen kombiniert werden, um die tatsächliche endgültige Systemleistung widerzuspiegeln und zu zeigen, was unter der Haube passiert. (Bild: wladimir1804 - stock.adobe.com)

Das softwaredefinierte Fahrzeug (Software Defined Vehicle, SDV) ist schon da, doch die Entwicklungsprozesse sind in der Automobilindustrie noch stark in der Vergangenheit verankert. Bereits heute verwenden Fahrzeuge 100 Millionen Zeilen Softwarecode und für das SDV wird diese Zahl exponentiell ansteigen. Die hohe Geschwindigkeit von Neuentwicklungen, die zunehmende Komplexität von Fahrerassistenzsystemen (Advanced Driver Assistance System, ADAS) und SDV sowie die Einführung von Zonenarchitekturen für autonome Fahrzeuge stellen eine enorme Herausforderung dar.

Die Grenzen des linearen Entwicklungsprozesses

Der Entwicklungsprozess für Automobilelektronik war immer linear. Das heißt, zunächst die Anforderungen sammeln, das Konzept erstellen und bewerten, dann die Hardware entwerfen und in kleinen Chargen produzieren und schließlich testen. Erst im Anschluss daran wird die Software entwickelt. Auf die Verfügbarkeit einer Steuereinheit (Electronic Control Unit, ECU) zu warten, um dann den Proof of Concept der Hardware zu testen, kann die Markteinführung unter Umständen um 12 bis 18 Monate verzögern – und das auch nur, wenn es keine größeren Probleme gibt. Das ist einfach zu langsam, um mit dem aktuellen Innovationstempo Schritt zu halten. Die Kombination aus hoher Komplexität, neuen Funktionen und geschlossenen Systemen von Lieferanten macht es für OEMs nahezu unmöglich, die Systemleistung wirklich zu verstehen.

Hin zur iterativen Entwicklung oder zu Shift-Left

Genau deshalb spricht gerade jeder vom digitalen Zwilling. Durch die Verlagerung der Entwicklung in die virtuelle Welt kommt es zu einem Shift-Left, also zu einer zeitlichen Verschiebung des Prozesses nach vorn. So lassen sich Hardware und Software parallel entwickeln und testen. Der Prozess wird iterativ, wobei das Design von Hardware und Software mehrmals überarbeitet werden kann, bevor die Hardware tatsächlich verfügbar ist. Digitale Zwillinge sind auch hinsichtlich Wartung und Aktualisierung einfacher zu handhaben, da der kontinuierliche Entwicklungsfluss, die Integration und Aktualisierungen am SDV allesamt außerhalb des Fahrzeugs erfolgen.

Doch auch für den Einsatz des digitalen Zwillings gelten weiterhin viele der Probleme der traditionellen Automobilindustrie. An der Erstellung eines digitalen Zwillings komplexer Automobilsysteme sind mehrere Anbieter beteiligt, die Tools mit unterschiedlichen Standards und verschiedenen Interoperabilitätsgraden sowie verschiedene Typen von Modellen mit unterschiedlicher Wiedergabetreue bereitstellen. Es ist eine echte Herausforderung für jede IT-Abteilung, all diese Lösungen in einem zusammenhängenden Konzept zusammenzuführen.

Siemens_Diagramm_Pave360_Vorteile
Der Einsatz eines digitalen Zwillings überwindet die Herausforderungen für softwaredefinierte Fahrzeuge. (Bild: Siemens)

Digitaler Zwilling des gesamten Fahrzeugs

Mit der Pave360-Umgebung für Software Defined Vehicles lässt sich ein digitaler Zwilling des gesamten Systems erstellen, um es dann auszuführen, auf Leistung zu testen, zu verbessern und im Rahmen eines iterativen Prozesses erneut zu testen. Da die Software geschrieben werden kann, bevor die Hardware verfügbar ist, verkürzt sich die Markteinführungszeit erheblich. Die Software vereint umfassende Mixed-Fidelity-Funktionen für digitale Zwillinge und die Möglichkeit, sich mit mehreren Quellen zu verbinden, einschließlich der Hardware und realen Eingangsstimuli, um eine realistische Automobilumgebung zu schaffen. Das System ist zugänglich, da es Tools einbindet, die auf etablierten Standards basieren.

Durch die Erstellung von digitalen Zwillingen eines SoC, ECU oder System-of-Systems können OEMs neue Architekturmöglichkeiten erforschen, Tier-1-Anbieter können OEMs den Proof of Concept liefern, Tier-2-Anbieter die komplexen SOC-Rechenanforderungen verstehen und IP-Anbieter ihren Kunden die Bewertung von IP-Konfigurationen ermöglichen.  

Die Lösung wird in zwei Teilen implementiert: dem Frontend und dem Backend. Die Frontend Bench Integrated Development Environment (IDE) bietet eine vertraute Schnittstelle für Hardware- und Software-Entwickler mit einer detaillierten Analyse von Systemmetriken. Es ermöglicht die Konfiguration des gesamten Systems und reduziert den Integrationsaufwand. Das Backend-System führt den digitalen Zwilling aus und verbindet den virtuellen oder physischen Stimulus. Die digitalen Zwillinge von Pave360 lassen sich als Referenzplattform an jede Phase des Fahrzeugdesignzyklus anpassen, um die Entwicklung während des gesamten Prozesses zu beschleunigen.

Siemens_Diagramm_Pave360_Frontend_Backend
Bild 2: Pave360 stellt sozusagen ein virtuelles Fahrzeug auf dem Schreibtisch der Ingenieure bereit. (Bild: Siemens)

Virtuelle Lösung für frühe Softwareentwicklung

Die virtuellen Referenzplattformen basieren auf offenen Standards gemäß SystemC/TLM 2.0. So ist es möglich, das Zielsystem mit virtuellen Modellen für IP, SoCs oder ECUs aus beliebigen Quellen auf Grundlage dieser offenen Standards anzupassen. Entwickler können die Software-Entwicklung anschließend in ihrer eigenen virtuellen Referenzlösung „Run Fast“ iterieren und Pave360 Bench IDE für die Extraktion, Visualisierung und den Vergleich von Metriken verwenden. Die Entwicklung in der AWS-Cloud geht noch einen Schritt weiter und ermöglicht Ausführungsgeschwindigkeit nahezu in Echtzeit. Nach der ersten funktionalen Software-Entwicklung kann eine detaillierte Analyse der Hardware- und Software-Interaktion mit der Hybridlösung erfolgen.

Hybrid-Lösung für paralleles Hardware- und Softwaredesign

Software im frühen Entwicklungsstadium hat eigene Probleme, etwa Timing-Artefakte durch Hardware- und Software-Interaktionen, die zu unerwartetem Verhalten führen. Die Software hat auch Einfluss auf die gesamte Leistungsaufnahme. In beiden Fällen sind weitere Iterationen zur Optimierung des Systems erforderlich.

Durch die Kombination aus virtueller und hybrider Umgebung unter Verwendung desselben Designs, jedoch mit zwei verschiedenen Fidelitys, können Entwickler zwischen den beiden Fidelitys wechseln oder iterieren. Software kann auf virtueller Basis funktional korrekt gemacht und dann Regressionstests unterzogen werden, um Probleme beim Timing und bei der Leistungsaufnahme in hybrid laufenden RTL-Beschreibungen zu identifizieren. Softwareingenieure können die Software virtuell feinabstimmen und versuchen, Probleme bei Timing und Leistungsaufnahme zu beheben. Die nächste Version der Software kann dann erneut Regressionstests unterzogen werden, um zu prüfen, ob die Änderungen funktioniert haben.

Siemens_Diagramm_Pave360_Fahrzeugdesignzyklus
Bild 3: Der digitale Zwilling von Pave360 passt sich an jede Phase des Fahrzeugdesignzyklus an. (Bild: Siemens)

Konzentration auf kritische Systeme

Dieser iterative Prozess kommt in der Welt der Extremleistung der Formel 1 bereits zum Einsatz. Formel-1-Autos werden vollständig in virtuellen Umgebungen entwickelt, sodass ein hohes Maß an Vertrauen in die Leistungsfähigkeit entsteht, bevor die Implementierung tatsächlich stattfindet. Es existieren verschiedene Fidelity-Modelle von F1-Automobilkomponenten und die Ingenieure wechseln die Modelle regelmäßig, um Simulationszeit, Datenerfassung und Genauigkeit auszugleichen. Die Simulation eines gesamten F1-Autos mit höchster Fidelity ist angesichts der Rechenleistungs-, Daten- und Zeitanforderungen nahezu unmöglich. Die F1-Ingenieure konzentrieren sich daher auf bestimmte Komponenten des Fahrzeugs mit hoher Fidelity im Detail, während sie den Rest des Autos mit einer niedrigeren Fidelity schneller simulieren. Wenn zum Beispiel die Aerodynamik im Fokus steht, ist es nicht notwendig, den Motor oder die Kraftstoffsysteme mit höchster Fidelity zu modellieren.

Dieser Philosophie bedient sich auch Pave360. So wird die Simulationseffizienz maximiert, da sich die Ingenieure auf die kritischsten Systeme mit höchster Fidelity konzentrieren können, während der Rest des Systems mit niedrigerer Fidelity läuft.

Im hybriden Modus lässt sich mit der Schaltmethode „Run Fast, Run Accurate“ die Simulationszeit optimieren. Run Fast führt nicht kritische Prozesse wie das Booten schnell auf virtuellen Modellen aus. Dann wird auf Run Accurate umgeschaltet, um kritische Software auszuführen und die Performance und Leistungsaufnahme an RTL-Hardware-Modellen detailliert zu messen. So verkürzt sich der Zeitaufwand für die Ausführung des gesamten Designs in RTL.

Backplane erstellt digitalen Zwilling als System-of-Systems

Bei einem digitalen Zwilling als System-of-Systems müssen Tools aus verschiedenen Quellen kombiniert werden, um die tatsächliche endgültige Systemleistung widerzuspiegeln und zu zeigen, was unter der Haube passiert. Mehrere potenzielle Probleme wie Interoperabilität, die Notwendigkeit einer synchronisierten deterministischen Kommunikation und wiederholbarer Ergebnisse, eine optimale Simulationszeit und die Anforderung der vollständigen Transparenz für die Fehlererkennung und Leistungsanalyse sind hierfür zu überwinden.

Siemens_Diagramm_Backplane-verbindet-Tools+Clients
Bild 4: Die Backplane verbindet Tools und Clients aus mehreren Quellen, um einen digitalen Zwilling als System-of-Systems zu erstellen. (Bild: Siemens)

Die Backplane schafft die erforderliche offene Umgebung, um eine System-of-Systems-Lösung aus mehreren Quellen von sowohl Siemens als auch Drittanbietern zu erstellen und einen komplexen digitalen Mixed-Fidelity-Zwilling zu ermöglichen. Dabei unterstützt die Backplane den TLM2.0-Standard, vereinfacht den Anschluss benutzerdefinierter Komponenten und verbindet mehrere Systeme miteinander, sodass sich die Interoperabilität erforschen und analysieren lässt. Entwickler können von der Interoperabilität über verschiedene Modelle hinweg profitieren, darunter:

• Mehrere ECU- oder SoC-basierende Systeme

• Mehrere System-Fidelitys von virtuellen TLM-Modellen über genaue RTL-Modelle (vHIL) bis hin zu realen HW-Systemen (HIL)

• Mehrere Protokolle von CAN, SPI, PWM bis Ethernet und sogar benutzerdefinierte Protokolle

• Mehrere Tool-Umgebungen, darunter traditionelle EDA-Suiten bis hin zu physikalischen und thermischen Modellierungen

Die Backplane synchronisiert die Simulationsereignisse, um sicherzustellen, dass die Systemzeit koordiniert ist. Auf diese Weise lassen sich Ereignisse, die über mehrere Domänen oder Systeme hinweg auftreten, analysieren, als ob sie in der realen Welt aufgetreten wären, mit voller Debug-Funktionalität wie Stopp, Pause und Aufzeichnung plus Zeitstempel für den Datenaustausch.

Die Kombination all dieser einzelnen Elemente macht den digitalen Zwilling mit Pave360 so nützlich. OEMs und andere Akteure der Automobilindustrie können sich vom traditionellen linearen Designfluss trennen und jetzt mit dem beginnen, was sie bereits haben, daraus einen digitalen Zwilling aufbauen und das Design vor dem Bau der Hardware iterieren. Der digitale Zwilling für die Automobilindustrie, der sich durch Portierung in die AWS-Cloud auf nahezu Echtzeit weiter beschleunigen lässt, ist somit ein virtuelles Auto, das dem gesamten Unternehmen als einzige Informationsquelle dient und sich an jede Fahrzeugaktualisierung anpasst.

Sie möchten gerne weiterlesen?