Modellbasierte Entwicklung eines Doppelkupplungsgetriebes ... · • Modul- und System-Tests in Simulink • Dauerlaufsimulationen mit Integer-Code Ziel für neue Projekte: + Tool-Landschaft

Modellbasierte Entwicklung eines Doppelkupplungsgetriebes mit Rapid-Prototyping und Software-in the-Loop Simulator

Holger Brückmann, Jochen Strenkert, Dr. Uwe Keller, EP/MAG, Daimler AGBenno Wiesner-Tittes, Dr. Andreas Junghanns, QTronic GmbH 01. Juli 2009

Folien zum Vortag beim VDI Kongress "Getriebe in Fahrzeugen", Friedrichshafen, 30.06.-01.07.2009

Folie 2Modellbasierte Entwicklung eines Doppelkupplungsgetriebes mit RPT und SiL, 01.07.09DCT_mit_RPT_und_SiL_VDI_Vortrag.ppt

Agenda

R üc kblic k und M otiva tion1

E ntw ic klung DC T2

R apid Prototyping3

Automatis iertes Tes ten4

C ode C overag e Ana lys e5

Aus blic k6


Agenda



R apid Prototyping3



Aus blic k6


Rückblick und MotivationSoftware-in the-Loop Simulatoren sind in der Daimler Getriebeentwicklung schon seit Jahren im Einsatz:

Rückblick und Motivation

7G -Tronic seit 1998

• Rapid-Prototyping mittels Backbone• Integer-Code-Simulation• System-Tests• Dauerlaufsimulationen mit Integer-

Code

- viele unterschiedliche Tools - große Teile in-house entwickelt

Autotronic seit 1998

• Rapid-Prototyping mittels A-Muster• Simulink-SiL mit Float-Code• Modul- und System-Tests in Simulink• Dauerlaufsimulationen mit Integer-

Code

Ziel für neue Projekte: + Tool-Landschaft vereinheitlichen + Verwendung von „Standardsoftware“ + Minimierung der in-house-Anpassungen

Erstanwendung der neuen Lösung im Doppelkupplungsgetriebeprojekt (DCT)


Agenda



R apid Prototyping3



Aus blic k6


Funktionsbaukasten

• Funktionssoftware mit ca. 150 Modulen• entwickelt mit MatLab/Simulink/Stateflow• und dSpace TargetLink mit DataDictionary• 100% Autocode

Entwicklung DCT

Ziel des SiL:• integrierte Toolkette

•Vereinen von Software-in the-loop und Rapid Prototyping

•sowie Softwareabsicherung und das automatisierte Testen


dSpace Code Generator

Ablauf der Software-Erstellung

Entwicklung DCT

150 Module aus MatLab/Simulink

Microsoft Visual Studio Compiler

C-Code

Cross Compiler

Object Code fürInfineon TriCore

• Programmstand für Steuergerät

• A2L Datenbasis

• Objects für alle 150 Module

• Programmstand für SiL• A2L Datenbasis• DLL für Simulation• Objects für alle 150

Module

Object Code für x86

V orteile:•Kein Anpassen der Simulink-Module nötig

• Identischer Code zwischen Steuergerät

und SiL (Integer-Arithmetik)

•Für S iL und S teuerg erä t w erden die

g leic hen Quellen benutzt


BetriebssystemRahmensoftware

Funktionssoftware

Funktionssoftware

Aufbau der Software im Steuergerät

Entwicklung DCT

B etriebs s ys tem

• Treiber

• Speicher

• …

Aufbau der Software im SiL

R ahmens oftw are

• EEPROM

• CAN Daten

• …

Funktions s oftw are

• 150 Module

Wrapper

Wrapper

+ Vollständige

Funktionssoftware

+ CAN Daten

+ EEPROM

- Kein Fehlerspeicher

- Keine Diagnose

Der Wrapper bildet die Funktionen der Rahmensoftware nach.

Viele dieser Funktionen geben dann nur default-Werte zurück.


Entwicklung DCT

Funktionsentwickler ändert sein Modul

Erstellt Code

Kompiliert sein Modul mit Microsoft Visual Studio

Holt sich die anderen 149 Module als Objects

Funktionssoftware mit 150 Objects

WrapperA2L

DLL

Ergebnis:• Programmstand als DLL mit der

vollständigen Funktionssoftware• A2L Datenbasis mit den Adressen

der DLL• Erstellung geschieht innerhalb von

Minuten, da nur ein Modul ausgetauscht wurde

• Jeder Entwickler hat die Möglichkeit sein Modul sofort zu testen

• Kein Quellcode der anderen Module ist nötig zum Erstellen des Standes

Linkt mit Microsoft Visual Studio

Fertige SiL Software


Simulationsaufbau

Entwicklung DCT

Tools:• Simulieren: Silver (QTronic)

• Messen: Canape (Vector)

• Debugging: Visual Studio (Microsoft)

• Automatisiertes Testen: TestWeaver (QTronic)

• Code Coverage: Testwell CTC++ (Verifysoft)


Simulationsaufbau

Entwicklung DCT

S ilver C ore

C onfig urable G U I

Graphisches User-Interface (GUI) mit Silver:• Interaktion des Fahrers/Users

•Gaspedal, Bremse, Zündung, Temperatur, …

können variiert werden

• Alle Ein- und Ausgangssignale können direkt

manipuliert werden







Simulationsaufbau

Entwicklung DCT

S ilver C ore

Hardware-Modell

Dymola DLL


Hardware-DLL:• Simuliert Fahrzeug, Motor und Getriebe

• Erstellt in-house mit DymolaTools:

• Simulieren: Silver (QTronic)






Simulationsaufbau

Entwicklung DCT

S ilver C ore

X C P

Canape

via TCP/IP


XCP mit Canape:• XCP messen via TCP/IP über Gigabit-Ethernet

• Keine Bandbreitenbegrenzung wie bei CAN

• Online verstellen der Parameter ist möglich

Hardware-Modell

Dymola DLL







Simulationsaufbau

Entwicklung DCT

S ilver C ore

X C P

Canape

via TCP/IP

Funktionss oftw are

Wrapper-DLL


Hardware-Modell

Dymola DLL

Funktionssoftware mit Wrapper-DLL:

• Vollständige Funktionssoftware (alle 150 Module)

•Nachgebildete Rahmensoftware im WrapperTools:• Simulieren: Silver (QTronic)






Simulationsaufbau

Entwicklung DCT

S ilver C ore

X C P

Canape

via TCP/IP

Funktionss oftw are

Wrapper-DLL A 2LPDB

PARDC MH EX

R eader Writer


Hardware-Modell

Dymola DLL

A2L und Parameter:• A2L mit angepassten Adressen der DLL

• Vollständiger und aktueller Parametersatz wird beim

Öffnen der Simulationsumgebung geladenTools:







Simulationsaufbau

Entwicklung DCT

S ilver C ore

X C P

Canape

via TCP/IP

Funktionss oftw are

Wrapper-DLL A 2LPDB

PARDC MH EX

R eader Writer


Python

Tests und AdaptionTes t & A daptation

Hardware-Modell

Dymola DLL

Scripting mit Python:• Ist ein bestimmter Ablauf immer gleich, kann

dieser mit einem Script realisiert werden (z. B.

Motorstart, Adaptionslauf…)Tools:







Simulationsaufbau

Entwicklung DCT

S ilver C ore

X C P

Canape

via TCP/IP

Funktionss oftw are

Wrapper-DLL A 2LPDB

PARDC MH EX

R eader Writer

Debugging

V is ua l S tudio

attac h


Python

Tests und AdaptionTes t & A daptation

Hardware-Modell

Dymola DLL

Debugging mit Visual Studio:• Simulation kann zu jeder Zeit angehalten werden

•Der Visual Studio Debugger wird an den Silver

Prozess angehängtTools:







Vorteile SiL

Zusammenfassung

• Das Finden von Fehlern wird beschleunigt, da jeder Funktionsentwickler sein Modul selbst im Verbund testen kann

• Messen wie im Fahrzeug (dieselbe Messkonfiguration)• Fehlersimulation

• Sensorausfälle, Gangspringer, Übertemperatur• Fehlerstrategien und Schutzfunktionen können leichter

getestet werden

• EEPROM und Adaptionswerte• Scripting mit Python

• Adaptionsalgorithmen können gezielt angestoßen werden

• Debbuging• Jeder Funktionsentwickler kann sein Modul debuggen


Agenda



R apid Prototyping3



Aus blic k6


Rapid Prototyping

Rapid Prototyping

S ilver C ore

Funktionss oftw are

Wrapper-DLL

1 Simulationsumgebung Silver läuft auf dem Laptop: - Ohne graphisches User-Interface - Ohne Hardwaremodell - Mit Canape und XCP via TCP/IP - Wrapper-DLL mit Funktionssoftware


CancardXL

Rapid Prototyping

Rapid Prototyping

S ilver C ore

Funktionss oftw are

Wrapper-DLL

Treiber-Schnittstelle

2 Wrapper-DLL nimmt Verbindung mit CancardXL über die Treiber-Schnittstelle auf


CancardXL

Rapid Prototyping

Rapid Prototyping

S ilver C ore

Funktionss oftw are

Wrapper-DLL

CAN

3 CancardXL nimmt Verbindung mit Steuergerät im Fahrzeug via CAN auf


CancardXL

Rapid Prototyping

Rapid Prototyping

S ilver C ore

Funktionss oftw are

Wrapper-DLL

CAN


4 Steuergerät im Fahrzeug wird in Bypass Modus versetzt, in welchem es Daten von außen annimmt und interne Werte überschreibt


CancardXL

Rapid Prototyping

Rapid Prototyping

S ilver C ore

Funktionss oftw are

Wrapper-DLL

CAN


5 Steuergerät im Fahrzeug gibt über CAN die gemessenen Sensorwerte zurück


CancardXL

Rapid Prototyping

Rapid Prototyping

S ilver C ore

Funktionss oftw are

Wrapper-DLL X C P

Canape

via TCP/IP

CAN


6 Canape misst sowohl internen Signale der Funktionssoftware über die XCP-Koppelung also auch die Steuergeräte-Signale via CancardXL und CAN,


Agenda



R apid Prototyping3



Aus blic k6


Ziele des automatisierten Testens

Automatisiertes Testen

- Höhere Qualität und bessere Absicherung der Software bei der Inbetriebnahme im Fahrzeug - Überwachung der Applikation parallel zu Prüfständen und Dauerläufen

Erreicht wird dies durch- viele intelligent generierte Test-Szenarien- Regressionstests mit Dauerlaufsimulationen und Szenariodatenbanken

Welche Fehler sollen gefunden werden?- Runtime exceptions- Division by 0- Out of bound- Access violation- Infinit loop

Grenzwertverletzungen- Selbstspezifizierte Kriterien- Überhitzung von Bauteilen- Schaltzeiten


Automatisiertes Testen mit TestWeaver


TestWeaver Szenario SilverDatenbank

a b d

1 Einmalige Vorbereitung

• Interfacegrößen, Stellgrößen, Reports und Überwachungs-Kriterien definieren

• Python-Skript für Motorstart erstellen





a b d

2 Anbindung an Silver-Simulationsumgebung• Es können die gleichen DLLs für

Hardwaremodell und Funktionssoftware/Wrapper-DLL benutzt werden

• TestWeaver stößt bei der Simulation Silver an





a b d

3 Testen!

c falls Szenario auffällig oder kritisch ist, versucht TestWeaver dort anzusetzen und Variationen dieses Szenarios zu erzeugen um die Software auszuspielen und bewusst Fehler zu provozieren

a TestWeaver generiert Szenario

d Szenarien werden in Datenbank abgelegt

b Silver fährt das Szenario im Passiv-Mode nach

e aus den Szenarien werden Reports generiert




a b d

Vorteile:•Nahtlose Integration in die Toolkette

• automatische Testfall- bzw.

Szenariengenerierung

• Szenarien immer zu 100% reproduzierbar

•Debuggen der Szenarien möglich

• Reports können im Nachhinein noch angepasst,

verändert oder erstellt werden




Prüfen von Softwareständen

•mindestens 10000 Szenarien

• Reports und auffällige Szenarien analysieren

• kritische Szenarien in Szenariendatenbank

importieren


Agenda



R apid Prototyping3



Aus blic k6


Code Coverage Analyse mit Testwell CTC++

• In TestWeaver eingebunden• Separater Report in TestWeaver• Abdeckungsanalyse für

• Ganzes Projekt• C-Dateien• Funktionen• Codepfade

Code Coverage


Agenda


Entw ic klung DC T2

R apid Prototyping3



Aus blic k6


Ausblick

Ausblick

• Softwarequalität weiter verbessern• Codeabdeckung erhöhen• Dauerlaufsimulationen als Regressionstests• Verteiltes Simulieren, Softwarestände werden auf

mehreren Rechnern gleichzeitig simuliert• verschiedene Varianten miteinander vergleichen• Fehlerdatenbank mit kritischen Szenarien ausbauen


Vielen Dank für Ihre Aufmerksamkeit!

Documents

Modellbasierte Entwicklung eines Doppelkupplungsgetriebes ... · • Modul- und System-Tests in Simulink • Dauerlaufsimulationen mit Integer-Code Ziel für neue Projekte: + Tool-Landschaft