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
TITEL
Gemischt virtuell / realer Prototyp am Antriebsstrangprüfstand
MOBILITÄTSINDUSTRIE
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.
Bilder: AVL
Von BERNHARD D. VALNION
Wolfgang Puntigam
D
ie 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 ECONOMIC ENGINEERING 2/2016
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 Entwick-
lungsprozess 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 33
M OBILITÄTSINDUSTRIE
OFFICE SIMULATION
XIL TEST
BATTERY TEST BED
E-MOTOR TEST BED
ENGINE TEST BED
CHASSIS DYNO
POWERTRAIN TEST BED
ROAD TEST Software-Lösungen von IODP. Data.CONNECT befindet sich noch im Prototypen-Stadium
Model Backbone Model.CONNECT Execution Backbone Data.CONNECT Process Backbone Automation Backbone 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 EchtzeitBedingungen 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
Simulation
Virtual Test Bed
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
Test Bed
Chassis Dyno
Quelle: AVL 2016
Data Backbone
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
Road Test Im Rahmen von LeadProjekten wird gemeinsam mit dem Kunden die Wiederverwendung von Simulationsmodellen für weiteres Frontloading genutzt
Virtual Test Bed
Test Bed
Chassis Dyno
Road Test
Quelle: AVL 2016
Simulation
34
ECONOMIC ENGINEERING 2/2016
F RON TL O A DI N G
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 CoSimulation“ 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. ECONOMIC ENGINEERING 2/2016
Bild: AVL
Typisches Hardware-in-theLoop-Szenario
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
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 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 35
F RONTLOADING
Bild: AVL
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 IODPAnsatz von AVL ermöglicht. IODP steht damit für die offene, herstellerunabhängige Integration der CAE- und Test-Infrastruktur ■
36
beim Kunden. Es kann als ManagementUmgebung (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
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. ECONOMIC ENGINEERING 2/2016
INTEGRATED AND OPEN PROD UC T DE V E L OP M E N T
„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 VModell 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 ADASKonzept 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 AnECONOMIC ENGINEERING 2/2016
forderungen 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
37
U 6iÀÕÃÌvÀii ÛiÀÌiÀÕ} vØÀ >i
À>Ìi U >iÀ âiÀÌvâiÀÌiÀ / >Ìi>ÕÃÌ>ÕÃV
U i>ÌÕÀiL>ÃiÀÌi ÛiÀÌiÀÕ} vØÀ Û Li>ÀLiÌL>Ài `ii U ÌiµÕ>ÌBÌ `ÕÀV
6
iViÀ
