Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktionsabsicherung von elektronischen Fahrzeugsystemen; Dr. Rocco Deutschmann, tracetronic GmbH, Dresden
Semelhante a Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktionsabsicherung von elektronischen Fahrzeugsystemen; Dr. Rocco Deutschmann, tracetronic GmbH, Dresden
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungMarc Müller
Semelhante a Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktionsabsicherung von elektronischen Fahrzeugsystemen; Dr. Rocco Deutschmann, tracetronic GmbH, Dresden (20)
Technologieförderung in Sachsen; Christoph Zimmer‐Conrad, Referatsleiter im S...
Simulieren, Testen, Verifizieren - Alles oder Nichts? Systematische Funktionsabsicherung von elektronischen Fahrzeugsystemen; Dr. Rocco Deutschmann, tracetronic GmbH, Dresden
1. Simulieren, Testen, Verifizieren –
Alles oder Nichts?
Systematische Funktionsabsicherung von
elektronischen Fahrzeugsystemen
Innovationsforum „Software Saxony“
Software Saxony
Dr. Rocco Deutschmann
Dresden, 24.04.2009
engineering · software · test
2. Übersicht
Simulieren, Testen
Simulieren Testen, Verifizieren – Alles oder Nichts?
TraceTronic GmbH
Motivation
Simulation
Einsatzfelder
Techniken und Methoden im Absicherungsprozess
Testautomatisierung
Grenzen
Semiformale Verifikation
Zusammenfassung, Fazit
25.04.2009 2
3. Vorstellung TraceTronic GmbH
Über uns:
Als ehemalige Ausgründung aus der TU Dresden bildet die TraceTronic GmbH ein interdisziplinäres
Team aus Ingenieuren, Mathematikern und Informatikern zur Sicherung der Qualität Ihrer Produkte.
Kunden:
Leistungsspektrum/Know-How:
Softwarewerkzeuge und Dienstleistungen für die Validierung eingebetteter Systeme
Langjährige Erfahrung im Bereich des Tests und der Entwicklung automobiler Steuergerätesoftware
25.04.2009 3
6. Motivation
Gründe für Systematische Ab i h
G ü d fü S t ti h Absicherung
Kosten für Fehlerbehebung am Beispiel eines (!) schweren Software Fehlers
Quelle:
• deutscher Automobilzulieferer, Erhebung aus dem Jahr 2000
• method park, Safetronic 2004
25.04.2009 6
7. Motivation
Vorteile
V t il von Si l ti
Simulationstechniken b i T t
t h ik beim Testen
Kosten
Spät entdeckte Fehler sind teure Fehler
Prototypfahrzeuge sind sehr teuer
yp g
Sicherheitsgedanken
Simulationen zum Test von ABS ESP Crashs
ABS, ESP,
Prozesse mit hoher Zeitkonstante
Einfaches Reset physikalischer Prozesse möglich
f
z. B. „Motorabkühlung auf Knopfdruck“
Automatisierbarkeit
A ii b ki
Simulationen sind leichter steuerbar als echte Hardware
z. B. automatisiertes
z B „automatisiertes Abfahren eines virtuellen Testparcours“
Testparcours
25.04.2009 7
8. Motivation
Absicherung und Si l i
Ab i h d Simulation
Grundthese:
„Systematische und ökonomische Absicherung elektronischer
Fahrzeugsysteme ist ohne Simulation nicht durchführbar!“
Simulation als das zentrale Mittel zur systematischen
Funktionsabsicherung
Funktionstests durchgängig in simulierten oder
teilsimulierten Umgebungen
Systematisches , frühzeitiges Testen ohne Simulationen
nicht (mehr) möglich
25.04.2009 8
10. Simulation
Einsatzfelder
Ei f ld
Mechatronisches System
M ht i h S t
Entwicklung und Funktions-
Funktions
Auslegung absicherung
25.04.2009 10
11. Simulation
In der Entwicklung und Auslegung
Quelle: BMW
Crashsimulation
Quelle: www.cerfacs.fr
Simulation von Verbrennungsprozessen
Mechanische Modelle
Fahrwerksentwicklung
Quelle: Mercedes
Q
Verschleißsimulation
Strömungssimulation
Auslegung mechanischer Bauteile
• Aerodynamik
•Mt
Motorenentwicklung
t i kl
25.04.2009 11
12. Simulation
In der Funktionsabsicherung
F nktionsabsicher ng
Sensorrückmeldung
Sensormodelle
Streckenmodelle
Aktormodelle
Restbusmodell
Testobjekt
(Funktion, Steuergerät) Testumgebung
Aktoransteuerung
g
25.04.2009 12
14. Simulationen
Einordnung der Techniken
Was wird simuliert?
Umgebung
Funktionen
simuliert real
Rapidprototyping
ap dp ototyp g
Model-
Modellgetriebene Entwicklung Modelliert
in-the-Loop
Rapid
Funktion
Umgebung Software-in- prototyping
the-Loop
Model-in-the-Loop Implementiert
Software in the Loop
Software-in-the-Loop
Hardware-in-the-Loop
Hardware-
In Hardware
Prototyp
integriert in-the-Loop
p
25.04.2009 14
15. In-the-Loop
Simulationsumfang
Sim lations mfang
Primäres Ziel:
„Nur das nötigste Simulieren“
Simulation nicht zum Selbstzweck
Beispiel einer Umgebungssimulation für eine Motorsteuerungstest:
Viele Vereinfachungen:
- Konstanter Umgebungsdruck und T
K ttU b d k d Temperatur
t
- Feste Kurve für Motortemperatur
- Bremsunterdruck konstant
- Kennfelder für die notwendigen Aspekte des Verbrennungsprozesses
Behandlung komplexer physikalische Zusammenhänge:
- Verwendung echter Drosselklappen statt Simulation
25.04.2009 15
17. Testautomatisieurung und Simulation
Motivation
Testautomatisierung
Einmalige Testerstellung und automatisierte
Testdurchführung
Regressionstest für neue Softwarestände
Reproduzierbarkeit d E b i
R d i b k it der Ergebnisse
Auslastung der Simulationsumgebungen
Konzentration auf den kreativen Teil des Testprozesses
25.04.2009 17
18. Effizienter Einsatz von Simulation
Testautomatisierungsframework
Ttt ti i f k
Zentrale Kontrolle aller Werkzeuge
g
ECU-
ECU-TEST 4
Testautomatisierung
Simulationsplattform
Simulationsplattform
ECU Sonstiges
Simulationsplattform Bus
Diagnosewerkzeuge &
HiL-Plattformen SiL-Systeme Bus-Zugriff Spezialwerkzeuge
Applikationswerkzeug
A lik ti k
• dSPACE • M hW k
MathWorks •… •…
e
• ETAS MATLAB/
•…
• MicroNova Simulink
(National • National
Instruments) Instruments
LabVIEW
25.04.2009 18
20. Begrenzende Faktoren
Rechenkraft
R h k ft
Rechenkraft ist trotz stetiger Weiterentwicklung immer begrenzt
g g g
Quelle: Prof. Stefan Kurz, ETAS
GmbH,
Hardware-in-the-Loop Simulation
25.04.2009 20
21. Begrenzende Faktoren
Kosten-Nutzen-Verhältnis
Kosten Nutzen Verhältnis und Manpower
Simulation nicht zum Selbstzweck
Vollständige Simulation oft nicht wirtschaftlich
Durchschnittliche
Kosten pro
entdecktem Fehler
Kosten
Simulationskosten
Si l ti kt
abhängig u.a. von:
- Simulationstiefe
- Häufigen Anforderungsänderungen
Zeitpunkt in der Entwicklung
25.04.2009 21
22. Begrenzende Faktoren
Prozessintegration und Ak
P it ti d Akzeptanz
t
Prozessintegration
Simulationsmodell-Entwicklung ist Software-Entwicklung
Notwendige Prozessintegration:
g g
- Anforderungsmanagement
- Milestone-Koordinierung (das richtige Modell zur richtigen Zeit)
- Versionierung
Akzeptanz
p
Hoher Initialaufwand + generell bestehender Termindruck
Wechselwirkung: Modellnutzung <-> Modellqualität
- Modellqualität braucht Entwicklerinput und umgekehrt
Änderungen etablierter Strukturen oft schwierig
25.04.2009 22
23. Überwinden bestehender Grenzen
Positive Einflussfaktoren:
Stetig steigende Rechenleistung
Wiederverwendbarkeit und Erweiterbarkeit bestehender Modelle
Bessere Modellierungswerkzeuge
Breiterer Einsatz von Modellierungswerkzeugen
25.04.2009 23
25. Formale Verifikation
Scheitert aber schnell an
Komplexität
Akzeptanz
25.04.2009 25
26. Semiformale Verifikation
Klassische Testwelt Verifikationswelt
Formale Spezifikationen
SiL,HiL Testfahrten
Verzicht auf:
formale Funktions- und
Aufgezeichnete Messreihen
Umgebungsmodelle
„Traces“
T “
10100100110
TraceSys
y
010100101001000101001010010101
www.tracesys.de
25.04.2009 26
27. Semiformale Verifikation
Veranschaulichung
V h li h
Spezifikation (informal):
[…]
[ ] Der Klemme50 HighPegel muss mindestens 500ms anhalten
Klemme50-HighPegel
[…]
Spezifikation (in formaler Logik):
G{SignalChange}( “Signal==HIGH” -> G
[0,0.5](“Signal==HIGH”))
25.04.2009 27
29. Simulieren, Testen, Verifizieren
Alles d Nichts?
All oder Ni ht ?
Systematische Absicherung:
y g
Gelingt durch effektives und effizientes Zusammenspiel der einzelnen Techniken
Simulieren:
Im Absicherungsprozess vorrangig für
In-the-Loop-Umgebungssimulation
Testen:
Testautomatisierung garantiert hohe Wirtschaftlichkeit
eingesetzter In-the-Loop-Systeme
Wiederverwendbare Tests durch generische ECU-
ECU-TEST 4
Testfallbeschreibung
Semiformale Verifikation:
Analyse auf bereits anfallenden Daten (keine Zusatzkosten)
Gute Einbindung in Testautomatisierung
TraceTronic
TraceChecker
25.04.2009 29