SIMULATION UND TEST

Das Wirtschaftsfachmagazin für Ingenieure
Deutschland / Österreich € 14,90
Schweiz CHF 18,35
ISSN 1866-5004, 10811
April / Mai 2016 2-2016
www.economic-engineering.de
TRANSFORMATION
SIMULATION UND TEST
GESCHICKT KOMBINIEREN
AUTONOMES FAHREN
Hersteller im Spagat
zwischen strategischen
Partnerschaften und
Eigenentwicklung
WERKZEUGMASCHINEN
Mit Cloud Computing und
Industrie 4.0 Mehrwert in
der Zerspanungsbranche
schaffen
digitalPLANT: Trends in der Anlagenplanung ++ Vorschau Hannover Messe 2016 ++ Wie PLM und IoT zusammenpassen

T I T E L
Gemischt virtuell / realer Prototyp am
Antriebsstrangprüfstand

M O B I L I T Ä T S I N D U S T R I E
Durch Kombination von Simulation
und Test in eine
NEUE ÄRA
Bestehendes bewahren und
zugleich in ein völlig neues
Entwicklungszeitalter eintreten.
So lassen sich die Vorteile der
Co-Simulation auf Basis der
AVL Integrated and Open
Development Platform auf den
Punkt bringen. Die offene
Entwicklungsplattform
von AVL bringt endlich das
zusammen, was schon längst
zusammen gehört: physischer
Test und Virtual Prototyping.
Von BERNHARD D. VALNION
Wolfgang Puntigam
Die Automobilindustrie war bereits von
Beginn für die Sprengung bestehender
Grenzen und für faszinierende und innovative
neue Lösungen und Konzepte bekannt. Besonders
in der heutigen Zeit, in der es immer
schwerer wird, die hohe Komplexität in der
Fahrzeugentwicklung zu beherrschen, bedarf
es neuer transformaler Ansätze um vorhandenes
Wissen, Know-How und Kompetenz
aus einzelnen Entwicklungsabteilungen
zu bündeln.
Dieses vorhandene Wissen ist unwahrscheinlich
wertvoll und komplex. Es steckt in
Bilder: AVL
den Köpfen der Mitarbeiter, in Prozessen, in
Simulationsmodellen, liegt in Datenquellen,
in Beschreibungen von Anforderungen in
Testverfahren und natürlich in den Produkten
und seinen Bauteilen. Es ist von größter
Bedeutung dieses Wissen zu bewahren,
gleichzeitig verlangen aber steigende Entwicklungskosten,
Variantenkomplexität, oder
sinkende Time-to-Market danach, dass wir
neue Wege beschreiten. Die enorme Herausforderung,
die sich daraus ergibt ist es, bestehende
Expertise zu erhalten und zu nutzen
und gleichzeitig die Effizienz im Entwicklungsprozess
zu steigern und den Entwicklungsprozess
agiler zu gestalten. Genau hier
setzt die „Integrated and Open Development
Platform“ der AVL List GmbH mit Sitz in
Graz, Österreich, an. Die integrierte und offene
Entwicklungsplattform hat die Vision
virtuelle und reale Welt zu verbinden. Ein
wesentlicher Teil dieser Strategie ist es die
funktionsorientierte Entwicklung in den
frühen Phasen der Produktentstehung abzusichern.
Der reale Prototyp wird in den
frühen Phasen durch virtuelle Prototypen
ersetzt und im Laufe der Entwicklung zu
einem kombiniert virtuell/realen Prototypen
weiterentwickelt, der schließlich aus einer
Kombination von realen und virtuellen Komponenten
besteht.
Anstatt physische Prototypen und Prüfstandsversuche
zu nutzen, wird vermehrt versucht
über die Simulation von virtuellen
Prototypen und die gezielte Berechnung von
Systemeigenschaften (Stichwort „Systemsimulation“)
möglichst viele Design-Entscheidungen
möglichst früh herbeizuführen.
Hierbei kommen Methoden, wie multidisziplinäre
Simulation, „Model in the Loop“
(MiL), „Software in the Loop“ (SiL) und
„Hardware in the Loop“ (HiL) zum Einsatz.
Multidisziplinäre Simulation bedeutet in
ECONOMIC ENGINEERING 2/2016 33

MOBILITÄTSINDUSTRIE
OFFICE
SIMULATION
XIL
TEST
E-MOTOR
TEST BED
BATTERY
TEST BED
ENGINE
TEST BED
POWERTRAIN
TEST BED
CHASSIS
DYNO
ROAD
TEST
Software-Lösungen von
IODP. Data.CONNECT
befindet sich noch im
Prototypen-Stadium
Model Backbone
Execution Backbone
Data Backbone
Process Backbone
Automation Backbone
Model.CONNECT
Data.CONNECT
Quelle: AVL 2016
diesem Zusammenhang die modelltechnische
Abbildung mehrerer physikalischer Ansätze,
um Wechselwirkungen zu bewerten. Bei MiL
werden Simulationsmodelle und Kontrollfunktionen
integriert, um ein Design auf
einem hohen Abstraktionsniveau abzusichern.
Bei SiL liegen die Kontrollfunktionen bereits
in kompilierter Form vor. Bei HiL-Anwendungen
werden die Kontrollfunktionen
und physisch existierende Hardware, etwa
Steuerungsgeräte, ein ganzer Motor, oder ein
gesamter Antriebstrang unter Echtzeit-
Bedingungen getestet. Hier gilt das Motto:
Alles was nicht real vorhanden ist, wird durch
Simulationsmodelle ergänzt.
Ansätze zur Systemsimulation sind sehr anspruchsvoll,
da sie die vollständige Abbildung
aller Funktionen und Wechselwirkungen
eines Systems und dessen Interaktion
mit seiner Umgebung voraussetzen. In dem
hier beschriebenen Ansatz wird die Systemsimulation
um reale Komponenten ergänzt.
Dies bedeutet, dass im Rahmen der integrierten
und offenen Entwicklungs- umgebung
von AVL nicht mehr zwischen realen
und simulierten Komponenten unterschieden
wird. Es steht immer das System als Ganzes
im Vordergrund. Der Reifegrad des Systems
und all seiner virtuellen und realen Komponenten
wird durch die zu bewertenden Anforderungen
bestimmt.
Von Anfang an erfolgreich
Insbesondere bei der Entwicklung eines mechatronischen
Systems wird verlangt, dass die
disziplinübergreifenden Abhängigkeiten in
den frühen Entwicklungsphasen vollständig
virtuell abgebildet sind. Diese Forderung
wird auch dadurch bestärkt, dass zukünftige
Fahrzeugeigenschaften immer stärker durch
Software und Softwarefunktionen bestimmt
sein werden.
Ein Beispiel um dies zu verdeutlichen ist die
Aufgabe der Entwicklung von Betriebsstrategien
für Plug-in-Hybride oder rein elektrisch
betriebene Fahrzeuge. Die Festlegung
einer Betriebsstrategie hat wesentlichen Einfluss
auf die Dimensionierung der Komponenten
eines mechatronischen Systems.
Sportlich orientierte Strategien, die große und
dynamische Stromgradienten zulassen, erfordern
zum Beispiel größere Dimensionierungen
von elektrischen und thermischen
Komponenten. Werden hier die Komponenten
ohne Berücksichtigung der Betriebsstrategie
ausgelegt und dimensioniert, wird möglicherweise
später die Betriebsstrategie durch die
Hardware-Komponenten bestimmt und hat
gegebenenfalls Einschränkungen in den
gewünschten Fahrzeugeigenschaften zur
Folge. Schlussfolgernd muss hier bereits in
der frühen Entwicklungsphase das Wechselspiel
zwischen Komponenten und Betriebsstrategie
– die als Softwarefunktionen umgesetzt
werden – berücksichtigt werden. Hier
kann ein funktionaler virtueller Prototyp
helfen, die gewünschten Produkteigenschaften
optimal zu gestalten.
Zwar stehen entsprechende Simulationswerkzeuge
und Modellierungssprachen zur
Verfügung, jedoch wird aufgrund der Aufgabenteilung
— die einzelnen Abteilungen
bearbeiten unterschiedliche Domänen — mit
unterschiedlichen Werkzeugen gearbeitet.
Eine sukzessive Integration der (Sub-)Berechnungsmodelle
in eine einzige Simulationsumgebung
hat sich bisher als nicht
zielführend herausgestellt, da die Aufwände
dafür zu groß wären. Ein Grund ist darin zu
finden, dass die verwendeten Modelliersprachen
und Algorithmen erheblich an die
domänenspezifischen Berechnungsmodelle
angepasst sind und nicht einfach auf andere
Simulation Virtual Test Bed Test Bed Chassis Dyno Road Test
Im Rahmen von Lead-
Projekten wird gemeinsam
mit dem Kunden die
Wiederverwendung von
Simulationsmodellen für
weiteres Frontloading
genutzt
Simulation Virtual Test Bed Test Bed Chassis Dyno Road Test
Quelle: AVL 2016
34 ECONOMIC ENGINEERING 2/2016

FRONTLOADING
Anwendungen übertragen werden können.
Außerdem sollte man sich vor Augen führen,
dass in den domänenspezifischen Berechnungsmodellen
viel Know-How der einzelnen
Abteilungen steckt, das über Jahre
aufgebaut wurde, etabliert ist, die genutzten
Prozesse validiert und folglich mit
hoher Effizienz Anwendung findet. Daher
erweist sich Co-Simulation, oder auch
„gekoppelte Simulation“, immer öfter als
Lösungsweg, der einerseits die Schwierigkeiten
bei der Gesamtsystemmodellierung
überwindet und sich andererseits vorhandenes
Wissen, Modelle und Daten zu
Nutze macht.
Aus heterogen wird durchgängig –
im Dienste der Anwendung
Co-Simulation beschreibt nicht das Gesamtsystem
mit einer einzigen Modelliersprache,
sondern integriert Elemente aus verschiedenen
Domänen. So wird eine effiziente
Absicherung von Konfigurationen auch in
Kombination mit Softwarefunktionen möglich.
Mit der Kopplung von Hardware und
Simulation, also der Verschmelzung von
Simulation mit dem konventionellen Versuch,
wird im Bereich der „klassische Co-
Simulation“ ein neues Kapitel aufgeschlagen,
wobei die bisherige Arbeitsweise weiter bestehen
bleiben kann. Beispielsweise wird so
die Variantenentwicklung nachhaltig dabei
unterstützt, in den frühen Entwicklungsphasen
die richtige Auswahl an Fahrzeugkomponenten
für das jeweilige Fahrzeugprojekt
zu treffen. Indem Sub-Modelle
nach Bedarf gekoppelt werden, können automatisiert
verschiedenste Fahrzeugkomponententypen
kombiniert und bewertet
werden (Stichwort „Baukastensysteme“).
Eine Auslagerung dieser Variantenrechnungen
in die Cloud steigert zudem die Geschwindigkeit
der Bewertung erheblich.
Werden reale Komponenten in Verbindung
mit virtuellen verwendet (SiL, HiL, Prüfstand),
ist die Echtzeit-Simulation des
Gesamtsystems möglich. Das Ziel eines
solchen Ansatzes ist es nicht mehr zwischen
physisch existierenden und simulierten Komponenten
unterscheiden zu müssen und stets
das Gesamtsystem vor Augen zu haben.
Die Absicherung einer Konfiguration auf
Basis von Co-Simulation bietet auch deswegen
Vorteile, weil die Co-Simulationsanwender
nicht Experten in allen relevanten
Domänen sein können. So können sie sich
also weiterhin auf das eigene Arbeitsfeld beschränken.
Dies vereinfacht die Beherrschung der Komplexität
des Gesamtsystems und ermöglicht
Anwendern aus unterschiedlichen
Disziplinen und Bereichen, wie Simulation
und Versuch, die gleiche Sprache zu sprechen.
Modellbibliotheken steigern Effizienz
Ein CAE-Repository (Simulationsdatenbank)
zur Verwaltung von Modellen und
Simulationsergebnissen ist eine der Grundlagen
eines effizienten, funktionsgetriebenen
Entwicklungsprozesses. In der Pre-Processing-Phase
werden die Modelle, die von
den einzelnen Abteilungen oder Lieferanten
zur Verfügung gestellt werden, auf Gültigkeit
geprüft, mit Metadaten angereichert (zum
Beispiel Informationen zur verwendeten Version
des Simulationstools, Datenformats, der
Modellierungstiefe, Gültigkeitsbereich oder
des Modells) und in der Datenbank mit weiterer
Dokumentation gespeichert. Zu diesem
Zweck können spezielle Simulationsdatenmanagement-
oder PLM-Systeme verwendet
werden, die außerdem die Zugangs- und Versionskontrolle
übernehmen.
Eine andere essentielle Grundlage ist das Vorhandensein
von zweckmäßigen und qualitativ
hochwertigen Simulationsmodellen. Doch
woher kommen solche Simulationsmodelle?
In Zukunft werden verstärkt Komponentenprüfstände
zum Einsatz kommen, um hoch
qualitative Simulationsmodelle zu erzeugen.
Die Integration der einzelnen Komponenten
zu einem Gesamtsystem kann dabei rein
virtuell erfolgen, was eine Art „virtueller Prototypenbau“
erforderlich macht. Diese virtuellen
Prototypen müssen nach dem Vorbild
des physischen Prototypenbaus aufgebaut
werden. Es müssen hier „virtuelle Stücklisten“
geführt werden, die den virtuellen Prototypen
mit den verbauten simulierten Komponenten,
Softwarefunktionen und Applikationsständen
beschreiben. Auch hier gilt es,
vorhandenes Wissen aus der realen Welt in
der virtuellen Welt wiederzuverwenden.
Diese Vorgehensweise lässt sich auch auf
kombiniert virtuell/reale Prototypen übertragen.
Herausforderung: Durchgängige Wiederverwendung
von Simulationsmodellen
Das zuvor Beschriebene liest sich schlüssig
Bild: AVL
und ist zur Umsetzung in der Praxis auch
dringend zu empfehlen, wie das Beispiel
Start/Stopp-Automatik illustrieren soll:
Start/Stopp bedeutet nicht nur, den Motor anoder
abzustellen. Davon ist auch die
Innenraum-Klimatisierung betroffen (wer
will schon, dass an einem heißen Tag an der
Ampel die Klimaanlage abgeschaltet wird,
oder aber, dass man an kalten Wintertagen
frieren muss) oder auch das elektrische
Bordnetz, das bei zu vielen elektrischen Verbrauchern
Gefahr läuft zusammenzubrechen.
Der verstärkte Einzug von elektrischen und
elektrifizierten Komponenten sowie Regelungssystemen
verlangt, dass auf eine entsprechende
Stromversorgung noch mehr als
bisher geachtet werden muss. Mit anderen
Worten, die Funktionsabsicherung muss
Domänen-übergreifend stattfinden.
Typischerweise wird versucht, derartige Abhängigkeiten
manuell über Listen zu erfassen
oder es werden nur statische Abhängigkeiten
geprüft.
Dynamische Vorgängen und Wechselwirkungen
stellen hier eine große Herausforderung
dar, da einerseits die Simulationsmodelle
meist nicht kompatibel sind
(lag nie im Interesse der CAE-Systemanbieter)
und andererseits die notwendigen Integrationsstufen
der Prototypen erst sehr spät
in der Fahrzeugentstehung vorliegen. So ist
es auf diesem Wege sehr schwierig etwaige
Probleme rechtzeitig zu identifizieren. Selbst
kurz vor Serie kann es vorkommen, dass noch
nicht alle aktuellen Software- oder Kalibrationsstände
im Versuchsträger installiert
sind, wodurch Wechselwirkungen zwischen
einzelnen Systemen übersehen werden
können.
Integriert und offen zugleich
Typisches Hardware-in-the-
Loop-Szenario
Genau hier kommt die Integrated and Open
Development Platform (IODP) von AVL List
GmbH ins Spiel. Die Entwicklungsplattform
bietet folgende Vorteile:
■ Vernetzung bestehender Prozessschritte im
Entwicklungsablauf
ECONOMIC ENGINEERING 2/2016 35

FRONTLOADING
Mit der Verbindung von Simulation und Test
in eine neue Ära
■ Vernetzung von Simulation und Test
durchgängig über den gesamten Prozess
(Ausführen derselben Testspezifikation am
rein virtuellen, kombiniert virtuell-realen
Prototypen oder realen Prototypen)
■ Systemmodellierung und Ausführung, unabhängig
von Simulationsmodellen und
damit von CAE-Systemanbietern und ihren
Tools (Wiederverwendung von bestehenden
Modellen)
■ Eine einheitliche System-Konfiguration
und -parametrierung über verschiedene
Entwicklungsumgebungen hinweg (zum
Beispiel in der gekoppelten Simulation, bei
HiL, Prüfstandsversuchen oder Fahrversuchen)
■ Konsequente Ausrichtung auf die Applikation
und den Anwender
■ Management und Nachverfolgung der
Schnittstellen zwischen den einzelnen
Tools.
Eigentlich klingt das zu schön, um wahr zu
sein. Deshalb suchte die Redaktion das Gespräch
mit Wolfgang Puntigam, der sich bei
AVL dafür verantwortlich zeichnet, die beschriebene
Strategie umzusetzen. „Die OEMs
arbeiten normalerweise nach einer Baugruppen-orientierten
Vorgehensweise. So
wird der Antriebsstrang in Motor, Getriebe,
E-Maschinen, Batterie und weiteres
unterteilt. Der Vorteil der Integrated and Open
Development Platform (IODP) ist, dass sich
die funktionale Entwicklung weiter vorantreiben
lässt, weil über Bauteilgrenzen
hinweg gearbeitet werden kann und dabei bestehende
Best Practices weiterhin genutzt
werden können“, erklärt Puntigam als Einstieg.
Die Integration der einzelnen Domänen
und Prozesse werden hier durch den IODP-
Ansatz von AVL ermöglicht. IODP steht
damit für die offene, herstellerunabhängige
Integration der CAE- und Test-Infrastruktur
beim Kunden. Es kann als Management-
Umgebung (hierbei steht immer die Verbindung
zwischen Elementen im
Vordergrund) für insgesamt fünf Elementklassen
aufgefasst werden:
■ Modelle
■ Ausführumgebungen
■ Daten
■ Prozesse
■ Automatisierung.
Development Platform die Brücke
zwischen der virtuellen und realen
Welt schlagen
Bisher sind zwei IODP-Lösungen verfügbar:
die Model.CONNECT Software für die
Kopplung von Simulationsmodellen und die
Modellanbindung an die Ausführumgebung
(HiL, Prüfstände, Realtime-Systeme) und
Data.CONNECT für die Verknüpfung von
Datenbanken und Prozessen. „Unser Anspruch
ist, dass Modelle durchgängig verwendet
werden können, indem beispielsweise
Simulationsmodelle aus dem ‚Virtual
Engineering’ auch auf dem Prüfstand nutzbar
sind“, motiviert Puntigam AVLs integrierte,
offene Entwicklungsumgebung.
Model.CONNECT, das selbst modellfrei
und neutral ist, nutzt den FMI-Standard, um
die einzelnen Modelle, (beispielsweise von
IPG, Matlab Simulink, AVL Cruise,
Flowmaster, Modelica, Amesim, Kulilab,
AVL VSM, CarSim, Gamma Technologies,
um nur einige zu nennen) miteinander zu verbinden.
Es werden auch CAE-Systeme unterstützt,
die das Functional Mock-up Interface
(FMI) noch nicht unterstützen. In diesen
Fällen kommen Wrapper-Konzepte zur Anwendung,
die als eine Art Übersetzungsschicht
zwischen der jeweiligen spezifischen
Toolsprache und FMI gesehen werden
Bild: AVL
können. Des Weiteren bietet
Model.CONNECT die Möglichkeit,
Simulationsmodelle direkt an den Prüfstand
zu bringen um so eine Art „virtuell/realen
Prototypen“ aufzubauen.
Das Produkt Data.CONNECT befindet sich
derzeit noch in der Prototypenphase – dessen
Markteinführung darf aber mit Spannung
erwartet werden. Zum Hintergrund: Die
unterschiedlichen CAE-Anwendungen und
Testsysteme sind sehr spezifisch; nicht nur in
Hinsicht auf die Repräsentation der Modelle,
oder dem Betrieb von realen Komponenten,
sondern ebenso in Hinsicht auf Datenformate,
Navigationsmöglichkeiten, Zugriff auf Daten,
oder Darstellung der Ergebnisse (und KPIs).
Nicht weniger vielfältig sind die zugrunde
liegenden Datenbankstrukturen für die Verwaltung
von Simulationsmodellen, Testergebnisdaten,
Kalibrationsparameterdaten,
Stücklisten und Kostenkalkulationen.
Eine intelligente Verbindungsschicht, ein sogenannter
Data Connection Layer, wird diese
unterschiedlichen „Welten“ durch ein
virtuelles, zentralisiertes Link Repository verbinden,
so dass die Daten weiterhin physisch
in den ursprünglichen Datenbanken abgelegt
bleiben. Damit ist es zum Beispiel möglich
Simulationsdaten Tool- und Prüfstand-übergreifend
zu kalibrieren. So lassen sich Daten
aus unterschiedlichen Quellen in Beziehung
zueinander setzen. Beispielsweise kann so
eruiert werden, mit welchem Kalibrationsdatenstand
ein bestimmter Datensatz auf
einem Prüfstand erzeugt wurde, und in weiterer
Folge mit einer bestimmten Stückliste
und Kostenkalkulation verknüpft werden.
Diese Ergebnisse lassen sich mit bestimmten
Konfigurationen bei Fahrversuchen in Verbindung
setzen. Die Integrated and Open
Development Platform generiert hier dadurch
einen Mehrwert, dass bestehende Datensätze
miteinander vernetzt werden. Aufbauend auf
dieser Vernetzungsschicht können völlig neue
Applikationen zur Anwendung kommen,
welche noch nie dagewesene Einblicke in die
Entwicklung ermöglichen. Eine solche Applikation
ist beispielsweise die Nachverfolgung
von Abhängigkeiten über verschiedene
Datenquellen hinweg und das
Generieren von neuem Wissen und Erkenntnissen,
aufbauend auf vorhandenem, in proprietären
Quellen gespeichertem Wissen.
Optimierungsschleifen werden dadurch
wesentlich schneller und nachvollziehbarer
im Prozess möglich. Andere neue Anwendungsmöglichkeiten
können Prozesse
wesentlich beschleunigen, indem Ereignisse
in einer Quelle erkannt werden und dadurch
Aktionen in einer anderen Quelle und bei
einer anderen Anwendergruppe auslösen.
36 ECONOMIC ENGINEERING 2/2016

INTEGRATED AND OPEN PRODUCT DEVELOPMENT
„Dadurch können Aussagen schneller, fehlerfreier
und in wesentlich kürzerer Zeit
erfolgen“, sagt Puntigam mit Nachdruck.
Die Integrated and Open Development
Platform und das V-Modell
Das V-Modell, das häufig im Zusammenhang
mit CAE-Anwendungen diskutiert wird,
funktioniert laut Puntigam im Bereich der
Software-Entwicklung für mechatronische
Systeme hervorragend, kann jedoch nur mit
Einschränkung auf die funktionalen Entwicklung
übertragen werden, weil die verwendeten
Berechnungsmodelle in der frühen
Phase und reale mit simulierten Komponenten
nicht integriert werden können, um
sie mit den vorgegebenen Spezifikationen
tatsächlich auch vergleichen zu können. Puntigam
betont, dass ein funktionaler Entwicklungsprozess
nur durch den Bau von
virtuellen, und in weiterer Folge kombiniert
virtuell-realen Prototypen funktionieren
kann. Dennoch unterstützt IODP das V-
Modell durch seinen integrativen Ansatz, was
Entscheidungsprozesse enorm beschleunigt.
Damit lassen sich in der frühen Produktentwicklungsphase
viele „kleine Vs durchlaufen“,
wie es Puntigam ausdrückt. Die
Entwicklung fange damit an, die Attribute zu
definieren, indem das künftige Fahrzeug anhand
von Eigenschaften wie Verbrauch, Fahreindruck,
Steifigkeiten und Geräuscheindruck
(NVH) beschrieben wird.
„Über die damit verbundenen „kleinen Vs“
weiß der OEM, wo er tatsächlich bei der Entwicklung
steht“, sagt Puntigam. Der promovierte
Fahrzeugingenieur sieht darin auch
einen wesentlichen Enabler, dass agile Entwicklungsprozesse
in die Automobilentwicklung
Einzug halten können. Auf Fragen wie
zum Beispiel, für welche Effizienzmaßnahmen
man sich entscheiden soll, um seine
Ziele in Hinblick auf das Gesamtfahrzeug zu
erreichen (Gewicht versus Aerodynamik versus
Elektrifizierung versus anderer
Effizienzmaßnahmen), oder welches ADAS-
Konzept man umsetzen soll, müssen in Zukunft
rasch Antworten gefunden werden.
Auch die Tatsache, dass Software in Zukunft
der bestimmende Faktor für die Produkteigenschaften
sein wird, erfordert einen integrativen,
offenen Ansatz, um bereits in den
frühen Phasen der Entwicklung so viele Antworten
wie möglich in sehr kurzer Zeit geben
zu können.
Die Integrated and Open Development
Platform und Systems Engineering
Der funktionale Prototyp ist eine Sicht auf
das künftige Fahrzeug. Eine Ausprägung
davon ermöglicht das Systems Engineering,
bei dem die vom Kunden gewünschten Anforderungen
spezifiziert werden und auf
kleine Einheiten, bis auf die Ebene von Komponenten,
Software und Service aufgeteilt
werden. Dies bedingt, dass Attribute wie etwa
Fahrspaß, Effizienz, Verbrauch oder Total
Cost of Ownership modelliert und mit dem
System in Beziehung gesetzt werden können.
Hierzu hat man sich bei AVL bereits daran
gemacht, erste Software-Prototypen zu erstellen
und setzt die entwickelte Methode intern
wie auch in Kundenprojekten ein. Wenn
auch hier noch ein gutes Stück des Weges zu
gehen ist, ist bereits jetzt offensichtlich, dass
der IODP-Ansatz von AVL einen wertvollen
Beitrag zur Umsetzung von Systems
Engineering in Unternehmen leistet – ganz
nach dem Motto: „Connect existing elements
to enhance capabilities.“
Zum Schluss die Gretchen-Frage: Wie wird
die Integrated and Open Development
Platform verkauft? Wolfgang Puntigam sagt
dazu: „Software an sich ist nicht die Lösung,
sondern lediglich ein Enabler. Wichtig ist,
den Kunden dabei zu unterstützen, die Integrated
and Open Development Platform in
seinen eigenen Prozessen für spezifische Anwendungen
zu implementieren. Wir führen
dies über innovative Lead-Projekte durch.
Hier stehen immer die Entwicklungsaufgaben
des Kunden im Vordergrund – sei es, um ganz
neue innovative Problemstellungen zu lösen,
oder um Effizienzsteigerungen zu realisieren.
Zu Beginn geht es um die Analyse des aktuellen
Prozesses, also welche Entwicklungsaufgaben
in welcher Entwicklungsumgebung
mit welcher Toolkette umgesetzt werden
sollen. Im zweiten Schritt werden Potenziale
für Frontloading beziehungsweise Effizienzsteigerungen
identifiziert und priorisiert, um
die Entwicklungsaufgabe im Prozess weiter
nach vorne zu verlagern. Ein Schwerpunkt
dieser Projekte ist meist, Simulation und Test
in Form von Modellen, realen Komponenten
und Datenquellen miteinander zu verbinden.
Im dritten Schritt erfolgt die Umsetzung des
Frontloadings der Entwicklungsaufgabe gemeinsam
mit dem Kunden.“
Das Ziel der Projekte sei erst erreicht, wenn
die Ergebnisse in der neuen, früher im Prozess
angesiedelten Entwicklungsumgebung,
die gleichen Ergebnisse liefert wie zuvor in
einer späteren Phase. „Am Ende ist eine Methode
ja nur dann erfolgreich eingesetzt,
wenn die Kollegen im Engineering den Mehrwert
erkennen und einsetzen“, fasst Puntigam
zusammen.
INFOCORNER
Weitere Informationen zur integrierten und
offenen Entwicklungsplattform IODP von AVL
unter
www.avl.com/iodp
ECONOMIC ENGINEERING 2/2016 37