vda empfehlung zur umsetzung einer bremskraftverstärker ...€¦ · vda-empfehlungen...
TRANSCRIPT
VDA Empfehlung zur Umsetzung einer Kommunikationsschnittstelle zwischen einem elektrischen
Bremskraftverstärker und einem ESC-Steuergerät
360
Mit der vorliegenden unverbindlichen VDA-Empfehlung werden folgende Zielsetzungen verbunden: Definition und Erläuterung einer Kommunikationsschnittstelle zwischen einem elektrischen Bremskraftverstärker und einem ESC-Steuergerät, um die Kooperation unterschiedlicher Zulieferer (OES) für den elektrischen Bremskraftverstärker (eBooster) und das ESC zu vereinfachen. Der Anwendungsbereich der vorliegenden Empfehlung ist wie folgt definiert: Gemäß Anwendungsbereich der ECE-R13H: Fahrzeugkategorien M1 (Fahrzeuge zur Personenbeförderung) und N1 (Fahrzeuge zur Güterbeförderung) mit einer zulässigen Gesamtmasse bis zu 3,5 Tonnen.
Version 1.0 vom Dezember 2016
Projektgruppe VDA Schnittstelle eBooster ESC
Herausgeber: Verband der Automobilindustrie Copyright
Behrenstrasse 35 Nachdruck und jede sonstige Form 10117 Berlin der Vervielfältigung ist nur mit Telefon 030/897842-0 Angabe der Quelle gestattet.
Telefax 030/897842-606 Internet: www.vda.de
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 2
Copyright: VDA
Haftungsausschluss
Die VDA-Empfehlungen sind frei verfügbar und haben lediglich empfehlenden Charakter. VDA-Empfehlungen bieten unternehmensübergreifende Orientierung, berücksichtigen jedoch keine fallspezifischen Rahmenbedingungen. Sie bedürfen der weiterführenden Auslegung und Interpretation prozessbeteiligter Geschäftspartner.
VDA-Empfehlungen berücksichtigen den zum Zeitpunkt der jeweiligen Ausgabe herrschenden Standardisierungsgrad und Stand der Technik. Durch das Anwenden der VDA-Empfehlungen entzieht sich niemand der Verantwortung für sein eigenes Handeln. Jeder handelt insoweit auf eigene Gefahr. Eine Haftung des VDA und derjenigen, die an den VDA-Empfehlungen beteiligt sind, ist ausgeschlossen.
Nutzer werden gebeten, auf Mängel und ausstehende Abstimmungsinhalte hinzuweisen, und sich über den VDA am fortlaufenden Standardisierungsprozess zu beteiligen.
Die Verwender der Empfehlung werden gebeten, den VDA auf eventuelle Schutzrechtsprobleme hinzuweisen.
Der VDA ist auf Schutzrechte aufmerksam gemacht worden, die Implementierungen der Empfehlung betreffen können. Von den Schutzrechtsinhabern verlangt der VDA eine Erklärung, dass sie bereit sind, Verwendern eine Lizenz für relevante Schutzrechte nach FRAND-Bedingungen zu gewähren, sofern der an dieser Lizenz interessierte Verwender seinerseits bereit ist, gegebenenfalls seine von dieser Empfehlung berührten Schutzrechte ebenfalls zu FRAND-Bedingungen zu lizenzieren. Die Schutzrechtsinhaber, die dem VDA eine solche Erklärung abgegeben haben, können beim VDA erfragt werden.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 3
Copyright: VDA
Inhaltsverzeichnis
Haftungsausschluss ................................................................................................. 2
Inhaltsverzeichnis ..................................................................................................... 3
1 Einleitung .............................................................................................................. 9
1.1 Bremssystemdefinition (Festlegung der Systemgrenzen) ............................. 9
1.2 Inhalt des Dokuments .................................................................................... 9
2 Systembeschreibung .......................................................................................... 11
2.1 Beschreibung der Systemkomponenten ...................................................... 11
2.2 Konzepte im Systemverbund eBooster + ESC ............................................ 14
2.2.1 Degradationskonzept .............................................................................. 14
2.2.2 HMI-Konzept ........................................................................................... 15
2.2.3 Konzept zur Bremslichtansteuerung ....................................................... 21
2.2.4 Konzept Fahrerbremswunscherkennung ................................................ 23
2.2.5 Konzept externer Bremswunsch über eBooster ...................................... 24
2.2.6 OBD Konzept .......................................................................................... 25
2.2.7 Wakeup/ Postrun Konzept ...................................................................... 26
2.2.7.1 Wakeup ......................................................................................... 26
2.2.7.2 Postrun.......................................................................................... 27
2.2.8 Unter- / Überspannungskonzept ............................................................. 28
2.2.8.1 Gesonderte Betrachtung für die Bremskraftverstärkung ............... 29
2.2.8.2 Motorstart ...................................................................................... 29
2.2.8.3 Motorstart bei Start/Stopp-Funktionalität ....................................... 29
2.2.8.4 Elektrische Schnittstelle ................................................................ 30
2.2.9 Diagnosekonzept .................................................................................... 31
2.2.10 Bauteilschutz im eBooster ...................................................................... 32
2.3 Funktionsaufteilung zwischen eBooster + ESC ........................................... 34
2.4 Abgeleitete Anforderungen an die Teilsysteme ........................................... 36
2.4.1 Anforderungen an ESC ........................................................................... 36
2.4.2 Anforderungen an eBooster .................................................................... 37
2.4.3 Anforderungen an HMI............................................................................ 38
2.4.4 Anforderungen an den Generator ........................................................... 39
2.5 Hinweise zur Systemspezifikation ............................................................... 39
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 4
Copyright: VDA
2.5.1 Gesamtbremssystemauslegung ............................................................. 39
2.5.2 Lastspezifikationen ................................................................................. 40
2.5.2.1 Auswirkungen auf ESC Standardfunktionen ................................. 40
2.5.2.2 eBooster Lastwechsel ................................................................... 40
2.5.2.3 Lastherleitung Regeneratives Bremssystem ................................. 40
3 Grundlegende Funktionsarchitektur ................................................................... 41
3.1 Definition einer Funktionalen Architektur ..................................................... 41
3.2 Schnittstellendefinition ................................................................................. 45
3.2.1 Basisschnittstelle: Darstellung der Grundfunktionalität ........................... 46
3.2.1.1 Übersicht Schnittstellenbeschreibung ........................................... 47
3.2.1.2 Signal eBESCCompatibilityIndex .................................................. 49
3.2.1.3 Signal HbcRequest ....................................................................... 50
3.2.1.4 Signal eBDiagActive ..................................................................... 51
3.2.1.5 Signal BrakePedalApplied ............................................................. 52
3.2.1.6 Signal BrakePedalApplied_Q ........................................................ 53
3.2.1.7 Signal pRunout ............................................................................. 53
3.2.1.8 Signal pRunout_Q ......................................................................... 54
3.2.1.9 Signal sOutputRodDriver .............................................................. 55
3.2.1.10 Signal sOutputRodDriver_Q .......................................................... 56
3.2.1.11 Signal VehicleSpeed ..................................................................... 57
3.2.1.12 Signal VehicleSpeed_Q ................................................................ 58
3.2.1.13 Signal pMC1 ................................................................................. 58
3.2.1.14 Signal pMC1_Q ............................................................................. 59
3.2.1.15 Signal AbsActive ........................................................................... 60
3.2.1.16 Signal pEstMax ............................................................................. 61
3.2.2 Rekuperationsschnittstelle ...................................................................... 62
3.2.2.1 Übersicht Schnittstellenbeschreibung ........................................... 63
3.2.2.2 Signal pForceBlendingPotential .................................................... 64
3.2.2.3 Signal pForceBlendingPotential_Q ............................................... 64
3.2.2.4 Signal sOutputRodAct ................................................................... 65
3.2.2.5 Signal sOutputRodAct_Q .............................................................. 66
3.2.2.6 Signal pMcVirtual .......................................................................... 67
3.2.2.7 Signal pMcVirtual_Q ..................................................................... 67
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 5
Copyright: VDA
3.2.2.8 Signal pForceBlendingMC ............................................................ 68
3.2.2.9 Signal pForceBlendingMC_Q ........................................................ 69
3.2.2.10 Signal ForceBlendingActive .......................................................... 70
3.2.3 Schnittstelle für Externen Bremswunsch................................................. 71
3.2.3.1 Übersicht Schnittstellenbeschreibung ........................................... 72
3.2.3.2 Signal ExtReqPrio ......................................................................... 73
3.2.3.3 Signal ExtReqStatus ..................................................................... 73
3.2.3.4 Signal qTargetExternal.................................................................. 74
3.2.3.5 Signal qTargetExternal_Q ............................................................. 75
3.2.4 Schnittstelle zur Ansteuerung der Warnlampen (HMI) ............................ 76
3.2.4.1 Übersicht Schnittstellenbeschreibung ........................................... 76
3.2.4.2 eB_ HMI_WarningOn .................................................................... 77
3.2.4.3 ESC_HMI_WarningOn .................................................................. 78
3.2.5 Schnittstelle zur Ansteuerung des Bremslichts (BLA) ............................. 79
3.2.5.1 Übersicht Schnittstellenbeschreibung ........................................... 79
3.2.5.2 eB_BLA ......................................................................................... 80
3.2.5.3 ESC_BLA ...................................................................................... 81
3.2.6 Schnittstelle zur Ansteuerung des Generators ........................................ 82
3.2.6.1 Übersicht Schnittstellenbeschreibung ........................................... 83
3.2.6.2 RecuBrakeTorqueRequest ............................................................ 84
3.2.6.3 RecuBrakeTorqueRequest_Q ....................................................... 85
3.2.6.4 RecuBrakeTorqueCap .................................................................. 85
3.2.6.5 RecuBrakeTorqueCap_Q .............................................................. 87
3.2.6.6 RecuBrakeTorqueAct .................................................................... 87
3.2.6.7 RecuBrakeTorqueAct_Q ............................................................... 88
3.2.6.8 RecuBrakeTorqueDrag ................................................................. 89
3.2.6.9 RecuBrakeTorqueDrag_Q ............................................................ 89
3.2.7 Handhabung von Signal-Qualifiers ......................................................... 91
4 Funktionale Sicherheit ........................................................................................ 93
4.1 Definition des Umfangs eines Bremsregelsystems ..................................... 93
4.1.1 Motivation der Trennung des Bremsregelsystems in zwei Items ............ 93
4.1.2 Item Definition und Schnittstellen zu anderen Items ............................... 95
4.2 Gefährdungen und Risiken des Bremsregelsystems................................... 96
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 6
Copyright: VDA
4.2.1 Zu geringes Bremsmoment während der Fahrt (max. ASIL D) ............... 97
4.2.2 Ungewolltes oder zu hohes Bremsmoment während der Fahrt (max. ASIL D) 98
4.2.3 Zu geringes Bremsmoment im Stillstand bei Fahreranwesenheit (QM) .. 99
4.2.4 Zu hohes Bremsmoment im Stillstand (QM) ........................................... 99
4.2.5 Keine Ansteuerung des Bremslichts (max. ASIL B) ................................ 99
4.3 Funktionales Sicherheitskonzept ............................................................... 100
4.3.1 Sicherheitsziel G1.1: Vermeide ein zu geringes Bremsmoment bei Fahrerbremswunsch ......................................................................................... 100
4.3.1.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G1.1 .. 101
4.3.2 Sicherheitsziel G1.2: Vermeide ein zu geringes Bremsmoment bei Externem Bremswunsch ................................................................................... 103
4.3.2.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G1.2 .. 104
4.3.3 Sicherheitsziel G1.3: Vermeide ein zu geringes (symmetrisches) Bremsmoment in Regelsituation ESC, ABS, oder TCS (Regelaufgabe kann nicht mehr wahrgenommen werden). ........................................................................ 105
4.3.3.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G1.3 .. 106
4.3.4 Sicherheitsziel G2.1 Vermeide ein ungewolltes (symmetrisches oder asymmetrisches) Bremsmoment ohne Fahrerbremswunsch, das zur Instabilität des Fahrzeugs führt.......................................................................................... 108
4.3.4.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G2.1 . 108
4.3.5 Sicherheitsziel G2.2 Vermeide ein ungewolltes symmetrisches Bremsmoment ohne Fahrerbremswunsch unter Beibehaltung der Stabilität des Fahrzeugs (rein longitudinal) ............................................................................ 110
4.3.6 Sicherheitsziel G2.3: Vermeide ein zu hohes (symmetrisches) Bremsmoment in Regelsituation ESC, ABS, oder TCS (Regelaufgabe kann nicht mehr wahrgenommen werden). ........................................................................ 111
4.3.6.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G2.3 . 111
4.3.7 Sicherheitsziel G2.4: Vermeide ein zu hohes symmetrisches Bremsmoment bei Fahrerbremswunsch unter Beibehaltung der Stabilität des Fahrzeugs (“Überbremsen”). ............................................................................ 113
4.3.7.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G2.4 .. 113
4.3.8 Sicherheitsziel G2.5: Vermeide ein zu hohes symmetrisches Bremsmoment bei Externem Bremswunsch unter Beibehaltung der Stabilität des Fahrzeugs (“Überbremsen”). ............................................................................ 115
4.3.8.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G2.5 .. 115
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 7
Copyright: VDA
4.3.9 Sicherheitsziel G3.1:Vermeide ein zu geringes Bremsmoment im Stillstand bei Fahreranwesenheit (mit Möglichkeit Bremsdruck zu erhöhen) ................... 117
4.3.10 Sicherheitsziel G3.2:Vermeide ein zu geringes Bremsmoment im Stillstand bei Fahreranwesenheit (ohne Möglichkeit Bremsdruck zu erhöhen) -Fahrzeug rollt weg 117
4.3.11 Sicherheitsziel G4.1:Vermeide ein zu hohes Bremsmoment im Stillstand, durch Fahrer nicht über Gaspedal zu kontrollieren (Bremsmoment > mögliches Antriebsmoment) .............................................................................................. 117
4.3.12 Sicherheitsziel G5.1:Vermeide eine fehlende Ansteuerung des Bremslichts bei Externem Bremswunsch oder Fahrerbremsung ...................... 118
4.3.12.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G5.1 .. 118
4.4 ASIL Einstufung relevanter Signale und Teilfunktionen ............................. 120
4.5 Vorschlag zur Absicherung der Kommunikation auf dem Netzwerk .......... 124
5 Sicherheitsnachweise ....................................................................................... 126
5.1 FTA – Verantwortlichkeiten und Schnittstellenabstimmung ....................... 126
5.2 FMEA - Verantwortlichkeiten und Schnittstellenabstimmung .................... 126
5.2.1 Aufbau der FMEA Struktur .................................................................... 127
5.2.2 Umgang mit Informationen an der Schnittstelle zwischen den FMEAs . 128
5.3 „Metrikberechnungen“ gemäß ISO 26262 ................................................. 130
5.3.1 Hardware-Architekturmetriken gemäß ISO26262-5 Band 8 .................. 130
5.3.2 Bewertung von Sicherheitszielverletzungen durch zufällige Hardwarefehler gemäß ISO26262-5 Band 9 .................................................... 130
6 Testkonzept ...................................................................................................... 131
6.1 Indikator-Test ............................................................................................ 131
6.2 Test Strategie für die Verifikation und Validierung .................................... 132
6.2.1 Verifikation ............................................................................................ 133
6.2.2 Validierung ............................................................................................ 133
6.2.3 Teststufen ............................................................................................. 133
6.2.4 Allgemeine Erläuterungen und Festlegungen zur Teststrategie ........... 133
6.2.5 Voraussetzungen für die Komponenten und Systemtests .................... 133
6.2.6 Testaktivitäten ....................................................................................... 134
6.2.6.1 Testaktivitäten des eBooster OES .............................................. 134
6.2.6.2 Testaktivitäten des ESC OES ..................................................... 135
6.2.6.3 Testaktivitäten des OEM ............................................................. 136
6.2.6.4 Freigabeempfehlung des Gesamtlieferumfangs ......................... 136
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 8
Copyright: VDA
6.3 Test Stellgenauigkeit eBooster .................................................................. 137
6.3.1 Definition der Testsequenz und Testumgebung ................................... 137
6.3.2 Bewertung Stellerverhalten ................................................................... 139
7 Normative Referenzen...................................................................................... 140
8 Glossar ............................................................................................................. 141
9 Anhang ............................................................................................................. 144
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 9
1 Einleitung
1.1 Bremssystemdefinition (Festlegung der Systemgrenzen) Das Bremssystem besteht aus / Begriffsdefinitionen:
• einem elektrischen Bremskraftverstärker (eBooster) – bestehend aus Steuergerät, Aktuator und Übertragungseinrichtung –, welcher sowohl die Fähigkeit besitzt, die vom Fahrer aufgebrachten Bremskraft zu verstärken, als auch autonome Druckaufbauten ohne Fahrerbetätigung auszuführen.
• einem ESC-System (ESC) – bestehend aus Steuergerät und Hydraulikeinheit inkl. Druckversorgung, Ventilen und Speicher –, welches neben den bekannten Regelfunktionen optional die Möglichkeit bietet, ein Blenden der Bremsmomente zwischen Generator und hydraulischer Bremse auszuführen.
• Das Gesamtbremssystem ist als Hilfskraftbremssystem definiert.
Ziele dieser Schnittstellenbeschreibung:
• Harmonisierung der Schnittstelle zwischen ESC und eBooster, um die Austauschbarkeit der beiden Systeme von ggfs. unterschiedlichen Lieferanten zu ermöglichen.
• Reduktion des Systemintegrationsaufwands seitens OEM
Für eine OES-unabhängige Kombination von eBooster und ESC ist eine eindeutige Definition der Lieferanteile der jeweiligen Zulieferer, der entsprechenden Verantwortlichkeiten und der Schnittstelle zwischen den beiden Systemen erforderlich.
1.2 Inhalt des Dokuments Die VDA-Empfehlung 360 beschreibt und definiert die Aufteilung der Funktionen und die dafür notwendige Schnittstelle zur Darstellung eines „ESC-Standard“ bzw. eines blendingfähigen ESC-Systems zwischen einem eBooster von verschiedenen Herstellern. Darüber hinaus beschreibt es auch Konzeptansätze, die das Zusammenspiel eines eBooster mit einem ESC-System und die daraus abgeleiteten Schnittstellen beschreibt.
Die VDA-Empfehlung beschreibt:
• In Kapitel 2: Die Beschreibung des Systems inklusive der Funktionsaufteilung zwischen eBooster und ESC und die notwendigen Konzeptbeschreibungen, um die Schnittstellen zu erläutern
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 10
• In Kapitel 3: Die Definition der Funktionsausprägungen und der Funktionalen Architektur und die daraus abgeleiteten Schnittstellendefinitionen
• In Kapitel 4: Die Berücksichtigung der funktionale Sicherheit
• In Kapitel 5: Die Struktur einer „Fehlermöglichkeits- und Einflussanalyse (FMEA) und die Vorgehensweise im Rahmen eines Projektes mit zwei beteiligten OES
• In Kapitel 6: Das Testkonzept
• In Kapitel 7, 8 & 9: Normative Referenzen, Glossar und Anhänge
Der Inhalt dieser Empfehlung ist so gewählt, dass die Randbedingungen eine Kombination von eBooster und ESC von verschiedenen Zulieferern zulassen, jedoch eine produktspezifische Weiterentwicklung seitens OES nicht eingeschränkt wird.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 11
2 Systembeschreibung
2.1 Beschreibung der Systemkomponenten Das in dieser VDA-Empfehlung zu Grunde gelegte Bremssystem beschreibt eine Aufteilung auf zwei Geräte von zwei unterschiedlichen Lieferanten. Hierbei gibt es einen elektrischen Bremskraftverstärker (eBooster), welcher die Bremskraftverstärkung, die Möglichkeit zum aktiven Druckaufbau und eine Pedalkraftkompensation bei verblendfähigen Bremssystemen beinhaltet.
Der zweite Systemanteil ist das ESC-System mit den bekannten Regelfunktionen und der Möglichkeit einer Verblendung bei rekuperativen Bremsungen.
Um die Schnittstellen zwischen dem eBooster und dem ESC-System vollständig beschreiben zu können werden darüber hinaus noch weitere Systemkomponenten beschrieben. Hierzu gehören der Generator, die Warnlampen (HMI) und die Ansteuerung der Bremslichter (BLA-Coordinator).
Bild 1 - Übersicht der Funktionsarchitektur (Abkürzungen siehe Bild 15)
ESC-System
Ein Standard ESC-System umfasst das Antiblockiersystem, die Antriebsschlupfregelung und Giermomentregelung sowie diverse Mehrwertfunktionen. ESC beeinflusst Schleuderbewegungen und dient als Fahrstabilitätshilfe.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 12
In konventionellen Bremssystemen ohne Rekuperationsvermögen sind Radbremsen direkt mit der Betätigungseinheit hydraulisch gekoppelt. Durch die Betätigung des Bremspedals wird ein Bremsflüssigkeitsvolumen in die Radbremse verschoben und dadurch ein hydraulischer Druck aufgebaut. Bei neuen Fahrzeugkonzepten mit regenerativer Bremsfähigkeit kann der elektrische Antriebsstrang zur Verzögerung verwendet werden.
Hieraus ergibt sich eine weitere Anforderung an das ESC-System, eine koordinierte Zusammenarbeit zwischen den hydraulischen Bremsen und dem regenerativen Verzögerungsanteil über den Generator zu gewährleisten. Dafür muss das ESC einerseits das vom Fahrer geforderte Gesamtbremsmoment ermitteln, andererseits sollen auch die Bremsanforderungen von automatischen Bremsfunktionen (externe Verzögerungsanforderung) erfasst werden. Unter Berücksichtigung der Fahrzeugstabilität und des Rekuperationspotentials verteilt die Rekuperationssteuerung die resultierende Gesamtanforderung an die Bremsaktuatoren und den Generator.
eBooster-System
Der eBooster hat primär die Aufgabe, die Fußkraft des Fahrers bei der Pedalbetätigung zu verstärken. Der eBooster ist über die Eingangsstange direkt mit dem Fahrer über das Bremspedal gekoppelt. Durch Auswertung einer geeigneten Sensorik ermittelt der eBooster den Fahrerbremswunsch für die Pedalkraftverstärkung (siehe Bild 12). Die notwendige Unterstützungskraft wird in Abhängigkeit vom ermittelten Fahrerbremswunsch und einer hinterlegten Verstärkerkennlinie berechnet. Anders als das vakuumbasierte System ist der eBooster in der Lage, neben dem mechanischen Verstärkungsfaktor die Verstärkerkennlinie über Software unter Berücksichtigung von Systemgrenzen zu adaptieren.
Aufgrund der aktiven Regelung der Ausgangsstange im eBooster, welche mit dem Hauptzylinder mechanisch gekoppelt ist, ist der eBooster in der Lage, hydraulischen Druck aktiv aufzubauen. Dies eröffnet neue Möglichkeit für die Aktuierung von externen Bremsfunktionen.
In Fahrzeugen mit elektrifiziertem Antriebsstrang (z.B. HEV oder BEV) ist es möglich, regeneratorische Verzögerungsanteile über eine elektrische Maschine darzustellen. Dieser neue Freiheitsgrad führt jedoch dazu, dass der reale Vordruck im Bremssystem nicht mehr mit dem Zieldruck übereinstimmt, der bei einer rein hydraulischen Bremsung zur selben Verzögerung führt. Der eBooster ist in der Lage, die Differenz zwischen dem realen und „virtuellen“ Vordruck zu kompensieren. Diese Funktionalität wird als Pedalkraftkompensation bezeichnet.
Während ABS Eingriffe wird die Elastizität zwischen ESC und eBooster extrem reduziert und es können aufgrund der Steifigkeiten des eBoosters sehr hohe Drücke bzw. Druckgradienten in den hydraulischen Kreisen auftreten. Um die mechanischen Bauteile im eBooster und im ESC zu schützen, muss eine entsprechende Logik zur Druckbegrenzung vorgesehen werden.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 13
Generator
Der Generator beschreibt eine Energierückgewinnungseinrichtung, die durch die Rekuperationssteuerung bedarfsgerecht angesteuert wird, um regeneratives Verzögern zu realisieren. Damit das Generatormoment möglichst effizient genutzt werden kann, wird vom Generator an das ESC ein Generatorpotential zur Verfügung gestellt. Dieses Generatorpotential für den regenerativen Verzögerungsanteil hängt von vielen Faktoren ab, dazu gehören u.a. die Fahrzeuggeschwindigkeit, Batterieladezustand bzw. Bordnetzspannung. Diese Zustände des elektrischen Antriebsstrangs müssen vom Generator berücksichtigt werden und im Generatorpotential wiedergespiegelt werden. Die Rekuperationssteuerung benötigt diese Information zur bedarfsgerechten und energieeffizienten Aufteilung der angeforderten Gesamtverzögerung.
HMI
Das HMI (Human Machine Interface) bezeichnet in diesem Kontext die Kontrolllogik zur Ansteuerung der Kontrollleuchten zur Fahrerwarnung.
BLA-Coordinator
Der BLA-Coordinator (Brake Light Activation) beinhaltet die Kontrolllogik zur Ansteuerung der Bremsleuchten. Das Bremslicht muss sowohl bei Fahrerbremsung als auch bei Aktivierung von Bremsfunktionen ohne Fahrereinwirkung angesteuert werden.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 14
2.2 Konzepte im Systemverbund eBooster + ESC
2.2.1 Degradationskonzept Wenn die Pedalkraftverstärkung vom eBooster nicht verfügbar oder nicht ausreichend ist (erreichbare Verzögerung kleiner als 6,43m/s² bei 500N), kann das ESC System über aktiven Druckaufbau die Fahrerbremsung unterstützen. Dies wird im ESC durch die Funktion HBC1 (Hydraulic Booster Failure Compensation) realisiert. Als Ersatz für das bisher zur Verfügung stehende Vakuumsensorsignal muss nun der eBooster eine entsprechende Information an das ESC senden, damit die HBC-Funktion im ESC aktiviert werden kann, was mit dem Signal HbcRequest realisiert wird. Im Falle eines Fehlers im eBooster, der dazu führt, dass die Verzögerung von 6,43m/s² bei 500N nicht erreicht werden kann, wird die Verstärkung seitens eBooster abgeschaltet. So ist sichergestellt, dass durch die Aktivierung der Funktion HBC die Bremskraftverstärkung ausschließlich durch das ESC bereitgestellt und somit eine Doppelverstärkung vermieden wird.
Wenn die Kommunikation zwischen eBooster und ESC unterbrochen ist, wird die Funktion HBC mit reduzierter Performance aktiviert, weil davon ausgegangen werden muss, dass der eBooster noch verstärken und nur die Kommunikation ausgefallen sein könnte. Diese spezielle Funktionsstufe von HBC wird als HBCreduced bezeichnet. Falls die gesetzlich geforderte Mindestverzögerung von 6,43m/s² bei 500N Pedalkraft mit HBCreduced nicht erreicht wird, um z.B. eine übermäßige Doppelverstärkung zu verhindern, muss ROT bewarnt werden.
Zusätzlicher Hinweis: Die Funktion HBC ist eine sicherheitsrelevante Funktion, die im Falle eines eBooster-Ausfalls über das Signal HbcRequest aktiviert wird. Diese Funktion ist nicht zu verwechseln mit der Komfortfunktion HBB (Hydraulic Brake Boost), bei der der Fahrer bei Erreichen des Aussteuerpunkts des eBooster vom ESC unterstützt wird. Für die Aktivierung der HBB-Funktion wird ein separates Signal pRunout definiert. Im Gegensatz zu einem Vakuumbooster gibt es im Systemverbund eBooster und ESC keine Überlappung der beiden Funktionsgrenzen, d.h. entweder es wird ein Fehler im eBooster festgestellt, was zur Aktivierung HBC führt (via Signal HbcRequest) oder es wird bei Erreichen des Aussteuerpunkts die HBB Funktion im ESC aktiviert (via Signal pRunout).
1 Das Funktionskürzel wird bei Bosch und TRW verwendet. Bei Continental Automotive Systems wird diese Funktion als OHB (Optimised Hydraulic Brake) bezeichnet. „Failed Booster Support“ ist im Fachkreis auch eine übliche Bezeichnung für diese Funktion.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 15
2.2.2 HMI-Konzept Abgeleitet vom obigen Degradationskonzept legt das HMI-Konzept fest, wie das ESC und der eBooster die Bremsenwarnlampen (rote und gelbe) am Dashboard ansteuern. An dieser Stelle wird darauf hingewiesen, dass das HMI im Systemverbund mit hoher Wahrscheinlichkeit projektspezifisch umgesetzt wird. Trotzdem wird im Folgenden ein möglicher Lösungsvorschlag beschrieben. Abweichungen werden projektspezifisch zwischen OEM und den beiden OES anhand den im Projekt gültigen Lastenheften abgestimmt.
Bild 2 Prinzipielles HMI-Konzept
Das HMI-Konzept sieht vor, dass der eBooster nur maximal die gelbe, während das ESC beide Bremsenwarnlampen ansteuern kann.
Sobald im Systemverbund (eBooster + ESC) keine Redundanz für die Bremskraftverstärkung mehr gewährleistet werden kann, muss die gelbe Warnlampe von demjenigen Subsystem angesteuert werden, welches nicht mehr selbstständig die gesetzlich vorgeschriebene Verzögerung von 6,43m/s² bei 500N Pedalkraft erreichen kann.
Die rote Bremsenwarnlampe muss durch das ESC angesteuert werden, sobald keine oder nur eine reduzierte Bremskraftverstärkung unterhalb 6,43m/s² bei 500N Pedalkraft im Systemverbund eBooster + ESC bereitgestellt werden kann.
Folgende Beispiele sollen die Ansteuerung der Bremsenwarnlampen verdeutlichen:
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 16
1. Mögliche Bremskraftverstärkung über eBooster kleiner als 6,43m/s²
Bild 3 HMI-Konzept für Verstärkungsfehler von eBooster
• Bremskraftverstärkung über eBooster ist nicht oder nur unterhalb 6,43m/s² bei 500N Pedalkraft verfügbar (Bsp. eBooster interner Fehler).
• eBooster fordert aktiv vom ESC die Bremskraftunterstützung durch HBC, welche auch im ESC verfügbar ist.
• eBooster steuert die gelbe Bremsenwarnlampe an.
2. Mögliche Bremskraftverstärkung über ESC kleiner als 6,43m/s²
Bild 4 HMI-Konzept für fehlende HBC-Unterstützung von ESC
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 17
• Bremskraftverstärkung über ESC ist nicht oder nur unterhalb 6,43m/s² bei 500N Pedalkraft verfügbar (Bsp. ESC interner Fehler).
• eBooster Bremskraftunterstützung ist größer als 6,43m/s² bei 500N Pedalkraft verfügbar, daher keine Lampenansteuerung über eBooster.
• ESC steuert die gelbe Bremsenwarnlampe an.
3. Kommunikationsfehler
Hierbei wird zwischen drei Fehlerfällen unterschieden:
I. Nur die Kommunikation zwischen ESC und eBooster fällt aus:
Bild 5 HMI-Konzept für Kommunikationsausfall zwischen eBooster und ESC
• Fehler tritt in der Kommunikation zwischen dem eBooster und ESC auf.
• Unabhängig, davon, ob der eBooster noch verstärkt oder nicht, muss im ESC die HBC Funktion aktiviert werden (in Form von HBCreduced, siehe Kapitel 2.2.1).
• ESC steuert die gelbe Bremsenwarnlampe an.
Es ist sicherzustellen, dass die Betriebsbremswirkung von 6,43 m/s² eingehalten wird. Entweder ist dies durch eine entsprechende Auslegung der Hilfsbremswirkung oder durch eine entsprechende Verstärkung durch HBCreduced zu realisieren.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 18
II. Kommunikation zwischen ESC und Dashboard fällt aus:
Bild 6 HMI-Konzept Kommunikationsausfall zwischen ESC und Dashboard
• Kommunikation zwischen ESC und Dashboard bricht ab.
• Das Dashboard muss die rote Bremsenwarnlampe autark ansteuern.
III. Das komplette Kommunikationsnetzwerk fällt aus:
Bild 7 HMI-Konzept für kompletten Netzwerkausfall
• Kommunikation zwischen eBooster und ESC bricht ab. Gleichzeitig treten Kommunikationsfehler zwischen eBooster bzw. ESC und Dashboard auf.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 19
• Das Dashboard muss die rote Bremsenwarnlampe autark ansteuern.
4. Gleichzeitiger Ausfall der Unterstützung von eBooster und ESC
Bild 8 HMI-Konzept für gleichzeitigen Ausfall der Unterstützung von eBooster und ESC
• Bremskraftverstärkung über eBooster ist nicht oder nur unterhalb 6,43m/s² bei 500N Pedalkraft verfügbar (Bsp. eBooster interner Fehler).
• eBooster fordert aktiv vom ESC die Bremskraftunterstützung durch HBC, welche jedoch nicht verfügbar ist.
• ESC wertet die Zustände von eBooster und ESC aus und steuert die rote Bremsenwarnlampe an.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 20
5. eBooster in Diagnose
Bild 9 HMI-Konzept für eBooster-Diagnose
• eBooster befindet sich in Diagnose, währenddessen ist keine Bremskraftverstärkung über eBooster möglich.
• Der eBooster muss dem ESC über ein geeignetes Signal mitteilen, dass es sich in Diagnose befindet.
1. Es wird empfohlen, dass ESC sich in diesem Fall auch in Diagnose umschaltet. (Siehe 2.2.9)
2. Bei abweichender Umsetzung muss gewährleistet werden, dass alle aktiven hydraulischen Bremsfunktionen im ESC unterdrückt werden, damit ein gegebenenfalls durchgeführter Diagnosetest im eBooster nicht durch das ESC beeinflusst wird.
• In beiden Fällen ist Bremskraftunterstützung über ESC ebenfalls NICHT verfügbar. ESC erkennt den kritischen Zustand im Systemverbund und steuert die rote Bremswarnlampe an.
Die Anforderung an die rote Lampe besitzt höhere Priorität und muss entsprechend vom Dashboard berücksichtigt werden.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 21
2.2.3 Konzept zur Bremslichtansteuerung Für die Bremslichtansteuerung wird grundsätzlich zwischen Voll- und degradiertem System unterschieden:
Bremslichtansteuerung im Vollsystem (eBooster nicht degradiert)
Im Vollsystem wird das Bremslicht bei Fahrerbremsung über den eBooster angesteuert.
Das ESC steuert das Bremslicht nur bei aktiven Stabilitätseingriffen bzw. Zusatzbremsfunktionen an, welche nicht durch den Fahrer initiiert sind.
Bild 10 Prinzipielles Konzept zur Bremslichtansteuerung
Bremslichtansteuerung bei degradiertem eBooster
Wenn der eBooster degradiert ist, wird der Systemverbund in die Rückfallebene geschaltet. Da die Ansteuerung des Bremslichtes über den eBooster bei Fahrerbremsung gegebenenfalls nicht mehr möglich ist, wird das Bremslicht ausschließlich über das ESC angesteuert.
Bei Fahrerbremsung bildet das ESC das Ansteuerungssignal anhand des Vordrucksignals.
Die Bremslichtansteuerung bei aktiven Stabilitätseingriffen bzw. Zusatzbremsfunktionen wird weiterhin über das ESC ausgeführt.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 22
Bild 11 Konzept zur Bremslichtansteuerung in Rückfallebene
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 23
2.2.4 Konzept Fahrerbremswunscherkennung Der eBooster hat die Aufgabe die Fahrerbremskraft zu verstärken. Hierzu wird als Eingangsgröße der Fahrerbremswunsch benötigt. Je nach eBooster-Design kann dies z.B. durch eine geeignete Wegsensorik an der Eingangsstange realisiert sein.
In konventionellen ESC-Systemen wird üblicherweise der gemessene Vordruck als Fahrerbremswunsch interpretiert. Bei ESC-Systemen, die in der Lage sind Volumen zu verblenden, um z.B. rekuperatives Bremsen darzustellen, entspricht der gemessene Vordruck jedoch nicht mehr dem Fahrerbremswunsch. Daher wird als zusätzliche Eingangsgröße ein Wegsignal benötigt, um daraus ein Verzögerungswunsch zu berechnen.
Im Systemverbund eBooster und ESC wird dieses vom ESC-System benötigte Wegsignal vom eBooster zur Verfügung gestellt. Ein weiterer Wegsensor außerhalb des Systemverbunds eBooster und ESC ist nicht notwendig.
Während einer rekuperativen Bremsung, in der Volumen im ESC verblendet wird, ist es notwendig dem eBooster einen virtuellen Bremsdruck aus dem ESC zu senden, um den Arbeitspunkt für die Bremskraftverstärkung zu kennen.
Mit diesem beschriebenem Konzept ist es ausreichend die Volumenaufnahme des Bremsanlage (pV-Kennlinie) nur im ESC-System zu hinterlegen.
In Bild 12 wird das Konzept zur Fahrerbremswunscherkennung schematisch und beispielhaft dargestellt.
Bild 12 Konzept zur Fahrerbremswunscherkennung
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 24
Erläuterung zu Bild 12:
Während einer Bremsung misst der eBooster den Eingangsstangenweg über einen integrierten Sensor. Auf dieser Basis berechnet das eBooster-seitige Funktionsmodul DBR-F den Ausgangsstangenweg, der dem hydraulisch wirksamen Fahrerbremswunsch für die Fahrzeugverzögerung entspricht. Der Ausgangsstangenweg wird zur weiteren Verwendung an das ESC gesendet.
Ähnlich wie in einem konventionellen Bremssystem mit Vakuumverstärker wird der hydraulische Bremsdruck weiterhin im ESC gemessen und aufbereitet. Der Hauptbremszylinderdruck dient neben dem Ausgangsstangenweg des eBoosters als Eingangsgröße für das ESC-seitige Funktionsmodul DBR-T. Dies ermittelt anhand der im ESC hinterlegten pV-Kennlinie die Zielgröße der vom Fahrer erwünschten Fahrzeugverzögerung. Der im Bild schematisch dargestellte „virtuelle“ Bremsdruck entspricht dem Hauptbremszylinderdruck, der bei gleicher Pedalbetätigung in einem vergleichbaren konventionellen Bremssystem auftreten würde. Dieser „virtuelle“ Bremsdruck wird wiederum im eBooster für die Bremskraftverstärkung und im Falle von regenerativen Bremssystemen auch für die Pedalkraftkompensation berücksichtigt.
2.2.5 Konzept externer Bremswunsch über eBooster Aufgrund der hohen Dynamik für Druckaufbau und des leisen Betriebs wird der eBooster zur Ausführung von externen Bremsanforderungen (engl. External Brake Request, EBR) verwendet.
Dieser Ansatz betrifft den gesamten Systemverbund, dabei muss die Zusammenarbeit von eBooster und ESC koordiniert werden.
Die Funktionskette EBR ist in der Lage, die angeforderte Kraft/ Verzögerung in Längsrichtung zu regeln und mittels eBooster zu stellen (Beispiel Abstandsregelfunktionen wie ACC).
Die Nutzung dieser EBR-Funktion im Systemverbund eBooster + ESC ist optional. Es können natürlich die Längsdynamikfunktionen bzw. Haltefunktionen weiterhin über das ESC realisiert werden.
Ausgehend von funktionalen und sicherheitstechnischen Überlegungen wird empfohlen, die EBR-Funktion nur zu nutzen, wenn sich sowohl der eBooster als auch das ESC im Vollsystem befinden.
Die nachfolgende Ausführung beschreibt beispielhaft nur einen möglichen Lösungsansatz.
Die EBR Funktion ist sowohl für den Einsatz in konventionellen als auch in verblendfähigen Fahrzeugen konzipiert. Folglich unterscheidet der EBR Regler zwischen zwei Betriebsmodi:
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 25
• Druckregelung für eine konventionelle Verzögerung
In diesem Betriebsmodus fordert das ESC einen Zielvolumenstrom des eBoosters an, um einen entsprechenden Zieldruck im Hauptbremszylinder inkl. Einer geforderten Dynamik zu erreichen.
• Positionsregelung für eine regenerative Verzögerung
In diesem Betriebsmodus fordert das ESC einen Zielvolumenstrom vom eBooster an, um eine entsprechende Pedalposition inkl. einer geforderten Dynamik zu erreichen. Ziel dieser Positionsregelung ist es, während einer rekuperativen Bremsung dieselbe Strategie über die EBR Funktion bzw. im Falle einer Bremspedalbetätigung durch den Fahrer darzustellen.
Der eBooster nimmt die Anforderung des ESC entgegen und stellt anhand des aktuellen Unterstützungspotentials einen entsprechenden Volumenstrom zur Verfügung. Ist das Unterstützungspotential im eBooster erschöpft (Bsp. Aussteuerpunkt erreicht) oder muss aufgrund von Sicherheitsmechanismen im eBooster (Bsp. Einklemmschutz) der angeforderte Volumenstrom gestoppt werden, so wird dies dem ESC über die Information des aktuellen Aussteuerdrucks mitgeteilt. In diesem Fall übernimmt das ESC mit der Rückförderpumpe den restlichen Druckaufbau.
Welche Funktionen über den externen Bremswunsch gestellt werden können, müssen immer projektspezifisch zwischen OEM und den Zulieferern von eBooster und ESC abgestimmt werden, da die Freigabe und Absicherung abhängig vom jeweiligen eBooster-Design durchgeführt werden müssen.
Werden Funktionen über den eBooster aktuiert, kann dies zu einer Lastreduktion im ESC führen. Als Beispiel ist hierbei die ACC-Funktion zu nennen in Verbindung mit einem konventionellen ESC-System.
Evtl. Lastauswirkungen auf eBooster-Seite sind projektspezifisch vom eBooster-Zulieferer zu bewerten und frei zu geben.
2.2.6 OBD Konzept Im Systemverbund werden sowohl eBooster als auch ESC als Primary2 Steuergeräte definiert. Mit dieser Festlegung sind beide Produkte aus Sicht von OBD getrennt und projektspezifisch freizugeben. OBD hat somit keinen Einfluss auf die Schnittstelle zwischen eBooster und ESC, und wird nicht in dieser VDA-Empfehlung spezifiziert.
Nach Betrachtung der Schnittstelle aus Sicht von OBD ergibt sich die Überwachung der Kommunikation auf der Schnittstelle als notwendig, d.h. Überwachung auf Time-out und Datenintegrität etc.
2 Primary Steuergeräte erfassen lokale Daten in ihrem Fehlerspeicher und kommunizieren mit dem OBD Scan-Tool.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 26
Die Umsetzung der Schnittstelle im Fahrzeug ersetzt nicht die Systemanalyse des Bremssystems auf OBD-Auswirkungen. Diese muss im Kontext des Gesamtbremssystems unabhängig von der Schnittstellenbeschreibung durchgeführt werden.
2.2.7 Wakeup/ Postrun Konzept Die Verfügbarkeit der wesentlichen Bremsfunktionen im Systemverbund muss durch ein geeignetes Wakeup/ Postrun Konzept sichergestellt werden.
2.2.7.1 Wakeup
Beide Systeme (eBooster und ESC) müssen spätestens mit „Zündung ein“ (KL15 ein) aufstarten und die Kommunikationsschnittstelle nach einer kurzen Initialisierungszeit mit plausiblen Werten bedienen. Als Richtwert für die Initialisierungszeit auf der Kommunikationsschnittstelle sind 300 ms anzunehmen. Abhängig von der konkreten Steuergerätekonfiguration kann dieser Wert leicht variieren. Der eBooster muss nach „Zündung ein“ die Bremskraftverstärkung zur Verfügung stellen. Dies ist erfüllt, wenn die für die ServiceBrakePerformance benötigte Verstärkung bereitgestellt werden kann, unabhängig davon, ob das Bremspedal betätigt oder unbetätigt ist. Im fehlerfreien Fall ist eine HBC-Aktivierung bis zur Verfügbarkeit der Bremskraftverstärkung zu verhindern. Wird also der eBooster mit bereits betätigtem Bremspedal aktiviert, so bleibt die Bremse während der Initialisierungszeit (s.o.) unverstärkt. Konkret bedeutet dies:
- Der eBooster darf während einer fehlerfreien Initialisierungsphase keinen HbcRequest senden
- Im ESC darf während einer fehlerfreien Initialisierungsphase kein Timeout der betreffenden eBooster-Netzwerkbotschaft erkannt werden
- Die Schnittstelle für pRunout muss seitens eBooster nach der Initialisierung der Netzwerkschnittstelle mit gültigen Werten bedient werden. Der Runoutwert muß dabei mindestens dem Stillstandsrunout entsprechen
Aus Komfortgründen ist die Option vorzusehen, dass der eBooster bereits vor „Zündung ein“ durch eine unabhängige Wakeup-Quelle aktiviert wird und Bremskraftverstärkung seitens eBooster bereitgestellt wird. Diese Option ist nur sinnvoll, wenn bei einem möglicherweise nachfolgenden Motorstart nicht von einem Reset des eBoosters (bzw. ein kurzzeitiger Ausfall der Bremskraftverstärkung) auszugehen ist. Während des Systemhochlaufs muss die Kommunikation zwischen den Systemen in den unten genannten Use Cases derart aufgebaut werden, dass keine Fehlereinträge erfolgen.
• eBooster und ESC werden parallel mit „Zündung ein“ aktiviert
• eBooster wird vor „Zündung ein“ aktiviert, ESC wird erst mit „Zündung ein“ aktiviert
• eBooster und ESC werden vor „Zündung ein“ aktiviert
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 27
Der Zustand „ESC wird vor eBooster aktiviert“ ist im Rahmen des Wakeup nicht vorgesehen.
Die Verfügbarkeit der EBR Funktion muss spätestens ab „Zündung ein“ sichergestellt sein.
2.2.7.2 Postrun
Zur Erfüllung gesetzlicher Vorgaben und um ein dem konventionellen Bremssystem vergleichbares Verhalten bereitzustellen müssen die Systeme auch nach „Zündung aus“ noch aktiv bleiben können. Folgende Anforderungen sind dabei zu erfüllen
• Bereitstellen der Bremskraftverstärkung mindestens auf dem Niveau der Betriebsbremswirkung für mindestens 60 s nach „Zündung aus“ (Erfüllung der gesetzlichen Vorgaben der ECE-R13H). Aus Komfortgründen ist die Option vorzusehen, dass der eBooster für den Use Case „Zündung aus mit betätigtem Pedal“ die Bremskraftverstärkung über die minimal geforderten 60 s hinaus aufrechterhält.
• Im Falle von „Zündung aus während Fahrt“ muss als Option ein Aufrechterhalten der Verstärkung des eBoosters möglich sein. Als Geschwindigkeitsschwelle für den Stillstand sind hier 0.1 m/s anzusetzen.
• Evtl. noch aktive Haltefunktionen über EBR müssen mit „Zündung aus“ koordiniert beendet werden (bspw. Übergabe an Parkbremse). Dazu muss die Kommunikation auf der Netzwerkschnittstelle nach „Zündung aus“ noch solange möglich sein, bis der Vorgang abgeschlossen ist.
• Zur Reduzierung des elektrischen Energiebedarfs bei „Zündung aus“ muss ein koordiniertes Beenden der Netzwerkkommunikation möglich sein (Reduktion der aktiven ECUs), sobald kein Informationsaustausch zwischen eBooster und ESC mehr erforderlich ist. Hierzu müssen eBooster und ESC jeweils ermitteln, ob noch Kommunikationsbedarf mit dem anderen System erforderlich ist und in diesem Fall die Kommunikationsschnittstelle weiter aktiv halten. Das Partnersteuergerät muss in diesem Fall ebenfalls noch aktiv bleiben und die geforderten Signale/Funktionen bereitstellen.
Beispiele für den Use Case Postrun:
• Bei „Zündung aus“ (KL 15 aus) befindet sich das Fahrzeug im Stillstand bei gelöstem Pedal, keine Funktionen aktiv. Es besteht kein Kommunikationsbedarf zwischen eBooster und ESC, die Netzwerkschnittstelle kann freigegeben werden. Nachlaufzeit im eBooster minimal 60 s, im ESC Standard Nachlaufzeit. Die wird als der typische Anwendungsfall angenommen.
• „Zündung aus“ während Fahrt: In diesem Fall wird die Nachlaufzeit im eBooster typischerweise noch nicht gestartet. Seitens eBooster muß die Netzwerkschnittstelle noch aktiv gehalten werden um die Geschwindigkeitsinformation aus dem ESC empfangen zu können. Im ESC muß die Geschwindigkeitsinformation noch berechnet werden.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 28
• „Zündung aus“ im Stillstand aber mit aktiver verteilter Funktion (z.B. AVH über EBR). In diesem Fall muss das Netzwerk seitens ESC mindestens so lange aktiv gehalten werden, bis die Funktion koordiniert beendet wurde (z.B. AVH-Übergabe an Parkbremse).
• „Zündung aus“ im Stillstand mit betätigtem Pedal: Pedal wird nicht gelöst vor Ablauf der 60 s Frist: In diesem Fall wird seitens eBooster für minimal 60 s die Verstärkung aufrecht erhalten, unter Nutzung der o.g. Option auch darüber hinaus. Spätestens nach Lösen des Bremspedals wird der eBooster abgeschaltet.
2.2.8 Unter- / Überspannungskonzept Das Unter-/Überspannungskonzept ist dezentral angelegt, d.h. es gibt hinsichtlich der Versorgungsspannung keine expliziten Abhängigkeiten der Einzelkomponenten voneinander. Die jeweiligen Konzepte werden unabhängig definiert, jeweils bezogen auf die mögliche und geforderte Performance der betroffenen Funktionen:
1. Funktionen im ESC
• Standard ESC-Regler (ABS, TCS, VDC)
• Bremskraftunterstützung für eBooster-Fehler (HBC)
• Zusatzbremsfunktionen (HDC, AVH)
• Rekuperationsrelevante Funktionen
• Koordination externer Bremsanforderung
2. Funktionen im eBooster
• Bremskraftverstärkung
• Pedalkraftkompensation
• Ausführung externer Bremsanforderung
Generell gilt die Vorgehensweise, dass die Funktionen in beiden Einheiten getrennt abhängig von der jeweiligen Versorgungsspannung degradieren, wenn die definierten Funktionsanforderungen aufgrund der Spannungslage nicht mehr erfüllt werden können. Ob die Degradierung als Abschaltung oder als Reduzierung der Performance erfolgt, ist abhängig von der Funktion. Insbesondere bei der Verstärkungsfunktion im eBooster ist eine Reduzierung der Performance einer harten Degradierung vorzuziehen.
Bei verteilten Funktionalitäten (Rekuperation bzw. EBR) ist eine Abhängigkeit der beiden Komponenten voneinander gegeben. Die Degradierung im Partnersteuergerät erfolgt nicht aufgrund der Spannungslage sondern anhand der Statusinformationen (Qualifier) auf dem Bus.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 29
2.2.8.1 Gesonderte Betrachtung für die Bremskraftverstärkung
Die Bremskraftverstärkung kann von beiden Teilsystemen (eBooster wie ESC) bereitgestellt werden. Es wird jedoch die Annahme zugrunde gelegt, dass der Betriebsbereich des eBoosters sowohl bei Über- als auch bei Unterspannung größer ist als der Betriebsbereich der HBC-Funktion im ESC. Für den Fall, dass die Spannung im gesamten elektrischen Bordnetz auf dem gleichen Niveau liegt, hat dies zur Folge, dass das ESC bereits eine Funktionsdegradierung erfährt, während der eBooster noch zumindest eine reduzierte Bremskraftverstärkung liefert. Die Basisfunktion „Bremskraftverstärkung“ ist dabei höher zu bewerten als die Stabilitäts- und Zusatzfunktionen (Regler, Mehrwertfunktionen) aus dem ESC.
Die Degradierung von höheren Funktionen (Rekuperation, Externe Bremswunsch, Mehrwertfunktionen) darf nicht später erfolgen als die Degradierung der Bremskraftverstärkung.
2.2.8.2 Motorstart
Erfolgt bei aktivierter Bremskraftverstärkung ein Motorstart des Verbrennungsmotors, so ist eine Abschaltung der Bremskraftverstärkung zu vermeiden, eine vorübergehende Reduzierung der Verstärkung ist möglich. Für Extremfälle, in denen beim Motorstart ein Abschalten der Bremskraftverstärkung (oder ein Reset der eBooster-ECU) nicht zu vermeiden ist, muss die Bremskraftverstärkung mit möglichst geringer Verzugszeit wieder aktiviert werden, sobald die Spannung wieder ausreichend hoch ist. Für die Dauer der Nichtverfügbarkeit der Bremskraftverstärkung ist eine Rotbewarnung im Kombiinstrument vorzusehen, vorausgesetzt das Kombiinstrument lässt sich wieder ansteuern und der Lampencheck wurde bereits durchgeführt.
2.2.8.3 Motorstart bei Start/Stopp-Funktionalität
Das Unter-/Überspannungskonzept muss in der Lage sein, die typischen Anforderungen an Start/Stopp zu erfüllen. Als Start/Stopp-Situation werden im Systemverbund eBooster + ESP nur Motorstopps im Stillstand oder stillstandsnahen Bereich (v < 5 km/h) betrachtet.
• Keine Fehlereinträge
• Keine Fahrerwarnung
• Aufrechterhalten der Funktion „Berganfahrhilfe“. Es ist fahrzeugspezifisch zu verifizieren, ob die für den vollen Funktionsumfang erforderlichen Haltedrücke dargestellt werden können.
• Aufrechterhalten der Bremskraftverstärkung mit minimal Betriebsbremswirkung.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 30
Abgeleitete Anforderungen ans Bordnetz zur Erfüllung der Start/Stopp-Anforderungen:
• Während eines Motorstarts muss das Bordnetz die Stromaufnahme des eBoosters erlauben/unterstützen.
• Während eines Motorstarts muss das Bordnetz die Stromaufnahme des eBoosters und des ESC unterstützen für die typischen Anwendungsfälle:
- Motorstart mit Pedalbetätigung durch den Fahrer
- Motorstart mit aktiver Haltefunktion durch HHC, ggf. über EBR
2.2.8.4 Elektrische Schnittstelle
Die Spannungsbereiche für Vollfunktion im Systemverbund entsprechen den üblichen Werten für ESC Systeme und sind mit Verweis auf die projektspezifischen Lastenheften abzudecken. Sämtliche Spannungswerte beziehen sich auf die Spannung am jeweiligen ECU-Eingang (gemessen an den Stecker-Pin der jeweiligen ECU).
Wird der Spannungsbereich der Vollfunktion verlassen, kann es zu einer Degradierung kommen. Die folgende Abbildung zeigt schematisch die Degradierungsstrategie hinsichtlich der Basisfunktion „Bremskraftverstärkung“.
Bild 13: Schematische Darstellung der Systemverfügbarkeit abhängig von der Spannungslage
und resultierende Bremskraftverstärkung auf Fahrzeugebene
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 31
2.2.9 Diagnosekonzept Das Diagnosekonzept für den Systemverbund eBooster & ESC hat primär das Ziel, Fehlereinträge und unvorhergesehene Effekte in beiden Teilsystemen zu vermeiden. Dabei sollen keine unnötigen Fehlereinträge entstehen, nachdem ein Teilsystem in die Diagnose3 ging.
An dieser Stelle wird darauf hingewiesen, dass das Diagnosekonzept im Systemverbund mit hoher Wahrscheinlichkeit projektspezifisch umgesetzt wird. Trotzdem wird im Folgenden ein möglicher Lösungsvorschlag beschrieben, welches Verhalten im Systemverbund erwartet wird, wenn die Diagnose im eBooster (Fall 1) bzw. im ESC (Fall 2) aktiviert wird. Abweichungen werden projektspezifisch zwischen OEM und den beiden OES anhand den im Projekt gültigen Lastenheften abgestimmt.
Fall 1: eBooster aktiviert Diagnose:
• eBooster Verhalten:
o Während der Diagnose des eBooster darf keine HBC-Anforderung an das ESC geschickt werden, um die Hardwareansteuerung im eBooster (z.B. Testroutine über "InputOutputControlByIdentifier" nach ISO14229-1) nicht zu beeinflussen. Das entsprechende Signal „HbcRequest“ (siehe Kap. 3.2.1.3) darf nicht aktiviert werden.
o Für den Fall einer Hardwareansteuerung im eBooster während Diagnose soll das Signal pRunout (siehe Kap. 0) angepasst werden (z.B. Erhöhung des physikalischen Werts von pRunout durch einen spezifizierten Offset), um eine ungewollte HBB-Triggerung zu vermeiden.
o Im Falle von eBooster-Diagnose kann eine externe Bremsanforderung nicht mehr über den eBooster ausgeführt werden. Das Signal ExtReqStatus (siehe Kap. 3.2.3.3) muss die Nichtverfügbarkeit der EBR an das ESC übermitteln.
• ESC Verhalten:
o Während der Diagnose kann der eBooster eine Hardwareansteuerung durchführen. Um diesen nicht zu beeinflussen, soll eine Triggerung aktiver Funktionen im ESC (z.B. HBB) vermieden werden. Daher wird empfohlen, das ESC auch in Diagnose-Modus zu schalten, sobald der Systemverbund den Diagnosezustand vom eBooster erkennt.
o Es dürfen keine Fehlereintrage aufgrund der Nichtverfügbarkeit von eBooster Funktionen generiert werden.
3 Unter „Diagnose“ ist in dieser VDA Empfehlung stets „non-default Diagnostic Sessions“ nach ISO14229-1 zu verstehen, z.B. das "extended Diagnostic Session", bei der typischerweise Hardwareansteuerungen vorgenommen werden. Hierbei ist nicht die Diagnose im Vollsystem gemeint, um zum Beispiel Analysen von Funktionen durchzuführen.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 32
Es ist zu beachten, dass während der eBooster Diagnose keine Bremskraftverstärkung im Systemverbund verfügbar ist. Gemäß der gesetzlichen Anforderung muss die rote Lampe am HMI angesteuert werden, um den Operator über diesen Systemzustand zu informieren. Anhand der Ausführung in Kap. 2.2.2 muss ESC in diesem Fall die rote Lampe einschalten.
Fall 2: ESC aktiviert Diagnose:
• eBooster Verhalten:
o Die Bremskraftverstärkung von eBooster wird während der ESC Diagnose beibehalten.
• ESC verhalten:
o Es muss sichergestellt werden, dass alle von ESC an eBooster geschickten Signale weiterhin richtig berechnet werden können.
o Die zugehörigen Qualifier von den Signalen müssen den Zustand 1 (Normal) aufweisen.
2.2.10 Bauteilschutz im eBooster Abhängig vom realisierten mechanischen Design kann der eBooster im Vergleich zu einem konventionellen Vakuumbooster ggfs. ein steiferes System darstellen. In diesem Fall können höheren Druckspitzen während einer aktiven ABS-Regelung entstehen können. Die Druckspitzen könnten zu einem Schaden in der Getriebeeinheit oder im Elektromotor vom eBooster führen. ESC-seitig könnten die Ventile dadurch beschädigt werden.
Im eBooster ist aus diesem Grund beispielhaft eine Logik für den Bauteilschutz zu realisieren. Mit der Funktion PRL (Pressure Reduction Logic) wird aktiv im eBooster die Bremskraftverstärkung angepasst, dass die auftretenden Druckspitzen verringert werden.
Die Funktion PRL wird aktiviert, wenn
• Der eBooster eine aktive ABS-Regelung erkennt, und
• Eine projektspezifisch definierte Druckschwelle (siehe pMax_PRL in Bild 14) erreicht ist.
Der hydraulische Druck im Hauptbremszylinder soll zwischen zwei eingestellten Schwellen pendeln.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 33
Bild 14 Druckverläufe im Hauptbremszylinder während einer aktiven ABS-Regelung
Da die potentiellen Druckspitzen sowie die geeigneten Druckschwellen für die Funktion PRL je nach Systemkonfiguration sehr stark variieren, können sie im Rahmen dieser Empfehlung nicht generisch spezifiziert werden. Folgende Einflussgrößen können Auswirkungen auf die auftretenden Druckspitzen haben:
• Durchmesser Hauptbremszylinder
• Elastizitäten von:
o Bremsleitungen
o Basisbremse
o ESC-System
• Übertragungszeiten Bussystem
• Applikation ABS-Regler
• Blockierdruckniveau
Im Rahmen dieser Empfehlung wird vorgeschlagen die Funktion Bauteilschutz (PRL) projektspezifisch zwischen OEM und den Zulieferern abzustimmen.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 34
2.3 Funktionsaufteilung zwischen eBooster + ESC Anhand der obigen Ausführungen und der Beschreibung der Konzepte im Systemverbund werden folgende Funktionsmodule für eBooster und ESC definiert und entsprechend aufgeteilt. (siehe Bild 15)
Bild 15 Übersicht der Funktionen in eBooster und ESC
Die Aufgaben der einzelnen Funktionen werden in folgender Tabelle zusammengefasst.
Funktion eBooster ESC Aufgabe
DBR-F X Fahrerbremswunscherkennung für die Berechnung der Bremskraftverstärkung, die Erkennung erfolgt im eBooster rein wegbasiert.
BFB X Bremskraftverstärkung mit entsprechender Adaption der Verstärkerkennlinie.
PFC-E X Ausführen der Pedalkraftkompensation über den eBooster.
EBR-E X Ausführen des externen Bremswunsches über den eBooster.
PRL X Realisierung Bauteilschutz für den eBooster bei ABS.
BLA-F X Bremslichtansteuerung bei Fahrerbremsung im Vollsystem.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 35
Funktion eBooster ESC Aufgabe
HMI-eB X Aktivierung gelbe Warnlampe bei Degradierung eBooster.
SSH-eB X System State Handling im eBooster, um Degradierung im eBooster zu koordinieren.
DBR-T X Fahrerbremswunscherkennung für die Berechnung des Bremsmoments. Realisierung Weg- zu Verzögerungskennlinie.
BTC X
Bremskoordinator für regeneratives, hydraulisches Bremsen inkl. Ansteuerung Pedalkraftkompensation und Volumenblenden.
HBC X Bremskraftunterstützung bei eBooster-Fehler.
HBB4 X Kraftunterstützung durch ESC bei Erreichen des Aussteuerpunkts im eBooster.
EBR-C X Closed-Loop-Regelung des externen Bremswunsches.
BLA-B X Bremslichtansteuerung bei Fahrerbremsung im Backup.
HMI-E X Aktivierung Warnlampen bei Degradierung eBooster und nicht Verfügbarkeit HBC.
LDM X Längsdynamik Management Funktionen.
SSH-E X System State Handling im ESC, um Degradierung im ESC zu koordinieren.
Basis Controller X Standard ESC-Regler, z.B. ABC, TCS und VDC.
Tabelle 1 Aufgaben der Funktionen in eBooster und ESC
4 Das Funktionskürzel wird bei Bosch und TRW verwendet. Bei Continental Automotive Systems wird diese Funktion als OHB (Optimised Hydraulic Brake) bezeichnet. „Over-Boost Support“ ist im Fachkreis auch eine übliche Bezeichnung für diese Funktion.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 36
2.4 Abgeleitete Anforderungen an die Teilsysteme Anhand der obigen Ausführung können folgende Anforderungen an die Teilsysteme abgeleitet werden.
2.4.1 Anforderungen an ESC
#Sys_R1.1 Im Systemverbund eBooster/ ESC müssen alle Basisregelfunktionen (ABS, VDC etc.) nach wie vor im ESC realisiert werden.
#Sys_R1.2 Das ESC System muss über zumindest einen Drucksensor verfügen, der den Druck im Hauptzylinder (Primärkreis/Druckkreis) misst.
#Sys_R1.3 Im Falle von rein hydraulischer Bremsung, muss das ESC den Fahrerbremswunsch für die Verzögerung anhand des gemessenen Drucks am Hauptbremszylinder ermitteln.
#Sys_R1.4 Im Falle von regenerativen Systemvarianten muss das ESC mit der Zusatzinformation des Ausgangsstangenwegsignals vom eBooster und des gemessenen Drucks am Hauptbremszylinder die Fahrerbremswunscherkennung für die Bremsung ermitteln. Hierbei muss ein virtueller Bremsdruck errechnet werden.
#Sys_R1.5 Evtl. Adaptionen der Weg- zu Verzögerungskennlinie obliegen dem ESC-System und müssen bei der Berechnung der Fahrerbremswunsches und der Ausgabe des virtuellen Drucks berücksichtigt werden. (Bsp. Adaption Volumenaufnahme bei Querbeschleunigung)
#Sys_R1.6 Im Falle von regenerativen Systemvarianten muss das ESC System eine koordinierte Zusammenarbeit der hydraulischen und regenerativen Bremsaktuatoren sicherstellen. Dazu muss das ESC in der Lage sein, hydraulischen Druck in den Rädern durch aktives Volumenverblenden innerhalb der Systemgrenze zu regeln.
#Sys_R1.7 Das ESC System muss in folgenden Fällen eine Mindestverzögerung von 6,43 m/s2 bei einer Pedalkraft bis zu 500 N über die HBC-Funktion sicherstellen:
• Degradation eBooster
#Sys_R1.8 Das ESC System muss in folgenden Fällen eine Verzögerung von 6,43 m/s2 bei einer Pedalkraft bis zu 500 N über die HBC-Funktion sicherstellen. Falls diese Mindestverzögerung nicht erreicht wird, um z.B. eine übermäßige Doppelverstärkung zu verhindern, muss ROT bewarnt werden:
Kommunikationsfehler zwischen eBooster und ESC. Hier ist zudem die Anforderung an das ESC über die Realisierung der HBC-Funktion eine Doppelverstärkung zu verhindern, da davon auszugehen ist, dass der eBooster noch weiterhin verstärkt.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 37
#Sys_R1.9 Das ESC muss in bestimmten Bereichen bei Erreichen des Aussteuerpunktes des eBooster mit der HBB-Funktion (Hydraulic Brake Boost) den Fahrer unterstützen.
#Sys_R1.10 Das ESC muss den Fahrerbremswunsch und die externen Bremswünsche von definierten Zusatzfunktionen koordinieren und die resultierende Bremsmoment als Anforderung zwischen eBooster und ESC verteilen.
#Sys_R1.11 Im Falle von (automatischer) Aktivierung von Zusatzbremsfunktionen ohne Fahrereingriff muss das ESC das Bremslicht ansteuern.
#Sys_R1.12 Wenn der eBooster degradiert ist muss das ESC die Aufgabe zur Bremslichtansteuerung übernehmen.
#Sys_R1.13 Um das Fahrzeug aus Sicht der funktionalen Sicherheit abzusichern, muss das maximal zulässige Rekuperationspotential (z.B. 0,3g) definiert werden. Das ESC muss sicherstellen, dass keine höhere Verzögerung vom Generator angefordert wird.
#Sys_R1.14 Das ESC muss die gelbe Bremsenwarnlampe ansteuern, wenn die HBC-Funktion (Booster Failure Compensation) nicht verfügbar ist
#Sys_R1.15 Das ESC muss die gelbe Bremsenwarnlampe ansteuern, wenn die Kommunikation zum eBooster ausfällt oder fehlerhaft ist.
#Sys_R1.16 Das ESC muss die rote Bremsenwarnlampe ansteuern, wenn die HBC-Funktion (Booster Failure Compensation) nicht verfügbar ist und der eBooster keine Bremskraftverstärkung mehr bereitstellen kann.
#Sys_R1.17 Das ESC muss die rote Bremsenwarnlampe ansteuern, wenn die HBC-Funktion (Booster Failure Compensation) nicht verfügbar ist und die Kommunikation zwischen ESC und eBooster ausfällt.
Tabelle 2 Abgeleitete Anforderungen an ESC
Bezüglich der ESC Anforderungen sind die entsprechenden Anforderung zu erfüllen, die in dem jeweiligen gültigen Entwicklungslastenheft gefordert und final zwischen OEM und OES abgestimmt werden. Wenn die Anforderungen aus dem gültigen Lastenheft höher sind, sind diese Anforderungen wirksam.
2.4.2 Anforderungen an eBooster
#Sys_R2.1 Der eBooster muss die Bremskraftverstärkung für den Fahrer realisieren.
#Sys_R2.2 Der eBooster muss eine entsprechende Verstärkerkennlinie realisieren
#Sys_R2.3 Im Falle von regenerativen Systemvarianten muss der eBooster die Pedalkraft während rekuperative Bremsung kompensieren bis zu einer rein rekuperativen Fahrzeugverzögerung von 0,3g.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 38
#Sys_R2.4 Der eBooster muss den vom ESC zugewiesenen externen Bremswunsch einstellen.
#Sys_R2.5 Der eBooster muss ein geeignetes Konzept zum Bauteilschutz während einer ABS-Regelung bereitstellen.
#Sys_R2.6 Im Falle einer Fahrerbremsung muss der eBooster das Bremslicht ansteuern.
#Sys_R2.7 Ist die Bremslichtansteuerung im eBooster nicht möglich, muss dies dem ESC mitgeteilt werden.
#Sys_R2.8 Der eBooster muss Unterstützung vom ESC anfordern, sobald er nicht mehr eine entsprechende Bremskraftverstärkung für 6,43m/s² bei 500N Pedalkraft sicherstellen kann.
#Sys_R2.9 Der eBooster muss die gelbe Bremsenwarnlampe ansteuern, sobald er nicht mehr eine entsprechende Bremskraftverstärkung für 6,43m/s² bei 500N Pedalkraft sicherstellen kann.
Tabelle 3 Abgeleitete Anforderungen an eBooster
Bezüglich der Anforderungen an den eBooster sind die entsprechenden Anforderungen zu erfüllen, die in dem jeweiligen gültigen Entwicklungslastenheft gefordert und final zwischen OEM und OES abgestimmt werden. Wenn die Anforderungen aus dem gültigen Lastenheft höher sind, sind diese Anforderungen wirksam.
2.4.3 Anforderungen an HMI
#Sys_R3.1 Das HMI (Dashboard) muss die Warnlampenansteuerung vom eBooster und ESC entsprechend dem festgelegten Konzept berücksichtigen.
#Sys_R3.2 Hierzu muss das HMI die entsprechend spezifizierten Signale einlesen und verarbeiten.
Tabelle 4 Abgeleitete Anforderungen an HMI
Bezüglich der Anforderungen an das HMI sind die entsprechenden Anforderungen zu erfüllen, die in dem jeweiligen gültigen Entwicklungslastenheft gefordert und final zwischen OEM und OES abgestimmt werden. Wenn die Anforderungen aus dem gültigen Lastenheft höher sind, sind diese Anforderungen wirksam.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 39
2.4.4 Anforderungen an den Generator Zwischen dem ESC und Generator müssen geeignete Schnittstellen vorgesehen werden.
#Sys_R4.1 Der Generator muss das verfügbare Rekuperationsbremsmoment an das ESC schicken.
*) Projektspezifisch kann auch entschieden werden, die Rekuperationssteuerung im ESC nur anhand des aktuell realisierten Rekuperationsbremsmoments umzusetzen. In diesem Fall muss diese Anforderung nicht erfüllt werden.
#Sys_R4.2 Der Generator muss das aktuell realisierte Rekuperationsbremsmoment ans ESC schicken.
#Sys_R4.3 Der Generator muss das vom ESC angeforderte Bremsmoment rechtzeitig zur Verfügung stellen, die maximal zulässige Abweichung des Moments und des maximal zulässigen Zeitverzugs müssen in der Entwicklung vom ESC-System spezifiziert werden.
Tabelle 5 Abgeleitete Anforderungen an Generator
Bezüglich der Anforderungen an den Generator sind die entsprechenden Anforderungen zu erfüllen, die in dem jeweiligen gültigen Entwicklungslastenheft gefordert und final zwischen OEM und OES abgestimmt werden. Wenn die Anforderungen aus dem gültigen Lastenheft höher sind, sind diese Anforderungen wirksam.
2.5 Hinweise zur Systemspezifikation
2.5.1 Gesamtbremssystemauslegung Das Vorgehen zur Auslegung des Gesamtbremssystems ist mit dem Einsatz eines eBoosters im Vergleich mit einem herkömmlichen vakuumbasierten Bremskraftverstärker identisch. Der eBooster muss projektspezifisch für das jeweilige Fahrzeug ausgelegt werden. Es muss mit der Gesamtbremssystemauslegung sichergestellt werden, dass beim mechanischen Durchgriff eine Mindestverzögerung von 2,44 m/s² bei 500 N Pedalkraft erreicht werden (entsprechend den in ECE-R13H spezifizierten Testbedingungen). Diese Forderung gilt auch in Kombination mit ESC-Regelsystemen, die in der Lage sind Volumen zu verblenden. Die relevanten Fehlerfälle und Ableitung der notwendigen Maßnahmen müssen abhängig von der Strategie zur Volumenverblendung projektspezifisch zwischen OEM und den Zulieferern abgestimmt werden.
Pauschale Festlegungen wie z.B. die Dimensionierung des Hauptbremszylinders, die Festlegung der Aussteuerpunkts des eBoosters oder der Basisbremse (Reibwert, Volumenaufnahmen etc.) sind nicht zulässig. Die Gesamtbremssystemauslegung ist
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 40
demnach immer projektspezifisch zwischen OEM und den verantwortlichen Zulieferern abzustimmen.
2.5.2 Lastspezifikationen
2.5.2.1 Auswirkungen auf ESC Standardfunktionen
Die bisherig definierten Lastspezifikationen von ESC-Funktionen basieren auf der Kombination eines ESC-Systems mit einem herkömmlichen vakuumbasierten Bremskraftverstärker. Durch den Einsatz eines eBoosters sind dieselben Lastspezifikationen heranzuziehen. Falls eine Adaption aufgrund erhöhter Lastprofile bzw. –zyklen mit dem Einsatz eines eBoosters notwendig ist, ist dies projektspezifisch zwischen OEM und den Zulieferern abzustimmen.
2.5.2.2 eBooster Lastwechsel
Die eBooster Lastwechsel müssen aus den projektspezifischen Lastenheften abgeleitet werden unter Berücksichtigung der designrelevanten Schädigungsmechanismen. Eine allgemeingütige Herleitung von eBooster-Lastwechseln ist im Rahmen dieser Empfehlung nicht möglich.
2.5.2.3 Lastherleitung Regeneratives Bremssystem
Durch den Einsatz des eBoosters ergibt sich durch Nutzung der Pedalkraftkompensation (PFC) die Möglichkeit zur rekuperativen Bremsung ohne Einbuße an Pedalgefühl. Die Aufgabe des Volumenverblendens während einer rekuperativen Bremsung liegt im ESC (siehe Kapitel 2.4). Die Volumenverblendstrategie variiert je nach Zulieferer und ist auch kein Bestandteil dieser Empfehlung. Jedoch muss diese in der Lastherleitung sowohl für die ESC-Hydraulik als auch im eBooster mit berücksichtigt und gegebenenfalls angepasst werden, wenn die Funktion Pedalkraftkompensation im eBooster genutzt wird.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 41
3 Grundlegende Funktionsarchitektur
3.1 Definition einer Funktionalen Architektur Gemäß Kapitel 2 verteilt die Funktionale Architektur in Bild 16 die Gesamtaufgabe eines Bremssystems auf zwei definierte OES-Anteile eBooster und ESC. Auf dieser Basis werden die Kommunikationsschnittstellen zwischen beiden Systemen dargestellt.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 42
Bild 16 Funktionale Architektur des Systemverbunds eBooster & ESC
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 43
Basiert auf der oben dargestellten Architektur soll die Funktionsweise des Systemverbunds erklärt werden.
Usecase-Definition
• Teilbremsung in einem regenerativen Bremssystem
Bild 17 Signalfluss im Systemverbund eBooster + ESC während Teilbremsung
Die Bewegung des Bremspedals wird durch die integrierte Sensorik im eBooster erfasst. Im Vollsystem wertet das Softwaremodul BLA-F das Stangenwegsignal aus und veranlasst die Bremslichtaktivierung.
Parallel berechnet DBR-F den Weg der Ausgangsstange vom eBooster (sOutputRodDriver) und ein separates Signal, das angibt, ob der Fahrer das Pedal betätigt (BrakePedalApplied). Beide Signale werden an die ESC-seitige Bremswunscherkennung DBR-T geschickt.
Das Ausgangsstangenwegsignal (sOutputRodDriver) benötigt das ESC, um den Fahrerbremswunsch zu ermitteln. Bei der Berechnung gehen die Volumenaufnahme des Fahrzeugs (PV-Kennlinie) und bzw. ggfs. vorhandene projektspezifische Lernalgorithmen ein.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 44
Als relevantes Wegsignal für den Fahrerbremswunsch wird der Zielwert der Ausgangsstange definiert, da die Ausgangsstange das hydraulisch wirksame Volumen verschiebt, welches zur Fahrzeugverzögerung führt. Aufgrund der Möglichkeit im eBooster eine Verstärkerkennlinien durch einen bestimmten Differenzweg zwischen Ein- und Ausgangsstange zu beeinflussen, ist gegenüber einem vakuumbasierten Bremskraftverstärker die Ausgangsstange maßgebend für den Fahrerbremswunsch im ESC.
Die resultierende Zielbremsanforderung vom Fahrer wird an das Softwaremodul BTC weitergegeben. Im Falle von eBoosterausfall oder bei Kommunikationsfehler zwischen eBooster und ESC wird das Bremslicht von ESC über das Ausgangssignal von DBR-T angefordert.
BTC koordiniert die Aufteilung der Bremsanforderung auf das Basisbremssystem und den regenerativen Bremsaktuator. Dabei werden neben dem Fahrerbremswunsch auch die externen Bremsanforderungen berücksichtigt.
Um die Bremsmomente situations- und bedarfsgerecht zu koordinieren, werden folgende Informationen benötigt:
• das Potential des regenerativen Verzögerungsanteils (Generator)
• das Potential von eBooster zur Pedalkraftkompensation
• die Stabilitätszustände des Fahrzeugs
Das BTC ermittelt das Zielbremsmoment für den regenerativen Verzögerungsanteil an den Generator. Für die Restbremsanforderung verteilt BTC die Aufgabe zum Druckaufbau auf ESC. Der eBooster erhält parallel die Anforderung eine Pedalkraftkompensation durchzuführen.
Es wird ESC-seitig ein Signal an das Softwaremodul HAC geschickt, das die hydraulischen Aktuatoren in der Hydraulikeinheit ansteuert. An den eBooster schickt BTC eine Anforderung an das eBooster-seitige Softwaremodul PFC-E, das die Pedalkraftkompensation umsetzt.
Um ein konsistentes Pedalgefühl zu realisieren muss die Korrelation zwischen der Bremswirkung und Pedalkraft berücksichtigt werden. In Anlehnung an konventionelle Bremssysteme, bei der die Pedalkraft eindeutig über den Hauptzylinderdruck bestimmt wird, berechnet DBR-T anhand der hinterlegten Weg-Druck-Kennlinie einen virtuellen Systemdruck. Dieses Signal wird an das eBooster-seitige Softwaremodul PFC-E und BFB geschickt.
Anhand der Information über die Pedalbewegung und die Anforderung an Pedalkraftkompensation von ESC ermittelt BFB die Pedalkraftanforderung, die durch eBooster umgesetzt wird. Diese Anforderung wird begrenzt durch Sicherheitsmechanismen in SSH-eB und die Druckminderungslogik in PRL. Nach den beiden Softwaremodulen ergibt sich die finale Zielgröße für die Pedalkraftverstärkung, die der eBooster stellt.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 45
3.2 Schnittstellendefinition Die SW Schnittstellendefinition beschreibt im Detail die Schnittstelle zwischen einem eBooster- und einem ESC-System. Zur Übersicht sind in den weiteren Unterkapiteln die einzelnen Schnittstellen gemäß dem Funktionsumfang des Gesamtsystems in sechs Gruppen zusammengefasst:
1. Basisschnittstelle: Schnittstelle zur Darstellung der Grundfunktionalität
2. Rekuperationsschnittstelle: Schnittstelle zur Darstellung der Pedalkraftkompensation für die Rekuperation.
3. Schnittstelle Externer Bremswunsch: Schnittstelle zur Darstellung eines externen Bremswunsches über den eBooster.
4. HMI-Schnittstelle
5. Schnittstelle Bremslichtansteuerung
6. Generatorschnittstelle
Für die Spezifikation der Signale sind folgende Datentypen relevant:
Datentyp Beschreibung
enum Aufzählungsdatentyp (eng. enumerated type): Variablen mit einer endlichen Wertemenge
log Logischer Datentyp: Variablen, die nur zwei Zustände einnehmen können
cont Kontinuierlicher Datentyp: Variablen, die unter Berücksichtigung der Auflösung jeden beliebigen Zahlenwert innerhalb des definierten Wertbereichs einnehmen können
Tabelle 6 Übersicht Abkürzungen der Datentypen
Die vorstehend beschriebenen Signalspezifikationen sind mit dem jeweiligen projektspezifischen Lastenheften zwischen OEM und OES abzugleichen. Wenn die Anforderungen aus dem gültigen Lastenheft höher sind, sind diese Anforderungen wirksam.
Zudem ist zu beachten, dass die funktionalen Anforderungen an die jeweiligen Signale bzw. die Signalspezifikationen als Mindestanforderungen des Empfänger-Steuergerätes zu interpretieren sind. Diese formulierten Mindestanforderungen berücksichtigen den Systemverbund eBooster und ESC. Werden z.B. höhere Genauigkeitsanforderungen an ein bestimmtes Signal von einem 3. Steuergerät benötigt, so ist dies projektspezifisch abzustimmen.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 46
3.2.1 Basisschnittstelle: Darstellung der Grundfunktionalität Die Basisschnittstelle beschreibt den Umfang der SW-Signale, die zwischen einem aktiven Bremskraftverstärker (eBooster) und einem ESC-System (ESC) für die Darstellung der Grundfunktionalität benötigt werden.
Folgende Grundfunktionalitäten werden damit sichergestellt:
• Aktivierung der Failboost-Funktion im ESC bei z.B. Ausfall des eBoosters
• Unterstützung durch das ESC sobald der eBooster seinen Aussteuerpunkt erreicht.
• Realisierung des Bauteilschutzes im eBooster
• Fahrerbremswunscherkennung
Die Basisschnittstelle mit ihren Signalen zur Realisierung der Grundfunktionalität ist in Bild 18 dargestellt. Die Basisschnittstelle enthält eine bidirektionale Kommunikation zwischen dem eBooster und dem ESC.
Bild 18 Basisschnittstelle zur Darstellung der Basisfunktionalität zwischen eBooster und ESC
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 47
3.2.1.1 Übersicht Schnittstellenbeschreibung
ID Schnittstelle Aufgabe und Schnittstelleninhalt
1 eBESCCompatibilityIndex5 eBooster ESC:
Übermittlung einer statischen Nummer vom eBooster- ans ESC-Steuergerät, um die Kompatibilität der eBooster Software im ESC zu prüfen.
Die Nummer vom eBooster muss mit der im ESC übereinstimmen, sonst muss das ESC degradiert werden. In diesem Fall soll die Warnlampe entsprechend eingeschaltet werden.
2 HbcRequest eBooster ESC:
Übermittlung der Anforderung an die HBC Funktion bei fehlender Verstärkung im eBooster.
• FALSE (Es liegt KEINE Anforderung an HBC vor.)
• TRUE (Anforderung an HBC liegt vor.)
3 eBDiagActive eBooster ESC:
Übermittlung der Information, ob sich der eBooster gerade im Diagnosemodus befindet.
• FALSE (eBooster ist NICHT im Diagnosemodus.)
• TRUE (eBooster ist im Diagnosemodus.)
4 BrakePedalApplied eBooster ESC:
Übermittlung der Information, ob das Pedal vom Fahrer betätigt ist. Das Signal wird im ESC benötigt, um einen Fahrerbremswunsch zu erkennen.
• FALSE (Bremspedal ist NICHT betätigt.)
• TRUE (Bremspedal ist betätigt.)
5 pRunout eBooster ESC:
5 eBESCCompatibilityIndex wird nicht zur Darstellung von Bremsfunktionen verwendet. Das Signal dient lediglich zur Prüfung von Komptabilität beider Steuergeräten. Falls die Kompatibilitätsprüfung anders realisiert wird, wird das Signal nicht für den Systemverbund benötigt.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 48
Übermittlung des Aussteuerpunkts des eBoosters, der z.B. je nach verfügbarer Bordnetzenergie oder Temperatur abgesenkt wird. Das Signal wird im ESC eingelesen, um den Fahrer mit der HBB-Funktion (Hydraulic Brake Boost) oberhalb des Aussteuerpunkts zu unterstützen.
6 sOutputRodDriver eBooster ESC:
Übermittlung des Sollwerts des Ausgangsstangenwegsignals. Das Signal wird im ESC als Zusatzinformation für die Fahrerbremswunscherfassung benötigt:
• während der Rekuperation mit Volumenverblenden entspricht der gemessene Vordruck im Hauptbremszylinder nicht dem Fahrerbremswunsch
• hydraulische Bremsassistenzfunktionen (z.B. HBB, HBC etc.) benötigen das Signal als zusätzliche Aktivierungs- bzw. Abbruchbedingung aufgrund der höheren Steifigkeit eines eBoosters gegenüber einem Vakuumbooster (abhängig von dem ESC-System des Zulieferers)
7 VehicleSpeed ESC eBooster:
Übermittlung der aktuellen Geschwindigkeit des Fahrzeugs.
Im eBooster wird dieses Signal eingelesen, um den Stillstand zu erkennen bzw. Übergänge in den Stillstand zu berechnen. Dies wird wiederum für die Funktionen Pressure Reduction Logic (PRL – Bauteilschutz) bzw. für den externen Bremswunsch (EBR) benötigt.
8 pMC1 ESC eBooster:
Das Signal entspricht dem aktuellen Vordrucksensorwert aus dem ESC und wird im eBooster für die Realisierung der Funktion Pressure Reduction Logic (PRL – Bauteilschutz) benötigt.
9 AbsActive ESC eBooster:
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 49
Dieses Signal sendet an den eBooster die Information, ob gerade im ESC das ABS aktiv ist.
• FALSE (ABS ist nicht aktiv)
• TRUE (ABS ist aktiv)
10 pEstMax ESC eBooster:
Übermittlung des maximalen Raddrucks des geschätzten druckhöchsten Rades. Das Signal wird im eBooster eingelesen, um im ABS-Fall die Gegenkraft anzupassen und damit das Pedalgefühl zu verbessern.
Tabelle 7 : Übersicht Basisschnittstelle zwischen eBooster und ESC
3.2.1.2 Signal eBESCCompatibilityIndex
3.2.1.2.1 Signalspezifikation
Richtung eBooster ESC
Signalname eBESCCompatibilityIndex
Einheit -
Typ cont
Größe (Bits) 4
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 16
Auflösung / Bit -
3.2.1.2.2 Anforderungen an das Signal
#R1.1 Das Signal eBESCCompatibilityIndex muss eine statische Nummer sein, die sich nur in folgenden Fällen ändert:
• Einführung neuer Schnittstellensignale;
• Änderungen in bereits existierenden Schnittstellensignalen;
• Funktionale Änderungen in der Software eines Steuergerätes, die für den Systemverbund relevant sind.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 50
#R1.2 Das ESC muss degradiert werden, wenn der Wert des Signals eBESCCompatibilityIndex nicht mit dem ESC-internen Indexwert übereinstimmt. In diesem Fall soll die Warnlampe entsprechend eingeschaltet werden.
3.2.1.3 Signal HbcRequest
3.2.1.3.1 Signalspezifikation
Richtung eBooster ESC
Signalname HbcRequest
Einheit -
Typ log
Größe (Bits) 1
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 1
Auflösung / Bit -
3.2.1.3.2 Anforderungen an das Signal
#R2.1 Das ESC muss HBC auf Basis des Signals HbcRequest aktivieren, unabhängig davon welcher Wert auf dem Signal pRunout steht.
#R2.2 Das Signal HbcRequest kann folgende Zustände einnehmen:
• FALSE: HBC wird NICHT angefordert
• TRUE: HBC wird angefordert
#R2.3 Das Signal HbcRequest muss auf „TRUE“ gesetzt werden, wenn der eBooster aufgrund Fehler degradiert ist und keine Verstärkung zur Verfügung stellen kann.
#R2.4 Das Signal HbcRequest muss auf „FALSE“ gesetzt werden, wenn sich der eBooster in Diagnose befindet.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 51
3.2.1.4 Signal eBDiagActive
3.2.1.4.1 Signalspezifikation
Richtung eBooster ESC
Signalname eBDiagActive
Einheit -
Typ log
Größe (Bits) 1
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 1
Auflösung / Bit -
3.2.1.4.2 Anforderungen an das Signal
#R3.1 Das Signal eBDiagActive kann folgende Zustände einnehmen:
• FALSE: eBooster ist NICHT in Diagnose6
• TRUE: eBooster ist in Diagnose
#R3.2 Das Signal eBDiagActive muss auf „TRUE“ gesetzt werden, wenn sich der eBooster in Diagnose befindet. Ein Zurücksetzen des Signals nach eBooster-Diagnose darf nur erfolgen, wenn eBooster wieder im normalen Betrieb ist und keine HBC Funktion anfordert.
6 Unter „Diagnose“ ist in dieser VDA Empfehlung stets „non-default Diagnostic Sessions“ nach ISO14229-1 zu verstehen, z.B. das "extended Diagnostic Session", bei der typischerweise Hardwareansteuerungen vorgenommen werden. Hierbei ist nicht die Diagnose im Vollsystem gemeint, um zum Beispiel Analysen von Funktionen durchzuführen.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 52
3.2.1.5 Signal BrakePedalApplied
3.2.1.5.1 Signalspezifikation
Richtung eBooster ESC
Signalname BrakePedalApplied
Einheit -
Typ log
Größe (Bits) 1
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 1
Auflösung / Bit 1
3.2.1.5.2 Anforderungen an das Signal
#R4.1 Der eBooster muss über das Signal BrakePedalApplied anzeigen, ob das Bremspedal vom Fahrer betätigt wird.
#R4.2 Das Signal BrakePedalApplied kann folgende Zustände einnehmen:
• FALSE: Das Bremspedal wird NICHT betätigt
• TRUE: Das Bremspedal wird vom Fahrer betätigt
#R4.3 Das Signal BrakePedalApplied muss im gleichen Nachrichtenframe wie das Signal sOutputrodAct übertragen werden. Falls dies nicht möglich ist, muss sichergestellt werden, dass der Zeitverzug zwischen beiden Signalen maximal 20ms beträgt.
#R4.4 Die gesamte Kommunikationskette zwischen der eBooster- und der ESC-ECU muss sicherstellen, dass das vom eBooster gesendete Signal BrakePedalApplied innerhalb von 60ms (nachdem der Fahrer das Pedal betätigte) im ESC ankommt.
#R4.5 Das Signal BrakePedalApplied muss auf „TRUE“ gesetzt werden, sobald der Fahrer das Bremspedal betätigt.
#R4.6 Das Signal BrakePedalApplied muss innerhalb von 200ms auf „FALSE“ gesetzt werden, nachdem der Fahrer das Bremspedal gelöst hat.
#R4.7 Das Signal BrakePedalApplied muss mit einer Hysterese versehen werden, um ein Hin- und Herschalten (Toggeln) des Signals zu verhindern.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 53
3.2.1.6 Signal BrakePedalApplied_Q
3.2.1.6.1 Signalspezifikation
Richtung eBooster ESC
Signalname BrakePedalApplied_Q
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 4
Auflösung / Bit 1
3.2.1.6.2 Anforderungen an das Signal
#R4_Q.1 Das Signal BrakePedalApplied_Q kann folgende Zustände einnehmen:
0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt.
3.2.1.7 Signal pRunout
3.2.1.7.1 Signalspezifikation
Richtung eBooster ESC
Signalname pRunout
Einheit bar
Typ cont
Größe (Bits) 8
Zykluszeit [ms] 20
Phys. Min. 0
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 54
Phys. Max. 250
Auflösung / Bit 1
3.2.1.7.2 Anforderungen an das Signal
#R5.1 Das Signal pRunout muss dem Druck entsprechen, der während einer Fahrerbremsung bei Erreichen der maximalen Verstärkung durch den eBooster vorliegt.
#R5.2 Die Berechnung des Signals pRunout muss Änderungen in der Bordnetzenergie, den Verstärkungsfaktor und den Hauptbremszylinderdurchmesser berücksichtigen.
#R5.3 Das Signal pRunout muss den Wert „0“ annehmen, wenn HBCRequest == TRUE ist
#R5.4 Das Signal pRunout darf keinen Wert anzeigen, der größer ist als der tatsächlich erreichbare Runout-Druck des eBoosters.
#R5.5 Nur relevant für den Fall Fahrerbremsung: Das Signal pRunout darf nicht auf kurzzeitige Signalstörungen (t <= 150ms) reagieren, die durch eine schnelle Fahrerpedalbetätigung hervorgerufen werden.
Wichtig: Diese Anforderung ist nicht gültig für die Ausführung eines externen Bremswunsches. Im Falle eines externen Bremswunsches muss das Signal pRunout sofort reagieren, um Verzugszeit bei der Übergabe an das ESP durch die Signalbildung zu verhindern.
#R5.6 Während eines Diagnosetests im eBooster muss das Signal pRunout so angepasst sein, dass der eBooster keine hydraulische Unterstützung in Form von HBB im ESC anfordert.
3.2.1.8 Signal pRunout_Q
3.2.1.8.1 Signalspezifikation
Richtung eBooster ESC
Signalname pRunout_Q
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 4
Auflösung / Bit 1
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 55
3.2.1.8.2 Anforderungen an das Signal
#R5_Q.1 Das Signal pRunout_Q kann folgende Zustände einnehmen:
0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt
#R5_Q.2 Wenn das Signal pRunout während der eBooster-Diagnose innerhalb der spezifizierten Toleranzen gebildet wird, muss das Signal pRunout_Q gültig (1: Normal) sein.
3.2.1.9 Signal sOutputRodDriver
3.2.1.9.1 Signalspezifikation
Richtung eBooster ESC
Signalname sOutputRodDriver
Einheit mm
Typ cont
Größe (Bits) 12
Zykluszeit [ms] 10
Phys. Min. -5
Phys. Max. 47
Auflösung / Bit 0,015625
3.2.1.9.2 Anforderungen an das Signal
#R6.1 Das Signal sOutputRodDriver muss dem Zielwert des Ausgangsstangenwegs definiert werden. Info: Das Signal entspricht nicht dem tatsächlich verschobenem Volumen, Verweis auf Signal sOutputRodAct
#R6.2 Das Signal sOutputRodDriver muss dem Fahrerbremswunsch entsprechen, unabhängig davon ob hydraulisch oder regenerativ gebremst wird.
#R6.3 Effekte, die sich durch Regelung der aktuellen Ausgangsstange im eBooster ergeben, dürfen nicht in dem Signal sOutputRodDriver abgebildet werden, da sie nicht dem Fahrerbremswunsch entsprechen.
#R6.4 Die Regelung der aktuellen Ausgangsstange im eBooster für die Stellerfunktion Pedalkraftkompensation (PFC) darf nicht im Signal sOutputRodDriver abgebildet werden.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 56
#R6.5 Das Signal muss die dynamischen Anpassungen in der eBooster-Regelung für die Verstärkerkennlinie beinhalten.
#R6.6 Das Signal sOutputRodDriver muss auch während der Ausführung eines externen Bremswunsches über den eBooster berechnet und gesendet werden.
#R6.7 Das Signal sOutputRodDriver muss auch im Falle eines Bremskreisausfalls verfügbar und gültig sein.
#R6.8 Bei gleicher Fahrerbetätigung muss die Abweichung des Signals sOutputRodDriver zwischen zwei aufeinander folgenden Bremsvorgängen kleiner als 0,15 mm betragen.
3.2.1.10 Signal sOutputRodDriver_Q
3.2.1.10.1 Signalspezifikation
Richtung eBooster ESC
Signalname sOutputRodDriver_Q
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 4
Auflösung / Bit 1
3.2.1.10.2 Anforderungen an das Signal
#R6_Q.1 Das Signal sOutputRodDriver_Q kann folgende Zustände einnehmen:
0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 57
3.2.1.11 Signal VehicleSpeed
3.2.1.11.1 Signalspezifikation
Richtung ESC eBooster
Signalname VehicleSpeed
Einheit m/s
Typ cont
Größe (Bits) 8
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 100
Auflösung / Bit 0,39
3.2.1.11.2 Anforderungen an das Signal
#R7.1 Das Signal VehicleSpeed muss der Fahrzeuggeschwindigkeit entsprechen.
#R7.2 Auf dem einachsigen Rollenprüfstand muss das Signal VehicleSpeed der Geschwindigkeit der angetriebenen Achse entsprechen. Stillstand darf daher nicht falsch angezeigt werden. Als Rollenprüfstände sind sowohl Prüfstände für Emissions-/ Verbrauchsmessungen als auch Bremsenprüfstände zu verstehen.
(Hilfreiche Information: Als Konsequenz muss im ESC ein eigenes Geschwindigkeitssignal für den eBooster gebildet werden.)
- Mögliche Umsetzung Signalbildung: VehicleSpeed = Maximalwert aus den beiden Mittelwerten aus Vorder- und Hinterachse
- Mögliche Umsetzung Fehlertoleranz: Ein fehlerhafter Radgeschwindigkeitssensor pro Achse ist zu tolerieren. Die Geschwindigkeit leitet sich dann aus der verbleibenden Geschwindigkeitsinformation der entsprechenden Achse ab. Zwei Fehler pro Achse führt zu einem ungültigen VehicleSpeed Signal.
#R7.3 Das Signal VehicleSpeed muss auch während der ESC-Diagnose gültig sein.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 58
3.2.1.12 Signal VehicleSpeed_Q
3.2.1.12.1 Signalspezifikation
Richtung ESC eBooster
Signalname VehicleSpeed_Q
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 8
Auflösung / Bit 1
3.2.1.12.2 Anforderungen an das Signal
#R7_Q.1 Das Signal VehicleSpeed_Q kann folgende Zustände einnehmen:
0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt
3.2.1.13 Signal pMC1
3.2.1.13.1 Signalspezifikation
Richtung ESC eBooster
Signalname pMC1
Einheit bar
Typ cont
Größe (Bits) 10
Zykluszeit [ms] 10
Phys. Min. -30
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 59
Phys. Max. 276,6
Auflösung / Bit 0,3
3.2.1.13.2 Anforderungen das Signal
#R8.1 Das Signal pMC1 muss dem aktuell gemessenen Druck im Druckkreis des Hauptbremszylinders entsprechen.
#R8.2 Das Signal pMC1 muss dem gemessenen Rohwert entsprechen und darf somit nicht Offset kompensiert oder gefiltert sein.
#R8.3 Aufgrund der Offset-Kompensation fürs pMC1-Signal in eBooster darf ein gültiges pMC1 Signal (pMC1_Q = 1: „Normal“) eine maximale Abweichung von +/-15bar gegenüber dem tatsächlichen Wert aufweisen.
3.2.1.14 Signal pMC1_Q
3.2.1.14.1 Signalspezifikation
Richtung ESC eBooster
Signalname pMC1_Q
Einheit -
Typ enum
Größe (Bits) 1
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 2
Auflösung / Bit 1
3.2.1.14.2 Anforderungen das Signal
#R8_Q.1 0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 60
#R8_Q .2 Die Dauer für die Zustandsänderung von „NotInitialized“ auf „Normal“ oder „Faulty“ muss kürzer als 200ms sein, um eine ausreichend schnelle Reaktion in der Funktion Bauteilschutz im eBooster zu gewährleisten.
*Die genannte Dauer ist hierbei auf der ESC-Seite spezifiziert und die im ESC benötigte Überwachungszeit ist inbegriffen. Sollte der Wert nicht eingehalten werden können, ist eine projektspezifische Abstimmung zwischen OES ESP und OES eBooster notwendig.
#R8_Q .3 Die Dauer für die Zustandsänderung von „Normal“ auf „Faulty“ muss kürzer als 100ms* sein, um eine ausreichend schnelle Reaktion in der Funktion Bauteilschutz im eBooster zu gewährleisten.
*Die genannte Dauer ist hierbei auf der ESC-Seite spezifiziert und die im ESC benötigte Überwachungszeit ist inbegriffen. Sollte der Wert nicht eingehalten werden können, ist eine projektspezifische Abstimmung zwischen OES ESP und OES eBooster notwendig.
#R8_Q .4 Wenn die Abweichung durch Offset- oder Verstärkungsfehler bei der Signalaufbereitung im Betrag größer als 15 bar wird, muss das Signal pMC1_Q innerhalb von 100ms von „Normal“ auf „Faulty“ umschalten.
3.2.1.15 Signal AbsActive
3.2.1.15.1 Signalspezifikation
Richtung ESC eBooster
Signalname AbsActive
Einheit -
Typ log
Größe (Bits) 1
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 1
Auflösung / Bit 1
3.2.1.15.2 Anforderungen an das Signal
#R9.1 Das Signal AbsActive muss die Information beinhalten, ob aktuell im ESC ABS aktiv ist.
#R9.2 Das Signal AbsActive kann folgende Zustände einnehmen:
• FALSE: ABS ist NICHT in aktiver Regelung
• TRUE: ABS ist in aktiver Regelung
#R9.3 Das Signal AbsActive muss auf TRUE gesetzt werden, sobald mindestens ein Rad im ABS ist.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 61
3.2.1.16 Signal pEstMax
3.2.1.16.1 Signalspezifikation
Richtung ESC eBooster
Signalname pEstMax
Einheit Bar
Typ Cont
Größe (Bits) 8
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 250
Auflösung / Bit 1
3.2.1.16.2 Anforderungen an das Signal
#R10.1 Das Signal pEstMax muss dem Druck des druckhöchsten Rades im ESC entsprechen.
#R10.2 Das Signal pEstMax wird im eBooster nur verwendet, wenn ABS aktiv ist. D.h. das Signal muss der Spezifikation entsprechen, sobald das Signal AbsActive gesetzt ist.
#R10.3 Das Signal pEstMax muss der Spezifikation entsprechen, sobald der Vordruck höher ist als 100 bar.
#R10.4 Während einer aktiven ABS-Regelung darf die Abweichung zwischen dem realen Druck des druckhöchsten Rades und pEstMax maximal 50% betragen. Eine höhere Abweichung als die 50% ist maximal für 300ms zulässig.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 62
3.2.2 Rekuperationsschnittstelle Die Rekuperationsschnittstelle beschreibt den Umfang der SW-Signale, die zwischen einem aktiven Bremskraftverstärker (eBooster) und einem ESC-System (ESC) für die Darstellung der Pedalkraftkompensation während Rekuperation benötigt werden.
Die Rekuperationsschnittstelle ist nur dann notwendig, wenn mindestens eine der folgenden Funktionalitäten im Gesamtsystemverbund zu realisieren ist:
• Pedalkraftkompensation während Rekuperation
• Berechnung des vom Fahrer verschobenen Volumens
Falls diese Funktionalitäten nicht benötigt oder gefordert sind, kann auf diese Schnittstelle verzichtet werden.
Die bidirektionale Kommunikation zwischen dem eBooster und dem ESC für die Rekuperationsschnittstelle in Bild 19 dargestellt.
Bild 19 Übersicht der Rekuperationsschnittstelle
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 63
3.2.2.1 Übersicht Schnittstellenbeschreibung
ID Schnittstelle Aufgabe und Schnittstelleninhalt
11 pForceBlendingPotential eBooster ESC:
Übermittlung des Potentials des eBoosters für die Pedalkraftkompensation. Das ESC koordiniert anhand dieser Information die Anforderung an die Pedalkraftkompensation.
12 sOutputRodAct eBooster ESC:
Übermittlung der Wegposition der Ausgangsstange des eBooster. Die Größe ist relevant für die Berechnung des tatsächlich verschobenen Volumens im Hauptbremszylinder.
13 pMcVirtual ESC eBooster:
Übermittlung des virtuellen Vordrucks. Da während Rekuperation der Systemdruck durch Volumenverblenden nicht mit dem Fahrerbremswunsch korreliert, wird ein Ersatzsignal im ESC für den eBooster gebildet. Dieses ist die Basis der Pedalkraftkompensation und der Bremskraftverstärkung während Rekuperation im eBooster.
14 pForceBlendingMC ESC eBooster:
Übermittlung des Zieldrucks, der vom ESC während Volumenverblenden eingeregelt werden soll. Im eBooster wird durch Berechnung der Differenz zwischen pMcVirtual und pForceBlendingMC die Zielgröße für Pedalkraftkompensation abgeleitet.
15 ForceBlendingActive ESC eBooster:
Übermittlung des aktuellen Ansteuerwunsches für die Funktion Pedalkraftkompensation.
0: PFC_inactive (Pedalkraftkompensation wird nicht angefordert) 1: PFC_hold (aktueller Wert der Pedalkraftkompensation wird gehalten)
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 64
2: PFC_active (Pedalkraftkompensation wird angefordert)
Tabelle 8 : Übersicht Rekuperationsschnittstelle zwischen eBooster und ESC
3.2.2.2 Signal pForceBlendingPotential
3.2.2.2.1 Signalspezifikation
Richtung eBooster ESC
Signalname pForceBlendingPotential
Einheit Bar
Typ Cont
Größe (Bits) 8
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 125
Auflösung / Bit 0,5
3.2.2.2.2 Anforderungen an das Signal
#R11.1 Um Anforderungen an die Verstärkerkennlinie zu erfüllen und ggfs. das regenerative Bremsmoment bzw. der Volumenverblendung zu limitieren, muss das Signal pForceBlendingPotential im ESC bekannt sein.
#R11.2 Das Signal pForceBlendingPotential muss dem Potential des eBoosters zur Pedalkraftkompensation entsprechen, die abhängig von der Differenz zwischen dem virtuellen und tatsächlichen Druck im Hauptbremszylinder ist.
#R11.3 Das Signal pForceBlendingPotential muss als Druck definiert werden.
#R11.4 Die Berechnung des Signals pForceBlendingPotential muss sich auf das Hauptbremszylinderniveau beziehen.
#R11.5 Das Signals pForceBlendingPotential muss auf 0 bar gesetzt werden, wenn der eBooster in Diagnose ist.
3.2.2.3 Signal pForceBlendingPotential_Q
3.2.2.3.1 Signalspezifikation
Richtung eBooster ESC
Signalname pForceBlendingPotential_Q
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 65
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 4
Auflösung / Bit 1
3.2.2.3.2 Anforderungen das Signal
#R11_Q.1 Das Signal pForceBlendingPotential_Q kann folgende Zustände einnehmen:
• 0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
• 1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
• 2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt
#R11_Q.2 Das Signals pForceBlendingPotential_Q muss gültig (1: Normal) sein, wenn der eBooster in Diagnose ist und das kalkulierte Signal pForceBlendingPotential innerhalb der spezifizierten Toleranzen liegt.
3.2.2.4 Signal sOutputRodAct
3.2.2.4.1 Signalspezifikation
Richtung eBooster ESC
Signalname sOutputRodAct
Einheit mm
Typ Cont
Größe (Bits) 12
Zykluszeit [ms] 10
Phys. Min. -5
Phys. Max. 47
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 66
Auflösung [mm]/ Bit 0,015625
3.2.2.4.2 Anforderungen an das Signal
#R12.1 Das Signal sOutputRodAct muss der tatsächlichen Position der Ausgangsstange entsprechen, um damit das verschobene hydraulische Volumen zu repräsentieren.
#R12.2 Im Falle von regenerativen Bremssystemen mit Volumenverblendung muss das Signal sOutputRodAct das entsprechende Volumen während Pedalkraftkompensation widerspiegeln.
#R12.3 Im Bereich von 0 mm bis 42 mm darf das Signal sOutputRodAct maximal um ± 0.3mm vom tatsächlichen physikalischen Wert abweichen.
#R12.4 Das Signal sOutputRodAct muss auch im Falle eines Bremskreisausfalls verfügbar und gültig sein.
3.2.2.5 Signal sOutputRodAct_Q
3.2.2.5.1 Signalspezifikation
Richtung eBooster ESC
Signalname sOutputRodAct_Q
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 4
Auflösung / Bit 1
3.2.2.5.2 Anforderungen an das Signal
#R12_Q.1 Das Signal sOutputRodAct_Q kann folgende Zustände einnehmen:
0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 67
3.2.2.6 Signal pMcVirtual
3.2.2.6.1 Signalspezifikation
Richtung ESC eBooster
Signalname pMcVirtual
Einheit Bar
Typ Cont
Größe (Bits) 10
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 250
Auflösung / Bit 0,25
3.2.2.6.2 Anforderungen an das Signal
#R13.1 Das Signal pMcVirtual muss die Information über den Zieldruck im Bremssystem beinhalten.
#R13.2 Das Signal pMcVirtual muss rein wegbasiert auf Basis einer Referenz p/V-Kennlinie berechnet werden.
Anmerkungen:
• Während eines Volumen-Verblendevorgangs (Bsp. Raddruck = 0) muss ein gültiger Wert als wegbasierter Zieldruck ausgegeben werden, auch wenn nur der Generator zu Zielverzögerung beiträgt
• Während einer EBR-Aktivierung ohne Pedalbetätigung muss ein gültiger Wert als wegbasierter Zieldruck ausgegeben werden, der der Pedalposition entspricht
#R13.3 Das Signal pMcVirtual darf keine Sprünge bei Zustandsübergängen (z.B. EBR -> Fahrerbremsung) zeigen und darf keine dynamischen Druckeffekte aufweisen.
3.2.2.7 Signal pMcVirtual_Q
3.2.2.7.1 Signalspezifikation
Richtung ESC eBooster
Signalname pMcVirtual_Q
Einheit -
Typ enum
Größe (Bits) 2
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 68
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 4
Auflösung / Bit 1
3.2.2.7.2 Anforderungen an das Signal
#R13_Q.1 Das Signal pMcVirtual_Q kann folgende Zustände einnehmen:
• 0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
• 1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
• 2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt
3.2.2.8 Signal pForceBlendingMC
3.2.2.8.1 Signalspezifikation
Richtung ESC eBooster
Signalname pForceBlendingMC
Einheit Bar
Typ Cont
Größe (Bits) 10
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 250
Auflösung / Bit 0,25
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 69
3.2.2.8.2 Anforderungen an das Signal
#R14.1 Das Signal pForceBlendingMC muss dem Zieldruck im Hauptzylinder während der Volumenverblendung in ESC entsprechen. Der Zieldruck wird auch an den hydraulischen Aktuator in ESC gesendet, um den Druck entsprechend zu regeln.
3.2.2.9 Signal pForceBlendingMC_Q
3.2.2.9.1 Signalspezifikation
Richtung ESC eBooster
Signalname pForceBlendingMC_Q
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 4
Auflösung / Bit 1
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 70
3.2.2.9.2 Anforderungen an das Signal
#R14_Q.1 Das Signal pForceBlendingMC_Q kann folgende Zustände einnehmen:
• 0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
• 1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
• 2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt.
3.2.2.10 Signal ForceBlendingActive
3.2.2.10.1 Signalspezifikation
Richtung ESC eBooster
Signalname ForceBlendingActive
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 2
Auflösung / Bit 1
3.2.2.10.2 Anforderungen an das Signal
#R15.1 Das Signal ForceBlendingActive muss Information beinhalten, ob die Pedalkraftkompensation in eBooster ausgeführt werden soll.
#R15.2 Das Signal ForceBlendingActive kann folgende Zustände einnehmen:
• 0: PFC_inactive (Pedalkraftkompensation wird nicht angefordert.)
• 1: PFC_hold (Pedalkraftkompensation wird auf der letzten Vorgabe eingefroren. Hinweis: Dieser Signalzustand ist optional und muss nicht zwingend verwendet werden)
• 2: PFC_active (Pedalkraftkompensation wird angefordert.)
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 71
3.2.3 Schnittstelle für Externen Bremswunsch
Die Schnittstelle für Externen Bremswunsch beschreibt den Umfang der Signale, die zwischen einem aktiven Bremskraftverstärker (eBooster) und einem ESC-System (ESC) für die Umsetzung eines externen Bremswunsches über den eBooster benötigt werden.
Die Schnittstelle für Externen Bremswunsch ist nur notwendig, wenn ein externer Bremswunsch über den eBooster gestellt wird. Falls das ESC alle aktiven Druckaufbauten stellt ist diese Schnittstelle nicht notwendig.
Die bidirektionale Kommunikation zwischen dem eBooster und dem ESC für Externen Bremswunsch mit den dazu gehörigen Signalen ist in Bild 20 dargestellt.
Bild 20 Schnittstellen zur Darstellung EBR über eBooster
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 72
3.2.3.1 Übersicht Schnittstellenbeschreibung
ID Schnittstelle Aufgabe und Schnittstellen Inhalt
16 ExtReqPrio eBooster ESC:
Übermittlung der Information, ob der Fahrer oder der externe Bremswunsch das aktuelle Bremsmoment dominiert
FALSE (Externer Bremswunsch ist nicht aktiv oder Fahrer dominiert das Bremsmoment) TRUE (Externer Bremswunsch ist aktiv und dominiert das Bremsmoment)
17 ExtReqStatus eBooster ESC:
Übermittlung der aktuellen Verfügbarkeit des externen Bremswunsches als Stellerfunktion
0: EBR_NotInitilized (Die Stellerfunktion Externer Bremswunsch im eBooster befindet sich in der Initialisierungsphase und kann noch nicht genutzt werden) 1: EBR_NotAvailable (Die Stellerfunktion Externer Bremswunsch im eBooster ist nicht verfügbar)
2: EBR_Available (Die Stellerfunktion Externer Bremswunsch im eBooster ist verfügbar und kann genutzt werden)
18 qTargetExternal ESC eBooster:
Übermittlung des Zielwertes zur Ausführung des externen Bremswunsches im eBooster
19 qTargetExternal_Q ESC eBooster:
Übermittlung des aktuellen Ansteuerwunsches zur Ausführung des externen Bremswunsches im eBooster
0: qTarget_Off (keine Anforderung an Externen Bremswunsch Stellerfunktion im eBooster) 1: qTarget_EBR (aktive Volumenflussanforderung an Externen Bremswunsch Stellerfunktion im eBooster)
Tabelle 9 : Übersicht Schnittstelle zur Darstellung EBR über eBooster
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 73
3.2.3.2 Signal ExtReqPrio
3.2.3.2.1 Signalspezifikation
Richtung eBooster ESC
Signalname ExtReqPrio
Einheit -
Typ Log
Größe (Bits) 1
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 1
Auflösung / Bit 1
3.2.3.2.2 Anforderungen an das Signal
#R16.1 Das Signal ExtReqPrio muss darüber informieren, ob der Fahrer oder der externe Bremswunsch das aktuelle Bremsmoment dominiert
#R16.2 Das Signal ExtReqPrio kann folgende Zustände einnehmen:
• FALSE: Externer Bremswunsch ist nicht aktiv oder Fahrer dominiert das Bremsmoment
• TRUE: Externer Bremswunsch ist aktiv und dominiert das Bremsmoment
#R16.3 Das Signal ExtReqPrio muss auf TRUE gesetzt werden, sobald der Externe Bremswunsch über den eBooster den Fahrerbremswunsch überstimmt und somit das Bremsmoment auf Fahrzeugebene bestimmt.
#R16.4 Das Signal ExtReqPrio muss mit einer Hysterese umgesetzt werden, sodass ein Toggeln zwischen TRUE und FALSE verhindert wird. Die Setz- und Rücksetzbedingungen werden projektspezifisch vereinbart.
3.2.3.3 Signal ExtReqStatus
3.2.3.3.1 Signalspezifikation
Richtung eBooster ESC
Signalname ExtReqStatus
Einheit -
Typ enum
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 74
Größe (Bits) 2
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 4
Auflösung / Bit 1
3.2.3.3.2 Anforderungen an das Signal
#R17.1 Das Signal ExtReqStatus muss Information über den Zustand der EBR-Funktionalität beinhalten.
#R17.2 Das Signal ExtReqStatus muss folgende Zustände repräsentieren:
• 0: EBR_NotInitialized, EBR-Funktionalität im eBooster ist in Initialisierung
• 1: EBR_NotAvailable, EBR-Funktionalität im eBooster ist nicht verfügbar.
• 2: EBR_Available, EBR-Funktionalität in eBooster ist verfügbar und kann durch ESC ausgelöst werden.
#R17.3 Das Signal ExtReqStatus muss auf 1 (EBR_NotAvailable) gesetzt werden, wenn der eBooster in Diagnose ist.
3.2.3.4 Signal qTargetExternal
3.2.3.4.1 Signalspezifikation
Richtung ESC eBooster
Signalname qTargetExternal
Einheit ml/s
Typ cont
Größe (Bits) 16
Zykluszeit [ms] 10
Phys. Min. -252
Phys. Max. 252
Auflösung / Bit 0,0078125
3.2.3.4.2 Anforderungen an das Signal
#R18.1 Das Signal qTargetExternal muss den Zielvolumenfluss im Hauptbremszylinder wiederspiegeln, der vom eBooster bei einer EBR-Aktivierung angefordert wird.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 75
3.2.3.5 Signal qTargetExternal_Q
3.2.3.5.1 Signalspezifikation
Richtung ESC eBooster
Signalname qTargetExternal_Q
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 10
Phys. Min. 0
Phys. Max. 4
Auflösung / Bit 1
3.2.3.5.2 Anforderungen an das Signal
#R19.1 Das Signal qTargetExternal_Q muss folgende Zustände repräsentieren:
• 0: qTarget_Off, wenn keine externe Bremsanforderung vorliegt.
• 1: qTarget_EBR, im Falle von einer externen Bremsanforderung
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 76
3.2.4 Schnittstelle zur Ansteuerung der Warnlampen (HMI)
Die Schnittstelle für die Ansteuerung der Warnlampen (HMI) beschreibt den Umfang der Signale, die von einem eBooster bzw. einem ESC-System (ESC) an das HMI übermittelt werden.
Die Schnittstelle für die Ansteuerung der Warnlampe (HMI) mit ihren Signalen ist in Bild 21 dargestellt.
Bild 21 Schnittstellen zur Ansteuerung der Warnlampen
3.2.4.1 Übersicht Schnittstellenbeschreibung
ID Schnittstelle Aufgabe und Schnittstellen Inhalt
20 eB_HMI_WarningOn eBooster HMI:
Übermittlung der Information, ob der eBooster degradiert ist und somit nicht mehr die 6,43 m/s² bei 500 N Pedalkraft erreicht (Gelbe Warnlampe)
FALSE (Das Signal eB_Warning_On muss die Information beinhalten, ob der eBooster eine Bremskraftverstärkung
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 77
entsprechend 6,43 m/s² bei 500N bereit stellen kann) TRUE (eBooster ist degradiert und kann die 6,43 m/s² bei 500N Pedalkraft nicht mehr sicher stellen)
21 ESC_ HMI_WarningOn ESC HMI:
Übermittlung der Information, ob der eBooster degradiert ist und zusätzlich die HBC-Funktion im ESC nicht mehr zur Verfügung steht. Hiermit wird signalisiert, dass die erforderlichen 6,43 m/s² im Systemverbund eBooster + ESC nicht mehr mit 500 N Pedalkraft erreicht werden können (Rote Warnlampe)
FALSE (eBooster ist verfügbar oder HBC Funktion ist verfügbar im ESC) TRUE (Verstärkung vom eBooster fällt aus und die HBC Funktion im ESC ist nicht mehr verfügbar)
Tabelle 10 : Übersicht HMI-Schnittstelle zwischen eBooster bzw. ESC und HMI
3.2.4.2 eB_ HMI_WarningOn
3.2.4.2.1 Signalspezifikation
Richtung eBooster HMI
Signalname eB_ HMI_WarningOn
Einheit -
Typ Log
Größe (Bits) 1
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 1
Auflösung / Bit 1
3.2.4.2.2 Anforderungen an das Signal
#R20.1 Das Signal eB_HMI_WarningOn muss die Information beinhalten, ob der eBooster eine Bremskraftverstärkung entsprechend 6,43 m/s² bei 500 N bereit stellen kann
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 78
#R20.2 Das Signal eB_HMI_WarningOn kann folgende Zustände einnehmen:
• FALSE: eBooster ist nicht degradiert und kann die 6,43m/s² bei 500N Pedalkraft sicher stellen
• TRUE: eBooster ist degradiert und kann die 6,43 m/s² bei 500 N Pedalkraft NICHT mehr sicher stellen
3.2.4.3 ESC_HMI_WarningOn
3.2.4.3.1 Signalspezifikation
Richtung ESC HMI
Signalname ESC_HMI_WarningOn
Einheit -
Typ Log
Größe (Bits) 1
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 1
Auflösung / Bit 1
3.2.4.3.2 Anforderungen an das Signal
#R21.1 Das Signal ESC_HMI_WarningOn muss die Information beinhalten, ob im Systemverbund mit eBooster und ESC eine Verzögerung von 6,43 m/s² bei 500 N Pedalkraft erreicht werden kann.
#R21.2 Das Signal ESC_HMI_WarningOn kann folgende Zustände einnehmen:
• FALSE: HBC Funktion ist uneingeschränkt verfügbar im ESC
• TRUE: Verstärkung vom eBooster fällt aus und die HBx Funktionen im ESC sind nicht mehr verfügbar.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 79
3.2.5 Schnittstelle zur Ansteuerung des Bremslichts (BLA)
Die Schnittstelle für die Ansteuerung des Bremslichts (BLA) beschreibt den Umfang der Signale, die von einem eBooster bzw. einem ESC-System (ESC) an das BLA übermittelt werden.
Die Schnittstelle für die Ansteuerung des Bremslichts (BLA) mit ihren Signalen ist in Bild 22 dargestellt.
Bild 22 Schnittstellen zur Ansteuerung der Bremslichter
3.2.5.1 Übersicht Schnittstellenbeschreibung
ID Schnittstelle Aufgabe und Schnittstellen Inhalt
22 eB_BLA eBooster BLA:
Übermittlung der Information, ob das Bremslicht aufgrund Fahrerbremsung angesteuert werden muss
FALSE (Bremslicht wird nicht angesteuert) TRUE (Bremslicht wird angesteuert)
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 80
23 ESC_BLA ESC BLA:
Übermittlung der Information, ob bei degradiertem eBooster und bei Fahrerbremsung oder bei aktivierten Zusatzfunktionen das Bremslicht angesteuert werden muss
FALSE (Bremslicht wird nicht angesteuert) TRUE (Bremslicht wird angesteuert)
Tabelle 11 : Übersicht Schnittstelle zwischen eBooster bzw. ESC und BLA zur Ansteuerung der Bremslichter
3.2.5.2 eB_BLA
3.2.5.2.1 Signalspezifikation
Richtung eBooster BLA
Signalname eB_BLA
Einheit -
Typ Log
Größe (Bits) 1
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 1
Auflösung / Bit 1
3.2.5.2.2 Anforderungen an das Signal
#R22.1 Das Signal eB_BLA muss die Information beinhalten, ob das Bremslicht aufgrund einer Fahrerbremsung angesteuert werden muss
#R22.2 Das Signal eB_BLA kann folgende Zustände einnehmen:
FALSE: Bremslicht wird nicht angesteuert
TRUE: Bremslicht wird angesteuert
#R22.3 Das Signal eB_BLA muss mit einer Hysterese umgesetzt werden, um ein Toggeln des Signals zu verhindern. Die Setz- und Rücksetzbedingungen werden projektspezifisch vereinbart.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 81
3.2.5.3 ESC_BLA
3.2.5.3.1 Signalspezifikation
Richtung ESC BLA
Signalname ESC_BLA
Einheit -
Typ Log
Größe (Bits) 1
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 1
Auflösung / Bit 1
3.2.5.3.2 Anforderungen an das Signal
#R23.1 Das Signal ESC_BLA muss die Information beinhalten, ob das Bremslicht aufgrund Fahrerbremsung oder ESC Zusatzfunktionen angesteuert werden muss.
#R23.2 Das Signal ESC_BLA muss gesetzt werden, wenn die projektspezifischen Setzbedingungen der ESC Zusatzfunktionen (Bsp. Längsdynamikfunktionen) erfüllt sind.
#R23.3 Das Signal ESC_BLA darf bei einer Fahrerbremsung nur auf TRUE gesetzt werden, wenn der eBooster degradiert ist oder die Kommunikation zum eBooster unterbrochen ist.
#R23.4 Das Signal ESC_BLA muss bei einer Fahrerbremsung aus dem Drucksensorsignal im ESC gebildet werden
#R23.5 Das Signal ESC_BLA kann folgende Zustände einnehmen:
FALSE: Bremslicht wird nicht angesteuert
TRUE: Bremslicht wird angesteuert (im Falle von degradiertem eBooster oder Kommunikationsausfall oder aktivierten Zusatzfunktionen)
#R23.6 Das Signal ESC_BLA muss mit einer Hysterese umgesetzt werden, um ein Toggeln des Signals zu verhindern. Die Setz- und Rücksetzbedingungen werden projektspezifisch vereinbart.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 82
3.2.6 Schnittstelle zur Ansteuerung des Generators
Die Rekuperationsschnittstelle beschreibt den Umfang der SW-Signale, die zwischen einem ESC-System (ESC) und einem elektromotorisch getriebenen Antriebsstrang (Generator) für die Darstellung der Bremsmomentenbilanzierung (Brake Blending) während Rekuperation benötigt werden. Die Rekuperationsschnittstelle ist nur dann notwendig, wenn eine dieser zusätzlichen Funktionalitäten im Gesamtsystemverbund zu realisieren sind:
1. Erzeugen eines generatorischen Bremsmoments zum Verzögern des Fahrzeuges an den Antriebsachsen und Rückspeisung der entstehenden elektrischen Energie in die Fahrzeugbatterie
2. Bilanzierung zwischen dem generatorisch erzeugten Bremsmoment und dem mit der Reibungsbremse erzeugten Bremsmomentes.
Falls diese Funktionalität nicht benötigt oder gefordert ist, kann auf die Rekuperationsschnittstelle verzichtet werden. Die Rekuperationsschnittstelle mit ihren Signalen ist in
Bild 23 dargestellt. Die Rekuperationsschnittstelle enthält eine bidirektionale Kommunikation zwischen dem ESC und dem Generator.
Im Folgenden wird bei der Rekuperationsschnittstelle zwischen zwei Ansätzen unterschieden. Es muss projektspezifisch zwischen OEM und OES entschieden werden nach welchem Ansatz die Rekuperationsschnittstelle ausgeführt wird.
• Ansatz 1: Die Rekuperationsschnittstelle wird ohne Berücksichtigung des Schleppmoments realisiert. D.h. sowohl das verfügbare Rekuperationsmoment als auch das aktuell realisierte Moment beinhaltet nicht die Schlepprekuperation
• Ansatz 2: Die Rekuperationsschnittstelle wird mit Berücksichtigung des Schleppmoments realisiert. D.h. sowohl das verfügbare Rekuperationsmoment als auch das aktuell realisierte Moment beinhaltet die Schlepprekuperation, sodass ein weiteres Signal benötigt wird. Wichtiger Hinweis: Das ESC übernimmt aber hierbei nicht die Aufgabe die Schlepprekuperation durch einen aktiven Druckaufbau zu kompensieren. In dem beschriebenen Ansatz 2 muss der Fahrer den Anteil der Schlepprekuperation ausgleichen.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 83
Bild 23 Schnittstellen zur Ansteuerung des Generators
3.2.6.1 Übersicht Schnittstellenbeschreibung
ID Schnittstelle Aufgabe und Schnittstellen Inhalt
24 RecuBrakeTorqueRequest ESC Generator
Das Signal gibt die Anforderung des Bremssystems an das Rekuperationsmoment an.
25 RecuBrakeTorqueCap Generator ESC
Das Signal gibt das verfügbare Moment der E-Maschine an, welches der Antriebsstrang zur Verfügung stellen kann, um ein äquivalentes Bremsmoment zu erzeugen.
Ansatz 1: Das Signal beinhaltet nicht den Schleppmomentanteil
Ansatz 2: Das Signal beinhaltet den Schleppmomentanteil
26 RecuBrakeTorqueAct Generator ESC
Das Signal gibt das anliegende Moment der E-Maschine an.
Ansatz 1: Das Signal beinhaltet nicht den Schleppmomentanteil:
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 84
• Das Signal RecuBrakeTorqueDrag wird nicht benötigt
Ansatz 2: Das Signal beinhaltet den Schleppmomentanteil:
• zusätzliches Signal RecuBrakeTorqueDrag wird benötigt, um den Schleppmomentanteil aus dem aktuell realisierten Gesamtbremsmoment zu bereinigen.
27 RecuBrakeTorqueActDrag7 Generator ESC
Das Signal gibt das anliegende Schleppmoment der E-Maschine an.
Tabelle 12 : Übersicht Schnittstelle zwischen ESC und Generator
3.2.6.2 RecuBrakeTorqueRequest
3.2.6.2.1 Signalspezifikation
Richtung ESC Generator
Signalname RecuBrakeTorqueRequest
Einheit Nm
Typ Cont
Größe (Bits) 15
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 32767
Auflösung / Bit 1Nm
3.2.6.2.2 Anforderungen an das Signal
#R24.1 Das Bremsmoment muss positiv interpretiert werden.
#R24.2 Das Signal RecuBrakeTorqueRequest soll das für die Rekuperative Bremsung angeforderte Moment für den elektrischen Antriebsstrangs angeben.
7 Das Signal wird nur benötigt, wenn die Rekuperationsschnittstelle nach Ansatz 2 umgesetzt wird.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 85
#R24.3 Das Signal RecuBrakeTorqueRequest soll das angegebene Moment auf die Radebene beziehen.
#R24.4 Das Signal RecuBrakeTorqueRequest soll keine Schleppmomentenkompensation beinhalten.
3.2.6.3 RecuBrakeTorqueRequest_Q
3.2.6.3.1 Signalspezifikation
Richtung ESC Generator
Signalname RecuBrakeTorqueRequest_Q
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 3
Auflösung / Bit 1
3.2.6.3.2 Anforderungen an das Signal
#R24_Q.1 Das Signal RecuBrakeTorqueRequest_Q kann folgende Zustände einnehmen:
0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt.
3.2.6.4 RecuBrakeTorqueCap8
3.2.6.4.1 Signalspezifikation
8 Projektspezifisch kann auch entschieden werden, die Rekuperationssteuerung in ESC nur anhand der aktuell realisierte Rekuperationsbremsmoment umzusetzen. In diesem Fall ist das Signal nicht notwendig.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 86
Richtung Generator ESC
Signalname RecuBrakeTorqueCap
Einheit Nm
Typ Cont
Größe (Bits) 15
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 32767
Auflösung / Bit 1Nm
3.2.6.4.2 Anforderungen an das Signal
#R25.1 Bremsmoment muss positiv interpretiert werden.
#R25.2 Das Signal RecuBrakeTorqueCap soll das für die rekuperative Bremsung verfügbare Moment des elektrischen Antriebsstrangs angeben.
#R25.3 Das Signal RecuBrakeTorqueCap soll das angegebene Moment auf die Radebene beziehen.
#R25.4 Ansatz 1: Das anstelle des Verbrennungsmotors gelieferte Schleppmoment ist nicht in diesem Signal enthalten.
Ansatz 2: Das anstelle des Verbrennungsmotors gelieferte Schleppmoment ist in diesem Signal enthalten.
#R25.5 Das Signal RecuBrakeTorqueCap soll einen Gangwechsel von „D“ nach „N“ das nicht verfügbare Rekuperationspotential nachbilden.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 87
3.2.6.5 RecuBrakeTorqueCap_Q9
3.2.6.5.1 Signalspezifikation
Richtung Generator ESC
Signalname RecuBrakeTorqueCap_Q
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 3
Auflösung / Bit 1
3.2.6.5.2 Anforderungen an das Signal
#R25_Q.1 Das Signal RecuBrakeTorqueCap_Q kann folgende Zustände einnehmen:
0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt.
3.2.6.6 RecuBrakeTorqueAct
3.2.6.6.1 Signalspezifikation
Richtung Generator ESC
Signalname RecuBrakeTorqueAct
Einheit Nm
Typ Cont
9 Projektspezifisch kann auch entschieden werden, die Rekuperationssteuerung in ESC nur anhand der aktuell realisierte Rekuperationsbremsmoment umzusetzen. In diesem Fall ist das Signal nicht notwendig.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 88
Größe (Bits) 15
Zykluszeit [ms] 20
Phys. Min. -32767
Phys. Max. 32767
Auflösung / Bit 5Nm
3.2.6.6.2 Anforderungen an das Signal
#R26.1 Das Bremsmoment muss positiv interpretiert werden.
#R26.2 Das Signal RecuBrakeTorqueAct soll das für die rekuperative Bremsung aktuell anliegende Moment des elektrischen Antriebsstrangs angeben.
#R26.3 Das Signal RecuBrakeTorqueAct soll das angegebene Moment auf die Radebene beziehen.
#R26.4 Ansatz 1: Das Signal RecuBrakeTorqueAct soll keinen Schleppmomentenanteil beinhalten.
Ansatz 2: Das Signal RecuBrakeTorqueAct muss den Schleppmomentenanteil beinhalten.
3.2.6.7 RecuBrakeTorqueAct_Q
3.2.6.7.1 Signalspezifikation
Richtung Generator ESC
Signalname RecuBrakeTorqueAct_Q
Einheit -
Typ enum
Größe (Bits) 2
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 3
Auflösung / Bit 1
3.2.6.7.2 Anforderungen an das Signal
#R26_Q.1 Das Signal RecuBrakeTorqueAct_Q kann folgende Zustände einnehmen:
0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 89
1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt.
3.2.6.8 RecuBrakeTorqueDrag
3.2.6.8.1 Signalspezifikation
Richtung Generator ESC
Signalname RecuBrakeTorqueDrag
Einheit Nm
Typ Cont
Größe (Bits) 15
Zykluszeit [ms] 20
Phys. Min. -32767
Phys. Max. 32767
Auflösung / Bit 5 Nm
3.2.6.8.2 Anforderungen an das Signal
#R27.1 Das Bremsmoment muss positiv interpretiert werden.
#R27.2 Das Signal RecuBrakeTorqueDrag soll das anliegende Schleppmoment der E-Maschine an.angeben.
#R27.3 Das Signal RecuBrakeTorqueDrag soll das angegebene Moment auf die Radebene beziehen.
3.2.6.9 RecuBrakeTorqueDrag_Q
3.2.6.9.1 Signalspezifikation
Richtung Generator ESC
Signalname RecuBrakeTorqueDrag_Q
Einheit -
Typ enum
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 90
Größe (Bits) 2
Zykluszeit [ms] 20
Phys. Min. 0
Phys. Max. 3
Auflösung / Bit 1
3.2.6.9.2 Anforderungen an das Signal
#R27_Q.1 Das Signal RecuBrakeTorqueDrag_Q kann folgende Zustände einnehmen:
0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal nicht mehr oder noch gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 91
3.2.7 Handhabung von Signal-Qualifiers In der vorliegenden VDA-Empfehlung sind für ausgewählte Schnittstellensignale mit dem Datentyp „cont“ zusätzliche Qualifier-Signale definiert, die den Zustand bzw. die Gültigkeit der zugehörigen Nutzsignale angibt.
Jedes Qualifier kann folgende Zustände einnehmen:
• 0: NotInitialized (Nicht initialisiert): Dieser Zustand wird eingenommen, wenn das zugehörige Signal aufgrund fehlender Initialisierung nicht gebildet werden kann.
• 1: Normal (Normaler Betrieb): Dieser Zustand wird eingenommen, wenn das zugehörige Signal gebildet werden kann, und der Signalwert innerhalb der spezifizierten Toleranzen liegt.
• 2: Faulty (Fehler): Dieser Zustand wird eingenommen, wenn das zugehörige Signal zwar gebildet werden kann, aber der Signalwert außerhalb der spezifizierten Toleranzen liegt.
Die Umsetzung der Signal-Qualifiers kann auch projektspezifisch festgelegt werden, z.B. durch Umsetzung der Qualifier im Wertbereich der Nutzsignale oder durch Definition weiterer Zustände. Die vorliegende Spezifikation ist nur als Empfehlung zu interpretieren.
Allerdings hat der OEM als Systemintegrator dafür zu sorgen, bei abweichender Umsetzung der Signal-Qualifiers gemeinsam mit beiden OES (von eBooster und ESC) abzustimmen.
Für die Zustandsübergänge der Qualifiers wird folgendes empfohlen:
• Die Signal-Qualifier müssen nach einer definierten Zeit von „0: NotInitialized“ auf „2: Faulty“ gesetzt werden, damit das Empfängersystem über ungültige Signale informiert wird. Die Toleranzzeit für die Umschaltung kann projektspezifisch abgestimmt werden.
• Der Systemverbund reagiert auf ungültige Signale durch entsprechende Degradation. Dabei gilt im Allgemeinen, dass das Empfängersystem entscheidet darüber, welche Funktionalitäten noch dargestellt werden können. Die endgültige Definition und Umsetzung der Systemdegradation für jede einzelnes Signal-Qualifier ist nach den funktionalen Anforderungen des Empfängersystems (OES von eBooster oder ESC) und den Kundenanforderungen (OEM) projektspezifisch abzustimmen.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 92
Die angehängte Tabelle gibt nur ein Beispiel für die möglichen Degradationen.
Direction Signal Name Possible
ESC Degradation
Possible
eBooster Degradation
eB -> ESC BrakePedalApplied_Q No recuperation; no EBR
eB -> ESC sOutputRodDriver_Q No recuperation; no EBR
eB -> ESC pRunout_Q No HBB; no EBR
eB -> ESC sOutputRodAct_Q No recuperation; no EBR
eB -> ESC pForceBlendingPotential_Q No recuperation; no EBR
ESC -> eB VehicleSpeed_Q No EBR
ESC -> eB pMC1_Q No EBR
ESC -> eB pMCVirtual_Q No PFC
ESC -> eB qTargetExternal_Q No EBR
ESC -> Gen RecuBrakeTorqueRequest_Q No recuperation
Gen -> ESC RecuBrakeTorqueCap_Q No recuperation
Gen -> ESC RecuBrakeTorqueAct_Q No recuperation
Tabelle 13 Mögliche Degradationen im Systemverbund bei ungültigen Signalen
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 93
4 Funktionale Sicherheit Diese VDA-Empfehlung beschreibt eine mögliche Aufteilung der Teilfunktionen eines Bremsregelsystems bestehend aus eBooster und ESC.
Im Hinblick auf das Fahrzeug-Gesamtsystem muss die Funktionale Sicherheit gewährleistet sein. Die Betrachtung der Funktionalen Sicherheit erfolgt gemäß den Anforderungen der Norm ISO 26262 und bezieht sich im Kontext dieses Kapitels allein auf die E/E-Bestandteile (elektrisch und/oder elektronisch) des Bremsregelsystems.
Dieses Kapitel behandelt zunächst die Definition des Betrachtungsumfangs des Bremsregelsystems, sowie einen Vorschlag zur Definition der Items gemäß ISO26262-3. Es werden die für das Bremsregelsystem relevanten Gefährdungen und Risiken bestimmt und daraus die Sicherheitsanforderungen an die beteiligten Items abgeleitet.
Es handelt sich dabei um keine technische Vorgabe, sondern um eine Empfehlung eines möglichen Sicherheitskonzepts. Dabei werden Sicherheitsziele postuliert (angenommen) um ein sinnvolles und verständliches Sicherheitskonzept abzuleiten. Die Sicherheitsziele stammen weder aus einer Gefährdungs- und Risikoanalyse noch stellen sie einen zu erreichenden Stand der Technik dar. Die angenommenen Sicherheitsziele sind dabei möglichst realitätsnah formuliert und sind in ähnlicher Form in bereits laufenden Projekten zwischen OEM und OES anwendbar.
Insbesondere kann es weitere Sicherheitsziele geben, oder in dieser Empfehlung herangezogene Sicherheitsziele besitzen aus OEM-Sicht andere Risikobewertungen oder Attribute (z.B. FTTI, kritische Fehleramplitude).
Hintergrund dieses Vorgehens ist, basierend auf den angenommenen Gefährdungen und Risiken des Bremsregelsystems, ein Funktionales Sicherheitskonzept vorzuschlagen, welches selbst bei geänderten Risikoparametern übernommen werden kann (mit entsprechender Anpassung des ASIL, FTTI etc.).
4.1 Definition des Umfangs eines Bremsregelsystems
4.1.1 Motivation der Trennung des Bremsregelsystems in zwei Items
Vorschlag in dieser VDA-Empfehlung ist, den eBooster und das ESC als getrennte items zu definieren. Die Vorteile dieser Definition sind hierbei:
• es handelt sich um zwei getrennte Produkte (ggf. von unterschiedlichen Lieferanten)
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 94
• die Sicherheitsnachweise und Sicherheitsanalysen (FMEA, FTA etc.) können weitestgehend getrennt erfolgen, ohne dass u.U. sensible Informationen ausgetauscht werden müssen
• zur Darstellung der Sicherheitsnachweise müssen die Prozesse und Vorgehensweisen nicht abgestimmt werden
• damit entfällt auch für den OEM ein großer Teil des Abstimmungsaufwands zwischen den beiden Tier1
Trotz des Vorschlages, getrennte items zu definieren, wird in dieser VDA-Empfehlung ein Funktionales Sicherheitskonzept auf Ebene des Systemverbunds Bremsregelsystem erarbeitet, welches die Sicherheitsziele für die beteiligten Items definiert.
Ausgangssignale (Sendesignale) mit Sicherheitsrelevanz sind hierbei Sicherheitsanforderungen für das item, welches das Signal sendet.
Dies wiederum motiviert, ggf. vorhandene Ausfallraten etc. von Eingangssignalen (Empfangssignalen) nicht in entsprechende quantitative Analysen (FTA etc.) aufzunehmen, da der Nachweis der Funktionalen Sicherheit bereits beim Sender des Signals erfolgt.
Die konkrete Ausgestaltung des items wird bewusst offen gelassen wegen der Varianz an Sensorik und herstellerspezifischen Strategien der Item Definition z.B. bzgl. der Themen:
• notwendige externe Sensorik, ggf. deren Signalübertragung
• notwendige externe Aktorik (z.B. Bremslicht-Ansteuerung), ggf. deren Übertragung
• notwendige externe Sicherheitsmechanismen (z.B. Warnlampen / HMI)
Darüber hinaus soll den Zulieferern die Möglichkeit gegeben werden, evtl. bereits bestehende item Definitionen und Nachweise der Funktionalen Sicherheit der Einzelsysteme ESC bzw. eBooster unverändert übernehmen zu können.
Die Kommunikationsstrecke zwischen den beteiligten items eBooster und ESC (CAN / Flexray etc.) ist in Verantwortung des OEM. Es wird daher empfohlen, die Kommunikationsstrecke als eigenes Item in Verantwortung des OEM zu definieren.
Im Rahmen des Funktionalen Sicherheitskonzepts auf Ebene des Systemverbunds werden entsprechende Sicherheitsanforderungen an die Übertragungsstrecke gestellt, ebenso wie an die beteiligten Aktoren und weitere Systemelemente.
Ein Vorschlag für notwendige Sicherheitsmaßnahmen auf der Kommunikationsstrecke ist in Kap. 4.5 gegeben.
Zusammenfassung:
• basierend auf definierten Gefährdungen und Risiken wird ein Sicherheitskonzept für die Funktionen im Systemverbund entworfen.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 95
• die daraus abgeleiteten Sicherheitsanforderungen sind Sicherheitsziele für die einzelnen items eBooster bzw. ESC
• die beiden items können damit getrennt den Nachweis der funktionalen Sicherheit führen
4.1.2 Item Definition und Schnittstellen zu anderen Items
Folgendes Bild gibt einen Überblick über die vorgeschlagen Definition der einzelnen Items. Die Funktionen der Items ist Kapitel 2.1 zu entnehmen. Diese Definition sowie die Schnittstellenbeschreibung werden unverändert für die Item Definition übernommen.
Zusätzlich wird ein Architekturelement „Vehicle Infrastructure“ vorgeschlagen, welches die Anforderungen an den OEM zusammenfasst. Dieses Architekturelement zur Fahrzeug-Infrastruktur kann damit u.a. die Funktionalen Sicherheitsanforderungen bzgl. Spannungsversorgung und Kommunikationsbus (CAN / FlexRay) aufnehmen.
Bild 24 Bremsregelsystem mit den beteiligten Items eBooster und ESC sowie die Interfaces zu
den Architekturelementen in Verantwortung des OEM. Gegenüber der Funktionsarchitektur in Bild 1 wird lediglich ein zusätzliches
Architekturelement „Vehicle Infrastructure“ eingeführt um Sicherheitsanforderungen z.B. an die Spannungsversorgung oder Netzwerkkommunikation zu allokieren. HMI und BLA sind stark
projektabhängig, ggf. werden Interfaces (z.B. vom eBooster zum HMI) nicht verwendet.
Das zu betrachtende System beinhaltet somit folgende Items
• eBooster
• ESC
eBooster
ESC
HMIBLA -Coordinator
Generator
InterfaceBasic
functionality
Interface Recuperation
InterfaceExternal Brake
Request
InterfaceGenerator
InterfaceHMI eBooster
InterfaceHMI ESC
InterfaceBLA eBooster
InterfaceBLA ESC
DBR-FDriver Brake
Request – Brake Force
BFBBrake Force
Boost
PFC-EPedal Force
Compensation -Execution
EBR-EExternal Brake
Request -Execution
PRLPressure
Reduction Logic
BLA-FBrake Light
Activation Driver – Full System
HMI-eBHMI - eBooster
DBR-TDriver Brake
Request – Brake Torque
BTCBrake TorqueCoordinator
HBCHydraulic
Booster FailureCompensation
HBBHydraulic Brake
Boost
EBR-CExternal Brake
Request –Controller
BLA-BBrake Light
Activation Driver – Backup
HMI-EHMI - ESC
LDMLongitudinal
Dynamic Management
Basic Controller
ABS, TCS, VDC
SSHSystem State
Handling
SSHSystem State
Handling
VehicleInfrastructure
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 96
und die vom OEM zu verantworteten Architekturelemente
• BLA Coordinator
• HMI
• Generator
• Vehicle Infrastructure
Es bleibt dem OEM überlassen, diese Architekturelemente als eigene Items zu behandeln oder diese als Teilelemente von größeren Items zusammenzufassen. Im Weiteren werden BLA Coordinator, HMI, Generator, und Vehicle Infrastructure daher als Architekturelemente bezeichnet.
Besonders die Schnittstellen zum HMI und zum BLA Coordinator sind bekannt als stark projektabhängig. Um diese Schnittstellenempfehlung lösungsunabhängig zu halten, werden mögliche Schnittstellen vorgehalten, auch wenn sie im jeweiligen Projekt nicht genutzt werden.
4.2 Gefährdungen und Risiken des Bremsregelsystems
Es wurde keine explizite Gefährdungs- und Risikoanalyse gemäß den Anforderungen der Norm ISO 26262:2011 (vgl. ISO 26262-3:2011, Kapitel „Hazard Analysis and Risk Assessment“) durchgeführt.
Sicherheitsziele und Sicherheitskriterien wurden angenommen und stellen typische Anforderungen und Kriterien in Projekten zwischen OEM und OES dar.
Die dargelegten Sicherheitsziele stellen lediglich die Basis für das Funktionale Sicherheitskonzept dar und definieren ausdrücklich keinen Stand der Technik. Die Sicherheitsziele werden in dieser Empfehlung weder bestimmt noch explizit vorgegeben.
Ebenfalls werden allgemeingültige Formulierungen wie z.B. „adäquate Fahrerbewarnung“ verwendet um den notwendigen Spielraum für projekt- und regionsspezifische Definitionen zu eröffnen.
Ebenso werden keine sicherheitsrelevanten Fehleramplituden definiert. Fehlertolerante Zeitintervalle (FTTI) werden auf Sicherheitszielebene allgemeingültig mit X ms (für zu geringes Bremsmoment), Y ms (für ungewolltes bzw. zu hohes Bremsmoment), und Z ms (Gefährdungen, die zu einer Instabilität des Fahrzeugs führen) angenommen.
Die Erfüllung der folgend genannten Anforderungen stellt weder ein notwendiges noch hinreichendes Kriterium zur Erfüllung der Anforderungen der ISO26262 im jeweiligen Projekt dar. Die Erfüllung der ISO26262 ist ausnahmslos im jeweiligen konkreten Projekt zu leisten, basierend auf den im Projekt definierten Gefährdungen und Risiken und den daraus abgeleiteten Funktionalen Sicherheitsanforderungen.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 97
4.2.1 Zu geringes Bremsmoment während der Fahrt (max. ASIL D)
Gefährdung Risiko
G1.1 Zu geringes Bremsmoment bei Fahrerbremswunsch Annahme: Min. ax < 2,44 m/s² ASIL D Min. ax >= 6,43 m/s² QM
FTTI Annahme: X ms Hinweis: Diese Gefährdung gilt explizit auch für Produkte / Systeme, die Hydraulikvolumen verblenden.
max. ASIL D
G1.2 Zu geringes Bremsmoment bei Externem Bremswunsch (EBR = External Brake Request) * Kontrollierbarkeit ist im Einzelfall für jede Funktion zu prüfen und kann zu einer abweichenden Einstufung führen. Automatisierte Fahrfunktionen sind nicht Inhalt der Betrachtung und müssen gesondert bewertet werden.
FTTI Keine Annahme getroffen
max. ASIL A*
G1.3 Zu geringes (symmetrisches) Bremsmoment in Regelsituation ESC, ABS, oder TCS (Regelaufgabe kann nicht mehr wahrgenommen werden) Beispiel: ABS Bremsung, über Reduktion des Aussteuerpunkts wird max. Bremsmoment reduziert.
FTTI Keine Annahme getroffen
max. ASIL B
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 98
4.2.2 Ungewolltes oder zu hohes Bremsmoment während der Fahrt (max. ASIL D)
Gefährdung Risiko
G2.1 Ungewolltes (symmetrisches oder asymmetrisches) Bremsmoment ohne Fahrerbremswunsch, das zur Instabilität des Fahrzeugs führt
FTTI Annahme: Z ms
Weitere Annahme: eine ungewollte regenerative Bremsung mit max. 3m/s2 ist mit einer „QM“-Bewertung angenommen.
max. ASIL D
G2.2 Ungewolltes symmetrisches Bremsmoment ohne Fahrerbremswunsch unter Beibehaltung der Stabilität des Fahrzeugs (rein longitudinal)
FTTI Annahme: Y ms
max. ASIL C
G2.3 Zu hohes (symmetrisches) Bremsmoment in Regelsituation ESC, ABS, oder TCS . Beispiel: zu hohes regeneratorisches Bremsmoment in ABS Regelsituation (Rad kann blockieren trotz aktivem ABS)
FTTI Annahme: Y ms
max.
ASIL B
G2.4 Zu hohes symmetrisches Bremsmoment bei Fahrerbremswunsch unter Beibehaltung der Stabilität des Fahrzeugs (“Überbremsen”).
FTTI Annahme: Y ms
Weitere Annahme: eine zu hohe regenerative Bremsung mit max. 3m/s2 ist mit einer „QM“-Bewertung angenommen.
max.
ASIL A
G2.5 Zu hohes symmetrisches Bremsmoment bei Externem Bremswunsch unter Beibehaltung der Stabilität des Fahrzeugs (“Überbremsen”).
FTTI Annahme: Y ms
* Kontrollierbarkeit ist im Einzelfall zu prüfen und kann ggf. zu niedrigeren Einstufungen führen. Die o.g. Einstufungen stellen die Basis für das Funktionale Sicherheitskonzept dar. Zusatz „max“ da abhängig vom Inhalt des Externen Bremswunsches.
max. ASIL C*
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 99
4.2.3 Zu geringes Bremsmoment im Stillstand bei Fahreranwesenheit (QM)
Gefährdung Risiko
G3.1 Zu geringes Bremsmoment im Stillstand bei Fahreranwesenheit (mit Möglichkeit Bremsdruck zu erhöhen) Situation wird als allgemein kontrollierbar angenommen.
max. QM
G3.2 Zu geringes Bremsmoment im Stillstand bei Fahreranwesenheit (ohne Möglichkeit hydraulischen Bremsdruck zu erhöhen – Aktivierung der Feststellbremse möglich) Situation wird als allgemein kontrollierbar angenommen. Vermeiden des Rückrollens durch externe Maßnahme (Feststellbremse) möglich.
max. QM
4.2.4 Zu hohes Bremsmoment im Stillstand (QM)
Gefährdung Risiko
G4.1 Zu hohes Bremsmoment im Stillstand QM Einstufung gemäß VDA0305-100 (Kreuztausch Parkbremse).
max. QM
4.2.5 Keine Ansteuerung des Bremslichts (max. ASIL B)
Gefährdung Risiko
G5.1 Keine Ansteuerung des Bremslichts bei Externem Bremswunsch oder Fahrerbremsung** * Abhängig von E Parameter der entsprechenden Funktion
** nur anwendbar, wenn System eBooster + ESC die Funktion der Bremslichtansteuerung bei Fahrerbremsung übernimmt
max. ASIL B*
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 100
4.3 Funktionales Sicherheitskonzept
Im Rahmen des Funktionalen Sicherheitskonzepts werden im Folgenden die aus den angenommenen Gefährdungen und Risiken stammenden Anforderungen für das Bremsregelsystem definiert und auf die beteiligten Items allokiert. Diese Analyse erfolgt Schritt für Schritt für jedes einzelne Sicherheitsziel. Verwendete Dekompositionsansätze gemäß ISO26262:2011-9, Kapitel 5 werden erläutert und die entsprechenden redundanten Sicherheitsanforderungen definiert. Die entsprechende Dekomposition kann dabei auch über Item-Grenzen hinweg erfolgen.
Dieses Funktionale Sicherheitskonzept besitzt keinen Allgemeingültigkeitsanspruch, stellt jedoch eine mögliche Aufteilung der Anforderungen zwischen den beteiligten Items und Architekturelementen dar.
Es wird bewusst darauf verzichtet, die Funktionalen Sicherheitsanforderungen an die Items außerhalb des Bremsregelsystems mit einem ASIL-Attribut zu versehen. Grund hierfür ist die i.a. komplexe OEM-spezifische Fahrzeugarchitektur, die es nicht erlaubt, generell einem „HMI“ oder „BLA-Coordinator“ den entsprechenden ASIL zuzuweisen. Die Verwechslungs- und Fehlinterpretationsgefahr, z.B. direkte Verbindung eines ASIL auf „HMI“ mit einer ASIL-Anforderung für ein Kombi-Instrument, soll hiermit vermieden werden.
Dennoch sind die funktionalen Sicherheitsanforderungen an die Fahrzeugumgebung definiert, welche entsprechend der Fahrzeugarchitektur und dem Funktionalen Sicherheitskonzept im konkreten Projekt verfeinert werden müssen.
4.3.1 Sicherheitsziel G1.1: Vermeide ein zu geringes Bremsmoment bei Fahrerbremswunsch
Textuelle Beschreibung des funktionalen Sicherheitskonzepts für Sicherheitsziel G1.1
Die ASIL D Anforderung wird direkt auf die Items eBooster und ESC allokiert. Dabei ist die ASIL D Anforderung für das ESC eine bereits bekannte Anforderung aus dem ESC Sicherheitskonzept.
An das Item eBooster wird die ASIL D Anforderung, einen mechanischen Durchgriff zu gewährleisten, allokiert. Mit diesem mechanischen Durchgriff muss eine Mindestverzögerung von 2,44 m/s² erreicht werden. Die gleiche Anforderung wird auf das Basisbremssystem (OEM Verantwortung) allokiert, da die o.g. Anforderung nur in Kombination des Basisbremssystems mit dem betrachteten Systemverbund eBooster + ESC erfüllt werden kann. Da es sich hierbei um eine Anforderung an mechanische / hydraulische Komponenten handelt, ist keine Verfeinerung des Sicherheitskonzepts gemäß ISO26262 notwendig. Die ASIL D - Anforderung behält ihre Bedeutung bzgl. der Notwendigkeit der Validierung auf Systemebene.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 101
Die „verbleibende“ ASIL C Anforderung wird zwischen eBooster und ESC dekomponiert. Diese Dekomposition findet zwischen der Verstärkung im eBooster und der Wirksamkeit des Sicherheitsmechanismus HBC (Hydraulic Booster Failure Compensation) statt. Dieser Mechanismus wiederum bedingt die Erkennung der Nicht-Verstärkung im eBooster. Vorgeschlagen wird (wie in ISO26262 angedeutet) eine Dekomposition mit dem höheren ASIL auf dem Sicherheitsmechanismus:
ASIL C wird dekomponiert nach
ASIL A(C) für die Verstärkung des eBooster
UND
ASIL B(C) für Erkennung der Nicht-Verstärkung im eBooster, deren Kommunikation und die entsprechende Reaktion im ESC (Auslösung des HBC).
Diese Dekomposition ist nur gültig bei hinreichender Unabhängigkeit zwischen Verstärkung und Erkennung der Nicht-Verstärkung. Diese Unabhängigkeit ist mit dem Nicht-dekomponierten ASIL C nachzuweisen.
4.3.1.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G1.1
Hinweis zu den Toleranzzeiten für die dekomponierten Anforderungen #R1.1.2 ff.:
Da es sich um latente Fehler handelt, könnten hier theoretisch auch längere Fehlertoleranzzeiten (z.B. die mittlere Dauer eines Zündungszyklus) spezifiziert werden. Es wird hier jedoch aus Gründen der Erklärbarkeit des Funktionalen Sicherheitskonzepts die Fehlertoleranzzeit der ursprünglichen nicht dekomponierten Sicherheitsanforderung übernommen.
Item eBooster
Anf. ID ASIL Anforderung
#R1.1.1
D Der eBooster muss einen mechanischen Durchgriff gewährleisten um folgende Verzögerungsanforderung zu erfüllen: Min. ax >= 2.44 m/s².
FTTI X ms
#R1.1.2
A(C) Der eBooster muss die Verstärkung des Fahrerbremswunsches gewährleisten.
FTTI X ms
#R1.1.3 B(C) Der eBooster muss den Ausfall der Verstärkung des Fahrerbremswunsches sicher erkennen.
FTTI X ms
#R1.1.4 B(C) Der eBooster muss den Ausfall der Verstärkung des Fahrerbremswunsches sicher an das ESC kommunizieren
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 102
FTTI X ms
Fehleramplitude Signal HbcRequest fehlerhaft auf “FALSE”
Sicherer Zustand Keine Kommunikation auf dem Netzwerk mit adäquater Fahrerbewarnung
#R1.1.5 C Der eBooster muss gemeinsame Fehlerursachen (common causes) vermeiden, die gleichzeitig zu einem Ausfall der Verstärkung des Fahrerbremswunsches UND der Nichterkennung dieses Ausfalls führen
FTTI X ms
Hinweis:
Sollte Anforderung #R1.1.5 wegen unzureichender Unabhängigkeit nicht umgesetzt werden können, so kann die genannte Dekomposition in die Anforderungen #R1.1.2 und #R1.1.3 nicht durchgeführt werden. Eine mögliche Alternative ist die Erkennung der Nichtverstärkung und deren Kommunikation (Anforderungen #R1.1.3 und #R1.1.4) mit ASIL C zu belegen.
Item ESC Anf. ID ASIL Anforderung
#R1.1.6 B(C) Das ESC muss bei Empfang des Signals HbcRequest auf „TRUE“ die Verstärkung des Fahrerbremswunsches gemäß Kennlinie des HBC übernehmen.
FTTI X ms
Fehleramplitude HBC verstärkt nicht oder zu wenig
#R1.1.7 B(C) Das ESC muss bei Verlust der Kommunikation mit dem eBooster (mindestens bei Verlust des Signals HbcRequest) die Verstärkung des Fahrerbremswunsches gemäß Kennlinie des reduzierten HBC übernehmen.
FTTI X ms
Fehleramplitude HBC verstärkt nicht oder zu wenig Hinweis: ggf. muss diese Sicherheitsanforderung gegen die Sicherheitsanforderung #R2.4.4 priorisiert werden. Dies könnte mit Hinweis auf den höheren ASIL des ursprünglichen Sicherheitsziels (ASIL D in G1.1 gegenüber ASIL A in G2.4) zu einem Wegfall des HBC reduced führen (mit entsprechender adäquater Fahrerbwarnung) und damit zu einem Wegfall der Anforderung #R2.4.4.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 103
Architekturelement BLA Coordinator
Keine Anforderung
Architekturelement HMI
Anf. ID Anforderung
#R1.1.8 Das HMI muss die Fahrerwarnung gemäß Warn- und Anzeigekonzept gemäß des spezifizierten Funktionalen Sicherheitskonzepts umsetzen.
Architekturelement Generator
Anf. ID Anforderung
#R1.1.9
Der Generator muss das angeforderte Bremsmoment innerhalb der funktionalen Grenzen umsetzen. Annahme1: max. regeneratives Bremsmoment 3 m/s2 Annahme2: generatorisches Unterbremsen kann vom Fahrer durch Erhöhung des Fahrerbremswunsches kompensiert werden.
Architekturelement Vehicle Infrastructure
Anf. ID Anforderung
#R1.1.10
Die Spannungsversorgung der items eBooster und ESC muss entsprechend der funktionalen Anforderung zur Verfügung gestellt werden.
FTTI X ms
Fehleramplitude U < kleinste Versorgungsspannung bei der noch eines der items (eBooster, ESC, HMI) die Sicherheitsanforderungen noch erfüllen kann.
Sicherer Zustand Adäquate Fahrerbewarnung
#R1.1.11
Die items eBooster und ESC müssen Signale (insbesondere Statussignale) auf dem Netzwerk austauschen können.
FTTI X ms
Fehleramplitude Keine Kommunikation
Sicherer Zustand Adäquate Fahrerbewarnung.
4.3.2 Sicherheitsziel G1.2: Vermeide ein zu geringes Bremsmoment bei Externem Bremswunsch Textuelle Beschreibung des funktionalen Sicherheitskonzepts für Sicherheitsziel G1.2
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 104
Basierend auf der in diesem Dokument vorgeschlagenen Partitionierung der Funktion des Externen Bremswunsches (EBR = External Brake Request) werden an eBooster und ESC gleichermaßen Anforderungen mit ASIL A allokiert.
4.3.2.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G1.2
Item eBooster
Anf. ID ASIL Anforderung
#R1.2.1
A Der eBooster muss einen vom ESC geforderten Volumenstrom umsetzen.
FTTI Nicht definiert
Fehleramplitude Externer Bremswunsch (Notbremsfunktion) wird nicht oder unzureichend ausgeführt
Sicherer Zustand Adäquate Fahrerbewarnung, dass EBR Funktionen nicht verfügbar sind
Item ESC Anf. ID ASIL Anforderung
#R1.2.2 A Das ESC muss bei Empfang eines Externen Bremswunsches dem eBooster einen Ziel-Volumenstrom mittels der Interfacegröße qTargetExternal zur Verfügung stellen.
FTTI Nicht definiert
Fehleramplitude Externer Bremswunsch (Notbremsfunktion) wird nicht als Zielvolumenstrom qTargetExternal dem eBooster zur Verfügung gestellt
Sicherer Zustand Adäquate Fahrerbewarnung, dass EBR Funktionen nicht verfügbar sind
#R1.2.3 A Das ESC muss bei Empfang eines Externen Bremswunsches diesen korrekt zwischen dem eBooster (über die Interfacegröße qTargetExternal) und dem Generator verteilen.
FTTI Nicht definiert
Fehleramplitude Externer Bremswunsch (Notbremsfunktion) wird insgesamt zu gering angefordert (über qTargetExternal und/oder Generatoranforderung).
Sicherer Zustand Adäquate Fahrerbewarnung, dass EBR Funktionen nicht verfügbar sind
Architekturelement BLA Coordinator
Keine Anforderung
Architekturelement HMI
Anf. ID Anforderung
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 105
#R1.2.4 Das HMI muss eine Meldung des ESC oder des eBoosters auf dem Netzwerk, dass EBR Funktionen nicht mehr umgesetzt werden können, geeignet dem Fahrer kommunizieren.
FTTI Nicht definiert
Fehleramplitude Keine oder falsche Fahrerinformation
Sicherer Zustand rechtzeitige Benachrichtigung des Fahrers, dass EBR Funktionen nicht verfügbar sind
Architekturelement Generator
Anf. ID Anforderung
#R1.2.5
Der Generator muss das durch das ESC angeforderte Bremsmoment innerhalb der funktionalen Grenzen umsetzen.
Annahme1: max. regeneratives Bremsmoment 3 m/s2
Architekturelement Vehicle Infrastructure
Anf. ID Anforderung
#R1.2.6
Die Spannungsversorgung der items eBooster und ESC muss gemäß der funktionalen Anforderungen sichergestellt werden.
FTTI Nicht definiert
Fehleramplitude U < kleinste Versorgungsspannung bei der noch eines der items (eBooster, ESC, HMI) die Sicherheitsanforderungen noch erfüllen kann
Sicherer Zustand rechtzeitige Benachrichtigung des Fahrers, dass EBR Funktionen nicht verfügbar sind
#R1.2.7 Ein externer Bremswunsch einer Notbremsfunktion muss sicher auf dem Netzwerk kommuniziert und übertragen werden
FTTI Nicht definiert
Fehleramplitude U < kleinste Versorgungsspannung bei der noch eines der items (eBooster, ESC, HMI) die Sicherheitsanforderungen noch erfüllen kann
Sicherer Zustand rechtzeitige Benachrichtigung des Fahrers, dass EBR Funktionen nicht verfügbar sind
4.3.3 Sicherheitsziel G1.3: Vermeide ein zu geringes (symmetrisches) Bremsmoment in Regelsituation ESC, ABS, oder TCS (Regelaufgabe kann nicht mehr wahrgenommen werden). Textuelle Beschreibung des funktionalen Sicherheitskonzepts für Sicherheitsziel G1.3
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 106
Dieses Sicherheitsziel ist ein Spezialfall des Sicherheitsziels G1.1. Die dort vorgeschlagenen Konzepte können direkt übernommen werden zur Verhinderung des Unterbremsens. Übrig bleiben die Anforderungen bzgl. der Störung der Regelaufgaben der ESC, ABS und TCS Funktion.
4.3.3.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G1.3
Item eBooster
Anf. ID ASIL Anforderung
#R1.3.1
B Der eBooster darf in der ESC/ABS/TCS Regelsituation die Verstärkung nicht mehr zurücknehmen (z.B. über Variation des Aussteuerpunkts) als zur Erfüllung der Regelaufgabe notwendig ist.
Hinweis zur Erfüllung der Regelaufgabe ESC/ABS: ursprüngliches ABS-Niveau kann vom Bremsregelsystem immer noch erreicht werden, bzw. definierte ESC-Akzeptanztests müssen trotz Variation des Aussteuerpunkts erfüllt werden. TCS hier nicht relevant, da i.a. in Bremssituation nicht aktiv.
FTTI Nicht definiert
Fehleramplitude Zu hohe Absenkung des Aussteuerpunkts, die zu einem Bremsdruckniveau < ursprüngliches ABS-Niveau führt.
Sicherer Zustand Keine Absenkung des Aussteuerpunkts.
Item ESC Keine Anforderung aus dem Systemverbund für die Regelaufgabe selbst (ist nicht im Fokus dieser Betrachtung)
Anf. ID ASIL Anforderung
#R1.3.2
B Das ESC muss im Falle einer Variation des Aussteuerpunkts durch den eBooster in der ESC/ABS/TCS Regelsituation die HBB-Verstärkung so anpassen, dass die Erfüllung der jeweiligen Regelaufgabe noch gesichert ist.
Hinweis zur Erfüllung der Regelaufgabe ESC/ABS: ursprüngliches ABS-Niveau kann vom Bremsregelsystem immer noch erreicht werden, bzw. definierte ESC-Akzeptanztests müssen trotz Variation des Aussteuerpunkts erfüllt werden. TCS hier nicht relevant, da i.a. in Bremssituation nicht aktiv.
FTTI Nicht definiert
Fehleramplitude Zu geringe Anhebung der HBB-Verstärkung, die zu einem Bremsdruckniveau < ursprüngliches ABS-Niveau führt.
Sicherer Zustand Keine Absenkung des Aussteuerpunkts des eBoosters
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 107
#R1.3.3
B Das ESC muss im Fall einer regenerativen Bremsung das regenerative Moment so anpassen, dass die Erfüllung der jeweiligen Regelaufgabe noch gesichert ist.
Hinweis zu Erfüllung der Regelaufgabe ESC/ABS: ABS kann vom Bremsregelsystem immer noch geregelt werden (d.h. blockierte Räder können ggf. wieder anlaufen): Bei zu hoher regenerativer Bremsanforderung ist dies evtl. nicht mehr der Fall. TCS hier nicht relevant, da i.a. in Bremssituation nicht aktiv.
Architekturelement BLA Coordinator
Keine Anforderung
Architekturelement HMI
Keine Anforderung
Architekturelement Generator Anf. ID Anforderung
#R1.3.4
Der Generator muss das angeforderte Bremsmoment innerhalb der funktionalen Grenzen umsetzen.
Annahme1: max. regeneratives Bremsmoment 3 m/s2
Architekturelement Vehicle Infrastructure
Keine Anforderung
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 108
4.3.4 Sicherheitsziel G2.1 Vermeide ein ungewolltes (symmetrisches oder asymmetrisches) Bremsmoment ohne Fahrerbremswunsch, das zur Instabilität des Fahrzeugs führt. Textuelle Beschreibung des funktionalen Sicherheitskonzepts für Sicherheitsziel G2.1
Es wird angenommen, dass ein eBooster nur gleichzeitig in beiden Bremskreisen, den Fahrerbremswunsch verstärken kann. Es ist daher eine Anforderung an die eBooster-Architektur eine solche Asymmetrie zu vermeiden.
Ungewolltes symmetrisches Bremsmoment, das zur Instabilität des Fahrzeugs führt, kann nur bei einer ungewollten Bremsung durch den eBooster und einem Versagen einer entsprechenden Maßnahme im ESC (ABS/EBD Funktion) auftreten.
Es wird daher folgende Dekomposition der ASIL D – Anforderung vorgeschlagen:
ASIL B(D) für den eBooster und das ESC zur Vermeidung der ungewollten Bremsung ohne Fahrerbremswunsch
ASIL B(D) für das ESC die Stabilität zu gewährleisten.
Unabhängig von dieser Dekomposition muss für regeneratorisches Bremsmoment das ESC außerdem die Aufgabe übernehmen, das regeneratorische Moment soweit abzusenken, so dass die Regelaufgabe der ABS/EBD Funktion noch gegeben ist.
4.3.4.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G2.1
Item eBooster
Anf. ID ASIL Anforderung
#R2.1.1
B(D) Der eBooster darf ohne Fahrerbremswunsch oder ohne Externen Bremswunsch keinen Druckaufbau verursachen.
FTTI Z ms (Übernahme aus Sicherheitsziel G 2.1)
Sicherer Zustand Keine Verstärkungsfunktion des eBoosters und Senden von HBCRequest an ESC + Fahrerwarnung gemäß Warn- und Anzeigekonzept
Item ESC Keine Anforderung aus dem Verbundsystem für die Regelaufgabe selbst (ist nicht im Fokus dieser Betrachtung)
Anf. ID ASIL Anforderung
#R2.1.2
B(D) Das ESC muss im Falle einer ungewollten Bremsung die Stabilität des Fahrzeugs gewährleisten.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 109
Hinweis:
Dies beinhaltet i.a. die Darstellung einer ABS/EBD Funktion und die Reduktion des regeneratorischen Bremsmomentes wenn notwendig
FTTI Z ms (Übernahme aus Sicherheitsziel G 2.1)
Sicherer Zustand HBC Funktion nicht verfügbar + Fahrerwarnung gemäß Warn- und Anzeigekonzept
#R2.1.3
B(D) Das ESC darf ohne Fahrerbremswunsch und ohne Externen Bremswunsch keinen Druckaufbau verursachen.
FTTI Z ms (Übernahme aus Sicherheitsziel G 2.1)
Sicherer Zustand HBC Funktion nicht verfügbar + Fahrerwarnung gemäß Warn- und Anzeigekonzept
#R2.1.4
D Das ESC darf ohne Fahrerbremswunsch und ohne Externen Bremswunsch kein regeneratorisches Bremsmoment anfordern.
FTTI Z ms (Übernahme aus Sicherheitsziel G 2.1)
Sicherer Zustand Kein Senden eines regeneratorischen Moments + Fahrerwarnung gemäß Warn- und Anzeigekonzept
Architekturelement BLA Coordinator
Keine Anforderung
Architekturelement HMI
Keine Anforderung
Architekturelement Generator Anf. ID Anforderung
#R2.1.4
Der Generator darf ohne Ansteuerbefehl durch das ESC keinen ungewollten Bremsmomentenaufbau verursachen.
Die Kontrollierbarkeit ist im Einzelfall zu prüfen.
FTTI Nicht definiert
Fehleramplitude Stabilität des Fahrzeugs nicht gewährleistet
Sicherer Zustand Keine Ansteuerung des Generators, bzw. Generator ohne Funktion
Architekturelement Vehicle Infrastructure
Keine Anforderung
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 110
4.3.5 Sicherheitsziel G2.2 Vermeide ein ungewolltes symmetrisches Bremsmoment ohne Fahrerbremswunsch unter Beibehaltung der Stabilität des Fahrzeugs (rein longitudinal) Textuelle Beschreibung des funktionalen Sicherheitskonzepts für Sicherheitsziel G2.2
Ungewollte symmetrische Bremsmomente können sowohl vom eBooster, als auch vom ESC unabhängig voneinander verursacht werden. Die Sicherheitsanforderungen werden daher direkt auf die beteiligten Items allokiert. Eine Dekomposition ist hier nicht möglich.
Item eBooster
Anf. ID ASIL Anforderung
#R2.2.1
C Der eBooster darf ohne Fahrerbremswunsch und ohne Externen Bremswunsch keinen Druckaufbau verursachen.
FTTI Y ms (Übernahme aus Sicherheitsziel G 2.2)
Sicherer Zustand Keine Verstärkungsfunktion des eBoosters und Senden von HBCRequest an ESC + adäquate Fahrerbewarnung gemäß Warn- und Anzeigekonzept
Item ESC
Anf. ID ASIL Anforderung
#R2.2.2
C Das ESC darf ohne Fahrerbremswunsch oder ohne Externen Bremswunsch keinen Druckaufbau verursachen.
FTTI Y ms (Übernahme aus Sicherheitsziel G 2.2)
Sicherer Zustand HBC Funktion nicht verfügbar + adäquate Fahrerbewarnung Fahrerwarnung gemäß Warn- und Anzeigekonzept
#R2.2.3
QM Das ESC darf ohne Fahrerbremswunsch und ohne Externen Bremswunsch kein regeneratorisches Moment anfordern.
FTTI Nicht definiert
Sicherer Zustand Kein Senden eines regeneratorischen Moments + adäquater Fahrerbewarnung gemäß Warn- und Anzeigekonzept
Architekturelement BLA Coordinator
Keine Anforderung
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 111
Architekturelement HMI
Keine Anforderung
Architekturelement Generator Anf. ID Anforderung
#R2.2.4
Der Generator darf ohne Fahrerbremswunsch oder ohne Externen Bremswunsch keinen eigenständigen Bremsmomentenaufbau verursachen. Hinweis: hier wird ein max. regeneratorisches Moment äquivalent zu 3 m/s2
angenommen. Dies führt noch nicht zur Verletzung des Sicherheitsziels G2.2
Architekturelement Vehicle Infrastructure
Keine Anforderung
4.3.6 Sicherheitsziel G2.3: Vermeide ein zu hohes (symmetrisches) Bremsmoment in Regelsituation ESC, ABS, oder TCS (Regelaufgabe kann nicht mehr wahrgenommen werden). Textuelle Beschreibung des funktionalen Sicherheitskonzepts für Sicherheitsziel G2.3
Dieses Sicherheitsziel ist ein Spezialfall des Sicherheitsziels G2.4. Die dort vorgeschlagenen Konzepte können direkt übernommen werden zur Verhinderung des Überbremsens. Übrig bleiben die Anforderungen bzgl. der Störung der Regelaufgaben der ESC, ABS und TCS Funktion.
4.3.6.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G2.3
Item eBooster
Anf. ID ASIL Anforderung
#R2.3.1
B Der eBooster darf in der ESC/ABS/TCS Regelsituation die Verstärkung nicht höher einstellen, als der Fahrerbremswunsch (bzw. der Externe Bremswunsch)
Hinweis zur Erfüllung der Regelaufgabe ESC/ABS: Definierte ABS und ESC-Akzeptanztests müssen trotz Variation der Verstärkung erfüllt werden. TCS hier nicht relevant, da i.a. in Bremssituation nicht aktiv.
FTTI Nicht definiert
Fehleramplitude Regelaufgabe kann nicht mehr erfüllt werden
Sicherer Zustand Keine Änderung der Verstärkung oder sicherer Zustand gemäß Sicherheitskonzept für G2.1
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 112
Item ESC Keine Anforderung aus dem Verbundsystem für die Regelaufgabe selbst (ist nicht im Fokus dieser Betrachtung)
Anf. ID ASIL Anforderung
#R2.3.2
B Das ESC muss im Falle einer Änderung der Verstärkung durch den eBooster in der ESC/ABS/TCS Regelsituation die HBB-Verstärkung so anpassen, dass die Erfüllung der jeweiligen Regelaufgabe noch gesichert ist.
FTTI Nicht definiert
Fehleramplitude Regelaufgabe kann nicht mehr erfüllt werden
Sicherer Zustand Keine Änderung der HBB-Verstärkung oder sicherer Zustand gemäß Sicherheitskonzept für G2.1
#R2.3.3
B Das ESC muss im Fall einer regenerativen Bremsung das regenerative Moment so anpassen, dass die Erfüllung der jeweiligen Regelaufgabe noch gesichert ist.
FTTI Nicht definiert
Fehleramplitude Regelaufgabe kann nicht mehr erfüllt werden
Sicherer Zustand Keine regenerative Bremsung
Architekturelement BLA Coordinator
Keine Anforderung
Architekturelement HMI
Keine Anforderung
Architekturelement Generator Anf. ID Anforderung
#R2.3.4
Der Generator muss eine Reduktion des angeforderten Bremsmoments innerhalb der funktionalen Grenzen umsetzen.
Annahme: max. regeneratives Bremsmoment 3 m/s2
FTTI Nicht definiert
Fehleramplitude Regelaufgabe kann nicht mehr erfüllt werden
Sicherer Zustand Keine regenerative Bremsung
Architekturelement Vehicle Infrastructure
Keine Anforderung
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 113
4.3.7 Sicherheitsziel G2.4: Vermeide ein zu hohes symmetrisches Bremsmoment bei Fahrerbremswunsch unter Beibehaltung der Stabilität des Fahrzeugs (“Überbremsen”).
Textuelle Beschreibung des Funktionalen Sicherheitskonzepts für Sicherheitsziel G2.4
Die Anforderung beinhaltet den Fall der Doppelverstärkung („Double Boost“), d.h. die gleichzeitige Verstärkung des Fahrerbremswunsches in eBooster und ESC.
Die korrekte (in diesem Sicherheitsziel die nicht zu hohe) Umsetzung der Verstärkung mit dem maximalen ASIL A wird direkt auf den eBooster und das ESC allokiert.
Zur Vermeidung einer Doppelverstärkung in eBooster und ESC muss der eBooster dem ESC den korrekten Status mitteilen, damit das ESC nicht zusätzlich zum eBooster verstärkt. Im Falle eines Kommunikationsausfalls zwischen eBooster und ESC muss angenommen werden, dass der eBooster nach wie vor gemäß Spezifikation verstärkt. Die Verstärkung im ESC durch die HBC-Funktion muss damit ggf. geeignet reduziert werden um eine Überbremsung zu vermeiden.
4.3.7.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G2.4
Item eBooster
Anf. ID ASIL Anforderung
#R2.4.1
A Der eBooster darf den Fahrerbremswunsch nicht zu hoch verstärken
FTTI Y ms
Sicherer Zustand Umsetzung des Fahrerbremswunsches oder Nicht-Verstärkung des Fahrerbremswunsches mit Fahrerinformation gemäß Warn- und Anzeigekonzept.
#R2.4.2
A Der eBooster darf ESC nicht unberechtigt melden, dass eine Unterstützung notwendig ist (eBooster verstärkt dennoch)
FTTI Y ms
Sicherer Zustand Umsetzung des Fahrerbremswunsches oder Nicht-Verstärkung des Fahrerbremswunsches mit adäquater Fahrerbewarnung gemäß Warn- und Anzeigekonzept.
Item ESC
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 114
Anf. ID ASIL Anforderung
#R2.4.3 A Das ESC darf bei Empfang des Signals HbcRequest auf „FALSE“ keine Verstärkung des Fahrerbremswunsches ausführen
FTTI Y ms
Fehleramplitude ESC verstärkt fälschlicherweise (Doppelverstärkung) / Überbremsung
Sicherer Zustand Nicht-Verstärkung des Fahrerbremswunsches mit adäquater Fahrerbewarnung gemäß Warn- und Anzeigekonzept.
#R2.4.4 A Bei Ausfall der Kommunikation zwischen eBooster und ESC muss das ESC einen reduzierten HBC ausführen um mögliche Doppelverstärkung zu vermeiden.
FTTI Y ms
Fehleramplitude ESC verstärkt fälschlicherweise nicht im HBC Reduced (Doppelverstärkung)
Sicherer Zustand Nicht-Verstärkung des Fahrerbremswunsches mit adäquater Fahrerbewarnung gemäß Warn- und Anzeigekonzept.
Hinweis: ggf. muss diese Sicherheitsanforderung gegenüber der Sicherheitsanforderung #R1.1.7 aufgegeben werden. Dies könnte mit Hinweis auf den höheren ASIL des ursprünglichen Sicherheitsziels (ASIL D in G1.1 gegenüber ASIL A in G2.4) zu einem Wegfall des HBC reduced führen (mit adäquater Fahrerbewarnung) und damit zu einem Wegfall dieser Anforderung.
#R2.4.5 A Das ESC darf bei Empfang des Signals HbcRequest auf „TRUE“ oder bei Kommunikationsausfall keine zu hohe Verstärkung des Fahrerbremswunsches ausführen
FTTI Y ms
Fehleramplitude ESC verstärkt fälschlicherweise zu viel (Doppelverstärkung) / Überbremsung
Sicherer Zustand Nicht-Verstärkung des Fahrerbremswunsches mit adäquater Fahrerbewarnung gemäß Warn- und Anzeigekonzept.
Architekturelement BLA Coordinator
Keine Anforderung
Architekturelement HMI
Keine Anforderung
Architekturelement Generator
Anf. ID Anforderung
#R2.4.6
Der Generator darf kein höheres Moment absetzen als angefordert
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 115
Annahme1: max. regeneratives Bremsmoment 3 m/s2 Annahme2: generatorisches Überbremsen kann vom Fahrer durch Reduzierung des Fahrerbremswunsches kompensiert werden
Architekturelement Vehicle Infrastructure
Keine Anforderung
4.3.8 Sicherheitsziel G2.5: Vermeide ein zu hohes symmetrisches Bremsmoment bei Externem Bremswunsch unter Beibehaltung der Stabilität des Fahrzeugs (“Überbremsen”).
Textuelle Beschreibung des Funktionalen Sicherheitskonzepts für Sicherheitsziel G2.5
Die ASIL C Anforderung beschreibt die Überbremsung ohne die Möglichkeit der Kontrollierbarkeit durch den Fahrer.
Zur Vermeidung einer Doppelverstärkung in eBooster und ESC muss der eBooster dem ESC den korrekten Status mitteilen, damit das ESC nicht zusätzlich zum eBooster verstärkt. Im Falle eines Kommunikationsausfalls zwischen eBooster und ESC muss angenommen werden, dass der eBooster nach wie vor gemäß Spezifikation verstärkt. Die Verstärkung im ESC muss damit reduziert werden um eine Überbremsung zu vermeiden.
Es wird im Weiteren angenommen, dass die Umsetzung (Aktuierung) des Externen Bremswunsches nur durch den eBooster erfolgen kann. Damit darf bei Externem Bremswunsch ein HbcRequest nicht zu einer Aktivierung des HBC im ESC führen.
4.3.8.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G2.5
Item eBooster
Anf. ID ASIL Anforderung
#R2.5.1
C Der eBooster darf einen externen Bremswunsch nicht zu hoch ausführen bei korrektem Signal qTargetExternal
FTTI Y ms
Fehleramplitude Zu hohe Fahrzeugverzögerung / Überbremsung
Sicherer Zustand Nicht-Ausführung des externen Bremswunsches mit rechtzeitiger Fahrerinformation, dass externe Bremswünsche nicht ausgeführt werden können.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 116
Item ESC
Anf. ID ASIL Anforderung
#R2.5.2 C Das ESC darf bei Empfang eines externen Bremswunsches (ohne Fahrerbremswunsch) keinen HBC ausführen, auch wenn das Signals HbcRequest auf „TRUE“ steht
FTTI Y ms
Fehleramplitude HBC verstärkt fälschlicherweise. Zu hohe Fahrzeugverzögerung / Überbremsung
Sicherer Zustand Nicht-Ausführung des externen Bremswunsches mit rechtzeitiger Fahrerinformation, dass externe Bremswünsche nicht ausgeführt werden können.
#R2.5.3 C Das ESC darf bei Empfang eines externen Bremswunsches (ohne Fahrerbremswunsch) keinen zu hohen Volumenfluss qTargetExternal beim eBooster anfordern.
FTTI Y ms
Fehleramplitude Zu hohe Fahrzeugverzögerung / Überbremsung
Sicherer Zustand Nicht-Ausführung des externen Bremswunsches mit rechtzeitiger Fahrerinformation, dass externe Bremswünsche nicht ausgeführt werden können.
Architekturelement BLA Coordinator
Keine Anforderung
Architekturelement HMI
Keine Anforderung
Architekturelement Generator
Anf. ID Anforderung
#R2.5.4
Der Generator darf kein höheres Moment absetzen als angefordert
Annahme1: max. regeneratives Bremsmoment 3 m/s2 Annahme2: generatorisches Überbremsen kann vom Fahrer durch Reduzierung des Fahrerbremswunsches kompensiert werden
Architekturelement Vehicle Infrastructure
Anf. ID Anforderung
#R2.5.5 Es dürfen keine ungewollten Externe Bremswünsche an das Bremssystem übermittelt werden.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 117
FTTI Y ms
Fehleramplitude Zu hohe Fahrzeugverzögerung / Überbremsung
Sicherer Zustand Nicht-Ausführung des externen Bremswunsches mit rechtzeitiger Fahrerinformation, dass externe Bremswünsche nicht ausgeführt werden können.
4.3.9 Sicherheitsziel G3.1:Vermeide ein zu geringes Bremsmoment im Stillstand bei Fahreranwesenheit (mit Möglichkeit Bremsdruck zu erhöhen) Die Situation wird als kontrollierbar angenommen, daher ist kein Funktionales Sicherheitskonzept notwendig.
4.3.10 Sicherheitsziel G3.2:Vermeide ein zu geringes Bremsmoment im Stillstand bei Fahreranwesenheit (ohne Möglichkeit Bremsdruck zu erhöhen) -Fahrzeug rollt weg Textuelle Beschreibung des Funktionalen Sicherheitskonzepts für Sicherheitsziel G3.2
Das Sicherheitsziel ist ein Spezialfall des Sicherheitsziels G1.1 und ist komplett darüber abgedeckt. Kein spezielles Funktionales Sicherheitskonzept für den Fall des Fahrzeugstillstands notwendig.
Bremsmomente können hierbei als äquivalente Haltemomente angesehen werden.
4.3.11 Sicherheitsziel G4.1:Vermeide ein zu hohes Bremsmoment im Stillstand, durch Fahrer nicht über Gaspedal zu kontrollieren (Bremsmoment > mögliches Antriebsmoment) Textuelle Beschreibung des Funktionalen Sicherheitskonzepts für Sicherheitsziel G4.1
Das Sicherheitsziel ist ein Spezialfall der Sicherheitsziele G2.2, 2.4 und 2.5 und ist komplett darüber abgedeckt. Kein spezielles Funktionales Sicherheitskonzept für den Fall des Fahrzeugstillstands notwendig.
Bremsmomente können hierbei als äquivalente Haltemomente angesehen werden.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 118
4.3.12 Sicherheitsziel G5.1:Vermeide eine fehlende Ansteuerung des Bremslichts bei Externem Bremswunsch oder Fahrerbremsung Textuelle Beschreibung des Funktionalen Sicherheitskonzepts für Sicherheitsziel G5.1
Die Ansteuerung des Bremslichts bei Externem Bremswunsch ist Aufgabe des ESC, daher werden Sicherheitsanforderungen auf das ESC, die Fahrzeug-Infrastruktur und die Bremslichtansteuerung allokiert.
Die Ansteuerung des Bremslichts bei Fahrerbremswunsch ist Aufgabe des eBoosters, daher werden Sicherheitsanforderungen auf den eBooster, die Fahrzeug-Infrastruktur und die Bremslichtansteuerung allokiert
4.3.12.1 Abgeleitete Sicherheitsanforderungen für Sicherheitsziel G5.1
Item eBooster
Anf. ID ASIL Anforderung
#R5.1.1 B Der eBooster muss bei einem Fahrerbremswunsch eine notwendige Bremslichtansteuerung auf dem Netzwerk kommunizieren
FTTI Nicht definiert
Fehleramplitude Keine Kommunikation einer notwendigen Bremslichtansteuerung
Sicherer Zustand Nicht definiert
Item ESC
Anf. ID ASIL Anforderung
#R5.1.2 B Das ESC muss bei Empfang eines externen Bremswunsches eine notwendige Bremslichtansteuerung auf dem Netzwerk kommunizieren
FTTI Nicht definiert
Fehleramplitude Keine Kommunikation einer notwendigen Bremslichtansteuerung
Sicherer Zustand Nicht definiert
Architekturelement BLA Coordinator
Anf. ID Anforderung
#R5.1.3 Der BLA Coordinator muss bei Empfang einer notwendigen Bremslichtansteuerung auf dem Netzwerk diese umsetzen
FTTI Nicht definiert
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 119
Fehleramplitude Keine Umsetzung einer notwendigen Bremslichtansteuerung
Sicherer Zustand Nicht definiert
Architekturelement HMI
Keine Anforderung
Architekturelement Generator
Keine Anforderung
Architekturelement Vehicle Infrastructure
Anf. ID Anforderung
#R5.1.4 Die Vehicle Infrastructure muss die Kommunikation einer notwendigen Bremslichtansteuerung auf dem Netzwerk gewährleisten.
FTTI Nicht definiert
Fehleramplitude Bremslichtansteuerung wird nicht auf dem Netzwerk kommuniziert bzw. unterdrückt
Sicherer Zustand Nicht definiert
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 120
4.4 ASIL Einstufung relevanter Signale und Teilfunktionen
Die gemäß dieser Schnittstellenspezifikation relevanten Signale und Teilfunktionen haben unterschiedlichen Einfluss auf die im vorigen Kapitel aufgeführten Gefährdungen. In Bild 24 ist die jeweils abgeleitete maximale ASIL Einstufung dargestellt, die sich aus der Verbundfunktion und den definierten Anwendungsfällen ergibt. Bei den ASIL Allokationen wird ein maximales regeneratives Bremsmoment von 3 m/s2 vorausgesetzt. Eine Zusammenfassung der (maximalen) Risikobewertung von Basis-, Reku- und EBR-Schnittstelle ist in Tabelle 14 gezeigt. Eine detaillierte Darstellung mit Gefährdungen, Fehleramplitude und Fehlertoleranzzeiten der genannten Schnittstellen ist in Tabelle 15 zu finden. Alle Qualifier der Signale sind mit der korrespondierenden ASIL Einstufung des zugehörigen Signals bewertet und werden der Übersichtlichkeit halber nicht mitgeführt.
Betrachtungsumfang ist die Verbundfunktion der individuellen Items eBooster und ESC sowie die unmittelbar angrenzenden Funktionsblöcke.
Zum ESC Funktionsumfang gehörige Teilfunktionen, an denen der eBooster nicht beteiligt ist (z.B. Darstellung von ESC Zusatzfunktionen wie Hydraulischer Bremsassistent, Active Vehicle Hold etc.), wurden daher nicht bewertet.
Sicherheitsanforderungen an die Schnittstellensignale zwischen eBooster und ESC sind in ANNEX A1 (Schnittstellendetails, Funktionale Sicht) angegeben. Es wurden die betroffenen Gefährdungen mit den höchsten Risikoeinstufungen betrachtet. Daher wurden für einige Signalwerte von diskreten Schnittstellensignalen (z.B. Enums) ebenfalls keine expliziten Anforderungen definiert. Für Signale mit der Einstufung QM wurden keine Sicherheitsanforderungen spezifiziert. Sicherheitsanforderungen an die Funktionsblöcke sind nicht explizit angegeben. Sie leiten sich von den Anforderungen an die von ihnen generierten Ausgangssignale ab. Die hier angegebenen Analysen stellen eine Empfehlung dar. Die Vollständigkeit und Korrektheit muss über die projektspezifischen Sicherheitsanalysen gewährleistet werden.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 121
Tabelle 14 Maximale Risikobewertungen der Schnittstellensignale (Übersicht):
Schnittstelle Richtung des Signals Signalname max. ASIL
Basis
eB -> ESC
eBEspCompatibilityIndex QM HbcRequest B eBDiagActive QM BrakePedalApplied B pRunout B sOutputRodDriver C
ESC -> eB
VehicleSpeed C pMC1 B AbsActive B pEstMax QM
Reku
eB -> ESC pForceBlendingPotential QM sOutputRodAct C
ESC -> eB pMcVirtual QM pForceBlendingMc QM ForceBlendingActive QM
EBR eB -> ESC ExtReqPrio C
ExtReqStatus A
ESC -> eB qTargetExternal C qTargetExternal_Q C
Beachte: Die ASIL Einstufung der Signalqualifier korrespondiert mit den zugehörigen Signalen und wird aus Platzgründen nicht mitgeführt.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 122
Tabelle 15 Detaillierte Risikobewertungen der Schnittstellensignale inklusive Fehleramplitude und angenommenen Fehlertoleranzzeiten Sc
hnitt
stel
le
Ric
htun
g de
s Si
gnal
s Signalname Anforderungsbeschreibung (Haupt-)Gefährdung ASIL kritische
Fehleramplitude Fehlertoleranzzeit
Bas
is
eB ->
ES
C
eBEspCompatibilityIndex statische Nummer von eB- an ESC-Steuergerät, um Kompatibilität sicherzustellen n.a. QM - nicht spezifiziert
HbcRequest Anforderung an die HBC-Funktion bei fehlender Verstärkung im eBooster
G2.4 Zu hohes symmetrisches Bremsmoment aufgrund "Double Boost" A Fehlerhaftes Signal:
"TRUE" statt "FALSE" Y ms
G1.1 zu geringes Bremsmoment aufgrund der Nicht-Aktivierung von HBB/HBC B(C) Fehlerhaftes Signal:
"FALSE" statt "TRUE" X ms
eBDiagActive Information, ob sich der eBooster gerade im Diagnosemodus befindet - QM
Sicherheitsmaßnahme im ESC wird vorausgesetzt
Abhängig von Sicherheits-maßnahmen im ESC
BrakePedalApplied Übermittlung der Information, ob das Pedal vom Fahrer betätigt ist. Zur Fahrerbremswunscherkennung und LDM-Funktionen
G3.1 zu geringes Bremsmoment im Stillstand (z.B. HHC Funktion)
B Fehlerhaftes Signal: "TRUE" statt "FALSE" nicht spezifiziert
QM Fehlerhaftes Signal: "FALSE" statt "TRUE" nicht spezifiziert
pRunout Signal wird im ESC eingelesen, um mit der Funktion HBB den Fahrer oberhalb des Aussteuerpunkts zu unterstützen.
G2.4 Zu hohes symmetrisches Bremsmoment aufgrund "Double Boost" A zu niedriger Wert Y ms
G1.1 zu geringes Bremsmoment aufgrund der Nicht-Aktivierung von HBB/HBC B(C) zu hoher Wert X ms
sOutputRodDriver
Sollwert des Augangsstangensignals. Zusatzinformation für Fahrerbremswunscherfassung: • bei Reku. mit Volumenverblenden p_vor =|= Fahrerbremswunsch • zusätzliche Aktivierungs- bzw. Abbruchbedingun bei HBB, HBC,... aufgrund höherer eBooster-Steifigkeit
G1.2 zu geringes Bremsmoment (für spezielle regenerative Bremssysteme)
C zu niedriger Wert X ms
ES
C ->
eB
VehicleSpeed zur Stillstanderkennung im eBooster bzw. um Übergänge in den Stillstand zu berechnen. Dies wird wiederum für PRL (Bauteilschutz) bzw. für EBR benötigt
G1.1 zu geringes Bremsmoment aufgrund Komponentenschutz C Fehlerhafte
Stillstandserkennung Xms
pMC1 Signal entspricht dem aktuellen ESC-Vordrucksensorwert und wird für PRL (Bauteilschutz) und EBR benötigt
G1.1 zu geringes Bremsmoment (potentielles Signal für Komponentenschutz)
B (due to E2) zu niedriger Wert X ms
AbsActive Signaliert aktives ABS im ESC. Info über Systemsteifigkeit, um Pedalgefühl zu verbessern und für PRL
G1.1 zu geringes Bremsmoment (potentielles Signal für Komponentenschutz)
B (due to E2)
Fehlerhaftes Signal: "TRUE" statt "FALSE" X ms
B (due to E2)
Fehlerhaftes Signal: "FALSE" statt "TRUE" X ms
pEstMax max. Raddruck des geschätzten druckhöchsten Rades. Signal wird im eBooster eingelesen, um im ABS-Fall die Gegenkraft zu limitieren (PRL) und damit das Pedalgefühl zu verbessern.
- QM - nicht spezifiziert
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 123
Schn
ittst
elle
Ric
htun
g de
s Si
gnal
s Signalname Anforderungsbeschreibung (Haupt-)Gefährdung ASIL kritische Fehleramplitude Fehlertoleranzzeit
Rek
u
eB ->
ES
C pForceBlendingPotential
Übermittlung des aktuellen Potentials des eBoosters für die Pedalkraftkompensation. Das ESC kann anhand dieser Information die Anforderung an die Pedalkraftkompensation koordinieren.
- QM - -
sOutputRodAct
Übermittlung der aktuellen Wegposition der Ausgangsstange des eBooster. Die Größe ist relevant, um die Berechnung des tatsächlich verschobenen Volumens im Hauptbremszylinder zu realisieren.
G2.5 Zu hohes symmetrisches Bremsmoment bei EBR C zu hoher Wert Y ms
G1.2 zu geringes Bremsmoment (für spezielle regenerative Bremssysteme) C zu niedriger Wert X ms
ES
C ->
eB
pMcVirtual
Übermittlung des virtuellen Vordrucks auf Fahrerbrems-wunschbasis, da während Rekuperation der Systemdruck durch Volumenverblenden nicht mit dem Fahrerbrems-wunsch korreliert, muss ein Ersatzsignal im ESC gebildet und dem eBooster gesendet werden. Darstellung der Funktion Pedalkraftkompensation und Bremskraft-verstärkung während Rekuperation im eBooster.
- QM - -
pForceBlendingMc
Übermittlung des Zieldrucks, der gleichzeitig im ESC während Volumenverblenden als Zielgröße an die Hydraulik angefordert wird. Im eBooster wird durch Berechnung der Differenz zwischen pMcVirtual und pForceBlendingMC die notwendige Pedalkraftkompensation abgeleitet.
- QM - nicht spezifiziert
ForceBlendingActive Übermittlung des aktuellen Ansteuerwunsches (Aktivierungsbit) für die Funktion Pedalkraftkompensation. - QM - nicht spezifiziert
EBR
eB ->
ES
C
ExtReqPrio
Übermittlung der Information, ob der Fahrer oder der EBR das aktuelle Bremsmoment dominiert FALSE (EBR ist nicht aktiv oder Fahrer dominiert das Bremsmoment) TRUE (EBR ist aktiv und dominiert das Bremsmoment)
G2.2 ungewolltes symmetrisches Bremsmoment C Fehlerhaftes Signal:
1 statt 0 Y ms
ExtReqStatus Status der EBR Funktion als Erweiterung des HbcRequests
G1.2 Zu geringes Bremsmoment bei EBR (Notbremsassistent) A "Available" statt "not available" nicht spezifiziert
ES
C ->
eB
qTargetExternal Übermittlung des Zielwertes zur Ausführung des externen Bremswunsches im eBooster
G2.5 Zu hohes symmetrisches Bremsmoment bei EBR C zu hoher / ungewollter Wert
>3m/s2 Y ms
G1.2 Zu geringes Bremsmoment bei EBR (Notbremsassistent) A zu niedriger Wert nicht spezifiziert
qTargetExternal_Q Aktivierungsbit und Control-Mode für externen Bremswunsch über eB
G2.5 Zu hohes symmetrisches Bremsmoment bei EBR C
2 (qTarget_EBRmaxPerformance) statt 1 (qTarget_EBR)
Y ms
G1.2 Zu geringes Bremsmoment bei EBR (Notbremsassistent) A 0 (qTargetOff) statt 1 oder 2 nicht spezifiziert
Beachte: Die ASIL Einstufung der Signalqualifier korrespondiert mit den zugehörigen Signalen und wird aus Platzgründen nicht mitgeführt.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 124
4.5 Vorschlag zur Absicherung der Kommunikation auf dem Netzwerk
Für die Absicherung der Kommunikation auf dem Netzwerk trägt die Verantwortung der OEM. Folgende Sicherheitsmaßnahmen werden empfohlen:
Standardabsicherung (unabhängig vom ASIL)
o Überprüfung des DLC (Data Length Code) o Überwachung des Übertragungsprotokolls (CAN bzw. FlexRay)
- Vorschlag für max. ASIL A und ASIL B Signale
o Applikationszähler (Alive Counter) >= 1 bit o Applikations Checksumme Länge >= 1bit o Art der Checksumme: keine spezielle Empfehlung
- Vorschlag für max. ASIL C und ASIL D Signale
o Applikationszähler (Alive Counter) >= 4 bit o Applikations Checksumme Länge >= 8bit o Art der Checksumme: CRC-8 oder vergleichbar
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 125
Bild 25- Übersicht der Funktionsarchitektur des Systemverbunds eBooster/ ESC mit relevanten ASIL Einstufungen
(Maximum über alle Gefährdungen). Ein maximales regeneratives Bremsmoment von 3 m/s2 wird angenommen.
Regenerative Brake Actuator
HMIBrake Light
eBooster
ESC – Electronic Stability Control
SSH-e
BLA-F
Brake Light Activation Driver
– Full System
PRL
Pressure Reduction Logic
BFB
Brake Force Boost
DBR-F
Driver Brake Request – Brake Force
PFC-E
Pedal Force Compensation
- Execution
EBR-E
External Brake Request
- Execution
HMI-Y
HMI eB- Yellow Lamp
DBR-T
Driver Brake Request – Brake Torque
BTC
Brake Torque Coordinator
EBR-C
External Brake Request
- Controller
HMI-R
HMI ESC- Red Lamp
BLA-B
Brake Light Activation Driver
– Backup
HBC
Hydraulic Booster Failure Compensation
LDM
Longitudinal Dynamic Management
HBB
Hydraulic Brake Boost
HAC
Hydraulic Actuator Control
Bra
kePe
dalA
pplie
d
pRun
out
sOut
putR
odD
river
sOutputRodDriverSSC
Sensor Signal Chains
pMC
1
pEst
Max
pFor
ceBl
endi
ngP
oten
tial
sOut
putR
odA
ct
pMC
Virtu
al
pMC
Virtu
al
pFor
ceBl
endi
ngM
C
Forc
eBle
ndin
gA
ctiv
e
Ext
Req
Prio
Ext
Req
Sta
tus
qTar
getE
xter
nal
qTar
getE
xter
nal_
Q
sOut
putR
odD
river
Bra
kePe
dalA
pplie
d
sOut
putR
odD
river
System State Handling
- ESC
SSH-eB
System State Handling
- eB
Hbc
Req
uest
Veh
icle
Spe
ed
VehicleSpeed
HMI_ESC
Target_Driver
BrakeLight_On_Driver/Pressure_BLA
Target_LDM
Target_EBR
pTarget
pRun
out
HU
Hydraulic Unit
Pump_actuation
Ventil_actuation
HBC
_act
ivat
ion
Basic Contollers
VDCTCS
ABS
pTarget_Wheel (4x)pMC1
BLABrake Light Activation
eB_BLA
ESC_BLA
HMIHuman Machine
Interface
eB_HMI_WarningOn
ESC_HMI_WarningOn
Generator
Rec
uBra
keTo
rque
Act
Rec
uBra
keTo
rque
Req
uest
Brake Pedal
DriverDemand
Legend of signalsExternal decel. Request
Basic signals
EBR signals
Recuperation signals
ax/ Fx/ Mx
QM
DriverDemand
DBR_offset
PFC_offsetBrakeDemand_BFB
Bra
keD
eman
d_A
rb
HMI_iB
DriverDemand
EBR_active
DriverDemand
E-Motor
Electric Motor
BrakeDemand_Fin
QM
C
C B QM
QM
QM C
C
C C
B B
B QM
QM
C
B
C
B
C
C
A
C C C
BC
CC
C
D
B
C
C
ASIL Rating
A
A
ASIL Rating for System Modules
ASIL Rating for Signals
QM
QM B C D
B C D
EPB-CSSM
EPB HW Driver Controll
EPB
PBCEPB Actuation Control
Actuation_req
Actuator_ctrl
PBCOutOutofSpec
HPS
eBES
CC
ompa
tibili
tyIn
dex
Rec
uBra
keTo
rque
Cap
eBD
iagA
ctiv
e
B
QM
QMA
Interface between ESC&eBooster and external moduls
Internal signals of ESC/eBooster, only for concept explanation
D Stability_Info
pTarget_FRpTarget_FLpTarget_RRpTarget_RL
Abs
Activ
eB
C
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 126
5 Sicherheitsnachweise
5.1 FTA – Verantwortlichkeiten und Schnittstellenabstimmung
Gemäß der oben genannten Definition der beiden (getrennten) Items ist eine explizite Schnittstelle zwischen den beiden Tier1 nicht notwendig. Die FTA ist gemäß des in den Häusern der Tier1 definierten Vorgehens bzgl. FTA und Tailoring der ISO26262-Anforderungen zu erstellen (FTA rein qualitativ, oder quantitativ, für alle Sicherheitsziele >= ASIL C oder erweitert etc.). Dabei sind als Top Gates der FTA die allokierten Sicherheitsziele anzusetzen, die auch die Sicherheitsanforderungen an die Ausgangssignale umfassen.
Eine „gemeinsame“ FTA für das Verbundsystem oder Austausch von Fehlerraten ist damit nicht vorgesehen. Um zu belastbaren Aussagen zu kommen, müssten ohnehin Datenbasen, Fehlermodi, Berechnungsmethoden etc. abgestimmt werden. Diese Abstimmungen sind bei jeder Paarung der Tier1 ggf. neu zu veranlassen.
5.2 FMEA - Verantwortlichkeiten und Schnittstellenabstimmung
Für die Erstellung der System-FMEA jeder Partei aus dem eBooster /ESC -Kreuztausch gelten folgende Randbedingungen:
• Der OES des eBoosters und der OES des ESC erstellen eine eigene System-FMEA gemäß den funktionalen Verantwortlichkeiten und berichten den von ihr verantworteten Anteil am Bremsregelsystem direkt an den OEM.
• Es wird empfohlen die S-FMEAs (eBooster und ESC) entsprechend VDA-Empfehlung zu erstellen.
• Der Entwicklungsumfang jedes OES enthält nur Überwachungen (im Sinne von Diagnosen und Entdeckungsmaßnahmen im Kundenbetrieb) für den eigenen HW-Lieferanteil und den eigenen Funktionsanteil am Bremsregelsystem.
• Die Bewertungskataloge für die FMEA Kennwerte B (Bedeutung der Fehlerfolge), A (Auftretenswahrscheinlichkeit der Fehlerursache) und E (Entdeckungswahrscheinlichkeit der Fehlerursache, des Fehlers bzw. der Fehlerfolge) sind zu Beginn der FMEA-Arbeiten zwischen OEM und Kreuztauschparteien abzustimmen.
• B-Werte aus der Fahrzeug-FMEA werden vom OEM an die Kreuztauschparteien zu jedem Top-Fehler der System-FMEA eBooster und System-FMEA ESC übergeben bzw. mit dem OES abgestimmt.
• Nur dem OEM wird das Recht eingeräumt, in die einzelnen S-FMEAs Einsicht zu nehmen, jedoch nicht dem Kreuztauschpartner.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 127
5.2.1 Aufbau der FMEA Struktur Der Aufbau der FMEA-Struktur ist jedem OES überlassen. Es wird empfohlen, die allgemeinen Grundsätze zur FMEA-Erstellung nach VDA Band 4, Ringbuchkapitel 3 einzuhalten. Ggf. sind besondere Anforderungen des OEM zu berücksichtigen.
Die Schnittstelle zwischen System-FMEA eBooster und System-FMEA ESC muss dabei so gewählt sein, dass eine Abstimmung der Schnittstelleninhalte möglich ist.
Grundsätzlich lässt sich die Schnittstelle zwischen System-FMEA eBooster und System-FMEA ESC aus einer Kombination aus physikalischen und signalbasierten Schnittstellen ableiten (siehe Bild 26)
Bild 26 – Übertragungsverhalten (Fehlerpropagation) bei Fehler in den Eingangssignalen und
interne Fehleranalyse in den beteiligten Items
Die abstrakte Betrachtung in Bild 26 zeigt die Basis-Eingangssignale (Fehlerursachen) auf der linken Seite und die Fehlerfolgen auf Fahrzeug / Aktuatorebene bzw. Signalebene auf der rechten Seit (Fehlerfolgen). Struktur der FMEA Schnittstelle bzgl. des Signalaustausches (Darstellung ist schematisch und enthält nur einen Auszug der Signale, wie sie in Kapitel 3 beschrieben sind).
Wesentlich bei dieser Betrachtung ist die Unterscheidung zwischen der Fehlerpropagation bei Fehler in den Eingangssignalen und der internen Fehlerpropagation bei fehlerfreien Eingangssignalen. Beide Analysen sind innerhalb der getrennten FMEAs durchzuführen. In beiden Fällen sollten die Fehlerfolgen die Aktuator- und die Signal(ausgangs-)schnittstelle beinhalten.
DBR-FDriver Brake
Request – Brake Force
BFBBrake Force
Boost
PFC-EPedal Force
Compensation -Execution
EBR-EExternal Brake
Request -Execution
PRLPressure
Reduction Logic
BLA-FBrake Light
Activation Driver – Full System
HMI-eBHMI - eBooster
DBR-TDriver Brake
Request – Brake Torque
BTCBrake TorqueCoordinator
HBCHydraulic
Booster FailureCompensation
HBBHydraulic Brake
Boost
EBR-CExternal Brake
Request –Controller
BLA-BBrake Light
Activation Driver – Backup
HMI-EHMI - ESC
LDMLongitudinal
Dynamic Management
Basic Controller
ABS, TCS, VDC
SSHSystem State
Handling
SSHSystem State
Handling
Signal InterfaceESC in
(from eBooster / Generator)
Signal InterfaceeBooster in
(from ESC / Generator)
InterfaceActuator
(HMI / Generator)
InterfaceActuator
(HMI / Generator)
Fault propagation
Fault propagation
Fault freeSignal Interface
ESC in
Fault freeSignal Interface
eBooster in
Signal InterfaceeBooster out
(to ESC / Generator)
Signal InterfaceESC out
(to eBooster / Generator)
eBooster
ESC
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 128
5.2.2 Umgang mit Informationen an der Schnittstelle zwischen den FMEAs
In der Schnittstelle zwischen den beiden System-FMEA sind Informationen aus zwei verschiedenen Richtungen zur Verfügung zu stellen.
Von der System-FMEA, die Schnittstellensignale empfängt, sind folgende Informationen zu übergeben:
• B-Bewertungen • Amax_soll
Beispiel einer Fehlerursache auf Empfänger-Seite: „sOutputRodDriver – auf Null eingefroren“
• B = 10 (Fehlerfolge auf Empfängerseite) • Amax_soll = 1
Hinweis 1: Die hier eingetragenen Werte haben lediglich exemplarischen Charakter und erheben keinen Anspruch auf Richtigkeit.
Hinweis 2: Aufgrund der unterschiedlichen FMEA-Auswerteverfahren kann Amax_soll
abweichende Bedeutungen annehmen:
• Bei Verwendung der Risikoprioritätszahl RPZ berücksichtigt Amax_soll die im Projekt gesetzte RPZ-Grenze sowie die Entdeckungsmaßnahmen auf Empfänger-Seite.
• Bei Verwendung der Risikomatrix berücksichtigt Amax_soll die Vorgaben bzgl. der Kombination BxAmax_soll.
Von der System-FMEA, die Schnittstellensignale sendet, sind folgende Informationen zu übergeben:
• Beschreibung der TOP-Fehlerfolgen • Bestätigung der geforderten Amax_soll-Werte, jeweils aktualisiert zu den
geforderten OEM Freigaben
Erweiterung des obigen Beispiels auf Sender-Seite:
• TOP-Fehlerfolge „„sOutputRodDriver – auf Null eingefroren“ • Amax_soll = 1 bestätigt!
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 129
Der Austausch der Information soll über ein Schnittstellenblatt, z.B. in Form einer Exceltabelle erfolgen.
Bild 27 – Graphische Darstellung des Informationsaustauch zwischen den System FMEAs
eBooster und ESC
An der Schnittstelle zwischen den beiden System-FMEAs werden die Amax_soll-Werte zur Auftretenswahrscheinlichkeit der jeweils anderen Seite bestätigt. Eine Offenlegung der tatsächlich erreichten Werte erfolgt nicht.
Ist zwischen den beiden beteiligten OES keine Einigung zu erzielen, die zu einer hinreichend kleinen RPZ bzw. zu einer akzeptablen BxA-Kombination führt, dann ist der OEM in der Pflicht, an einer Lösung mitzuarbeiten.
Hinweis: Der Amax_soll-Wert ist in der System-FMEA des Signalempfängers ein Prognosewert für die Auftretenswahrscheinlichkeit der beschriebenen Fehlerursache im Kundenbetrieb.
Bei Verwendung der Risikoprioritätszahl soll dieser Wert aus der System-FMEA des Signalsenders separat durch Berücksichtigung von AxE berechnet werden. Der A-Wert aus der System-FMEA des Signalsenders entspricht in der Regel nur bei E=10 dem A-Wert für das Schnittstellenblatt.
Beispiel: Bei der Bedeutung einer Fehlerfolge von B=10 und fehlender Entdeckungsmaßnahme beim Signalempfänger (E =10) gilt ein Amax_soll = 1 als bestätigt (und somit RPZEmpfänger = 100), wenn z.B. die reale Auftretenswahrscheinlichkeit der zugehörigen Fehlerursachen beim Signalsender A ≤ 2 und die zugehörigen Entdeckungswahrscheinlichkeiten beim Signalsender E ≤ 6 sind.
Actuators (Severity on vehicle level)
FMEA FMEA
Requirement to signal ESCOut occurence (A_max_soll)Information on severity of failure effect (B rating in FMEA eBooster)
HMIBLA -Coordinator
Generator
eBooster ESC
Brakes (actuation / foundation)
Severity onvehicle level for affected
actuators
Approval of fulfillment of ESCOut occurence A_max_sollTop Failure effect on sender side (incl. B rating) in FMEA ESC)
Requirement to signal eBoosterOut occurence (A_max_soll)Information on severity of failure effect (B rating in FMEA ESC)
Approval of fulfillment of eBoosterOut occurence A_max_sollTop Failure effect on sender side (incl. B rating) in FMEA eBooster)
Severity onvehicle level for affected
actuators
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 130
Bei der Verwendung der Risikomatrix aus den FMEA-Kennwerten B und A ist zu Beginn des Projektes zwischen OEM und Signalsender abzustimmen, ob für A nur der Wert der Auftretenswahrscheinlichkeit ohne bzw. mit Berücksichtigung der Entdeckungsmöglichkeit durch den Signalsender verwendet werden soll.
5.3 „Metrikberechnungen“ gemäß ISO 26262
Alle quantitativen Analysen (Hardwaremetriken / Sicherheitszielverletzung durch zufällige Hardware-Fehler) werden auf den einzelnen Items durchgeführt. Ein Zusammenführen / Budgetierung der Metriken ist nicht sinnvoll, da mit diesen Analysen die jeweilige Hardware-Architektur bewertet wird
5.3.1 Hardware-Architekturmetriken gemäß ISO26262-5 Band 8
Die Hardware-Architekturmetriken gemäß ISO26262-5 Kapitel 8 („Evaluation of Hardware Architectural Metrics“) werden auf Itemebene pro Sicherheitsziel berechnet.
Jeder Lieferant berechnet auf seinem Item bzgl. der auf sein Item allokierten Sicherheitsziele die Hardware-Architekturmetriken. Dabei ist jedem Lieferant freigestellt, durch welche Methode und für welche Sicherheitsziele er diese Analyse durchführt gemäß des Lieferanten-spezifischen „Tailoring“ der ISO26262-Anforderungen.
Die in ISO26262-5 definierten Zielwerte sind einzuhalten.
5.3.2 Bewertung von Sicherheitszielverletzungen durch zufällige Hardwarefehler gemäß ISO26262-5 Band 9
ISO26262-5 Kapitel 9 („Evaluation of safety goal violations due to random hardware failures“) beschreibt zwei alternative Methoden des Nachweis, dass zufällige Hardwarefehler hinreichend sicher beherrscht werden. In diesem Schnittstellendokument soll daher bewusst keine Vorgabe gemacht werden, welche der beiden Methoden anzuwenden ist. Damit wird auch die PMHF Methode nicht vorgeschrieben.
In jedem Fall wird der Teil des Sicherheitsnachweis gemäß ISO26262-5 Band 9 auf den auf das Item allokierten Sicherheitszielen durchgeführt, eine Budgetierung ist nicht vorgesehen, da diese die PMHF Methode zwingend voraussetzt.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 131
6 Testkonzept Dieses Kapitel beschreibt eine Möglichkeit bei der Integration des eBoosters und des ESCs in das Fahrzeug, Software und Hardware lieferantenunabhängig zu testen, so dass auch weiterhin potentielle Fehler im Systemverbund rechtzeitig vor der Abgabe der Teilsysteme an den OEM entdeckt und abgestellt werden.
6.1 Indikator-Test Nach dem aktuellen Stand der Technik wird die Mehrzahl der ESCs für Bremssysteme mit einem konventionellen Vakuumbremskraftverstärker entwickelt und auch validiert. Durch den Einsatz eines eBoosters können sich Änderungen im Zusammenspiel und der Lastverteilung der beiden System-Komponenten eBooster und ESC ergeben. Eine generische Aussage über die Substitution eines Vakuumbremskraftverstärkers durch einen eBooster ist im Rahmen dieses Dokumentes nicht möglich. Aus diesem Grund soll ein Indikatortest die geforderten, durch Zusammenspiel von eBooster und ESC realisierten Funktionen, abprüfen und als Bewertungsgrundlage dienen. Gleichzeitig werden auch Abhängigkeiten, die sich aus der hydraulischen Schnittstelle zu den Radbremsen ergeben (Elastizität der Gesamtbremsanlage) mit berücksichtigt.
Es wird empfohlen hier teilaktive Funktionen zu berücksichtigen, bei denen es zu einer Überlagerung von eBooster und ESC kommt: Fahrer betätigt das Pedal, Im ESC werden Ventile und/oder Druckversorgung angesteuert, z.B. ABS, HBB, HBA… Darüber hinaus müssen zusätzlich Funktionen betrachtet werden, deren Betriebsbereich sich durch Eigenschaften des eBoosters gegenüber denen des Vakuumboosters geändert haben. Es sollte geprüft werden, ob es durch eine Verschiebung der Betriebsbereiche zu Überlagerungen mit anderen bereits bestehenden Funktionen kommt.
Anhand des Indikatortests sollen zum einen die funktionalen Auswirkungen bewertet werden. Muss eine bestehende Implementierung einer Funktion angepasst werden, und wenn ja wie müssen die Parameter dieser Funktion gewählt werden (Anpassen der Schwellwerte, Aktivierungsdauer, Abbruchbedingungen etc.).
Zum anderen sollen die Auswirkungen auf die Haltbarkeit bewertet werden. Anhand der durchgeführten Indikatortests soll überprüft werden, ob sich Änderungen ergeben die außerhalb des abgeprüften Belastungskollektivs des jeweiligen Designs liegen. Dabei wird davon ausgegangen, dass die von OES zu OES unterschiedlichen Designs auch individuelle Schädigungsmechanismen aufweisen.
Anhand der Bewertung des Indikatortests können zusätzliche Maßnahmen erforderlich werden, die im Laufe des Projekts zu berücksichtigen sind.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 132
6.2 Test Strategie für die Verifikation und Validierung Da der Systemverbund durch zwei OES-Anteile gebildet wird kann eine Freigabe nur durch die beiden OES (eBooster & ESC) erfolgen. Dieses Kapitel beschreibt die jeweiligen Freigabeumfänge der beiden OES. Im Rahmen der Empfehlung eBooster/ ESC Schnittstelle ist jeder OES nur für die Freigabe seiner Lieferumfänge verantwortlich.
Dennoch ist sichergestellt, dass vor einer abschließenden Freigabe das Gesamtsystem mit den endgültigen Software- und Hardwareständen auf Funktionalität und Robustheit getestet wird.
Zur systematischen Verifikation und Validierung ist im Rahmen des Testkonzepts eine Aufteilung der Teststufen auf die beiden OES erforderlich.
Bild 28 stellt das für die Entwicklung und Freigabe zugrundeliegende Entwicklungsmodell dar (V-Modell). Dieses ist die Basis für die Entwicklung und Freigabe der definierten Lieferumfänge eBooster und ESC und wird von beiden OES für die jeweils eigenen Lieferumfänge durchlaufen.
Bild 28 – Validierung und Verifikation gemäß V-Modell
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 133
6.2.1 Verifikation Es muss sichergestellt werden, dass zu den jeweiligen Entwicklungsstufen die geforderten Funktionen entsprechend der spezifizierten und mit dem OEM abgestimmten Anforderungen implementiert sind und Fehler in dieser Implementierung so früh wie möglich identifiziert werden. Dieses Ziel wird durch eine sinnvolle eindeutige Aufteilung der Testaufgaben und Verantwortungen zwischen den beiden OES unter Berücksichtigung der gängigen Standards und Qualitätsziele erreicht.
6.2.2 Validierung Es muss sichergestellt werden, dass die spezifizierten Anforderungen die jeweilige Funktion auch im Sinne des Anwenders hinreichend genau und lückenlos beschreiben.
Die Validierung erfolgt für beide Lieferumfänge durch den jeweiligen OES auf Basis der jeweiligen Anforderungen unter Einbeziehung der vereinbarten Schnittstelle.
6.2.3 Teststufen Üblicherweise werden Teststufen gebildet, die sich vom SW Entwicklungsprozess nach dem V-Modell (siehe Bild 28) ableiten. Die Hardware relevanten Teststufen unterliegt autark der jeweiligen OES-Verantwortung. Die Software relevanten Teststufen sind nach dem Schnittstellenkonzept für den jeweiligen Lieferumfang durchzuführen und liegen in der Verantwortung der jeweiligen OES.
6.2.4 Allgemeine Erläuterungen und Festlegungen zur Teststrategie Die Testaktivitäten sind je nach Entwicklungsstufe und Reifegrad des Projekts vom jeweiligen OES mit dem OEM abzustimmen und abzuleisten. Die Erstellung der Testkonzepte obliegt eBooster und ESC OES für ihre Lieferanteile.
Die Integration im Fahrzeug der beiden Lieferanteile des ESC-OES und des eBooster-OES obliegt dem OEM
6.2.5 Voraussetzungen für die Komponenten und Systemtests Da Abhängigkeiten zwischen dem eBooster und ESC bestehen, werden die folgenden Komponenten von den beteiligten Parteien zu Verfügung gestellt:
Vom OEM:
• Kommunikationsmatrix zur Restbussimulation durch die OES. (Empfehlung: Übermittelung in einem branchenüblichen Format wie z.B. dbc, Autosar XML oder Fibex)
• Der OEM stellt nach Vereinbarung eine dem vereinbarten Lieferstand entsprechende Integrationsumgebung an die OES (Fahrzeugmodell, Applikationsfahrzeug etc.).
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 134
Vom ESC OES:
• Bereitstellen der Kommunikationsmatrix zur Restbussimulation an den eBooster OES in dem vom OEM zur Auftragsvergabe spezifizierten Format zu jedem SW-Entwicklungsstand.
• Der ESC OES liefert ESC-HW und –SW entsprechend dem vereinbartem Lieferstand.
Vom eBooster OES: • Bereitstellen der Kommunikationsmatrix zur Restbussimulation an den ESC
OES in dem vom OEM zur Auftragsvergabe spezifizierten Format zu jedem SW-Entwicklungsstand.
• Der eBooster OES liefert eBooster-HW und –SW entsprechend dem vereinbartem Lieferstand.
6.2.6 Testaktivitäten Innerhalb der beschriebenen Schnittstelle ergeben sich folgende Testaufgaben:
• Test zum jeweiligen Lieferumfang • Test der Schnittstelle
Die Tests zum jeweiligen Lieferumfang liegen beim entsprechenden OES. Die Tests der Schnittstelle sind von beiden OES aus der jeweiligen Perspektive durchzuführen.
6.2.6.1 Testaktivitäten des eBooster OES Die Testaktivitäten für den Lieferanteil des eBooster unterliegen autark dem OES und sind mit dem OEM abzustimmen
• SW Komponententest (ENG6) SW Komponententests liegen in der Verantwortung des eBooster OES. Diese werden autark durch den eBooster OES durchgeführt.
• HW Komponententest (ENG6) HW Komponententests liegen in der Verantwortung des eBooster OES. Diese werden autark durch den eBooster OES durchgeführt.
• SW Integrationstest (ENG7) Die Integrationstests der eBooster SW Module liegen in der Verantwortung des eBooster OES. Diese werden autark durch den eBooster OES durchgeführt.
• HW Integrationstest (ENG7) Die HW Integrationstests des eBoosters liegen in der Verantwortung des eBooster OES. Diese werden autark durch den eBooster OES durchgeführt.
• SW Test (ENG8) Die SW Tests des eBoosters liegen in der Verantwortung des eBooster OES. Diese werden autark durch den eBooster OES durchgeführt.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 135
• System Integrationstests (ENG9) Die System Integrationstests des eBoosters liegen in der Verantwortung des eBooster OES. Diese werden autark durch den eBooster OES durchgeführt.
• Systemtest (ENG10) Die Systemtests des eBoosters liegen in der Verantwortung des eBooster. Hierzu muss der eBooster OES mit dem OEM eine geeignete Testumgebung, (Applikationsfahrzeug, Fahrzeugmodell etc.) abstimmen oder vom OEM bereitgestellt bekommen. Auffälligkeiten im Lieferumfang ESC werden an den ESC OES und den OEM kommuniziert.
6.2.6.2 Testaktivitäten des ESC OES Die Testaktivitäten für den Lieferanteil des ESC autark dem OES und sind mit dem OEM abzustimmen.
• SW Komponententest (ENG6) SW Komponententests liegen in der Verantwortung des ESC OES. Diese werden autark durch den ESC OES durchgeführt.
• HW Komponententest (ENG6) HW Komponententests liegen in der Verantwortung des ESC OES. Diese werden autark durch den ESC OES durchgeführt.
• SW Integrationstest (ENG7) Die Integrationstests der ESC SW Module liegen in der Verantwortung des ESC OES. Diese werden autark durch den ESC OES durchgeführt.
• HW Integrationstest (ENG7) Die HW Integrationstests des ESCs liegen in der Verantwortung des ESC OES. Diese werden autark durch den ESC OES durchgeführt.
• SW Test (ENG8) Die SW Tests des ESCs liegen in der Verantwortung des ESC OES. Diese werden autark durch den ESC OES durchgeführt.
• System Integrationstests (ENG9) Die System Integrationstests des ESCs liegen in der Verantwortung des ESC OES. Diese werden autark durch den ESC OES durchgeführt.
• Systemtest (ENG10) Die Systemtests des ESCs liegen in der Verantwortung des ESC OES. Hierzu muss der ESC OES mit dem OEM eine geeignete Testumgebung, (Applikationsfahrzeug, Fahrzeugmodell etc.) abstimmen, oder vom OEM bereitgestellt bekommen. Auffälligkeiten im Lieferumfang eBooster werden an den eBooster OES und OEM kommuniziert.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 136
6.2.6.3 Testaktivitäten des OEM Die Integration der beiden Lieferanteile des ESC OES und des eBooster OES zu dem Gesamtsystemverbund (Fahrzeug) obliegt dem OEM. Zum Gesamtsystemverbund gehören auch die bereits erwähnten Komponenten BLA-Coordinator, HMI, Generatorinterface und Funktionen, die erst im Gesamtsystemverbund getestet werden können wie z.B. Volume-Blending und Pedal Force Compensation.
6.2.6.4 Freigabeempfehlung des Gesamtlieferumfangs Der ESC OES und der eBooster OES sprechen für ihre jeweiligen Lieferanteile einzelne Freigabeempfehlung aus.
Die Freigabe des Gesamtsystemverbunds erfolgt durch den OEM.
Hierzu sind die Reifegrade der beiden OES-Anteile inklusive der Freigabe entsprechend der Entwicklungsstufen des OEM einzuhalten. In diesem Zusammenhang hat jeder OES den Reifegrad des eigenen Lieferumfangs zu den Freigabestufen mit dem OEM abzustimmen.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 137
6.3 Test Stellgenauigkeit eBooster Wie bereits in vorliegendem Dokument beschrieben wurde, kann der eBooster über die Schnittstelle qTargetExternal als externer Steller verwendet werden. Ein vom ESC geforderter Volumenfluss führt im eBooster zu einer Bewegung der Ausgangsstange und somit zu einem aktiven Druckaufbau in den Rädern.
Einerseits kann der eBooster für Funktionen genutzt werden, die eine hohe Druckstellgenauigkeit bzw. geringe Solldruckgradienten fordern wie z.B. ACC / CDD. Andererseits kann der eBooster für Funktionen eingesetzt werden, die eine hohe Druckaufbaudynamik fordern wie z.B. Fußgängerschutzfunktionen.
Um eine erste initiale Bewertung durchzuführen, ob der eBooster die funktionalen Anforderungen als Steller erfüllt, wird im Folgenden ein möglicher Test vorgeschlagen. Es wird empfohlen diesen Test in einer frühen Entwicklungsphase im Projekt durchzuführen.
Grundsätzlich gelten die im Projekt gültigen Lastenhefte, nach denen der Nachweis seitens eBooster erbracht werden muss. Daher ist das Vorgehen, die detaillierte Bewertung und der Zeitpunkt des Tests projektspezifisch zwischen OEM und OES abzustimmen.
6.3.1 Definition der Testsequenz und Testumgebung Es werden die in Bild 29 und Bild 30 dargestellten Rampenprofile als Solldruckvorgabe vorgeschlagen.
Vorgabe „Kleine Gradienten“
Bild 29 – Profil mit kleinen Gradienten
0 10 20 30 40 50 600
5
10
15
20
25
30
35
40
Time [s]
Pres
sure
[bar]
Pressure Profile
1 bar/s
1.5 bar/s
2.5 bar/s
-1 bar/s
-1.5 bar/s
-2.5 bar/s
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 138
Vorgabe „Mittlere Gradienten“
Bild 30 – Profil mit mittleren Gradienten
Um das gewählte Rampenprofil mit den definierten Druckgradienten abzuprüfen wird vorgeschlagen eine Testsequenz im ESC zu implementieren. Da der eBooster als Steller geprüft werden soll, wird empfohlen den Test im Open-Loop-Betrieb durchzuführen, d.h. ohne aktive Druckregelung im ESC.
Bild 31 zeigt das Wirkprinzip der Testsequenz. Dabei wird die Solldruckvorgabe durch die im ESC implementierte Testsequenz an das Modul EBR-C gesendet. Anhand der Steifigkeitsinformationen im Modul HAC kann der Zielvolumenstrom über das Signal qTargetExternal an den eBooster übermittelt werden.
Der Test kann sowohl im Fahrzeug (z.B. Stillstand) als auch in einer Prüfstandsumgebung durchgeführt werden. Es ist zu beachten, dass die für das jeweilige Projekt relevante pV-Kennlinie verwendet wird. Zudem soll das Lüftspiel in der Radbremse auf ein Minimum reduziert werden, indem zum Beispiel vor der Durchführung der Testsequenz manuell eingebremst wird.
Bild 31 – Sequenz zum Stellerverhaltentest
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 139
6.3.2 Bewertung Stellerverhalten
Bild 32 zeigt die relevanten Kenngrößen, die das Stellerverhalten charakterisieren.
Bild 32 – Kenngrößen zur Bewertung Stellerverhalten
Folgende Tabelle beinhaltet einen Vorschlag für mögliche Passed-Kriterien, die jedoch grundsätzlich projektspezifisch zwischen OEM und OES entsprechend den gültigen Lastenheften abzustimmen sind.
Kenngröße Beschreibung Wert
t1 Maximal zulässige Verzugszeit bis sich die eBooster Ausgangsstange bewegt
100ms
t2 Maximal zulässige Verzugszeit in der Haltephase bis die eBoosters Ausgangsstange steht (Verfahrweg = 0mm)
100ms
pPos / pNeg Maximal zulässige Druckabweichung beim Übergang in die Haltephase in Bezug auf den eingeschwungenen Istdruck
MIN (+/-1bar ODER +/-20%)
TarGradPos Maximal zulässige positive Druckabweichung Targ Grad * 1.2
TarGradNeg Maximal zulässige negative Druckabweichung Targ Grad * 0.8
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 140
7 Normative Referenzen
• Entwicklung des Systems in Übereinstimmung mit der ISO26262
• ECE R-13 (EU)
• ECE R-13H (Japan)
• ISO14229-1: Road vehicles - Unified diagnostic services (UDS) - Part1: Specification and requirements
• Hinweis zum Zertifizierungsprozess: o Falls nach dieser vorliegenden Empfehlung entwickelt wurde, ist es
grundsätzlich empfehlenswert einen Hinweis in den jeweiligen Gutachten auf die Einhaltung dieser vorliegenden Empfehlung zu geben.
o Zudem wird empfohlen bei der Dokumentation folgende normative Referenzen zu beachten: R13H Anhang8 R13 Anhang 18 R79 Anhang6 Gb21670 Annex
Hierdurch soll sichergestellt werden, dass sowohl die Gutachten für das Einzelteil als auch für den Systemverbund, beim Einsatz von „Kreuztausch betroffenen Teilen“ bei der Zertifizierung von komplexen elektronischen Systemen, anwendbar bleiben.
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 141
8 Glossar
0-km-Bereich Zeitbereich vor Fahrzeugauslieferung an Endkunden
ABS Antiblockiersystem
ACC Adaptive Cruise Control (radarbasierte Geschwindigkeitsregelanlage)
AEB Automatic Emergency Brake
ASIL Automotive Safety Integrity Level
AVH Automatic Vehicle Hold
BEV Battery Electric Vehicle
BFB Brake Force Boost (Bremskraftverstärkung)
BLA Brake Light Activation (Bremslichtansteuerung)
BLA-F Brake Light Activation – Full System
BLA-B Brake Light Activation – Backup
Black-Box Ist ein geschlossenes System unter Vernachlässigung des inneren Aufbaus. Im gegebenen Zusammenhang wird nur das äußere Verhalten über definierte Schnittstellen betrachtet. Die innere Struktur mag bekannt sein, darf aber nicht benutzt werden.
BLS Brake Light Switch (Bremslichtschalter)
BTC Brake Torque Coordinator
Cont Continuous Value (Numeric Data Type)
CRC Zyklische Redundanzprüfung (Cyclic-redundancy-check)
DBR Driver Brake Request (Fahrerbremswunsch)
DBR-F Driver Brake Request – Brake Force
(Fahrerbremswunscherkennung für die Berechnung der Bremskraftverstärkung seitens eBooster)
DBR-T Driver Brake Request – Brake torque
(Fahrerbremswunscherkennung für die Berechnung des Bremsmoments seitens ESC)
DS Drucksignal
EBR External Brake Request (Externer Bremswunsch)
EBR-E External Brake Request – Execution
EBR-C External Brake Request – Controller
ECU Electronic Control Unit (elektronisches Steuergerät)
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 142
EMV Elektromagnetische Verträglichkeit (EMC, Electro Magnetical Compatibility
enum Enumeration (Enumerated Type)
EPB Electric Parking Brake (Elektrisches Parkbremssystem)
ESC Electronic Stability Control (ESP, VSC, DSC,…)
ETA Event Tree Analysis (Ereignisbaumanalyse)
EV Electric Vehicle
Feld-Bereich Zeitbereich des Fahrzeugbetriebs bei Endkunde
FMEA Failure Modes and Effect Analysis (Fehlermöglichkeits und Einfluß Analyse)
FMEDA Failure Modes, Effects and Diagnostic Coverage Analysis
FTA Fault Tree Analysis (Fehlerbaumanalyse)
FUSI Funktionssicherheit (Functional Safety)
HBA Hydraulic Brake Assists
HBC Hydraulic Booster Failure Compensation
HDC Hill Descent Control
HEV Hybrid Electric Vehicle
HHC Hill Hold Control
HIL Hardware in the Loop
HMI Human-machine-interface
HMI-E Human-machine-interface - ESC
HMI-eB Human-machine-interface - eBooster
HW Hardware
eB eBooster
ISO International Standarization Organisation
LDM Longitudinal Dynamic Management
LH Lastenheft (Requirements Specification)
Log Logical Value (Boolean Data Type)
L/R Left/Right (Links/Rechts)
OBD On-Board Diagnosis
OES Original Equipment Supplier (Lieferant)
OEM Original Equipment Manufacturer (Fahrzeughersteller)
PFC Pedal Force Compensation
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 143
PFC-E Pedal Force Compensation – Execution
PMHF Probabilistic Metric of Random Hardware Failures
PRL Pressure Reduction Logic
RASI Responsible Accountable Support Inform (Verantwortlichkeits Matrix)
(R) verantwortlich für die Durchführung (eng. Responsible)
(A) Delegieren und Freigeben (eng. Accountable)
(S) Mitarbeit (eng. Support)
(I) zu Informieren (eng. Information).
RMI Roll Movement Intervention (Überschlagvorbeugung)
SSH-eB System State Handling - eBooster
SSH-E System State Handling - ESC
SW Software
SYS System
TCS Traction Control System
TMC Tandem Master Cylinder (Hauptzylinder)
VDA Verband der Automobilindustrie
VDI Verein Deutscher Ingenieure
VT Vehicle Test (Fahrzeugtest)
#R Requirement/Anforderung
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 144
9 Anhang
A1. Übersicht der Schnittstellensignale eBooster <-> ESC
Direction Signal Name Base Hev EBR Description Transfer cycle
Type Signal length
Range max. ASIL
eB->ESC eBESCCompatibilityIndex x Index to ensure the compateBility between eB and ESC software
20ms cont 4 Bit 0 - 15 QM
eB->ESC HbcRequest x With this signal eBooster requests the fail boost function of ESC
20ms logic 1 Bit 0: No HBC support requested (also to be sent as init value)
1: HBCFull support requested
B
eB->ESC eBDiagActive x eBooster must set this signal to "TRUE", if the eBooster is in diagnosis mode
20ms logic 1 Bit 0: eBooster diagnosis is inactive (also to be sent as initial value)
1: eBooster diagnosis is active
QM
eB->ESC BrakePedalApplied x Information about the driver attendance
20ms logic 1 Bit 0: brake pedal not applied
1: brake pedal applied
B
eB->ESC BrakePedalApplied_Q x Qualifier for BrakePedalApplied 20ms enum 2 Bit 0: NotInitialized
1: Normal
2: Faulty
B
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 145
eB->ESC sOutputRodDriver x Information of driver brake request.
Calculation of:
- target value for the output rod in eBooster
Also shows pedal travel with active pressure increase via eBooster
10ms cont 12 Bit -5...47 mm C
eB->ESC sOutputRodDriver_Q x Information about the signal quality of sOutputRodDriver
10ms enum 2 Bit 0: NotInitialized
1: Normal
2: Faulty
C
eB->ESC pRunout x During driver braking: maximum achievable master cylinder pressure with boost (runout)
With an active pressure increase: maximum achievable brake master cylinder pressure.
20ms cont 8 Bit 0 - 250bar B
eB->ESC pRunout_Q x Qualifier for pRunout 20ms enum 2 Bit 0: NotInitialized
1: Normal
2: Faulty
B
ESC->eB VehicleSpeed x Averaged wheel speed of the driven axle
20ms cont 8 Bit 0 - 100m/s C
ESC->eB VehicleSpeed_Q x Qualifier for VehicleSpeed 20ms enum 2 Bit 0: NotInitialized
1: Normal
2: Faulty
C
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 146
ESC->eB pMC1 x Current pressure of the master cylinder pressure sensor in the ESC. Raw value without offset compensation.
10ms cont 10 Bit -30 – 276 bar B
ESC->eB pMC1_Q x Information about signal quality of pMC1.
10ms enum 2 Bit 0: NotInitialized
1: Normal
2: Faulty
B
ESC->eB AbsActive x Indicates that at least one wheel ABS is in control.
10ms logic 1 Bit 0: no ABS
1: ABS active
B
ESC->eB pEstMax x Maximum of the estimated wheel pressures.
20ms cont 8 Bit 0 - 250bar QM
ESC->eB pMcVirtual x Virtual master cylinder pressure caluclated in ESC based on sOutputRodDriver. The signal is always stroke based and during pure hydraulic braking it represent nearly the real master cylinder pressure. During recuperation, it is a virtual value. While EBR the signal has also a valid value and represent the virtual pressure e.g. during blending while CDD over EBR.
10ms cont 10 Bit 0 - 250bar QM
ESC->eB pMcVirtual_Q x Qualifier for pMcVirtual 10ms enum 2 Bit 0: NotInitialized
1: Normal
2: Faulty
QM
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 147
eB->ESC sOutputRodAct x x Current value for output rod in eBooster indicates the shifted volume in master cylinder. Gives information, if the compensation port is closed.
Includes e.g. the pedal force compensation control for Hev.
10ms cont 12 Bit -5...47 mm C
eB->ESC sOutputRodAct_Q x x Information about the signal quality of sOutputRodAct
10ms enum 2 Bit 0: NotInitialized
1: Normal
2: Faulty
C
eB->ESC pForceBlendingPotential x Represent the potential of eBooster pedal force compensation as pressure.
Consider the DRR adjustment due to mechanical limitations and current pressure.
20ms cont 8 Bit 0 - 125bar QM
eB->ESC pForceBlendingPotential_Q x Qualifier for pForceBlendingPotential
20ms enum 2 Bit 0: NotInitialized
1: Normal
2: Faulty
QM
ESC->eB pForceBlendingMC x Target value of master cylinder pressure used by force blending function. Can differ from real master cylinder pressure, to avoid short peaks and disturbances which should not be compensated by force-blending
10ms cont 10 Bit 0 - 250bar QM
ESC->eB pForceBlendingMC_Q x Qualifier for pForceBlendingMC 10ms enum 2 Bit 0: NotInitialized
1: Normal
2: Faulty
QM
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 148
ESC->eB ForceBlendingActive x Control state of force-blending interface to activate or hold the pedal force compensation.
10ms enum 2 Bit 0: PFC_inactive
1: PFC_hold
2: PFC_active
QM
eB->ESC ExtReqStatus x Status of external brake request (EBR) function
10ms enum 3 Bit 0: EBR_NotInitialized
1: EBR_NotAvailable
2: EBR_Available
A
eB->ESC ExtReqPrio x Flag to signal if driver request or external brake request is dominating
10ms logic 1 Bit 0: EBR not dominate the brake torque
1: EBR dominates the brake torque
C
ESC->eB qTargetExternal x Target volume flow for external brake request (EBR) by eBooster
10ms cont 16 Bit -252 – 252 ml/s C
ESC->eB qTargetExternal_Q x Enable bit for qTargetExternal 10ms enum 2 Bit 0:qTarget_Off
1:qTarget_EBR
2:<undefined>
3:<undefined>
C
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 149
A2 Übersicht der Schnittstellensignale Vehicle Infrastructure Direction Signal Name Description Transfer
cycle Type Signal
length Range
eB->HMI eB_HMI_WarningOn With this signal eBooster requests the warning lamp in the dashboard
20ms logic 1 Bit 0: No request to the warning lamp 1: Warning lamp requested
ESC->HMI ESC_HMI_WarningOn With this signal ESC requests the warning lamp in the dashboard
20ms logic 1 Bit 0: No request to the warning lamp 1: Warning lamp requested
eB->BLA eB_BLA With this signal eB requests the brake light activation
20ms logic 1 Bit 0: No request to the brake light 1: Brake light requested
ESC->BLA ESC_BLA With this signal ESC requests the brake light activation
20ms logic 1 Bit 0: No request to the warning lamp 1: Warning lamp requested
ESC->Generator RecuBrakeTorqueRequest Represents the current requirement of the brake system to regenerative brake moment
20ms cont 15 Bits 0 - 32767 Nm
ESC->Generator RecuBrakeTorqueRequest_Q Qualifier for RecuBrakeTorqueRequest 20ms enum 2 Bits 0: NotInitialized 1: Normal 2: Faulty
VDA-Empfehlung 360 Version 1.0 Dezember 2016 Seite 150
Generator->ESC RecuBrakeTorqueCap Represents the potential of the electrical drivetrain in providing regenerative brake moment.
20ms cont 15 Bits 0 - 32767 Nm
Generator->ESC RecuBrakeTorqueCap_Q Qualifier for RecuBrakeTorqueCap 20ms enum 2 Bits 0: NotInitialized 1: Normal 2: Faulty
Generator->ESC RecuBrakeTorqueAct Represents the actually effective regenerative brake torque from the electrical drivetrain.
20ms cont 15 Bits -32767 - 32767 Nm
Generator->ESC RecuBrakeTorqueAct_Q Qualifier for RecuBrakeTorqueAct 20ms enum 2 Bits 0: NotInitialized 1: Normal 2: Faulty
Generator ->ESC
RecuBrakeTorqueActDrag The signal shows the applied drag torque of the electrical machine.
20 ms cont 15 Bits -32767 - 32767 Nm
Generator ->ESC
RecuBrakeTorqueActDrag_Q Qualifier for RecuBrakeTorqueActDrag 20 ms enum 2 Bits 0: NotInitialized 1: Normal 2: Faulty