Das Elektrofahrzeug als flexibler Verbraucher undEnergiespeicher im Smart HomeZur Erlangung des akademischen Grades einesDoktors der Ingenieurwissenschaften(Dr.-Ing.)von der KIT-Fakultät für Wirtschaftswissenschaftendes Karlsruher Instituts für Technologie (KIT)genehmigteDISSERTATIONvonMarc MültinTag der mündlichen Püfung: 18.07.2014Referent: Prof. Dr. Hartmut SchmeckKorreferent: Prof. Dr. Hansjörg Fromm2014 KarlsruheABSTRACTIm Zuge der Nachhaltigkeit eines zukünftigen Individualverkehrs sowie der Verfolgung diverserwirtschafts- und energiepolitischer Ziele wird die Elektromobilität sowohl von der Bundesregie-rung als auch international derzeit intensiv gefördert. Unter den energiepolitischen Zielen istu. a. eine saubere Art der Energieerzeugung durch bspw. Photovoltaik- und Windenergieanla-gen und somit eine Abkehr von nuklearen bzw. fossilen Energieträgern zu verstehen. Jedochsind die Zeiträume der höchsten Erzeugungsrate durch solche Anlagen und der stärkstenAbnahmemenge elektrischer Energie über den Tag gesehen oftmals nicht deckungsgleich. Diesewetterbedingte Volatilität induziert einen nötigen Paradigmenwechsel hinsichtlich der Nutzungdes Energienetzes: weg von einem zentralistischen verbrauchsorientierten Produktionssystem,hin zu einem dezentralen erzeugungsorientierten Verbrauchssystem, bei welchem der Nutzerseinen elektrischen Energiebedarf mehr an der Verfügbarkeit regenerativ erzeugten Stromsausrichtet. Eine dezentralisierte Infrastruktur aus Energiespeichern mit hohem Wirkungsgradwäre eine geeignete Lösung für eine Entkopplung der Verfügbarkeit elektrischer Energie undderen Verbrauch. Eine Möglichkeit stellen mobile Energiespeicher dar, wie sie in Elektro-fahrzeugen in Form von Traktionsbatterien zu finden sind. Diese Elektrofahrzeuge müssenjedoch auf geschickte Weise in das Stromnetz integriert werden, sodass viele gleichzeitigladende E-Fahrzeuge das Netz nicht überlasten, sondern stattdessen als netzstützende undstabilisierende Speicher und Verbraucher agieren können.Die vorliegende Arbeit beschäftigt sich daher mit der Integration eines rückspeisefähigenElektrofahrzeugs in das Energiemanagement-System eines mit kommunikationsfähigen Kom-ponenten ausgestatteten Haushalts (Smart Home). Ziel ist es, das Elektrofahrzeug bestmöglichals flexibel steuerbaren Verbraucher und Energiespeicher zu nutzen und somit die lokaleEigenstromnutzung zu maximieren sowie Stromkosten zu senken. Basierend auf externenzeitvariablen Strompreis- sowie Lastbegrenzungssignalen, die die aktuelle Netzsituation in ge-eigneter Weise abbilden, Benutzervorgaben sowie technischen Restriktionen wird mittels einesevolutionären Algorithmus der Gesamtlastgang dieses Smart Home kostenbasiert optimiert.Der Informationsaustausch zwischen E-Fahrzeug und Energiemanagement-System wird überden Kommunikationsstandard ISO/IEC 15118 realisiert, welcher erstmals die Übermittlungenergierelevanter Mehrwertinformationen und somit einen flexibel steuerbaren Lade- wie auchRückspeisevorgang ermöglicht.Aus einem makroskopischen Blickwinkel heraus wird zusätzlich die Realisierung einesbenutzerfreundlichen E-Roaming-Verfahrens, welches es dem Elektromobilisten erlaubt, un-abhängig von seinem Stromliefervertrag die Batterie seines Elektrofahrzeugs anbieter- undländerübergreifend an öentlicher Ladeinfrastruktur aufzuladen, detailliert beschrieben undanalysiert.iiiWIDMUNGIch möchte an dieser Stelle jenen Menschen danken, die mich auf verschiedenste Weise bei derErstellung dieser Arbeit unterstützt haben.In erster Linie möchte ich meinem Doktorvater, Prof. Dr. Hartmut Schmeck, meinen Dankaussprechen für die akademische Freiheit bei der Suche nach einem für mich sehr spannendenPromotionsthema sowie für seine Unterstützung in jeglicher Hinsicht. Ebenso bedanke ichmich bei meinem Korreferenten, Prof. Dr. Hansjörg Fromm, für die intensive und tiefgehendeDiskussion meiner Arbeit, welche mir einen zusätzlichen Blickwinkel ermöglichte und zu einerbesseren Verständlichkeit dieser Dissertationsschrift beitrug.Die unzähligen Diskussionen einzelner Aspekte meiner Arbeit mit meinen Institutskollegenwaren mir eine unschätzbar große Hilfe, führten sie doch zu einigen zielführenden Erkenntnissenund Ideen. Insbesondere möchte ich mich hier bei Lukas König, Florian Allerding, PradyumnShukla, Daniel Pathmaperuma, Kaibin Bao und Christian Gitte bedanken.Die Erstellung einer Dissertation geht über die Jahre mit diversen Hochs und Tiefs einher.Gerade in solchen demotivierenden Momenten eines Tiefs sind Freunde und Familie wichtigeGesprächspartner, um das Ziel nicht aus den Augen zu verlieren. Daher gilt mein größterDank meinen Eltern, meinem engsten Freundeskreis sowie meiner Freundin, die nicht nurin schwierigen Zeiten für mich da waren und mich motiviert haben, sondern auch für dienötige Entspannung und Abwechslung sorgten, um die nötige Kraft zu schöpfen, die es zurAnfertigung einer Dissertation bedarf.vINHALTSVERZEICHNISTabellenverzeichnis ixAbbildungsverzeichnis xiAbkürzungsverzeichnis xv1 Einführung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3.1 PowerUp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.2 INEES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.3 Smart V2G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.4 Aktivhaus B10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.5 Fellbach ZEROplus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.3.6 Toyota City Low-carbon Society Verification Project . . . . . . . . . . 151.4 Wesentliche Beiträge dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 161.5 Gliederungsübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Standardisierungsinitiativen für interoperable E-Mobilitätsladelösungen 192.1 Standardisierung der Hardwareschnittstellen . . . . . . . . . . . . . . . . . . . 192.1.1 IEC 62196 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.1.2 IEC 61851 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.2 Standardisierung der Kommunikationsprotokolle . . . . . . . . . . . . . . . . 292.2.1 ISO/IEC 15118 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.2 Open Charge Point Protocol (OCPP) . . . . . . . . . . . . . . . . . . 392.2.3 IEC 61850 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.2.4 Die SAE Normenfamilie für intelligentes Laden . . . . . . . . . . . . . 403 Versuchsaufbau und Evaluationsumgebung 413.1 Das Energy Smart Home Lab (ESHL) . . . . . . . . . . . . . . . . . . . . . . 413.2 Das Energiemanagement-System (EMS) des ESHL . . . . . . . . . . . . . . . 423.3 Der Konflikt zweier Eingabequellen – E-Fahrzeug und EMP . . . . . . . . . . 49viiInhaltsverzeichnis3.4 Architekturbedingte Kodierungs-Einschränkungen . . . . . . . . . . . . . . . 524 Integration des E-Fahrzeugs in das Energiemanagement 534.1 Makroskopische Perspektive auf das Smart Home Szenario . . . . . . . . . . . 534.2 Der lokale Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.3 Das Optimierungs-Teilproblem Elektrofahrzeug . . . . . . . . . . . . . . . . . 594.3.1 Zu kodierende Parameter und Kodierungsansätze . . . . . . . . . . . . 594.3.2 Restriktionen der Ladeflexibilität . . . . . . . . . . . . . . . . . . . . . 644.3.3 Formale Darstellung der kodierten Parameter und Restriktionen . . . 674.3.4 Beispiel der Korrektur eines Bitvektors im Teilproblem . . . . . . . . . 714.3.5 Die Wahl einer geeigneten Bitvektor-Repräsentation . . . . . . . . . . 744.3.6 Berücksichtigung der Ladecharakteristik einer Lithium-Ionen-Batterie 764.4 Der lokale Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.5 Der ISO/IEC 15118-2 Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.6 Datenobjekte im Kommunikationsfluss zwischen Elektroauto und EMS . . . . 815 Das E-Roaming Szenario 875.1 Das Zertifikatskonzept gemäß ISO/IEC 15118-2 . . . . . . . . . . . . . . . . . 885.1.1 Anforderungen aus Sicht eines OEMs . . . . . . . . . . . . . . . . . . 885.1.2 Anforderungen aus Sicht eines E-Mobilitätsanbieters . . . . . . . . . . 895.1.3 Zertifikatstypen gemäß ISO/IEC 15118-2 . . . . . . . . . . . . . . . . 905.1.4 Resultierende Entscheidungen als Basis für das Zertifikatskonzept . . 925.1.5 Initialer Bereitstellungsprozess (Certificate Provisioning) . . . . . . . . 935.1.6 Vereinfachtes Zertifikatsmanagement im privaten Umfeld . . . . . . . 965.2 Das Hubject-Modell – Clearingstelle und Anbieter eines E-Mobilitäts-Marktplatzes 975.2.1 Das Open InterCharge Protocol (OICP) . . . . . . . . . . . . . . . . . 1005.3 Green eMotion – Europäischer Marktplatz aus der Forschungsperspektive . . 1026 Evaluation 1056.1 Zukunftsfähgikeit der ISO/IEC 15118 Norm . . . . . . . . . . . . . . . . . . . 1056.1.1 Akzeptanz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056.1.2 Erweiterbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.1.3 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116.1.4 Ezienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.1.5 Komplexität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1186.2 Evaluation des ausgewählten Kodierungsschemas für das Elektrofahrzeug . . 1216.2.1 Auswertung der realen Wohnphase im Herbst 2013 . . . . . . . . . . . 1216.2.2 Lastgänge simulativer Wohnphasen . . . . . . . . . . . . . . . . . . . . 1246.2.3 Auswertung der realen Wohnphase im Frühjahr 2014 . . . . . . . . . . 1407 Zusammenfassung und Ausblick 1437.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1437.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145A Simulationsergebnisse Wohnphase Frühjahr 2014 149Literaturverzeichnis 159viiiTABELLENVERZEICHNIS2.1 Dokumentenstruktur des ISO/IEC 15118 Standards und entsprechende (ge-plante) Stadien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.1 Abbildung ISO/IEC 15118-2 Parameter auf formales Modell (erweiterte Para-meter durch Unterstreichung gekennzeichnet) . . . . . . . . . . . . . . . . . . 674.2 Abbildung eines Bitvektors der Länge vier auf Leistungswerte [kW] . . . . . . 724.3 Modifizierte Abbildung eines 4-Bit-Strings auf negative Leistungswerte . . . . 744.4 Abbildung eines 4-Bit-Strings auf Leistungswerte mittels Gray-Kodierung . . 754.5 Abbildung eines 5-Bit-Bitvektors auf Leistungswerte mittels Gray-Kodierung 764.6 Verschachtelung des Datentypen PMaxSchedule . . . . . . . . . . . . . . . . . 806.1 Übersicht über bereits bestehende Firmen-Aktivitäten bzgl. ISO/IEC 15118 . 1076.2 Übersicht über die in einer V2GTP-Nachricht erlaubten Payloadtypen (nach [39])1086.3 Definition von ID, Kategorie und Name eines Dienstes (nach [39]) . . . . . . . 1106.4 Vergleich der Verschlüsselungsstärken basierend auf diversen Sicherheitsniveaus[49] [21] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1166.5 Standzeiten am Smart Home sowie energierelevante Daten des Elektrofahrzeugsin Woche 4 der Herbstwohnphase . . . . . . . . . . . . . . . . . . . . . . . . . 1246.6 Simulationsdurchläufe mit diversen Parameterkonstellationen . . . . . . . . . 1276.7 Stromkosten aller simulierten Wochenlastgänge im Herbst (inkl. Strafkostenfür Lastgrenzenüberschreitung) . . . . . . . . . . . . . . . . . . . . . . . . . . 1306.8 Stromkosten aller simulierten Wochenlastgänge im Herbst (keine Strafkostenfür Lastgrenzenüberschreitung) . . . . . . . . . . . . . . . . . . . . . . . . . . 1306.9 Standzeiten am Smart Home sowie energierelevante Daten des Elektrofahrzeugsin Woche 2 der Frühjahrswohnphase . . . . . . . . . . . . . . . . . . . . . . . 1406.10 Stromkosten aller simulierten Wochenlastgänge im Frühjahr (inkl. Strafkostenfür Lastgrenzenüberschreitung) . . . . . . . . . . . . . . . . . . . . . . . . . . 1416.11 Stromkosten aller simulierten Wochenlastgänge im Frühjahr (keine Strafkostenfür Lastgrenzenüberschreitung) . . . . . . . . . . . . . . . . . . . . . . . . . . 141ixABBILDUNGSVERZEICHNIS1.1 Zielkurve der Marktentwicklung für Elektrofahrzeuge bezogen auf die Jahre2010 bis 2020 [52] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Schematische Darstellung der Förderung durch die Bundesregierung (angelehntan [24]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Beitrag und Ziele der erneuerbaren Energien bezogen auf den Brutto-InlandsstromverbrauchDeutschlands (Quelle: BDEW, Stand 12/2013) . . . . . . . . . . . . . . . . . 51.4 Brutto-Stromerzeugung 2013 in Deutschland (ca. 629 Mrd. kWh), aufgeteiltnach Energieträgern (Quelle: BDEW, AG Energiebilanzen Stand: 12/2013) . 61.5 Systemarchitektur der Kommunikation zwischen E-Fahrzeug und Smart Gridim Projekt PowerUp [42] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.6 Interaktion zwischen den ISO/IEC 15118 V2G und IEC 62056 DLMS/COSEMSchnittstellen während des Aufbaus einer Ladesession im Projekt PowerUp [42] 121.7 Grundriss des Aktivhaus B10 [43] . . . . . . . . . . . . . . . . . . . . . . . . . 142.1 Gesamtbild eines Ladestecksystems bestehend aus Buchsen, Steckern undSteckdose. Hier: das Combined Charging System (CCS) für das AC- undDC-Laden (Quelle: Phoenix Contact) . . . . . . . . . . . . . . . . . . . . . . . 202.2 Überblick über den weltweiten Einsatz der normierten Ladestecksysteme fürElektromobilität. GB steht für Guobiao, chinesisch für “Nationaler Standard”(Quelle: Phoenix Contact) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3 Fahrzeugseitige Ladebuchse nach der Combined Charging System Spezifikation(Quelle: Phoenix Contact) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.4 DC-Ladestecker nach der Combined Charging System Spezifikation (Quelle:Phoenix Contact) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5 Ein Typ 2 Ladestecker für ein- und dreiphasiges AC-Laden (Quelle: Mennekes) 232.6 Combined Charging System zum AC- und DC-Laden mit den Steckvorrichtun-gen Typ 1, Typ 2, Combo 1 und Combo 2 [51] . . . . . . . . . . . . . . . . . 242.7 Typ 2 Ladekabel für ein- und dreiphasiges AC-Laden nach Mode 2 mit inte-grierter ICCB (Quelle: Mennekes) . . . . . . . . . . . . . . . . . . . . . . . . . 262.8 Beispielhafter Ladezyklus illustriert anhand eines PWM-Signals (angelehntan [37], Anhang A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27xiAbbildungsverzeichnis2.9 Abbildung der Teile 2 und 3 des ISO/IEC 15118 Standards sowie der verwen-deten Protokolle auf die ISO/OSI-Schichten [39] . . . . . . . . . . . . . . . . . 312.10 Request-Response Nachrichtenpaare im PnC-Modus und Wechselstrom-Ladeszenario 342.11 Session-Handling gemäß der ISO/IEC 15118-2 Spezifikation [39] . . . . . . . . 353.1 Grundriss des Energy Smart Home Lab . . . . . . . . . . . . . . . . . . . . . 433.2 Überblick über die O/C-Architektur des Energiemanagement-Systems im SmartHome (angelehnt an [3]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.3 Globaler Optimierungsprozess im Organic Smart Home [4] . . . . . . . . . . . 463.4 EMP-Benutzungsschnittstelle zur Eingabe des gewünschten Abfahrtszeitpunktsund der Mindestreichweite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.1 Übersicht zur Integration des Elektrofahrzeugs in das Smart Home Energie-management (das Ladekabel ist Abbildung 2.1 entlehnt) . . . . . . . . . . . . 544.2 Kapazitäts- und Energiekennwerte zum Zeitpunkt tp: Beispiel mit negativemE≠EV (tp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.3 Kapazitäts- und Energiekennwerte zum Zeitpunkt tp: Bespiel mit positivemE≠EV (tp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.4 Übersicht über die Zeitpunkte tp, tm, ts und td . . . . . . . . . . . . . . . . . 704.5 Korrekturmechanismus bei der Genotyp-Phänotyp-Abbildung im Teilproblem 734.6 Zusammenhang der Komponenten Ladegerät, Batterie und Batteriemanage-mentsystem [63] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774.7 Strom- und Zellspannungsverlauf beim CC-CV-Ladeverfahren [63] . . . . . . 774.8 Verlauf dreier Ladevorgänge mit ähnlicher Leistung in der CC-Phase undStart-SOC 59 % [63] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784.9 Verlauf zweier Ladevorgänge mit ähnlicher Temperatur und Start-SOC 50 % [63] 784.10 Beispielhafter Verlauf von Eingangsstrom, -Spannung und -Leistung währendeines ungesteuerten dreiphasigen Ladevorgangs mit durchschnittlich 10 kW [63] 794.11 Beispielhafter Kommunikationsfluss zwischen den Entitäten EVCC, SECC,Treiber, EMP sowie lokalem Observer und Controller (Teil 1/2) . . . . . . . . 824.12 Beispielhafter Kommunikationsfluss zwischen den Entitäten EVCC, SECC,Treiber, EMP sowie lokalem Observer und Controller (Teil 2/2) . . . . . . . . 834.13 Fallunterscheidung im lokalen Observer beim Verarbeiten von vom Treibergesendeten CarDetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.1 Überblick über die diversen Zertifikatstypen, welche im Rahmen des Plug-and-Charge Identifikationsmodus’ gemäß ISO/IEC 15118-2 zum Einsatz kommen [39] 915.2 Prozessschritte im Zuge der Bereitstellung des Vertragszertifikats (angelehntan [39]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.3 Hubject Rollenmodell im E-Roaming Szenario (Quelle: Hubject.com) . . . . 975.4 Hubject Rollenmodell im E-Roaming Szenario [33] . . . . . . . . . . . . . . . 995.5 Architektur des Green eMotion EV Servcie Market [30] . . . . . . . . . . . . 1035.6 Referenzarchitektur – Demonstrationsfokus [30] . . . . . . . . . . . . . . . . . 1046.1 Header-Struktur einer V2GTP-Nachricht [39] . . . . . . . . . . . . . . . . . . 1086.2 Vorgaben für TLS-Unterstützung durch EVCC und SECC [39] . . . . . . . . 1126.3 Übersicht aller XML-basierten Signaturen [39] . . . . . . . . . . . . . . . . . . 113xiiAbbildungsverzeichnis6.4 ECDH-Schlüsselaustausch mit kurzlebigem und statischem öentlichem Schlüs-sel [39] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1156.5 Quantitative Übersicht über ISO/IEC 15118 Nachrichtengrößen in XML unddiversen EXI-Modi [61] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1176.6 Zustandsautomat des SECC für das Wechselstromladen [39] . . . . . . . . . . 1196.7 Auswertung der Lastgänge einzelner Verbraucher sowie des BHKWs in der 4.Woche (Wohnphase 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1226.8 Simulation A (Herbst, 2 Personen, ohne PV/BHKW, EV-Last gesteuert) . . . 1326.9 Simulation B (Herbst, 2 Personen, ohne PV/BHKW, EV-Last ungesteuert) . 1336.10 Simulation C (Herbst, 2 Personen, mit PV/BHKW, EV-Last gesteuert) . . . 1346.11 Simulation D (Herbst, 2 Personen, mit PV/BHKW, EV-Last ungesteuert) . . 1356.12 Simulation E (Herbst, 5 Personen, ohne PV/BHKW, EV-Last gesteuert) . . . 1366.13 Simulation F (Herbst, 5 Personen, ohne PV/BHKW, EV-Last ungesteuert) . 1376.14 Simulation G (Herbst, 5 Personen, mit PV/BHKW, EV-Last gesteuert) . . . 1386.15 Simulation H (Herbst, 5 Personen, mit PV/BHKW, EV-Last ungesteuert) . . 1396.16 Auswertung der 2. Woche der Wohnphase im Frühjahr 2014 . . . . . . . . . . 142A.1 Simulation I (Frühjahr, 2 Personen, ohne PV/BHKW, EV-Last gesteuert) . . 150A.2 Simulation J (Frühjahr, 2 Personen, ohne PV/BHKW, EV-Last ungesteuert) 151A.3 Simulation K (Frühjahr, 2 Personen, mit PV/BHKW, EV-Last gesteuert) . . 152A.4 Simulation L (Frühjahr, 2 Personen, mit PV/BHKW, EV-Last ungesteuert) . 153A.5 Simulation M (Frühjahr, 5 Personen, ohne PV/BHKW, EV-Last gesteuert) . 154A.6 Simulation N (Frühjahr, 5 Personen, ohne PV/BHKW, EV-Last ungesteuert) 155A.7 Simulation O (Frühjahr, 5 Personen, mit PV/BHKW, EV-Last gesteuert) . . 156A.8 Simulation P (Frühjahr, 5 Personen, mit PV/BHKW, EV-Last ungesteuert) . 157xiiiABKÜRZUNGSVERZEICHNISAC Alternating Current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19BHKW Blockheizkraftwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41BMS Batterie-Management-System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37CCS Combined Charging System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22CPO Charge Point Operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100DC Direct Current . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20E-MP E-Mobility Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100EA Evolutionärer Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52EMP Energy Management Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42EMS Energiemanagement-System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41ESHL Energy Smart Home Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41EV Electric Vehicle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20EVCC Electric Vehicle Communication Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32EVSE Electric Vehicle Supply Equipment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20OCPP Open Charge Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39OICP Open InterCharge Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95PWM Pulsweitenmodulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25SECC Supply Equipment Communication Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 32SOC State of Charge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29xvKAPITEL 1EINFÜHRUNGForschungsinitiativen und staatliche Förderprogramme, welche darauf abzielen, die Potentialeder Elektromobilität zu erforschen und Anreizmechanismen zur Ankurbelung des Markthoch-laufs von Elektrofahrzeugen zu erzeugen, sind weltweit verstärkt zu beobachten. Die deutscheBundesregierung verabschiedete beispielsweise im Jahre 2009 den Nationalen Entwicklungs-plan Elektromobilität [17], welcher das Rahmenwerk für zukünftige Technologieentwicklungendarstellen soll, um einen geplanten Markthochlauf der Elektromobilität in Deutschland voran-zutreiben.Mit der Förderung der Elektromobilität verfolgt die Bundesregierung diverse umwelt- undwirtschaftspolitische Ziele, worunter bspw. die Reduzierung der Abhängigkeit von Erdölimpor-ten fällt. Der fossile Energieträger Öl stellt schließlich eine begrenzte Ressource dar, derenFörderung zunehmend mit steigenden Rohstopreisen einhergeht. Im Zuge der Nachhaltigkeiteines zukünftigen Individualverkehrs verspricht man sich von der Elektromobilität auch eineerhebliche Minimierung von Emissionen, wie der klimaschädlichen Treibhausgase (CO2), desFeinstaubs und des Lärms, die allesamt durch Verbrennungsmotoren entstehen. Um ihrepolitischen Ambitionen an einem messbaren Meilenstein auszurichten, wurde das Ziel voneiner Million Elektrofahrzeugen auf deutschen Straßen bis zum Jahr 2020 ausgerufen undu. a. im Nationalen Entwicklungsplan Elektromobilität verankert.Im Rahmen des Konjunkturpakets II “Pakt für Beschäftigung und Stabilität in Deutsch-land” der Bundesregierung wurden daher auch 500 Millionen Euro zur Förderung der F&EEntwicklungen im Bereich der Elektromobilität im Zeitraum von 2009 bis 2011 investiert.Um diese und zukünftige Fördermittel möglichst ezient einzusetzen, wurde auf Einladungder Bundesregierung am 3. Mai 2010 die Nationale Plattform Elektromobilität (NPE) ge-gründet. Diese setzt sich aus Vertretern der Industrie, Wissenschaft, Politik, Gesellschaft undGewerkschaften zusammen. Ziel dieses Beratergremiums ist es, in sieben themenzentriertenArbeitsgruppen Konzepte zu entwickeln, die einen marktorientierten und technologieoenenAnsatz verfolgen, um Deutschland zum Leitanbieter und Leitmarkt für Elektromobilität bis2020 zu entwickeln. Den sieben Arbeitsgruppen• Antriebstechnologie,• Batterietechnologie,• Ladeinfrastruktur und Netzintegration,1Kapitel 1 Einführung• Normung, Standardisierung und Zertifizierung,• Materialien und Recycling,• Nachwuchs und Qualifizierung sowie• Rahmenbedingungengehören u. a. Vertreter von vier Ministerien an, die unter dem Dach der Bundesregierungdie Elektromobilität mit unterschiedlichen Etats und Projekten fördern. Hierzu zählen dieBundesministerien für Umwelt- und -bau (BMUB)1, für Verkehr und digitale Infrastrukturen(BMVI)2, für Bildung und Forschung (BMBF) sowie für Wirtschaft und Energie (BMWi)3, wel-che sich über die Gemeinsame Geschäftsstelle Elektromobilität der Bundesregierung (GGEMO)als zentralen Ansprechpartner gegenseitig austauschen.In ihrem dritten Fortschrittsbericht vom Juni 2012 erläutert die NPE das Markthochlauf-szenario für Elektrofahrzeuge für die Jahre 2010 bis 2020, welches Abbildung 1.1 zu entnehmenist. Unter die Kategorie “Elektrofahrzeug” fallen aus Sicht der NPE sowohl reine batteriebe-triebene E-Fahrzeuge (BEVs) als auch Hybridfahrzeuge, worunter sich neben Plug-in Hybriden(PHEVs) auch sogenannte Range-Extender subsumieren. Laut den Zahlen des Kraftfahrtbun-desamtes (KBA)4 sind zum Stichtag 1. Januar 2014 genau 12.156 rein batteriebetriebeneElektrofahrzeuge (Pkw) in Deutschland zugelassen. Die genaue Summe der Plug-in Hybrideist schwer zu erfassen, da das KBA sie in seiner Statistik erst seit dem Jahr 2013 separatvon übrigen Hybridfahrzeugen (insgesamt 85.575 zum 1.1.2014) ausweist. Allein im Jahr 2013wurden jedoch deutschlandweit bereits 1.385 Plug-in Hybride neu zugelassen. Die zusammengenommen 97.731 Elektrofahrzeuge zum 1.1.2014 sind somit fast deckungsgleich mit derantizipierten Hockeykurve aus Abbildung 1.1. Die nächsten drei Jahre des Markthochlaufsstellen mit dem steilen Anstieg der Kurve den wesentlich schwierigeren Teil dar, welcher einwichtiger Indikator dafür sein wird, ob das Millionenziel bis 2020 wirklich erreicht werdenkann.Im Rahmen der NPE wurden ebenso sogenannte thematische Leuchttürme bestimmt, diedurch die vier Ministerien gefördert werden. Ein Beispiel für einen solchen Leuchtturm ist derFörderbereich “IKT für Elektromobilität”, welcher durch das BMWi gefördert wird. Darüberhinaus fördern die vier Ministerien gemeinsam auf Empfehlung der NPE vier ausgewähl-te “Schaufenster” für Elektromobilität. Diese Schaufenster sind regionale Demonstrations-und Pilotvorhaben, welche öentlichkeitswirksam Innovationen im Bereich der Elektromo-bilität entwickeln und erlebbar machen sollen. Eine Übersicht über die Projekte des baden-württembergischen Schaufensters “LivingLab BWe mobil” liefert die Landesagentur für Elek-tromobilität und Brennstozellentechnologie Baden-Württemberg GmbH [43]. Einen weiterenBaustein der Forschungspolitik des Bundes hinsichtlich Elektromobilität stellt das Spitzen-cluster Elektromobilität Südwest5 dar, welches den Fokus auf die Themen Markt und Kosten,Handhabung und Komfort sowie vernetzte Mobilität setzt.1Mit Ernennung des Kabinetts Merkel III am 17. Dezember 2013 wurde das Bundesumweltministerium (BMU)in das Bundesumwelt- und -bauministerium (BMUB) umbenannt.2Vor Ernennung des Kabinetts III als Bundesministerium für Verkehr, Bau und Stadtentwicklung (BMVBS)bekannt.3Vor Ernennung des Kabinetts III als Bundesministerium für Wirtschaft und Technologie (BMWi) bekannt.4Eine übersichtlich aufbereitete Statistik des Branchendienstes electrive.net [22] liefert ebenso eine guteÜbersicht über die Zulassungszahlen.5http://www.e-mobilbw.de/de/aufgaben/cluster-elektromobilitaet-sued-west.html246 Fortschrittsbericht der Nationalen Plattform Elektromobilität (Dritter Bericht)Auf dem Weg zum Leitmarkt 5.4 Status der Maßnahmen zur Marktstimulation- -Abbildung 14: Zielkurve Marktentwicklung 2010 – 2020Mit der Umsetzung eines öffentlichen Beschaffungsprogramms für E-Fahrzeuge wurde begonnenMit dem Regierungsprogramm Elektromobilität von 2011 hat die Bundesregierung eine Erweiterung der bestehenden, marktseitigen Förderung von Elektrofahrzeugen vorgenommen. Die bestehende fünfjährige Befreiung von der Kfz-Steuer für Pkw soll auf zehn Jahre erweitert und auf Nutzfahrzeuge ausgedehnt werden. Ergänzend wurde ein öffentliches Beschaffungsprogramm für Elektrofahrzeuge in Aussicht gestellt und zwischenzeitlich mit der Umsetzung begonnen. Darüber hinaus wurde die Empfehlung der NPE aufgenommen, eine Kompensation des bestehenden Nachteils bei der Besteuerung der privaten Nutzung von elektrischen Dienstfahrzeugen (BEV, REEV, PHEV) zu ermöglichen. Dieser Nachteilsausgleich kann zu einem höheren Anteil der Nutzung von Elektrofahrzeugen als Dienstfahrzeugen führen. Mit der Einführung der Wechselkennzeichen greift die Bundesregierung eine weitere Empfehlung der NPE auf. Anders als von der NPE vorgeschlagen, erfolgte bisher keine Reduzierung der Kfz-Steuerpflicht für ein angemeldetes Zweitfahrzeug. Weitere Vorschläge der NPE wie Sonderabschreibungen, KfW-Darlehen oder Steuer-Incentives wurden bisher noch nicht umgesetzt. Die im Regierungsprogramm ange kündigten Maßnahmen werden derzeit von den zuständigen Ressorts in konkrete rechtliche Regelungen überführt.Eine Abweichung von den durch die NPE vorgeschlagenen Fördermaßnahmen würde sich nach bisherigen Annahmen direkt in einer Reduktion der erreichbaren Absatzentwicklung niederschlagen. Weitere Hürden für die Marktentwicklung der Elektromobilität, wie enger gefasste Bemessungskriterien, reduzieren diese Zahl weiter. Abbildung 1.1: Zielkurve der Marktentwicklung für Elektrofahrzeuge bezogen auf die Jahre2010 bis 2020 [52]Es ist also deutlich erkennbar, welch hohen Stellenwert die Förderung der Elektromobilitätmit ihren verschiedensten Themenbereichen in Deutschland hat. Abbildung 1.2 fasst dieFörderstruktur unter dem Dach der Bundesregierung in einer schematischen Darstellungz sammen. Die als weiße Balken dargestellten Leuchtturm-Elemente sollen di Erweiterbarkeitdieses Themenspektrums repräsentieren.Im Z ge der vom BMWi geleiteten Förd rini iativ “IKT für Elektromobilität II: Smart Car– Smart Grid – Smart Trac” wurde das Forschungsprojekt iZEUS – intelligent Zero EmissionUrban System6 ins Leben gerufen, dessen Ergebnisse auch im Rahmen des Schaufensters“Living Lab BW E-Mobil” des Landes Baden-Württemberg präsentiert werden. Der folgendeAbschnitt 1.1 wird die Forschungsziele des Projekts aufgreifen und die Notwendigkeit derinformatio stechnischen Einbindung von Elektrofahrzeugen i das Energieversorgungssystemvor dem Hintergrund der in Deutschland eingeläuteten Energi wende motivier n. DieseMotivation bildet die einführende Grundlage für die Forschungstätigkeit und resultierendenErgebnisse, welche in dieser Arbeit präsentiert werden.6http://izeus.kit.edu3Kapitel 1 EinführungBUNDESREGIERUNG**BMUB*BMVI*BMBF*BMWi*GGEMO*NATIONALE*PLATTFORM*ELEKTROMOBILITÄT*************THEMATISCHE*LEUCHTTÜRME**********SCHAUFENSTER**********Ba#erie'Antriebstechnologie'und'Fahrzeugintegra6on'Leichtbau'Recycling'IKT'und'Infrastruktur'Bayern?Sachsen'Baden?Wür#emberg'Berlin?Brandenburg'Niedersachsen'Abbildung 1.2: Schematische Darstellung der Förderung durch die Bundesregierung (angelehntan [24])1.1 MotivationDas deutsche Erneuerbare-Energien-Gesetz (EEG) aus dem Jahre 2000 läutete eine Revolu-tion in Deutschlands Energiesektor ein, speziell dem deutschen Stromnetz, welches sich überJahrzehnte bereits zu einer zentralistischen Struktur mit Stromerzeugung aus vorwiegendgroßen fossilen und nuklearen Kraftwerken entwickelt hatte. Der Fokus der elektrischen Ener-gieerzeugung verschiebt sich seither hin zu einer steten Erhöhung des Anteils der erneuerbarenEnergien (EE) am deutschen Strommix. Zusammen mit der gesetzlich festgelegten Förderungfür eine Stromerzeugung aus Wind- und Solarkraftanlagen wirkten diese Maßnahmen bisherals wichtige Geburtshelfer für die deutsche Energiewende.Der Erfolg der deutschen Energiewende hängt jedoch auch von den energiepolitischenZielen der europäischen Nachbarn ab, schon allein aufgrund der engmaschigen Stromnetze aufdem europäischen Kontinent. Vor dem Hintergrund der Versorgungssicherheit, Bezahlbarkeitund Netzstabilität verpflichteten sich die EU-Mitgliedstaaten im Rahmen der Erneuerbare-Energien-Richtlinie 2009/28/EG des Europäischen Parlaments und des Rates vom 23. April2009, bis 2020• die Treibhausgasemissionen um mindestens 20 Prozent gegenüber 1990 zu reduzieren,• eine Energieezienzsteigerung um 20 Prozent anzustreben, sowie41.1 Motivation• einen Anteil von 20 Prozent erneuerbarer Energien am Gesamtenergieverbrauch zuerreichen,was gemeinhin unter dem Begri “20-20-20”-Ziele zusammengefasst wird. Im Rahmen einerlangfristigen Klimaschutzpolitik der EU hat das Europäische Parlament seine Zielausrichtungerneuert und sich in einer Sitzung am 05.02.2014 dafür ausgesprochen, bis 2030 den Anteilder Treibhausgasemissionen um 40% zu senken, den Ausbau der erneuerbaren Energiequellenauf 30% zu heben und eine Verbesserung der Energieezienz um 40% zu erreichen [26].Die Bundesregierung definiert darüber hinaus eigenständige Ziele für Energieezienz sowiefür den Anteil erneuerbarer Energien, wie Abbildung 1.3 zu entnehmen ist7. Darüber hinaushat Deutschland als Konsequenz aus der Reaktorkatastrophe in Fukushima im Jahre 2011in seinem Atomausstiegsgesetz beschlossen, sämtliche Kernkraftwerke Deutschlands bis zumJahr 2022 in einem mehrstufigen Prozess stillzulegen und vom Netz zu nehmen.4% 5% 7% 8% 9% 10% 14% 15% 16% 17% 20% 24% 25% 35% 40-45% 50% 55-65% 65% 80% 1996199820002002200420052007200820092010201120122013**202020252030203520402050Ziele im Energiekonzept der Bundesregierung 2011/ Verienbarung Koalitionsvertrag 2013 Anteil des Stroms aus regenerativen Energiequellen* Abbildung 1.3: Beitrag und Ziele der erneuerbaren Energien bezogen auf den Brutto-Inlandsstromverbrauch Deutschlands (Quelle: BDEW, Stand 12/2013)Aus Abbildung 1.4 geht klar hervor, dass die volatilen, wetterabhängigen Energieträger Wind-und Solarenergie mit einem Anteil von über 50 % an der Gesamterzeugung aus erneuerbarenEnergien die Grundpfeiler der zukünftigen Energieversorgung darstellen. Mit Hilfe dieserEnergieformen kann sehr günstig Strom erzeugt werden, da lediglich Investitionskosten fürdie initiale Fertigung sowie Installation der Anlagen als auch relativ geringe Wartungskostenanfallen. Keine Kosten müssen für die jeweiligen Rohstoe aufgewendet werden, da Wind undSonne naturgegeben kostenfrei zur Verfügung stehen – im Gegensatz zu den stetig steigendenKosten für nukleare und fossile Rohstoe. Diese saubere Art der Energieerzeugung bringtes jedoch mit sich, dass die Verfügbarkeit der elektrischen Energie zunehmend vom Wetterabhängig ist.Die Zeiträume der höchsten Erzeugungsrate durch EE-Anlagen und der stärksten Abnah-memenge elektrischer Energie sind über den Tag gesehen daher oftmals nicht deckungsgleich.7Die Angaben für 2013 stellen einen geschätzten Wert dar.5Kapitel 1 EinführungKernenergie 15,4% Braunkohle 25,8% Steinkohle 19,7% Erdgas 10,5% Heizöl, Pumpspeicher und Sonstige 5,2% Wind 7,9% Biomasse 6,8% Wasser 3,4% Photovoltaik 4,5% Siedlungsabfälle 0,8% Erneuerbare 23,4% Abbildung 1.4: Brutto-Stromerzeugung 2013 in Deutschland (ca. 629 Mrd. kWh), aufgeteiltnach Energieträgern (Quelle: BDEW, AG Energiebilanzen Stand: 12/2013)Diese Volatilität induziert einen nötigen Paradigmenwechsel hinsichtlich der Nutzung desEnergienetzes: weg von einem zentralistischen verbrauchsorientierten Produktionssystem, hinzu einem dezentralen erzeugungsorientierten Verbrauchssystem, bei welchem der Nutzer seinenelektrischen Energiebedarf mehr an der Verfügbarkeit regenerativ erzeugten Stroms ausrichtet,was eine hohe Flexibilität beim Verbraucher erfordert.Daher ist eine kosteneektive und energieeziente Evolution des Übertragungs- und Verteil-netzes hin zu einem System notwendig, in welchem Energieerzeugungseinheiten, Energiespei-cher, private wie auch industrielle Verbraucher sowie Netzbetriebsmittel intelligent miteinanderverknüpft sind und untereinander kommunizieren können, basierend auf Informations- undKommunikationstechnologien (IKT) und Automatisierungsmechanismen. Ein solches Systemwird weitgehend als “Smart Grid” (intelligentes Energienetz) bezeichnet [51].Eine dezentralisierte Infrastruktur aus Energiespeichern mit hohem Wirkungsgrad stellteine geeignete Lösung für eine Entkopplung der Verfügbarkeit elektrischer Energie, welcheaus fluktuierenden erneuerbaren Energieträgern produziert wird, und deren Verbrauch dar.Als Gegenentwurf werden Reservekraftwerke diskutiert, welche jedoch mit zunehmendemAusbau erneuerbarer Energien eine immer geringere Volllaststundenzahl erreichen und je nachKraftwerk weiterhin die Zerstörung der Umwelt mit der Emission von Treibhausgasen befördern.Jene Energiespeicher können vielfältiger Natur sein, angefangen von Pumpspeicherkraftwerkenund Kraft-Wärme-Kopplungs-Einheiten (BHKWs) hin zu stationären Batterien, wobei alldiese Alternativen ihre Vor- und Nachteile mit sich bringen. Eine weitere Möglichkeit stellenmobile Energiespeicher dar, wie sie in Elektrofahrzeugen in Form von Traktionsbatterien8 zufinden sind.Diese Elektrofahrzeuge müssen jedoch auf geschickte Weise in das Stromnetz integriert8Wenn im weiteren Verlauf dieser Arbeit die Rede von der Batterie des Elektrofahrzeuges ist, dann ist hiermitstets die Hochvolt-Batterie (auch Traktionsbatterie genannt) gemeint, im Gegensatz zur 12 V Batterie,welche üblicherweise die Bordelektronik versorgt und mit einer viel geringeren Kapazität ausgestattet ist.61.1 Motivationwerden, sodass ein hoher Gleichzeitigkeitsfaktor der Ladevorgänge das Netz nicht im Übermaßbelastet. Im Gegensatz hierzu können die in den Elektrofahrzeugen verbauten mobilen Speicherals netzstützende und stabilisierende Komponente agieren und somit wichtige Bestandteileeines auszubauenden Smart Grids darstellen. Die Aufgabe der Netzstabilisierung, welchebisher klassisch auf der Übertragungsnetzebene angesiedelt gewesen ist, verlagert sich somitzunehmend auch auf die Ebene der Verteilnetze, an die die Elektrofahrzeuge angeschlossen sind.Neben der Schlüsselrolle als Treiber der Nachhaltigkeit des zukünftigen Individualverkehrskönnen die Elektrofahrzeuge somit auch zur eektiven Ausnutzung der Netze beitragen, sofernEnergieversorger, Netzbetreiber und Elektrofahrzeuge ein gemeinsames Kommunikationssys-tem nutzen. Elektrofahrzeuge können überschüssige Energie aus fluktuierenden erneuerbarenEnergiequellen speichern und – falls mit einem Wechselrichter ausgestattet – diese Energiewieder in das Netz einspeisen, sobald diese wieder benötigt wird. Damit ein Elektrofahrzeugauch als steuerbare Last und dezentraler Energiespeicher im Verteilnetz eingesetzt werdenkann, ohne den Fahrkomfort bezüglich der Reichweite negativ zu beeinträchtigen, ist dieErschließung der Flexibilität des Ladebedarfs eine grundlegende Voraussetzung für einenfunktionierenden Paradigmenwechsel zu “Verbrauch folgt der Erzeugung”.Die folgenden drei Integrationsszenarien, welche in ähnlicher Form bereits in [46] vorgestelltwurden, beschreiben das hohe Potential einer vorteilhaften kommunikationstechnischen Ein-bindung von Elektrofahrzeugen in das Smart Grid:Integrationsszenario 1: Entkopplung von Erzeugung und VerbrauchEntkopplung der Verfügbarkeit von überschüssiger, volatil erzeugter erneuerbarer Energie vonihrem Verbrauch, indem durch Nutzung der in E-Fahrzeugen9 verbauten Batterien die Energieerst gespeichert und in Spitzenlastzeiten wieder in das Netz rückgespeist wird. Das Ziel isteine minimale Abweichung von einem gewünschten Lastprofil und somit eine Lastverschiebungin energetisch vorteilhaftere Zeiten.Zudem kann durch die Integration eines E-Fahrzeugs in ein Energiemanagement-Systemeines privaten Haushalts bei einem automatisiert gesteuerten Ladevorgang sowohl der Eigen-verbrauch als auch der Kapitalwert einer auf dem heimischen Dach installierten PV-Anlagedeutlich gesteigert werden, wie bspw. durch Kaschub et al. [40] gezeigt wurde. Die stetig sin-kende Vergütung für die Netzeinspeisung von PV-Strom aufgrund fallender Investitionskostenführt dazu, dass sich der Eigenverbrauch sogar rentabler gestaltet.Integrationsszenario 2: Unterbrechungsfreie StromversorgungNutzung des Elektrofahrzeugs als unterbrechungsfreie Stromversorgung im Falle eines Strom-ausfalls. Das Fahrzeug könnte das Haus im Notfall mit elektrischer Energie aus seiner Batterieversorgen, bis das Haus wieder netzseitig mit Strom versorgt wird. Dies ist ein Anwendungsfall,welcher bspw. in Japan bereits viel Anklang findet. Aus diesem Grund hat der japanischeFahrzeughersteller Mitsubishi eine sogenannte “Power BOX” entwickelt, welche als Adap-ter fungiert, über den man das Mitsubishi Electric Vehicle (ehemals i-MiEV) mit einemHausanschluss verbindet, um so eine Leistung von 1500 W bereitzustellen [44]. Das ElectricVehicle kann laut Aussage Mitsubishis mit seinen 16 kWh einen Haushalt somit bis zu sechsStunden mit elektrischer Energie versorgen. Es stehen somit maximal 9 kWh an Energie für dieRückspeisung zur Verfügung, um stets eine gewisse Mindestreichweite garantieren zu können.9Fortan werden die Begrie Elektrofahrzeug, Elektroauto und E-Fahrzeug synonym für einen rein batteriebe-triebenen Pkw verwendet.7Kapitel 1 EinführungIntegrationsszenario 3: NetzdienstleistungenIn einem dritten konkreten Anwendungsfall könnte das Elektrofahrzeug für Netzdienstleistung-en genutzt werden, um einer Über- bzw. Unterspannung im Niederspannungsnetz zu begegnen.Eine Unterspannung tritt bei einem hohen Verbrauch und langen Leitungen auf, wohingegen ei-ne Überspannung oft in Zusammenhang mit einer vergleichsweise hohen Netzeinspeisung durchPhotovoltaikanlagen auftritt, wie es bspw. oft im ländlichen Raum zu beobachten ist. So könnteeinerseits, ähnlich zu Integrationsszenario 1, im Falle einer Überspannung dezentral erzeugterStrom aus PV-Anlagen vor Ort verbraucht bzw. im Falle einer Unterspannung elektrischeEnergie verbrauchsnah bereitgestellt werden. Eine technische Evaluierung dieses Potentialssowie Annahmen zu möglichen jährlichen Einnahmen aus solchen Systemdienstleistungenwurde bspw. in Rolink et al. [57] vorgenommen.Andererseits könnte bspw. Blindleistung auf Anfrage des Netzbetreibers bereitgestellt oderkompensiert werden. Blindleistung entsteht aufgrund physikalischer Eekte durch eine Pha-senverschiebung in Wechselstromnetzen und beeinflusst die Spannung im Netz. Im Gegensatzzur Wirkleistung ist die Blindleistung nicht nutzbar und kann auch nicht vergütet werden.Befindet sich ein Abschnitt des Stromnetzes in einem ungünstigen Spannungsband, so kannder Netzbetreiber mit einem bestimmten Verschiebungsfaktor (ein Zahlenwert zwischen 0und 1) den gewünschten Anteil der Blindleistung kommunizieren, welchen letzten Endes dasElektrofahrzeug durch seinen bi-direktionalen Umrichter bereitstellen könnte.Speziell dem ersten Integrationsszenario widmet sich u. a. das Forschungsprojekt iZEUS, indessen Rahmen diese Arbeit entstanden ist. Nachdem die Hintergründe einer vorteilhaftenIntegration von Elektrofahrzeugen in das Energienetz motiviert wurden, werden nun imFolgenden die zentralen Zielsetzungen der vorliegenden Arbeit vorgestellt.1.2 ZielsetzungZiel dieser Arbeit ist es, ein rückspeisefähiges Elektroauto in das Energiemanagement-Systemeines Hauses zu integrieren, welches aufgrund seiner kommunikationstechnischen Ausstattungund der installierten Verbraucher und Erzeuger, die stets ihren Zustand mitteilen können, alsSmart Home bezeichnet wird. Im Rahmen der Forschungsprojekte MeRegioMobil10 und iZEUSwurde ein solches Smart Home aufgebaut und stetig erweitert. In diesem Zuge wurde einEnergiemanagement-System (EMS) konzipiert und eingesetzt, welches sämtliche thermischenund elektrischen Komponenten beobachtet und steuert. Kapitel 3 wird auf die Versuchsumge-bung noch genauer eingehen, weiterführende Details hierzu sind [3] zu entnehmen.Zur Realisierung einer kommunikationstechnischen Einbindung eines Elektrofahrzeugs indas Energienetz, speziell am Beispiel eines Smart Home, bedarf es jedoch Kommunikations-protokolle, die in der Lage sind, energierelevante Mehrwertinformationen auszutauschen undzu verarbeiten. Um das Integrationsszenario so realistisch wie möglich zu gestalten und dieMöglichkeit zu bieten, die gewonnenen Erkenntnisse im Zuge eines wissenschaftlichen Transfersauch in zukünftige Produkte einfließen zu lassen, soll keine proprietäre Lösung zum Einsatzkommen. Vielmehr ist es sinnvoll, auf bereits existierende oder in der Entwicklung befindlicheStandards zu setzen, welche eine breitere Akzeptanz und Verwertbarkeit der wissenschaft-lichen Erkenntnisse sicherstellen. Aus diesem Grund kommt für die Kommunikation undVerarbeitung der energierelevanten Mehrwertinformationen an der Schnittstelle zwischen Elek-troauto und Ladestation respektive EMS der Kommunikationsstandard ISO/IEC 15118 zum10http://meregiomobil.forschung.kit.edu81.3 Verwandte ArbeitenEinsatz. Basierend auf diesem Standard soll ein intelligentes Lademanagement konzipiert undimplementiert werden. Hierbei werden sowohl Restriktionen und Randbedingungen, die dasElektrofahrzeug dem EMS mitteilt, als auch die Lastsituation im Smart Home berücksichtigt,um ein geeignetes Lastprofil für das E-Fahrzeug zu generieren. Dieses Lastprofil repräsentiertsowohl Zielvorgaben durch den Bewohner des Smart Home, dessen Entscheidungen stetsoberste Priorität haben, als auch die Auswirkungen der Steuersignale, die dem Smart Homekommuniziert werden, wie bspw. ein zeitvariabler Strompreistarif oder ein zeitvariables Last-begrenzungssignal.Darüber hinaus soll aus einem makroskopischeren Blickwinkel heraus ein sogenanntes E-Roaming Szenario betrachtet werden. Als E-Roaming im Kontext der Elektromobilität wirddie Möglichkeit verstanden, sein Elektrofahrzeug an einer beliebigen Ladestation aufladenzu können, unabhängig davon, ob ein Vertragsverhältnis mit dem Betreiber genau dieserLadeinfrastruktur besteht. Vor diesem Hintergrund werden neben den Potentialen, die derISO/IEC 15118 Kommunikationsstandard hierfür bietet, auch weitere Kommunikationspro-tokolle wie das Open Charge Point Protocol (OCPP) sowie das Open InterCharge Protocol(OICP) beleuchtet. Diese drei Protokolle bauen auf verschiedenen Kommunikationsstufennahtlos aufeinander auf und ermöglichen durch einen einfachen Zugang zu (semi-)öentlicherLadeinfrastruktur ein benutzerfreundliches Elektromobilitätserlebnis.Ausgehend von den präsentierten Zielstellungen werden im folgenden Abschnitt bereitsbestehende wissenschaftliche und technologische Ergebnisse in diesem Zusammenhang vorge-stellt, bevor im letzten Abschnitt des einführenden Kapitels die wesentlichen Beiträge dervorliegenden Arbeit diesen Ansätzen gegenübergestellt werden.1.3 Verwandte ArbeitenIn der Literatur finden sich zahlreiche Veröentlichungen zu Konzepten, welche den gesteuertenLadevorgang eines oder mehrerer Elektrofahrzeuge in einem eingegrenzten Gebiet adressieren.Ein gewichtiger Teil jener wissenschaftlicher Untersuchungen hat einen eher wirtschaftlichgeprägten Fokus. So untersuchen bspw. Schuller et. al. [64] in einer Simulation das ökonomi-sche Potential eines preisgesteuerten intelligenten Ladevorgangs sowie der Bereitstellung vonEnergie im Vergleich zu einem ungesteuerten Ladevorgang anhand der Großhandelspreise fürStrom an der europäischen Marktplattform EEX, empirischen Fahrprofilen aus dem deutschenMobilitätspanel11 sowie drei unterschiedlichen E-Fahrzeugspezifikationen. Hierbei wird ange-nommen, dass nur zu Hause geladen wird. Nach Einbeziehung energie- und leistungsbezogenerAbnutzungskosten kommen sie zu dem Schluss, dass die Stromkosten für Berufstätige imDurchschnitt um mehr als 32 % gesenkt werden können, für Rentner liege die Kostenersparnisgar bei mindestens 51 %.In einer weiteren Arbeit von Schuller und Rieger [65] wurde evaluiert, welchen wirtschaftli-chen Kostenvorteil auf Endkundenseite die Einbindung von Elektrofahrzeugen in den deut-schen Regelenergiemarkt hat. Die Ergebnisse zeigen auf, dass die profitabelste Option dieBereitstellung negativer Regelenergie (Laden des E-Fahrzeugs) im Sekundär- wie auch imTertiärregelenergiemarkt darstellt, mit durchschnittlich jährlichen Erträgen von 730,31 Europro Fahrzeug. Hierbei wurden empirische Preisdaten aus den Jahren 2011 und 2012 der vier11http://mobilitaetspanel.ifv.kit.edu9Kapitel 1 Einführunggroßen Übertragungsnetzbetreiber Amprion, TransnetBW, 50Hertz Transmission und TenneTTSO mit einbezogen. Weiterhin wird angenommen, dass ein Aggregator eine ausreichendgroße Menge an E-Fahrzeugen steuern kann, wobei einerseits die Mobilitätsbedürfnisse derFahrer und andererseits die Mindestanforderungen für die Teilnahme am Regelenergiemarkt(festgelegt im sogenannten Transmission Code) berücksichtigt werden.Gottwalt et. al. [29] gehen ebenfalls von einer zentralen Aggregatorinstanz aus, um denLadevorgang einer Flotte von E-Fahrzeugen dahingehend zu steuern, dass eine maximaleKorrelation mit der Verfügbarkeit von Wind- und PV-Energie erzielt und somit die Nutzungkonventioneller Kraftwerke minimiert wird. Hierbei wird erneut auf empirische Fahrdatenaus dem deutschen Mobilitätspanel zurückgegrien, wobei speziell die Fahrprofile von Be-rufstätigen herangezogen werden und die Annahme besteht, dass nur zu Hause geladen wird.Sie kommen zu dem Ergebnis, dass die jährliche Ausbeute der zur Verfügung stehendenWindenergie durch einen gesteuerten Ladevorgang auf ca. 67 % fast verdoppelt werden kann.Die vorliegende Arbeit unterscheidet sich zu den meisten bisherigen Untersuchungen darin,dass der Fokus mehr auf der technischen Integration des Elektrofahrzeugs mittels teilsstandardisierter Informations- und Kommunikationstechnologie liegt. Um nun aus der Vielzahlder verfügbaren Publikationen einen angemessenen Vergleich zu dieser Arbeit ziehen zukönnen, werden im restlichen Teil dieses Abschnitts jene Arbeiten vorgestellt, welche sichauch mit einem konkreten Kommunikationsprotokoll beschäftigen und nicht – wie es oft inder Literatur anzufinden ist – ein solches bereits als gegeben voraussetzen, ohne näher aufwichtige Kommunikationsdetails einzugehen.Betreend autonomer Systeme wie dem in dieser Arbeit vorgestellten Smart Home EMS,welche sich mit elektrischem Energiemanagement beschäftigen, wurde bereits in Allerdinget al. [3] eine ausgiebige Vergleichsanalyse durchgeführt.1.3.1 PowerUpPowerUp [42] ist ein von der EU im Zuge des 7. Rahmenprogramms kofinanziertes Projekt,welches im Juli 2011 mit einer Laufzeit von 24 Monaten startete und die Spezifikation sowieEntwicklung eines Ende-zu-Ende Kommunikationssystems zwischen Elektrofahrzeug undSmart Grid zum Ziel hatte. Hierbei wurde für die Kommunikation zwischen Elektrofahrzeugund Ladestation auf den ISO/IEC 15118 Standard (damals noch in einem Draft-Stadium)gesetzt. Für die Kommunikation zwischen dem in der Ladestation eingebauten Smart Meterund einer zentralen Lastkontrolleinheit (“Load Balance Controller”) wurde auf den IEC62056 DLMS/COSEM Standard12 gesetzt, welcher zwar weltweit Anwendung findet, jedochbspw. nicht in den USA oder Deutschland. Dieser IEC-Standard enthält jedoch noch keineelektrofahrzeugspezifischen Datenobjekte, weshalb im Rahmen des Projekts dieser Standardum ebensolche Objekte erweitert wurde. Eine Übersicht über die Systemarchitektur vonElektrofahrzeug bis zur Lastkontrolleinheit auf Netzseite ist in Abbildung 1.5 dargestellt.In Abbildung 1.6 wird am Beispiel des Aufbaus einer Ladesession zwischen Elektrofahrzeugund Ladestation die Interaktion zwischend den Schnittstellen der beiden zum Einsatz kommen-den Standards dargestellt. Die ISO/IEC 15118 Nachricht ChargeParameterDiscoveryReq,welche wichtige Parameter bzgl. der Ladesteuerung kommuniziert und u. a. in Abschnitt 2.2.112http://www.dlms.com/documentation/dlmscosemspecification/iecstandardsforelectricitymetering.html101.3 Verwandte ArbeitenIntegrating EVs into the Smart-GridResults of the EU co-funded FP7 project “PowerUp”Andras KovacsBroadBitandras.kovacs@broadbit.comDave MarplesTechnolutiondave.marples@technolution.euRobert SchmidtDENSO AUTOMOTIVE Dtld. GmbHr.schmidt@denso-auto.deRaduz MorsztynCorinex Communicationsraduz.morsztyn@corinex.comAbstract— Standardization efforts are currently underway to realize the Europe-wide deployment of Smart-Grids. Numerous protocols have already been standardized; each tailored to a distinct application domains. Amongst these, Smart Metering and EV charging have only recently started to converge, and the goal of the PowerUp project has been to advance such convergence. This paper presents the major results from the project. The PowerUp consortium has specified and developed an end-to-end EV to Grid communication system, respecting the applicable communications standards. After introducing the underlying system architecture for the end-to-end integration of the Vehicle-to-Grid (V2G) communications interface, we describe critical Smart-Grid integration aspects for each protocol layer within the V2G communications protocol stack. Finally, prototype test observations are presented. The outlined end-to-end integration of the V2G interface demonstrates the technological solution for ensuring that even mass-deployment of EVs would not interfere with the stability of the electric grid.Keywords—EV to Grid communication; V2G communication interface; Smart Metering infrastructure; PLC technologies; Interoperability.I. INTRODUCTIONPreparing for the mass market deployment of EVs requires the development of an Vehicle to Grid (V2G) communication system for managing the EV recharging sessions to allow grid balancing and the correlated demands causing overloads. The standardization of an interoperable V2G communications interface is ongoing in the ISO/IEC 15118 working group [2]. This standard defines the communications interface between the EV and the local recharging controller device. On the automotive side of the V2G interface proprietary integration with the battery management and HMI components, usually over CAN or a similar bus structure, integrates the recharging functionality into the vehicle. On the grid side, integration with existing and upcoming Smart-Grid technologies is the key for a successful introduction of an EV to Grid communication system. These integrations, on the vehicle and grid sides, are the focus of PowerUp, and this article.In PowerUp an end-to-end EV to Grid communications system has been developed, implementing all the above integration aspects of the V2G interface[1]. This has been validated under both AC and DC charging scenarios. Figure 1 shows the system architecture view of the implemented solution. From an architectural perspective, ISO/IEC 15118 def ines the ‘Supply Equipment Communicat ions Controller’ (SECC) infrastructure-side entity for the V2G interface, while Smart-Grid systems terminate at the ‘Smart-Meter’ (SM) entity. The key for successful integration and deployment is therefore to develop the right interaction concept between these SECC and SM entities, which are both part of the local EV Supply Equipment (EVSE). The next section addresses physical deployment issues of these entities, and subsequent sections describe layer-by-layer integration issues of the involved communication protocol stacks.HPGP or UPA linkSmart GridDLMS/COSEM(IEC 62056 with EV specific extensions)V2G(ISO/IEC 15118-2)EVCCBattery Management SystemWSU statusONB&M statusONVOLTAGE(V)278 VCURRENT(A)20 ACharging…End at 11:30Battery25%AlarmsGeneral FaultBattery FaultDC/DC FaultMotor/InverterHMILoad Balance ControllerG5 wireless linkSECCSmart MeterHPGP-G3 converterEVSEFig. 1. The EV to Grid communications system architecture in PowerUp.It should be noted that this paper presents only a subset of the PowerUp results. The automotive integration aspects and the load-balancing algorithm have not been described here due to space constraints and to retain the focus on the EV to Grid communication system. Other complementing project results are available in [6].The PowerUp project has been co-funded by the EU within the FP7 programme2013 13th International Conference on ITS Telecommunications (ITST)978-1-4799-0846-2/13/$31.00 ©2013 IEEE 413Abbildung 1.5: Systemarchitektur der Kommunikation zwischen E-Fahrzeug und Smart Gridim Projekt PowerUp [42]noch näher beleuchtet wird, wird vom E-Fahrzeug (EV) an den Kommunikationscontroller inder Ladestation (SECC) gesendet. Dieser wiederum kommuniziert innerhalb der Ladestationüber eine Brücke mit dem Smart Meter (SM), welcher sodann eine PUSH-Anfrage an dasSmart Grid Kontrollzentrum sendet. Diese Kontrolleinheit sendet ihrerseits mittels einer imIEC 62056 definierten SET-Nachricht, erweitert um elektrofahrzeugspezifische Parameter,ein Ladeprofil samt Tarifinformationen zurück. Der SECC übermittelt durch das Senden derChargeParameterDiscoveryRes Nachricht dieses Ladeprofil weiter an das E-Fahrzeug.Dieses Einsatzszenario wird bspw. anhand eines Lieferdienstes dargestellt, welcher Paketeinnerhalb gewisser Fristen auszuliefern hat und dafür elektrifizierte Lieferwagen einsetzt.Wie auch schon von den Autoren festgestellt wird, ist die Kommunikation von Seitender Ladestation in ein Backend über die IEC 62056 DLMS/COSEM Schnittstelle nicht dieeinzige Möglichkeit. Eine sehr weit verbreitete Alternative stellt bspw. das Open Charge PointProtocol (OCPP) dar, welches in Abschnitt 2.2.2 kurz vorgestellt wird. Weitere Alternativenwie die IEC 61850 Kommunikationsschnittstelle (siehe Abschnitt 2.2.3) für die Kommunikationzwischen dezentralen Energieerzeugungseinheiten wie PV-Anlagen und BHKWs mit einemnetzseitigen Lastkontrollzentrum sind denkbar.Die vorliegende Arbeit unterscheidet sich von den Ansätzen des PowerUp-Projekts vor allem11Kapitel 1 EinführungBoth of these renegotiation types have been implemented in PowerUp using the current ISO/IEC 15118-2 message set, i.e. without specifying new non-standard messages. The resulting V2G application layer thereby fully complies with the ISO/IEC 15118-2 standard, while also allowing dynamic adjustments to the charging process of the EV.B. Interaction between V2G and DLMS/COSEMThe key to successful application layer integration between the EVs and the electric grid is to establish a proper interaction between the V2G application layer communicating towards the EVs and the DLMS/COSEM application layer [3] communicating with the grid control center. DLMS/COSEM transactions generally consider the SM entity as a server, which the grid control center may query via the GET service or configure via the SET service. However a new PUSH service has been recently introduced, which allows the SM to initiate the passing of some information to the grid control center. Our implementation of the V2G-DLMS/COSEM interaction makes full use of this PUSH capability and the concept of this interaction is shown in Figure 9. The SECC acts as a server on the V2G interface, meaning that any V2G transaction is initiated as a request to the SECC. During the setup phase of the V2G charging session each incoming request triggers a corresponding PUSH transaction to the grid controller, which then uses the SET transaction to load the response parameters into the SM. Upon receiving these parameters, the SECC responds to the incoming V2G request. This mechanism is illustrated in Figure 9 through the example of the ‘Charge Parameter Discovery’ transaction. Analogously, this same methodology is applied for the other remaining V2G transactions during the charge setup phase.Smart-Grid control center SM SECC EVSET (includes charging profile, SA Tuple ID, tariffs, ...)V2GDLMS/COSEMCharge Parameter Discovery Response (OK result, SA Tuple ID, tariffs, ...)PUSH (includes requested Energy Amount, departure time, ...)Charge Parameter Discovery Request (includes requested Energy Amount, departure time, ...)Fig. 9. Application layer interaction between the ISO/IEC 15118 V2G and IEC 62056 DLMS/COSEM interfaces during the charging session establishmentAfter starting the EV recharging session, V2G transactions comprise periodic ‘Charging Status’ and ‘Metering Receipt’ request/response messages. These requests can be locally handled by the SM via the SECC, without interacting with the grid controller. Therefore the grid controller can determine its own periodicity for querying the amount of energy transferred to the EVs (using GET transaction to the SM) or can instigate a renegotiation of the charging session if needed (using a GET transaction to the SM containing the same parameters as illustrated in Figure 9). This solution is crucial for not exceeding the (limited) capacity of the PLC link of the SM, because this link is potentially shared among a large number of SMs. Only the setup of the V2G session requires additional messages, whereas the energy consumption of charging process can be monitored at the same rate as ordinary SM queries, and thus can be piggybacked.The presently published DLMS/COSEM messages in the IEC 62056 standard do not contain EV-specific objects. The PowerUp projects has therefore specified the required DLMS/COSEM object extensions for performing the above-described interaction with the V2G interface, and has published these specifications on its project website [1]. These proposed extensions are scheduled for discussion at the DLMS User Association during September, 2013, and we anticipate them to become part of a future release of the IEC 62056 standards. Therefore we expect the PowerUp solution for application layer integration with the grid infrastructure to be compliant with upcoming releases of the relevant standards.For the user, this application layer integration is transparent. Those processes may be configured and supervised through intuitive user interfaces; Figure 10 illustrates the prototype implementation of such user interface. Fig. 10. User interfaces at EV-side. The screen on the left shows a diagnostic screen for monitoring the progress of the V2G session. The screen on the right shows the prototyped driver interface, displaying the charging schedule and status.We believe that our choice of designing an interaction between the ISO/IEC 15118 V2G interface and the IEC 62056 Smart-Metering interface is well justified by their current industrial relevance:•ISO/IEC 15118 represents a global consensus for the V2G interface between the EV and EVSE entities, with experts from EU, USA, and Japan/China/S. Korea contributing to the development of this standard.•IEC 62056 DLMS/COSEM represents a global consensus for the Smart-Metering interface; this standard has been adopted for Smart-Metering systems deployment nearly everywhere in the world [5] (with the exception of the USA and Germany).• Smart-Metering systems are expected to be widely deployed. In PowerUp, it was proposed to combine Smart-Metering and SECC functionality within one entity, as a suitable deployment solution for private EV charging scenarios. As for public EV charging scenarios, a similar solution could be applied, with additional mechanisms for identification and authentication.The above observations imply that the selected PowerUp solution for application layer integration with the grid infrastructure makes the project results globally relevant and easily deployable in the future.C. Alternative approachesWhile the V2G-DLMS/COSEM interaction mapping described above represents one proposed solution, it is nevertheless not the only possible mapping. This subsection therefore briefly presents an overview of alternative approaches, pursued by other research groups.2013 13th International Conference on ITS Telecommunications (ITST)417Abbildung 1.6: Interaktion zwischen den ISO/IEC 15118 V2G und IEC 62056 DLMS/COSEMSchnittstellen während des Aufbaus einer Ladesession im Projekt PowerUp [42]dadurch, dass die Lastkontrolle des E-Fahrzeugs unter Berücksichtigung der Lastsituation ineinem Smart Home, wie es in Abschnitt 3.1 noch vorgestellt wird, durchgeführt wird. Im SmartHome Szenario kommen eine Vielzahl sehr heterogener Verbraucher und Erzeuger zum Einsatz,für welche mittels eines geeigneten Optimierungsansatzes ein kostenoptimales Lastprofil untereiner Vielzahl an technischen und nutzerbedingten Restriktionen berechnet und kommuniziertwerden muss. Die zentrale Lastkontrolleinheit wird im In-House-Szenario der vorliegendenArbeit durch ein hierarchisch aufgebautes Energiemanagement-System verkörpe t, welches inAbschnitt 3.2 erläutert wird.Darüber hinaus wurde im PowerUp-Projekt der Aspekt der Rückspeisung von Energieaus dem Fahrzeug nicht betrachtet. Durch das Rückspeisen von Energie wird einerseits dasPotential der optimierten Eigenstromnutzung besser ausgeschöpft, andererseits aber auch dasOptimierungsproblem komplexer gestaltet.1.3.2 INEESDas vom Bundesumwelt- und Bauministerium geförderte Projekt INEES – “IntelligenteNetzanbindung von Elektrofahrzeugen zur Einbringung von Systemdienstleistungen” –, welcheszum 1. Juni 2012 mit einer Laufzeit von drei Jahren startete, hat zum Ziel, mit Hilfe einesPools von Elektrofahrzeugen Systemdienstleistungen anzubieten und somit diese Fahrzeuge inden Strommarkt, speziell den Regelenergiemarkt, einzubinden, was somit Integrationsszenario3 adressiert [72]. Mit Hilfe eines Flottenversuchs bestehend aus 20 VW e-up!s, welche derProjektpartner Volkswagen ausgewählten Testkunden bereitstellt, und der Kommunikationder einzelnen E-Fahrzeuge mit einem sogenannten Poolmanager soll ein gemeinsamer virtuellerStromspeicher signifikanter Größe gebildet werden, um die schwankende Produktion von Wind-und Sonnenenergie auszugleichen.Im Gegensatz zum Projekt PowerUp wird bei INEES, gegeben durch das Projektziel Sys-temdienstleistungen bereitzustellen, auch Energie rückgespeist, was über 10 kW DC-Wallboxen(an der Wand angebrachte Ladestationen) realisiert wird. Durch ein zu konzipierendes Anreiz-system für Fahrzeugnutzer soll darüber hinaus erforscht werden, in welcher Weise die Nutzeram ehesten dazu zu bewegen sind, die in ihren E-Fahrzeugen gespeicherte Energie für denPoolmanager und somit Regelenergiemarkt bereitzustellen. Der Projektpartner Lichtblickbietet hierfür seine Steuerungssoftware namens “Schwarm-Dirigent” an, welche die Steuerung121.3 Verwandte Arbeitender Lade- und Rückspeisevorgänge für die einzelnen Fahrzeuge durchführt.Leider ist zum aktuellen Zeitpunkt noch keine wissenschaftliche Veröentlichung zu diesemProjekt verfügbar, was möglicherweise auch damit zu tun hat, dass der zweiteilige Feldversucherst im April 2014 startete und Evaluationsergebnisse somit noch nicht vorliegen. Es istjedoch aus Gesprächen mit Projektteilnehmern bekannt, dass als Kommunikationsschnittstellefür die E-Fahrzeuge ebenfalls eine Version des ISO/IEC 15118 Standards eingesetzt wird,erweitert um gewisse Parameter, welche den Austausch von (Steuer-)Informationen bzgl. desNetzzustandes erlauben. Ein direkter Vergleich gestaltet sich jedoch aufgrund mangelnderwissenschaftlicher Publikationen zu diesem Projekt schwierig.1.3.3 Smart V2GIm Rahmen des über drei Jahre angelegten Projekts SmartV2G, welches im Herbst 2011startete, erforscht das Fraunhofer ESK die Kommunikationsschnittstellen zur Integration vonElektrofahrzeugen in das Smart Grid unter Anwendung der drahtgebundenen Protokolle IEC61851 und ISO/IEC 15118 für die Kommunikation zwischen Elektrofahrzeug und Ladestationsowie des IEC 61850 Standards für die Kommunikation mit einem Backend im Smart Grid [28].Des Weiteren werden drahtlose Kommunikationsprotokolle für diesen Zweck evaluiert. DasProjekt wird von der Europäischen Kommission im Rahmen des 7. Rahmenprogramms derEU gefördert.In den bereits bestehenden wissenschaftlichen Veröentlichungen13 wird der Ansatz verfolgt,mittels einer modellprädiktiven Regelung (Model Predictive Control – MPC) einen Aggregatorfür E-Fahrzeuge in die Lage zu versetzen, die Ladelast in einem Netzsegment kostenoptimal zusteuern und das Lastverschiebepotential sowie ggf. Systemdienstleistungen gewinnbringend amStrommarkt zu handeln. Hierbei werden Vorhersagen für die Ankunft von Elektromobilisten anLadestationen in diesem Netzsegment sowie Annahmen über Strompreise und Laststeuersignalegetroen.Zwar wird in der Projektbeschreibung und in Pressemitteilungen14 von der Anwendungdes ISO/IEC 15118 Protokolls gesprochen, jedoch finden sämtliche Steuerungsansätze in denPublikationen allein auf der Nutzung des eher rudimentären IEC 61851 Protokolls statt, aufwelches in Abschnitt 2.1.2 noch näher eingegangen wird. Auch ist das betrachtete Szenariobei genauerem Hinsehen nicht vergleichbar mit dem der hier vorliegenden Arbeit, da dasIn-House-Szenario nicht näher betrachtet wird.1.3.4 Aktivhaus B10Das Projekt, welches sich am ehesten mit dem Konzept dieser Arbeit vergleichen ließe, ist dasvor kurzem erst ins Leben gerufene Projekt Aktivhaus B1015, welches vom Bundesministeriumfür Verkehr und digitale Infrastruktur gefördert wird (Laufzeit 1. März 2012 - 30. April2016). Das angeblich erste Aktivhaus16 der Welt ist in der Lage, mehr Energie zu erzeugenals es für den Eigenbedarf benötigt und darüber hinaus noch zwei Elektrofahrzeuge derMarke Smart mit dem nötigen Strom zu versorgen. Die installierten PV-Anlagen erzeugeneinen jährlichen Überschuss von 2150 kWh. Die für die Gebäudeforschung relevanten Daten13http://www.smartv2g.eu/publications.html14http://www.esk.fraunhofer.de/de/medien/pressemitteilungen/pm1402.html15http://www.aktivhaus-b10.de/home/16Laut Definition der Projektwebseite steht der Begri “für Gebäude, die allein oder im Verbund mit anderen(in einem sogenannten Aktivhausverbund) mehr Energie erzeugen als sie selbst benötigen”.13Kapitel 1 Einführungwerden kontinuierlich erhoben und zusammen mit der gemessenen Energieerzeugung und dem-verbrauch wissenschaftlich ausgewertet.Aktivhaus B10 – Architektur und Mobilität für MorgenDas E-Lab in der WeißenhofsiedlungBauherr des Projekts ist eine Projektgesellschaft des gemeinnützigen Stuttgart Institute of Sus-tainability Stiftung e.V. (SIS). Die Planung des Gebäudes erfolgt kostenfrei durch das Büro von Werner Sobek. Die Errichtung des Gebäudes er-folgt − ebenfalls kostenfrei − durch die Schwö-rerHaus KG aus Hohenstein. Zahlreiche weitere Unternehmen unterstützen das Projekt, z. B. die Daimler AG durch die Bereitstellung von zwei Elektro-Smarts. www.livinglab-bwe.de/projekt/aktivhaus-b10/www.wernersobek.comDie 1927 innerhalb weniger Monate errichtete Weißenhofsiedlung auf dem Stuttgarter Killes-berg kam einer Revolution im Bauwesen gleich: Die Entwürfe verschiedener weltberühmter Architekten zeigten, wie wir künftig bauen und wohnen können. Teile der Weißenhofsiedlung wurden im Krieg zerstört und wiederaufgebaut – bis auf ein Grundstück im Bruckmannweg, das seit 1945 brach liegt. Hier entsteht nun − für die Dauer von drei Jahren − ein neues, zukunftswei-sendes Gebäude, das aufzeigt, wie innovative Materialien, Konstruktionen und Technologien unsere gebaute Umwelt nachhaltig verbessern können. Das Forschungsprojekt − nach seinem Standort im Bruckmannweg 10 kurz „B10“ genannt − ist das erste Aktivhaus der Welt. Dank eines ausge-klügelten Energiekonzepts und einer selbstler-nenden Gebäudesteuerung erzeugt es das Dop-pelte seines Energiebedarfs selbst − und zwar aus nachhaltigen Quellen. Mit dem gewonnenen Überschuss werden zwei Elektroautos und das unter Denkmalschutz stehende Haus des Archi-tekten Le Corbusier (seit 2006 Heimat des Wei-ßenhofmuseums) versorgt. Nach Abschluss des Forschungsprojekts wird das Gebäude vollstän-dig zurückgebaut, anderswo wieder aufgebaut oder zu 100 % rezykliert. Das Grundstück wird der Stadt Stuttgart anschließend wieder im ur-sprünglichen Zustand zurückgegeben.B10 ist Bestandteil des von der Bundesregierung geförderten Forschungsverbundes „Schaufens-ter Elektromobilität“. In einer ersten Nutzungs-phase können sich interessierte Besucher in B10 über das Energiekonzept und die angewandte Bautechnik informieren. In der zweiten Nut-zungsphase soll das Gebäude kostenfrei von zwei Studenten bewohnt werden. Während der gesamten Projektlaufzeit werden Energieerzeu-gung und Energieverbrauch sowie eine Vielzahl weiterer für die Gebäudeforschung hochrele-vanter Daten kontinuierlich gemessen und an der Universität Stuttgart wissenschaftlich aus-gewertet. Bauherr: E-Lab Projekt gGmbH, Stuttgart Architektur + Koordination, Tragwerksplanung: Werner Sobek, Stuttgart Energiekonzept: WSGreenTechnologies Interface: Werner Sobek Design Gebäudesteuerung: alphaEOS, Stuttgart Elektromobilität: Daimler AG Konstruktion: SchwörerHaus, Hohenstein Monitoring: ILEK, Universität Stuttgart Licht und Lichtplanung: Candela Lichtplanung, Stuttgart Rahmen Glasfassade: R&G Metallbau, Ellikon an der Thur/CH Raffstoren: Warema Renkhoff, Leinfelden Textilfassade: EPS Profi led Solutions, Siegen Vakuum-Isolier-Panele: Porextherm Dämmstoffe, Kempten Gartenbau: Jörg Seidenspinner Garten- und Landschaftsbau, StuttgartAnsicht des E-Lab vom Bruckmannweg – die Fassade an der Westseite besteht aus einem speziell entwickelten Vakuumglas, das sehr gute Wärmedämmwerte mit hoher Transparenz verbindet.B10ProjektpartnerAnsprechpartner:Prof. Dr. Dr. E.h. Dr. h.c. Werner SobekWerner Sobek Group70597 StuttgartT. +49 711 76750 38mail@wernersobek.com40 41Wohnen und ElektromobilitätSchaufenster ProjektübersichtAbbildung 1.7: Grundriss des Aktivhaus B10 [43]Als Projektpartner ist die Firma alphaEOS AG für die Gebäudesteuerung und das Energie-management verantwortlich und listet in ihrer Projektbeschreibung [7] folgende technischeSpezifikationen auf:• Aktivhaus erzeugt 200 % seines Energiebedarfs• Selbstlernendes, prädiktives Energiemanagement für Gebäude und Elektromobilität• Umfassende Vernetzung der Haustechnik, Haushaltsgeräte und Ladeinfrastruktur aufBasis des EEBus-Standards• Integrales, lernfähiges User Interface für Haussteuerung und Mobilitätsplanung• Anbindung an ein virtuelles Kraftwerk zur bedarfsgerechten Einspeisung und regionalenDirektvermarktung von StromüberschüssenAuch hier soll für die Kommunikation mit den Elektrofahrzeugen die ISO/IEC 15118 Schnitt-stelle zum Einsatz kommen und ein Home-Energy-Management-System (HEMS) die Interak-tion mit den Hausbewohnern erlauben. Hier wäre ein Vergleich des angewandten Konzeptssehr interessant, allerdings liegen – wahrscheinlich aufgrund der erst im Mai 2014 startendenWohnphasen – keinerlei wissenschaftliche Erkenntnisse vor.141.3 Verwandte Arbeiten1.3.5 Fellbach ZEROplusEin weiteres Forschungsprojekt mit Bezug zur Integration eines Elektrofahrzeugs in dasEnergiemanagement eines Haushalts ist das Projekt Fellbach ZEROplus, dessen Förderzeit-rahmen sich vom 1. November 2012 bis zum 31. Oktober 2015 erstreckt und welches aufwissenschaftlicher Seite vom Fraunhofer Institut für Solare Energiesysteme (ISE) begleitetwird. Ziel des Projektes ist es, für eine Baugruppe von sieben Energieplus-Häusern, welcheallesamt mit großen Photovoltaik-Anlagen ausgestattet sind, ebenfalls ein Home-Energy-Management-System (HEMS) zu entwickeln. Dieses soll dafür sorgen, dass der Strombedarfder Haushaltsgeräte sowie der zur Verfügung stehenden Elektrofahrzeuge vorwiegend mitregenerativ erzeugter Energie gedeckt wird. Das HEMS soll darüber hinaus die Energieflüsseauf Benutzungsschnittstellen im Haus visualisieren. Der Einsatz der Systeme soll im realenBetrieb über zwei Jahre demonstriert und wissenschaftlich ausgewertet werden, allerdingsexistieren zum aktuellen Zeitpunkt noch keine wissenschaftlichen Publikationen.Die E-Fahrzeuge werden über 22 kW Ladestationen (Wallboxen) aufgeladen und über Mode317 gesteuert. Laut Projektbeschreibung ist eine ISO/IEC 15118 Kommunikationsschnittstellezwar vorbereitet, jedoch stehen entgegen der ursprünglichen Planung für den realen Betriebkeine E-Fahrzeuge bereit, die diese Schnittstelle implementiert haben18. Darüber hinauskönnen diese Fahrzeuge auch nicht Energie in das Energienetz bzw. die Energieplus-Häuserzurückspeisen, was somit ein weiteres essentielles Unterscheidungsmerkmal zum Projekt iZEUSdarstellt, in dessen Rahmen diese Arbeit angefertigt wurde.1.3.6 Toyota City Low-carbon Society Verification ProjectMit Blick auf internationale E-Mobilitätsprojekte ist das Toyota City Low-carbon SocietyVerification Project [53] hervorzuheben, im Rahmen dessen in Toyota City ein ganzer Stadtteilmit bis zu 227 energieezienten Haushalten errichtet wird. Jene Haushalte sind mit PV-Anlagen, stationären Speicherbatterien, Brennstozellen sowie Elektro- und Hybridfahrzeugenausgestattet. Ein HEMS integriert und steuert sämtliche Komponenten eines Hauses undvisualisiert auf Touch-Displays für die Bewohner sowohl die Energieflüsse als auch die Preissi-gnale, welche gemäß der Lastsituation im Stadtviertel auch extreme Preisspitzen beinhaltenkönnen. Als Anreiz zur Energieeinsparung werden sogenannte “Eco-Punkte” vergeben, welchesich im Sinne eines energieezienten und schadstoarmen Stadtviertels auch für den Kaufvon ermäßigten Bustickets oder vergünstigten Produkten im Supermarkt einsetzen lassen.Dieser zukunftsweisende Ansatz ist einer der wenigen real existierenden Projekte, die daserneuerbare Energien einbindende Lastmanagement auf ein ganzes Stadtviertel ausweiten.Die Kommunikation zwischen den Elektrofahrzeugen und den jeweiligen Ladestationen bzw.HEMS basiert jedoch auf einem proprietären Kommunikationsprotokoll und setzt noch nichtauf die aktuelle Entwicklung eines standardisierten Protokolls nach ISO/IEC 15118.Das Anwendungsszenario eines Smart Home, dessen thermische und elektrische Verbraucherwie auch Erzeuger sich über ein flexibel und adaptiv agierendes Energiemanagement-Systemkostenoptimal einplanen lassen, wurde, wie Allerding [3] gezeigt hat, noch nicht ausgiebiguntersucht. Betrachtet man zusätzlich den Aspekt der Einbindung eines rückspeisefähigenElektrofahrzeugs in ein solches adaptives Energiemanagement mittels der Kommunikations-schnittstelle ISO/IEC 15118, welche sich als weltweiter Standard etablieren wird (vgl. Abschnitt17Siehe Abschnitt 2.1.2 für eine Beschreibung der vier Lademodi gemäß der Norm IEC 61851.18Laut inoziellen Informationen sollen Renault ZOEs zum Einsatz kommen.15Kapitel 1 Einführung6.1), so finden sich bisher noch keine zufriedenstellenden Untersuchungen in der wissenschaft-lichen Literatur.1.4 Wesentliche Beiträge dieser ArbeitDie vorliegende Arbeit beschäftigt sich konkret mit den Details des derzeit in der weltwei-ten Standardisierung befindlichen Kommunikationsprotokolls ISO/IEC 15118, welches denAustausch energierelevanter Mehrwertinformationen zwischen Elektroauto und Ladestationermöglicht. Es werden ausführlich die entsprechend definierten Nachrichten, Parameter undRestriktionen der Spezifikation dargelegt, welche für einen gesteuerten Ladevorgang nach denZielvorgaben des Hausbewohners einerseits und denen des Energiemanagements andererseitsberücksichtigt werden müssen. Dieses Kommunikationsprotokoll betrachtet den Anwendungs-fall der Rückspeisung von Energie nur konzeptionell, in der technischen Spezifikation findet sichjedoch keinerlei konkrete Umsetzung. Daher wird ergänzend hierzu erläutert, wie entsprechen-de Nachrichten der Protokollspezifikation um geeignete Paramter erweitert werden können, umdiesen Anwendungsfall zu realisieren und dennoch eine standardkonforme Implementierung,wie sie im Rahmen dieser Arbeit erfolgte, zu gewährleisten.Bevor das Elektrofahrzeug am Gesamtenergiemanagement des Smart Home teilnehmen undsomit als flexibler Verbraucher und Energiespeicher eingeplant werden kann, ist zunächst einformales Modell vonnöten, welches einerseits die technischen Restriktionen, die u. a. durchdie Batterie induziert werden, und andererseits die Benutzervorgaben abbildet. Im Zugedieser formalen Modellierung werden die entsprechenden Parameter der ISO/IEC 15118Spezifikation auf die mathematischen Variablen des Optimierungsproblems abgebildet, umsomit eine realitätsgetreue Optimierung durchführen zu können.Letzten Endes muss eine Implementierung des ISO/IEC 15118 Protokolls auch in der Lagesein, sich in das bestehende Energiemanagement-System des Smart Home einzugliedern, umdas Elektrofahrzeug überhaupt erst in die Gesamtoptimierung einbinden zu können. Hierfürist die Entwicklung eines eigenen Treibers zur Anbindung des Elektrofahrzeugs über dasISO/IEC 15118 Protokoll notwendig. Zusätzlich ist die Realisierung einer observierenden undsteuernden Komponente gemäß den Prinzipien des Organic Computing [45] und der darausentwickelten generischen Observer/Controller-Architektur, auf welcher das Energiemanagementfußt, essentiell. Diese Elemente (Observer, Controller und Treiber) sowie die Kodierung derenergierelevanten Mehrwertinformationen zur Einplanung des E-Fahrzeugs in das auf einemevolutionären Algorithmus basierende Gesamtenergiemanagement bilden den Kern des Beitragsdieser Arbeit.Das hier vorgestellte und implementierte Kommunikationsprotokoll wird darüber hinaushinsichtlich diverser Kriterien wie Akzeptanz, Erweiterbarkeit, Sicherheit, Komplexität undEzienz untersucht, um eine Aussage bezüglich seiner Zukunftsfähgikeit treen zu könnenund somit dem interessierten Leser einen kritischen und gut informierten Blick auf dieseSpezifikation mitzugeben.161.5 Gliederungsübersicht1.5 GliederungsübersichtNach der einführenden Motivation zum Forschungsgegenstand dieser Arbeit gibt Kapitel 2 eineÜbersicht über die Standardisierungsinitiativen, welche die hard- und softwareseitigen Schnitt-stellen und Komponenten im Bereich der E-Mobilität19 zum Zwecke der Interoperabilitätverschiedener Implementierungen vereinheitlichen sollen. In diesem Grundlagenkapitel wirdvor allem auch das bereits angesprochene Kommunikationsprotokoll ISO/IEC 15118 näherbeleuchtet, dessen Funktionsweise für das weitere Verständnis dieser Arbeit unabdingbar ist.Im sich daran anschließenden dritten Kapitel wird der Versuchsaufbau vorgestellt, in dessenRahmen die Evaluationen stattfinden. Hierbei werden alle relevanten Komponenten des realenSmart Home sowie das im Einsatz befindliche Energiemanagement-System eingeführt. Darüberhinaus wird detailliert erläutert, in welcher Weise das Elektrofahrzeug kommunikationstech-nisch an das EMS angebunden wurde.Die Integration des als flexibel steuerbare Last und gleichzeitig Verbraucher agierendenElektroautos in die Architektur des EMS wird ausführlich in Kapitel vier dargelegt. Hierbeiwird die Funktionsweise und Aufgabe jeder einzelnen Komponente – Treiber, Observer undController – sowie diverse mögliche Kodierungsschemata für den Austausch energierelevanterMehrwertinformationen samt ihrer Vor- und Nachteile im Detail besprochen.Kapitel fünf stellt einen von den vorigen Kapiteln etwas losgelösteren Abschnitt dar, welcherjedoch das Potential des ISO/IEC 15118 Protokolls hinsichtlich des E-Roamings beleuchtetund eine wichtige weitere Grundlage liefert, um im ersten Teil des Kapitels 6 eine Evaluationebendieses Protokolls durchführen zu können. Das Evaluationskapitel legt in seinem zweitenTeil den Fokus auf die Ergebnisse der Integration des rückspeisefähigen Elektroautos in dasEMS des Smart Home und stellt klar, welche Vorteile ein gesteuerter Ladevorgang hinsichtlichEigenstromoptimierung und Stromkostenreduktion mit sich bringt.Diese Arbeit schließt mit einer Zusammenfassung sowie einem Ausblick auf weitere sinnvolleForschungstätigkeiten in diesem thematischen Umfeld.19Die Begrie Elektromobilität und E-Mobilität werden fortan synonym verwendet.17KAPITEL 2STANDARDISIERUNGSINITIATIVEN FÜR INTEROPERABLEE-MOBILITÄTSLADELÖSUNGENDer Schlüssel zum Erfolg für eine neu in der Gesellschaft zu etablierende Technologie isteine gemeinsame Einigung der Interessensvertreter auf gewisse Standards, welche einerseitsInteroperabilität zwischen verschiedenen Implementierungen dieser neuen Technologie undandererseits Investitionssicherheit für die betreenden Akteure sichert. Im Bereich der Elek-tromobilität gibt es diverse technologische Schnittstellen auf Hardware- wie auf Softwareseite,auf die sich gleich mehrere unterschiedliche Industriezweige einigen müssen, die bis dato nochnie miteinander kooperieren mussten. So sind sowohl die Automobilhersteller als auch dieLadeinfrastrukturbetreiber, deren Zulieferer und die Vertreter der Energiewirtschaft daraninteressiert, einerseits dem Endkunden ein reibungsloses Elektromobilitätserlebnis und somiteine profitable Marktakzeptanz zu schaen und andererseits etwaige Transaktionskostenzwischen den Schnittstellen möglichst gering zu halten.Dieses Kapitel wird daher die hard- und softwareseitigen Schnittstellen und Komponenten,welche im Bereich der E-Mobilität durch Standardisierungsinitiativen bereits genormt werdenund grundlegend für das weitere Verständnis dieser Arbeit sind, näher erläutern.2.1 Standardisierung der HardwareschnittstellenSpricht man im Rahmen der Elektromobilität von einem Ladestecksystem, speziell im Bereichder elektrifizierten Pkws, so beinhaltet dieses System die vier Komponenten• fahrzeugseitige Buchse, auch Fahrzeugkupplung genannt (vehicle inlet),• fahrzeugseitiger Stecker (connector),• ladestationsseitiger Stecker (plug) und• ladestationsseitige Steckdose (socket outlet),welche auch in Abbildung 2.1 zusammenhängend dargestellt werden. Im Falle des Wechsel-stromladens (im Bild mit Alternating Current (AC) bezeichnet) ist das Ladekabel, welches diebeiden Steckerenden verbindet, transportabel, wohingegen beim Gleichstromladen (im Bild19Kapitel 2 Standardisierungsinitiativen für interoperable E-MobilitätsladelösungenAbbildung 2.1: Gesamtbild eines Ladestecksystems bestehend aus Buchsen, Steckern undSteckdose. Hier: das Combined Charging System (CCS) für das AC- undDC-Laden (Quelle: Phoenix Contact)mit Direct Current (DC) beschrieben) der ladestationsseitige Stecker fest mit der Ladestationverbunden ist. Der ozielle in sämtlichen Standardisierungsdokumenten die Elektromobilitätbetreend verwendete Terminus für das Elektroauto ist Electric Vehicle (EV), während dieLadestation als Electric Vehicle Supply Equipment (EVSE) bezeichnet wird.Es gibt grundsätzlich zwei Arten, die Batterie in einem Elektrofahrzeug wieder aufzuladen,nämlich das konduktive (kabelgebundene) und das induktive (kabellose) Laden. Diese Arbeitbeschäftigt sich mit dem konduktiven Laden, da dieser Anwendungsfall den kurz- bis mittelfris-tig vorherrschenden Weg darstellen wird, ein Elektrofahrzeug zu laden, in Anbetracht der meistnoch in Pilotstadien befindlichen kabellosen Ladesysteme. Es ist jedoch davon auszugehen,dass sich die induktiven Ladesysteme durchsetzen und kabelgebundene Systeme vom Marktverdrängen werden, allein aufgrund des höheren Benutzerkomforts (kein Ladekabel, welchesbspw. im Winter durch Schnee und Dreck schmutzige Hände verursacht). Abschnitte 2.1.1 und2.1.2 geben einen Überblick über die hardwareseitigen Standardisierungsbemühungen, welcheeine physikalische Interoperabilität zwischen Ladestation und Elektrofahrzeug gewährleistensollen.202.1 Standardisierung der Hardwareschnittstellen2.1.1 IEC 62196Die Europäische Kommission beauftragte im Juni 2010 die drei oziellen europäischenStandardisierungsorganisationen (das Europäische Komitee für Normung (CEN), das Euro-päische Komitee für elektrotechnische Normung (CENELEC) und das Europäische Institutfür Telekommunikationsnormen (ETSI)), auf Basis einer Standardisierungsinitiative derInternational Electrotechnical Commission (IEC) einen europäischen Standard für ein E-Mobilitäts-Ladestecksystem zu entwerfen. Eine Reihe von Vorschlägen das Aussehen unddie technische Spezifikation der Steckertypen betreend wurden daraufhin von diversen In-dustriegremien aus zahlreichen Ländern eingereicht, was letzten Endes in der IEC 62196Standardisierungsserie [1] mündete, betitelt mit „Stecker, Steckdosen, Fahrzeugkupplungenund Fahrzeugstecker – Konduktives Laden von Elektrofahrzeugen“.Teil 1 (IEC 62196-1) der mittlerweile dreiteiligen Norm geht auf generelle Anforderungenan das Ladestecksystem gemäß den vier Lademodi ein, wie sie in der Norm IEC 61851-1 [37] für AC- und DC-Laden definiert und in Abschnitt 2.1.2 näher beschrieben werden.Diese Anforderungen betreen Berührungsschutz, Festlegungen bzgl. Nennspannung undStromstärke sowie die Auslegung der Kontaktstifte für Signalisierungs- und Steuerungszwecke.Teil zwei definiert die Dimensionskompatibilität zwischen den diversen AC-Steckervarianten,wohingegen Teil drei (noch in der Entwurfsphase) sich mit dem Ladestecksystem für dasDC-Laden sowie die kombinierte AC/DC-Ladesschnittstelle beschäftigt.Im Rahmen der IEC 62196-2 und -3 Normungsserie werden drei Typen von Ladestecksys-temen unterschieden, welche in unterschiedlichen Teilen der Welt vorwiegend zum Einsatzkommen. Typ 1 ist dabei die maßgeblich in den USA und in Japan eingesetzte Stecksystem-variante, Teil 2 hingegen hat sich größtenteils in Europa durchgesetzt und Teil 3 kommt inChina zum Einsatz. Abbildung 2.2 illustriert die verschiedenen Gesichter aller Ladesteckerund -buchsen in einer Matrix.Am 24. Januar 2013 wurde auf Entscheidung der Europäischen Kommission ein Richtlinien-vorschlag veröentlicht [25], welcher das deutsche Typ 21 sowie das CCS-LadestecksystemCombo2, auf welches in diesem Abschnitt noch eingegangen wird, als europäischen Standarddefiniert. Dieser Vorschlag wurde am 9.4.2014 vom Europäischen Parlament beschlossen [27]und beendete somit die Diskussion und Unsicherheit bei Herstellern und Kunden bzgl. eineseinheitlich zu nutzenden Systems – zumindest in Europa.Das Typ 2 Ladestecksystem unterstützt sowohl das einphasige als auch das dreiphasige2Wechselstromladen, wobei letzteres höhere Ladeleistungen und somit auch kürzere Ladezeitenerlaubt. Amerikanische wie auch japanische Hausinstallationen erlauben nur das einphasigeAC-Laden aufgrund ihres 100-120/240 V Netzanschlusses, weshalb das Typ 1 Ladestecksystemin diesen Ländern auch bevorzugt wird. In Europa und China wurde hingegen ein einphasiger230 V sowie ein dreiphasiger 400 V Netzanschluss realisiert. Nichtsdestotrotz haben sichAutomobilhersteller weltweit darauf geeinigt, dass jedes in Europa verkaufte Elektrofahrzeugspätestens zum Jahre 2017 mit der Typ 2 Ladesteckvorrichtung ausgestattet sein wird [2] [70].Bis dahin kann die Kompatibilität zwischen Ladestationen und Elektrofahrzeugen, welche mitunterschiedlichen auf IEC 62196 basierenden Ladesteckvorrichtungen ausgerüstet sind, mitHilfe von Adaptern gesichert werden.1Der deutsche Vorschlag für das Typ 2 Ladestecksystem wird informell auch als „Mennekes-Stecker“ bezeichnet,benannt nach der Firma Mennekes, welche diesen Ladestecker bereits im Jahre 2009 einführte.2Das Dreiphasenwechselstromsystem, wie es bspw. in Deutschland Anwendung findet, wird für Transport undVerteilung von elektrischer Energie in Stromnetzen eingesetzt. Es besteht aus drei Wechselströmen gleicherFrequenz, welche zueinander in ihren Phasenwinkeln um 120 Grad verschoben sind.21Kapitel 2 Standardisierungsinitiativen für interoperable E-MobilitätsladelösungenAbbildung 2.2: Überblick über den weltweiten Einsatz der normierten Ladestecksysteme fürElektromobilität. GB steht für Guobiao, chinesisch für “Nationaler Standard”(Quelle: Phoenix Contact)Im Oktober 2011 präsentierten die acht Automobilhersteller Audi, BMW, Chrysler, Daimler,Ford, GM, Porsche und VW auf dem 15. VDI-Kongress ihren Vorschlag für eine einheitlicheLadeschnittstelle (fahrzeugseitige Ladebuchse wie auch Ladestecker), welche die AC- und dieDC-Lademöglichkeiten vereint: das Combined Charging System (CCS). Dieser Vorschlag flossin die internationale Standardisierung ein und wird seither unter der IEC 62196-3 Spezifi-kation genormt, welche sich bisher noch im Entwicklungsstadium befindet. Das Design derfahrzeugseitigen Ladebuchse ist Abbildung 2.3 zu entnehmen, das des Ladesteckers Abbildung2.4. Die Buchse kombiniert den bereits existierenden Typ 1 oder Typ 2 AC-Teil im oberenAbschnitt mit zwei großen zusätzlichen Pins, welche für die hohen DC-Ladeströme genutztwerden, im unteren Abschnitt. Beim Gleichstromladen wie auch beim Wechselstromladen wirddie Kommunikation über die entsprechenden AC-Pins des oberen Abschnitts abgewickelt. Jenach Einsatzgebiet des CCS-Systems (USA, Europa, Japan, China, etc.) unterscheidet sichdas Design des oberen Abschnitts gemäß der Typ 1 bzw. Typ 2 Spezifikation, welche auch als„Combo1“ (USA, Japan) bzw. „Combo2“ (Europa, China) Systeme bezeichnet werden. Dieweltweit agierenden Automobilhersteller haben sich bei der Gestaltung der CCS-Schnittstelleauf ein Maß geeinigt, welches Rückwirkungen auf die Karosseriebauten verhindert und somitmit den Maßen des bewährten Tankdeckels übereinstimmt [66].Abbildung 2.5 zeigt zum Vergleich einen Typ 2 Ladestecker für ein- und dreiphasigesAC-Laden, anhand dessen die Belegung der 7 Pins, von denen 3 Pins auch im CCS-Stecker fürdie Kommunikation genutzt werden, erläutert werden soll. Die drei stromführenden Phasensind in dieser Abbildung mit L1, L2 und L3 beschriftet, der mit PP bezeichnete ProximityPilot-Pin (auch „Plug Present“) dient der Überprüfung, ob ein Ladekabel eingesteckt wurde, N222.1 Standardisierung der HardwareschnittstellenAbbildung 2.3: Fahrzeugseitige Ladebuch-se nach der CombinedCharging System Spezifi-kation (Quelle: PhoenixContact)Abbildung 2.4: DC-Ladestecker nach derCombined Charging Sys-tem Spezifikation (Quelle:Phoenix Contact)Abbildung 2.5: Ein Typ 2 Ladestecker für ein- und dreiphasiges AC-Laden (Quelle: Mennekes)23Kapitel 2 Standardisierungsinitiativen für interoperable E-Mobilitätsladelösungenist der Neutralleiter und CP (Control Pilot) der für die Kommunikation zwischen Elektroautound Ladestation genutzte Pin, auf welchen in Abschnitt 2.1.2 noch näher eingegangen wird.In der Mitte befindet sich der Schutzleiter, auch „Protective Earth“ (PE) genannt.Das Combined Charging System ermöglicht im Falle des AC-Ladens Ladeleistungen von biszu 22 kW (bei 480 V und 32 A) und im Falle des DC-Ladens Leistungen von bis zu ca. 170 kW(bei 850 V und 200 A) [56] und ist somit für Anwendungsfälle vom langsamen einphasigenund schnelleren dreiphasigen AC-Laden zu Hause bis hin zum sehr schnellen DC-Laden anspeziellen öentlichen Ladestationen geeignet. Schnellladestationen werden daher oft damitbeworben, dass sie einen leeren Akku innerhalb einer halben Stunde auf 80 % volladen können.Die European Automobile Manufacturers Association (ACEA) hat sich darauf geeinigt, dassdas CCS als Standardschnittstelle für AC/DC-Ladestecksysteme in allen neuen Fahrzeugenab dem Jahr 2017 verbaut sein wird [2].Abbildung 2.6, welche aus der deutschen Normungsroadmap 2.0 [51] stammt, die im Herbst2014 neu aufgelegt werden wird, bietet zum Thema Ladestecker eine Übersicht, welchedie Funktionsweise der Typ 1 und Typ 2 Stecker sowie des darauf aufbauenden CCS imZusammenhang mit den entsprechenden Komponenten im Elektrofahrzeug erläutert. In diesemQuelle: BMW & Initiative Ladeschnittstelle CP PP PE Ladestecker Elektrofahrzeug Steuereinheit mit Pilot-auswertung und PLC AC-Ladegerät (1- oder 3-phasig) HV- Bordnetz mit Batterie CP PP N L1/ L L2 L3 PE DC - DC + DC-Schütz Typ 1 Typ 2 Combo 1 Combo 2 AC 1ph AC 3ph DC low DC high - - CP PP PE + - + - PP CP PE CP PP PE N L1 PP CP PE PP CP PE L N L1 N L3 L2 PP CP PE + + Combo 2 Inlet Typ 1 Inlet Typ 2 Inlet Combo 1 Inlet DC-Schütz Abbildung 15: Combined Charging System zum AC- und DC-Laden mit den Steckvorrichtungen Typ 1 / Typ 2, bzw. Combo 1 / Combo 2Zahlreiche Funktions- und Sicherheitsmaßnahmen gewährleisten die für den Anwender einfache Nutzung ohne darüber nachdenken zu müssen, ob eine Ladestation AC- oder DC-Laden anbietet und wo er denn anstecken soll. So wird zum einen über die Kommunikationsinhalte, die in der ISO / IEC 15118 standardisiert werden, der vollautomatische Ablauf des Ladevorgangs realisiert. Darüber hinaus gibt es Maßnahmen zur sicheren wechselnden Verwendung von Kontakten für AC- und DC-Ladens sowie zum Schutz vor Gefährdung durch Lichtbögen bei unautorisiertem Abziehen des Steckers während des Ladens.Oben aufgeführte Punkte (insbesondere der gemeinsame Ladeanschluss für AC- und DC-Laden) sind als Vorteile gegenüber dem sich derzeit auch schon im europäischen Markt befindlichen CHAdeMO-Ladesystems aus Japan zu betrachten, welches einen separaten DC-Ladestecker benötigt und ohne Schutzleiter (PE) konzipiert ist. 4.3.3 Sicherheit Elektrische Sicherheit Grundlegende Sicherheitsanforderungen für das Elektrofahrzeug, seine aufladbaren Energie-speicher, für die elektrische Betriebssicherheit und für den Schutz von Personen sind in der ISO 6469 beschrieben. Die Leitungen für Straßenfahrzeuge sind in der ISO 6722 genormt, welche zwei Spannungsklassen festlegt (60 V und 600 V). Batterie- und DC-Spannungspegel oberhalb 400/600 V Seitens der Automobil- und Zulieferindustrie gibt es erste Entwicklungen für Anwendungen mit System- oder Batteriespannungen oberhalb 600 V. Hier sind frühzeitig die entsprechenden Sicherheitsnormen zu erstellen oder anzupassen. Crash Beim Crash müssen die Rettungsleitfäden mit betrachtet werden, damit die relevanten Informationen den Rettungskräften zur Verfügung stehen. Aufgrund der steigenden Komplexität der im Rettungsfall zu beachtenden Anforderungen ist ein einheitlicher Aufbau der Rettungsleitfäden erforderlich. Bei ISO TC 22 ist ein Normungsantrag “Electrically propelled road vehicles – Safety specifications – Post crash safety requirements” gestellt worden zu Anforderungen an das Fahrzeug nach einem Unfall. Funktionale Sicherheit Die Normung für die Funktionale Sicherheit im Bereich Automotive ist durch die ISO 26262 abgedeckt (HW- und SW-System).36Die deutsche Normungs-Roadmap Elektromobilität – Version 2Januar 2012Abbildung 2.6: Combined Charging System zum AC- und DC-Laden mit den Steckvorrich-tungen Typ 1, Typ 2, Combo 1 und Combo 2 [51]Bild wird die unterschiedliche Nutzungsweise des Typ 1 und Typ 2 Steckers hinsichtlich ein-und dreiphasigem Wechselstromladens sowie langsamem (DC low) und schnellem (DC-high)Gleichstromladens illustriert. Mit den gelben „+“- und „-“-Kreisen wird deutlich gemacht,dass mit entspr chender Pin-Belegung der Typ 1 und Typ 2 Steckervorrichtung (bei Typ2 werden bspw. Phase 2 und 3 als dedizierte DC-Pi s genutzt) auch langsames DC-Ladenermöglicht werden kann. Beim Combo 1 und 2 System hingegen werden immer CP, PP undPE Pin des oberen AC-Teils für die Steuerung des Ladevorgangs genutzt.Neben dem europäischen Schnellladesystem CCS konkurriert noch das aus Japan stammen-242.1 Standardisierung der Hardwareschnittstellende CHAdeMO-System um die Marktvorherrschaft, wobei zur Zeit noch nicht abzusehen ist,ob eines der beiden Systeme in Zukunft das andere verdrängen wird, oder eine Koexistenzbestehen bleibt. Zumindest in Europa, speziell Deutschland, gibt es große Bestrebungen, dasCombined Charging System als Standard zu etablieren, was auch mit dem Verbundprojekt„SLAM – Schnellladenetz für Achsen und Metropolen“ untermauert wird [16]. Im Rahmendieses u. a. von den Autoherstellern BMW, Daimler, Porsche und VW, vom EnergieversorgerEnBW sowie vom BMWi unterstützten Projekts sollen bis zum Jahr 2017 400 Schnellladesta-tionen im Abstand von 50 bis 70 km in Deutschland aufgebaut werden, welche mit dem Typ 2Ladestecksystem sowie dem CCS ausgestattet werden. Das Projekt wird auf wissenschaftlicherSeite vom Institut für Arbeitswissenschaft und Technologiemanagement (IAT) der UniversitätStuttgart sowie von der RWTH Aachen begleitet.Der IEC 62196 Standard basiert wiederum auf der IEC 61851 [37] Norm. In dieseminternationalen Standard wird ein analoges Protokoll auf niederer Ebene spezifiziert, überdas die grundlegenden Signalisierungsmechanismen ablaufen, welche den Ladevorgang einesElektrofahrzeugs an einer Ladestation überhaupt erst ermöglichen.2.1.2 IEC 61851Elektrofahrzeuge können grundsätzlich in vier verschiedenen Lademodi geladen werden, welchein der IEC 61851 Norm spezifiziert sind. Diese Modi unterscheiden sich hinsichtlich erlaubterLadeströme, der eingesetzten Kommunikationsmechanismen mit dem Fahrzeug sowie deneinzuhaltenden Sicherheitsrichtlinien.• Mode 1:Das Elektrofahrzeug ist mit dem Wechselstromnetz verbunden, welches mit 16 A ab-gesichert ist und eine Spannung von bis zu 250 V (einphasig) bzw. 480 V (dreiphasig)liefert. Diese üblicherweise in einem Haushalt vorzufindenden Steckdosentypen werdenauch mit SCHUKO (für Schutzkontakt) oder CEE bezeichnet.• Mode 2:Das Elektrofahrzeug ist mit dem Wechselstromnetz verbunden, welches mit 32 A abge-sichert ist und eine Spannung von bis zu 250 V (einphasig) bzw. (480 V) dreiphasig liefert(SCHUKO oder CEE). Hierbei ist im Ladekabel eine sogenannte „In-cable control box“(ICCB) als Überstromschutz und zur Erkennung eines Fehlerstroms (FI-Schutzschalter)sowie zur Ladestromsteuerung integriert. Ein solches Ladekabel mit integrierter ICCBist in Abbildung 2.7 dargestellt. Der Ladestromrichter, welcher den Wechselstrom ausdem Stromnetz in Gleichstrom für die Batterie richtet, befindet sich im Fahrzeug.• Mode 3:Das Elektrofahrzeug ist mit dem Stromnetz über eine dedizierte Ladestation verbunden,welche zur Kommunikation mit einem Modul zur Pulsweitenmodulation (PWM) ausge-stattet ist und darüber hinaus einen FI-Schutzschalter, Ladeschütze (Relais) und einespezielle Ladebuchse aufweist. Der Ladestromrichter befindet sich im Fahrzeug.• Mode 4:Ähnlich zu Mode 3 mit der Ausnahme, dass der Ladestromrichter sich nicht im Fahrzeug,sondern in der Ladestation befindet, aufgrund dessen der direkt gelieferte Gleichstromhöhere Ladeleistungen und eine kürzere Ladedauer erlaubt.25Kapitel 2 Standardisierungsinitiativen für interoperable E-MobilitätsladelösungenAbbildung 2.7: Typ 2 Ladekabel für ein- und dreiphasiges AC-Laden nach Mode 2 mitintegrierter ICCB (Quelle: Mennekes)Wie dieser Auflistung zu entnehmen ist, steigen die Sicherheitsanforderungen von Mode 1 bisMode 3, weshalb die ACEA Mode 3 als zwingend anzuwendenden Lademodus für öentlicheLadestationen vorsieht. Mode 2 soll bei Heiminstallationen zum Einsatz kommen, sofern keineMode 3 Ladestation zur Verfügung steht.Bevor der eigentliche Ladevorgang beginnen kann, findet eine vorausgehende analogeKommunikation zwischen dem Elektrofahrzeug und der Ladestation in den Modi 2, 3 und4 statt. Der bereits erwähnte Control Pilot (CP) Leiter, welcher im IEC 62196 Ladekabelintegriert ist, erlaubt die Unterscheidung zwischen diversen Verbindungszuständen durch dieMessung des elektrischen Widerstands [V] im Kabel.• Zustand A (+12 V):Elektrofahrzeug ist nicht mit der Ladestation verbunden• Zustand B (+9 V):Elektrofahrzeug ist mit der Ladestation verbunden, aber noch nicht ladebereit• Zustand C (+6 V):Elektrofahrzeug ist mit der Ladestation verbunden und ladebereit (keine Ventilation)• Zustand D (+3 V):Elektrofahrzeug ist mit der Ladestation verbunden und ladebereit (Ventilation nötig)• Zustand E (0 V):Netzproblem oder Netz nicht verfügbar, Pilotleiter-Kurzschluss gegen Erde, . . .• Zustand F (-12 V):EVSE nicht verfügbar262.1 Standardisierung der HardwareschnittstellenDarüber hinaus definiert die IEC 61851 einen Mechanismus, welcher die ladestationsseitigmaximal erlaubten Ladeströme mittels eines analogen pulsweitenmodulierten Signals aufden CP-Leiter aufmoduliert und dafür sorgt, dass Ladeströme stets nur bei einem stehendenFahrzeug fließen können. Bei einer Pulsweitenmodulation wechselt der elektrische Strom ständigzwischen zwei Werten, wobei bei einer konstanten Frequenz der Tastgrad des Stromimpulses(das Tastverhältnis oder auch Pulspausenverhältnis) moduliert wird. Abbildung 2.8 soll diesenMechanismus anhand eines Beispiels erläutern.t"V"+12"+9"+6")12"Ladeschütz"EV"(S2)"offen"S2"geschlossen"S2"offen"aufgenommener"Wechselstrom"durch"EV"Wechselstrom"Versorgungsspannung"an"der"Steckdose"(EVSE)"+9"V"+6"V"+9"V"1234 56789Abbildung 2.8: Beispielhafter Ladezyklus illustriert anhand eines PWM-Signals (angelehntan [37], Anhang A)Solange kein E-Fahrzeug über ein Ladekabel mit einer Ladestation (EVSE) verbunden ist,wird die volle Generatorspannung von 12 V zwischen Pilotleiter (CP-Pin) und Erde gemessen.Wird nun ein solches Fahrzeug mit der EVSE verbunden 1, so wird dies durch ein gemessenes9 V Signal festgestellt. Dies entspricht nun dem Zustand B. Infolgedessen ist die Ladestationnun zur Stromversorgung bereit und zeigt dem E-Fahrzeug den verfügbaren Strom durchdas Tastverhältnis (PWM-Signal) an, wobei die Spannung anfängt, zwischen +9 V und -12 V zu wechseln. Sobald das PWM-Signal vom Ladesteuergerät im Fahrzeug empfangenwurde, wird die Nennleistung entsprechend angepasst und der Ladestecker fahrzeugseitigverriegelt. Daraufhin wird das Fahrzeug seinen Ladeschütz (mit S2 bezeichnet) schließen 2,was mit einem Zustandsübergang von B nach C einhergeht und somit die Ladebereitschaft desFahrzeugs signalisiert. Durch das Schließen des S2 wird die Spannung auf +6 V heruntergezogen.27Kapitel 2 Standardisierungsinitiativen für interoperable E-MobilitätsladelösungenNach einer kurzen Zeitspanne wird infolgedessen die Ladestation ihrerseits den Ladesteckerverriegeln und den Stromkreis schließen 3, indem sie den Hauptschütz schließt. Wenn ZustandD (+3 V) festgestellt wird, so werden die Schütze ladestationsseitig nur geschlossen, soferndie Belüftungsanforderung erfüllt ist. Kurz darauf beginnt auch schon die Energieaufnahmedurch das Fahrzeug 4. Zwischenzeitlich kann es zu einer Forderung nach Leistungsreduzierungkommen, wodurch das von der EVSE angezeigte Tastverhältnis geändert wird 5.Während des Ladevorgangs wird die Erdung (Protective Earth – PE) vom Control Pilot(Pilotleiter) konstant überwacht. Möchte das Fahrzeug nun seinen Ladevorgang beenden, sowird es die Energieaufnahme stoppen 6 und gleich darauf seinen S2 wieder önen 7, womitdas Spannungslevel wieder auf +9 V gehoben und ein Zustandsübergang von C (bzw. D) aufB erfolgen wird. Sobald nun die Ladestation ebenfalls Zustand B feststellt, wird sie ihrerseitsihren Hauptschalter önen 8, was dazu führt, dass keine Spannung mehr an der Steckdoseanliegt. Wird letzten Endes das Ladekabel von der Ladestation entfernt, so wird das gemesseneSpannungslevel an der Station wieder auf 12 V gehoben.Laut der IEC 61851 muss ein Tastverhältnis von 5 % verwendet werden, um den Pilotleiterfür die digitale Kommunikation und zur Überwachung des externen Ladegerätes im E-Fahrzeugverwenden zu können. Damit ist diese Norm ein analoges, sicherheitstechnisches Protokoll aufniederer Ebene und das Laden über Mode 3 die bisher gängigste Methode, die Batterie einesElektrofahrzeugs wieder aufzuladen.Der Vollständigkeit halber soll noch erwähnt werden, dass der Teil der IEC 61851, welcherfür den kabelgebundenen Ladeprozess spezifiziert wurde, sich in IEC 61851-1, IEC 61851-21und IEC 61851-22 aufgliedern lässt. Für das weitere Verständnis dieser Arbeit sind weitereDetails zu diesen spezifischen Dokumenten jedoch nicht relevant und finden daher keine nähereBetrachtung.Dieser Abschnitt sollte zeigen, dass eine grundlegende und rudimentäre Laststeuerung überein standardisiertes Protokoll bereits möglich ist. Allerdings ist es nicht möglich, über die IEC61851 energierelevante Mehrwertinformationen zu übertragen, welche eine genauere Planbarkeitder Lastverschiebung erlauben. Mit Hilfe von Informationen bzgl. der Gesamtenergiemenge,die das Elektrofahrzeug für eine vollgeladene Batterie noch benötigt oder gar des vom Fahrergeplanten Abfahrtszeitpunkts könnte die Flexibilität des Ladebedarfs ausgeschöpft werden, umein signifikantes Lastverschiebepotential zu heben und eine vorteilhafte Laststeuerung erst zuermöglichen.Es bedarf also eines oder mehrerer leistungsfähiger Kommunikationsprotokolle zwischenElektroauto und Ladestation samt dahinter liegenden Systemen, um diese und weitere ener-gierelevanten Mehrwertinformationen zu erheben, übertragen und zu verarbeiten, und die inAbschnitt 1.1 vorgestellten Szenarien der Integration eines Elektrofahrzeugs in das Energienetzverwirklichen zu können. Die weltweite Standardisierung der Kommunikationsschnittstellezwischen Elektrofahrzeug und Ladestation ist das Ziel der in der Entwicklung befindlichenNorm ISO/IEC 15118, auf welche im folgenden Abschnitt 2.2.1 näher eingegangen wird. DieWeiterverarbeitung relevanter Informationen zwischen einer Ladestation und einem Backend,welches die Lücke einer durchgängigen Informationsübertragung und -verarbeitung bis hin zumEnergievertrieb bzw. Neztbetreiber schließt, findet in Abschnitt 2.2.2 eine nähere Betrachtung.282.2 Standardisierung der Kommunikationsprotokolle2.2 Standardisierung der KommunikationsprotokolleNachdem im Abschnitt 2.1 die zu standardisierenden hardwareseitigen Schnittstellen füreinen interoperabel funktionierenden Ladevorgang eines Elektrofahrzeugs vorgestellt wurden,konzentriert sich dieser Abschnitt auf die Kommunikationsprotokolle, welche die Erhebung,Übermittlung und Verarbeitung energierelevanter Mehrwertinformationen erlauben. Zielsolcher Protokolle muss es sein, einen gesteuerten Ladevorgang zu ermöglichen, welcher sowohlden gewünschten Ladezustand des E-Fahrzeugs (auch als State of Charge (SOC) bezeichnet)zum Ende des Ladevorgangs gewährleistet, als auch mittels der steuernden Instanz3 eineminimale Abweichung von einem gewünschten Lastprofil realisiert.2.2.1 ISO/IEC 15118Im Jahre 2009 schlossen sich die Internationale Organisation für Normung (InternationalOrganization for Standardization – ISO) und die Internationale Elektrotechnische Kommission(International Electrotechnical Commission – IEC) zusammen und starteten eine Standardi-sierungsinitiative, welche basierend auf einem gemeinsamen internationalen Verständnis dieSpezifikation eines digitalen IP-basierten Kommunikationsprotokolls zwischen Elektrofahrzeug(EV) und Ladestation (EVSE) zum Ziel hatte. Dieses Protokoll soll einen benutzerfreundlichen„Plug-and-Charge“-Mechanismus für die Authentifizierung, Autorisierung, Abrechnung undflexible Lastkontrolle ermöglichen. Jene Initiative führte zum aktuell noch in der Entwick-lung befindlichen Standard ISO/IEC 15118, betitelt mit „Road vehicles - Vehicle to gridcommunication interface“. Es sei an dieser Stelle gleich erwähnt, dass der Ausdruck „Vehicleto grid“ dieses Titels etwas irreführend ist, da es sich tatsächlich nur um eine direkte Kom-munikation zwischen Elektrofahrzeug und Ladestation, nicht einem hinter der Ladestationkommunikationstechnisch angebundenen Dritten handelt.Dieses Kommunikationsprotokoll baut auf der Signalisierung entsprechend der Prozedur nachIEC 61851 auf und ergänzt somit das analoge sicherheitstechnische Protokoll um ein digitalesProtokoll auf höherer Kommunikationsebene. Die bidirektionale Kommunikation zwischen EVund EVSE beginnt, sobald ein PWM-Signal von 5% auf dem CP-Pin anliegt. Man hat sich unteranderem deswegen auf dieses Tastverhältnis geeinigt, da der entsprechende Ladestrom zu geringwäre, um ezient Energie zu übertragen. Die Aushandlung der Leistungsparameter erfolgtsomit nicht mehr auf analoger Ebene, sondern mittels der im ISO/IEC 15118 spezifiziertenParameter, wie gleich erläutert werden wird.Dieser Standard untergliedert sich wiederum in acht verschiedene Teildokumente. EineÜbersicht über die Dokumentenstruktur der ISO/IEC 15118 samt aktuellem Dokumentensta-dium und geplantem Übergang zum nächsten Stadium (jeweils incl. Veröentlichungsmonat)sind Tabelle 2.1 zu entnehmen. Während eines jeden Standardisierungsprozesses unter derFührung der ISO durchläuft ein zu standardisierendes Dokument verschiedene Stadien: Zuerstwird ein Vorschlag für einen Standard (New Working Item Proposal – NWIP) unterbreitet,danach ein Komitee-Entwurf (Committee Draft – CD) entwickelt, dem ein Entwurf für eineninternationalen Standard (Draft for International Standard – DIS) folgt, bis schließlich derfinale Entwurf (Final Draft for International Standard – FDIS), an welchem letztlich nur nocheditorielle Änderungen vorgenommen werden dürfen, feststeht. Zum Schluss einigt man sichauf den internationalen Standard (International Standard – IS). Mehr Informationen zu diesem3Als steuernde Instanz kommen, je nach Art des zu übermittelnden Steuersignals, mehrere Rollen imsich wandelnden Energiemarkt in Frage, wie bspw. ein Verteilnetzbetreiber oder ein lokal angesiedelterAggregator, welcher den Ladevorgang mehrerer Elektrofahrzeuge steuert.29Kapitel 2 Standardisierungsinitiativen für interoperable E-MobilitätsladelösungenTabelle 2.1: Dokumentenstruktur des ISO/IEC 15118 Standards und entsprechende (geplante)StadienKonduktives LadenTeil Titel Aktuelles Stadi-umPlanung1 General information and use case definition IS (04/13) –2 Network and application protocol requirements IS (04/14) –3 Physical layer and data link layer requirements FDIS (04/14) IS (11/14)4 Network and application protocol conformance test CD (03/14) DIS (10/14)5 Physical layer and data link layer conformance test NWIP (06/12) CD (07/14)Induktives LadenTeil Titel Aktuelles Stadi-umPlanung6 General information and use case definition for wi-reless communicationCD (04/14) DIS (11/14)7 Network and application protocol requirements forwireless communicationNWIP (01/14) CD (07/14)8 Physical layer and data link layer requirements forwireless communicationNWIP (12/13) CD (11/14)Prozess können [19] entnommen werden. Jede Stufe darf entsprechend dem ISO-Reglementnur eine bestimmte Zeitspanne einnehmen, bis die nächste Stufe erreicht sein muss, ansonstenwird der Standardisierungsprozess gestoppt.Die Spezifikationen bezüglich des induktiven Ladens bauen auf den Vorarbeiten zumkonduktiven Laden auf und erweitern diese um spezifische Anwendungsfälle und technischeAnforderungen, die für die drahtlose Energie- und Informationsübertragung vonnöten sind.Diese Arbeit bezieht sich auf das konduktive Laden und hierbei vor allem auf Teil 2 diesesStandards, da dieses Dokument die relevanten Nachrichten, Datenformate und Parameterdefiniert, welche zwischen Elektroauto und Ladestation auszutauschen sind und die energierele-vanten Mehrwertinformationen enthalten, deren Verarbeitung ein sinnvolles Lastmanagementüberhaupt erst durchführen lässt. In Abbildung 2.9 werden die Teile 1 bis 3 der ISO/IEC 15118Norm sowie eine Zuordnung der in Teil 2 eingesetzten Protokolle zu den ISO/OSI Schichtendargestellt. Hier kommt das Referenzmodell für Netzwerkprotokolle als Schichtenarchitekturzum Einsatz, nach dem eine jeweils obere Schicht die Dienste der unteren Schicht nutzt.ISO/IEC 15118-3 definiert hiernach die Powerline-basierte Verbindung zwischen E-Fahrzeugund Ladestation über die beiden untersten Schichten des 7-Schichten-Modells (Physical Layerund Data Link Layer). Konkret wird die Datenverbindung über den HomePlug Green PHYStandard [31] realisiert, was eine separate physische Verbindung für die Datenübertragungüberflüssig macht. Mithilfe der Powerline-Technologie wird das Ladekabel zur Übertragungder Datensignale genutzt, indem die Signale auf die Ladeverbindung (über den CP-Pin)aufmoduliert werden. Hierfür müssen sowohl das Elektroauto als auch die Ladestation einentsprechendes Green PHY Modul besitzen.Die weitere Kommunikation von der Netzwerkschicht (Schicht 3) bis hin zur Applikations-schicht (Schicht 7) wird über die ISO/IEC 15118-2 spezifiziert. Wie bereits erwähnt, basiert302.2 Standardisierung der Kommunikationsprotokolle,62)',6( ,62±$OOULJKWVUHVHUYHG9HKLFOHWR*ULG&RPPXQLFDWLRQ,62,(&26,/D\HU$SSOLFDWLRQ$SSOLFDWLRQ/D\HU0HVVDJHV6'3,62,(&(;,9*7326,/D\HU3UHVHQWDWLRQ26,/D\HU6HVVLRQ26,/D\HU7UDQVSRUW26,/D\HU1HWZRUN7&38'37/6,3,&036/$$&9*6WDQGDUGL]HG6HUYLFH3ULPLWLYH,QWHUIDFH,62,(&26,/D\HU'DWD/LQN26,/D\HU3K\VLFDO.H\ 26,/D\HUVDQGDSSOLFDEOHUHTXLUHPHQWVGHVFULEHGLQWKLV3DUWRI,62 26,/D\HUVDQGDSSOLFDEOHUHTXLUHPHQWVGHILQHGLQRWKHU3DUWVRI,62)LJXUH²9HKLFOHWR*ULG&RPPXQLFDWLRQGRFXPHQWRYHUYLHZ Abbildung 2.9: Abbildung der Teile 2 und 3 des ISO/IEC 15118 Standards sowie der verwen-deten Protokolle auf die ISO/OSI-Schichten [39]die Kommunikation zwischen EV und EVSE auf dem bewährten Internetprotokoll (IP), überwelches sowohl Datagramm-Pakete mittels UDP ausgetauscht als auch eine zustandsbehafteteKommunikation über TCP oder gar den abgesicherten TLS-Kanal durchgeführt werden kann.Eine Kommunikationssession wird mittels des in Teil 2 definierten Vehicle-to-Grid TransferProtocol (V2GTP) aufgebaut, welches unter anderem eine Session-ID im Header einer je-den Nachricht transportiert und somit Zustandsinformationen einer Session zuordnen undKonsistenzprüfungen durchführen lässt.Da dieser Kommunikationsstandard in eingebetteten Systemen zum Einsatz kommt, in31Kapitel 2 Standardisierungsinitiativen für interoperable E-Mobilitätsladelösungenwelchen stets auf einen geringen Speicherplatzverbrauch sowie eine niedrige Rechenleistunggeachtet werden muss, ist die Größe der auszutauschenden Nachrichten ein wichtiger Faktor.Sämtliche Nachrichten sind in einem XML-Format definiert und müssen entsprechend gegen einXML-Schema validiert werden. Eine Nachricht basierend auf XML ist zwar maschinenlesbar,enthält jedoch auch Metainformationen, welche die Nachricht wiederum aufblähen. Um eineeziente Kodierung und somit Daten-Kompression zu ermöglichen, kommt das vom WorldWide Web Consortium (W3C) spezifizierte Format EXI (Ecient XML Interchange) fürdie binäre Repräsentation von XML-Nachrichten auf der Präsentationsschicht zum Einsatz.Die Verarbeitung der Informationen auf binärer Ebene erhöht die Geschwindigkeit undreduziert sogleich den benötigten Speicherplatz in der jeweiligen Kommunikationseinheit.EXI-Nachrichten können bis zu 100 Mal kleiner sein als deren XML-Äquivalent [73].Die eigentlichen Nachrichten sowie deren Parameter und Datentypen werden in der soge-nannten Applikationsschicht, der obersten der 7 Schichten, definiert und sind Gegenstandweiterer Untersuchung im Verlauf dieser Arbeit. ISO/IEC 15118-1 beschreibt die Anwendungs-fälle, welche über die ISO/IEC 15118 abgedeckt werden und bildet somit den Rahmen für dieTeile ISO/IEC 15118-2 bis ISO/IEC 15118-5.Für eine erfolgreiche Verbreitung dieses Standards mit interoperablen Implementierungen istes wichtig, eine Referenzimplementierung zur Verfügung zu haben, auf welche sich möglichstviele Interessensgruppen einigen und ihre eigene Implementierung dagegen testen können.Hierfür müssen Testfälle generiert werden, welche die korrekte Umsetzung der diversenAnforderungen, welche bspw. in Teil 2 und 3 für den konduktiven Ladefall definiert wurden,für jede Implementierung überprüft. Dies ist Gegenstand der ISO/IEC 15118-4 und -5, wobeiTeil 4 die Testfälle für Teil 2, und Teil 5 die Testfälle für Teil 3 definiert.Das vom BMWi geförderte Projekt eNterop [67], an welchem die Partner Continental,Fraunhofer Gesellschaft, TU Dortmund, BMW, VW, Daimler, RWE und Siemens beteiligt sind,hat das Ziel, gemäß der Teile 4 und 5 automatisierbare Testabläufe in Software und Hardwarezu realisieren. Aufgrund der breit aufgestellten Partner aus den Bereichen Automobilindustrie,Energieversorger und Ladeinfrastrukturhersteller stehen die Chancen für die Akzeptanz einerdurch das Projekt zu etablierenden oenen Referenzplattform, welche die Interoperabilitätzwischen diversen Implementierungen sicherstellen soll, somit gut.Im weiteren Verlauf dieses Kapitels soll nun auf die konkreten Nachrichten eingegangenwerden, auf Basis derer die Kommunikation zwischen Elektrofahrzeug und Ladestation gemäßISO/IEC 15118-2 stattfindet. Die Erläuterung dieser Nachrichten bildet einen wichtigenGrundstein für das Kapitel 4, in welchem deren Verwendung anhand eines realen Szenariosillustriert wird.Der Kommunikationsfluss zwischen EV und EVSE im AllgemeinenDas Kommunikationsprotokoll ist gemäß eines Client/Server-Schemas aufgebaut. Die Kom-munikationseinheit im Elektrofahrzeug – fortan auch mit Electric Vehicle CommunicationController (EVCC) bezeichnet – stellt stets eine Anfrage, auf welche die Kommunikationsein-heit in der Ladestation – Supply Equipment Communication Controller (SECC) – innerhalbeines je Nachricht definierten Timeouts antworten muss. Anfragenachrichten werden im weite-ren Verlauf der Arbeit auch mit „Request“ (kurz Req), Antwortnachrichten mit „Response“(kurz Res) bezeichnet. Wird ein Timeout ausgelöst, so wird die Ladekommunikation abge-brochen und kann erneut vom EV initialisiert werden. Die Nutzung des bereits erwähntenEXI-Formats erlaubt relativ kleine Timeout-Werte, die je nach Nachricht zwischen 2 und 5322.2 Standardisierung der KommunikationsprotokolleSekunden liegen, innerhalb derer eine Antwort auf eine Anfrage eintreen muss. Darüber hin-aus dürfen nie mehr als 60 Sekunden zwischen zwei aufeinander folgenden Anfragen vergehen,sonst wird ebenfalls ein Timeout ausgelöst, außer es handelt sich um die letzte NachrichtSessionStopReq, welche die Kommunikationssession gänzlich beendet.Abbildung 2.10 illustriert alle Request-Response Nachrichtenpaare für den Fall des Wech-selstromladens im „Plug-and-Charge“ (PnC) Identifizierungsmodus. Beim PnC-Szenario mussder Elektromobilist lediglich das Ladekabel in Fahrzeug und Ladestation einstecken undalle Aspekte der Authentifizierung, Autorisierung, Abrechnung sowie Ladesteuerung werdenautomatisiert im Hintergrund abgewickelt, ohne dass eine weitere Interaktion des Nutzersvonnöten ist. Dieser Automatismus basiert auf den Informationen eines Vertrages zwischenKunde und E-Mobilitäts-Anbieter, welcher im EVCC abgespeichert ist. Der alternative Identi-fizierungsmodus gemäß ISO/IEC 15118 wird „External Identification Means“ (EIM) genannt,worunter die externe Authentifizierung und Autorisierung mittels einer RFID-Karte, Direkt-bezahlsystemen oder SMS subsumiert werden. Im Rahmen dieser Arbeit wird der Fokusauf den benutzerfreundlicheren und technologisch interessanteren PnC-Modus gelegt, dessenIdentifizierungsprozess mittels Zertifikaten und kryptographischen Methoden in Kapitel 5erläutert wird. Der Nachrichtenaustausch beim Gleichstromladen variiert nur marginal, dieParameter, welche für eine flexible Lastkontrolle ausgetauscht werden müssen, sind im AC-wie im DC-Fall gleich.Die Sequenz des Nachrichtenaustauschs kann in mehrere Bereiche semantisch unterteiltwerden, welche im Folgenden detailliert Erläuterung finden.Aufbau der IP-basierten KommunikationDie Kommunikation zwischen EVCC und SECC wird mit dem SECC Discovery Protocol(SDP) initiiert. Auf Basis einer UDP-Verbindung bringt somit der EVCC mittels des SDP dieIP-Adresse sowie die Portnummer des SECC in Erfahrung und überprüft, ob beide Seiteneine abgesicherte Kommunikation über TLS (Transport Layer Security) unterstützen oder obfortan über eine TCP-Verbindung (Transmission Control Protocol) kommuniziert werden soll.Sobald die IP-basierte Verbindung über eine Powerline-Kommunikation mittels des CP-Pinsim Typ 2 Ladekabel aufgebaut worden ist, initiiert der EVCC eine Protokoll-Handshake-Sequenz durch das Senden einer supportedAppProtocolReq-Nachricht, um sich mit demSECC auf eine Protokollversion der ISO/IEC 15118 zu einigen. Selbst während des Standardi-sierungsprozesses entstanden verschiedene Protokollstadien (DIS, FDIS und IS).Sobald sich EVCC und SECC auf eine Protokollversion geeinigt haben, wird eine Session-SetupReq-Nachricht gesendet, um eine sogenannte V2G (Vehcile-to-grid) Kommunikationsses-sion aufzubauen. Hierbei wird eine Session-ID ausgelotet, welche alle fortlaufenden Nachrichtenebendieser Session in ihrem Header führen müssen, damit auszutauschende Nachrichten jenerSession zugeordnet werden können und Zustandsinformationen über eine Ladepause hinweggehalten werden können. Abbildung 2.11 illustriert den Zusammenhang zwischen einer Sessionund mehreren Ladevorgängen. Falls das Elektrofahrzeug eine Ladepause einlegen sollte, sowird jegliche Kommunikation über alle Protokollschichten hinweg beendet und das Kommu-nikationsmodul EVCC abgeschaltet, um Energie zu sparen. Wenige Zustandsinformationenmüssen hierbei gespeichert werden und können bei der Initialisierung einer neuen Kommunika-tionssession durch die Session-ID, welche zuvor ausgehandelt wurde, wiederverwendet werden.Eine Ladesession („Charging Session“), die pausiert wurde, kann sich somit über mehrereV2G Kommunikationssessions erstrecken.33Kapitel 2 Standardisierungsinitiativen für interoperable E-MobilitätsladelösungenEV#Controller#gemäß#IEC#6185141EVSE#Controller#gemäß#IEC#6185141EVCC SECCZustand#ALadekabel#verbunden,#Zustand#BZustand#BServiceDiscoveryReq/4ResServiceDetailReq/4ResPaymentServiceSelecJonReq/4ResCerJficateInstallaJonReq/4ResCerJficateUpdateReq/4ResPaymentDetailsReq/4ResAuthorizaJonReq/4ResChargeParameterDiscoveryReq/4ResZustand#C#max.#250#ms#nach#4Req#Zustand#CPowerDeliveryReqChargingStatusReq/4ResMeteringReceiptReq/4ResZustand#B#max.#250#ms#nach#4ReqZustand#BSessionStopReq/4ResAuVau#einer#IP4basierten#Verbindung#via#PLC#supportedAppProtocolReq/4ResSessionSetupReq/4ResKommunikaJons4auVau#AuthenJfikaJon#und#AutorisaJonOpJonal:#MehrwertdiensteOpJonal:#Falls#VertragszerJfikat#nicht#installiertOpJonal:#Falls#VertragszerJfikat#bald#abläu[Zielsetzungen#und#Planung#des#Ladeprofils Lade4schütze#schließen#Ladeschleife#/#NeuplanungOpJonal:#Falls#Signierung#der#Zählerdaten#nöJgTerminierung#des#LadevorgangsPowerDeliveryReqLade4schütze#öffnen#Zustand#A#(+12V)#=#Kein#EV#angeschlossenZustand#B#(+9V)###=#EV#angeschlossen,#nicht#ladebereit#Zustand#C#(+6V)###=#EV#angeschlossen,#ladebereitPowerDeliveryResPowerDeliveryResOpJonal:#Im#Falle#der#vertragsbasierten#BezahlmethodeAbbildung 2.10: Request-Response Nachrichtenpaare im PnC-Modus und Wechselstrom-Ladeszenario342.2 Standardisierung der Kommunikationsprotokolle,62)',6(,62,(& ±$OOULJKWVUHVHUYHG 3DXVLQJ&KDUJLQJ6HVVLRQ9*&RPPXQLFDWLRQ6HVVLRQ6HVVLRQ,G 3OXJ,Q 3OXJ2XWWLPH9*&RPPXQLFDWLRQ6HVVLRQ6HVVLRQ,G 6HVVLRQ6WRS5HT5HVChargingSession=Pause)6HVVLRQ6HWXS5HT6HVVLRQ,' 5HV6HVVLRQ,' 7&37/6FRQQHFWLRQ 7&37/6FRQQHFWLRQ'DWD/LQN 'DWD/LQN6HVVLRQ6HWXS5HT6HVVLRQ,' 5HV6HVVLRQ,' 6HVVLRQ6WRS5HT5HVChargingSession=Terminate))LJXUH²9*&RPPXQLFDWLRQ6HVVLRQ KDQGOLQJ 6HVVLRQ +DQGOLQJ7KH IROORZLQJ DSSOLHV IRU WKH(9&&>9*@ $Q (9&& VKDOO SDXVH D9*&RPPXQLFDWLRQ6HVVLRQZLWK WKHSDUDPHWHU&KDUJLQJ6HVVLRQVHWWR YDOXH Ã3DXVH¶ LQ PHVVDJH 6HVVLRQ6WRS5HT DQGVKDOOVWRS WKH9*&RPPXQLFDWLRQ6HVVLRQWHUPLQDWH WKHWUDQVSRUW OD\HU127( :KHQSDXVLQJD9*&RPPXQLFDWLRQ6HVVLRQWKH(9&&WHUPLQDWHVLWVWUDQVSRUWOD\HUFRQQHFWLRQZKLFKLQGXFHVDVZHOODFKDUJLQJSDXVH1RYDOXHDGGHGVHUYLFHVDUHXVDEOHGXULQJDFKDUJLQJSDXVHHLWKHU>9*@ ,I DQ (9&& UHVXPHV D SUHYLRXVO\ SDXVHG 9* &RPPXQLFDWLRQ 6HVVLRQ WKH IROORZLQJSDUDPHWHU YDOXHV SURYLGHG E\ WKH (9&& LQ WKH SUHYLRXV 9* &RPPXQLFDWLRQ6HVVLRQVKDOOEHSURYLGHG DJDLQ IRU WKHUHVXPHG9*&RPPXQLFDWLRQ 6HVVLRQ 6HVVLRQ,' ZKLFK ZDVFRPPXQLFDWHG LQ WKHKHDGHURI WKH6HVVLRQ6HWXS5HVPHVVDJH LQWKH SUHYLRXV 9* &RPPXQLFDWLRQ 6HVVLRQ IRU DOO UHTXHVW PHVVDJHV VWDUWLQJ IURP6HVVLRQ6HWXS5HT 6HOHFWHG3D\PHQW2SWLRQ 3D\PHQW6HUYLFH6HOHFWLRQ5HT 5HTXHVWHG(QHUJ\7UDQVIHU0RGH &KDUJH3DUDPHWHU'LVFRYHU\5HT>9*@ ,I DQ (9&& ZDQWV WR UHVXPH D SUHYLRXVO\ SDXVHG 9* &RPPXQLFDWLRQ 6HVVLRQ LW VKDOO VHQGWKHSDUDPHWHU 'HSDUWXUH7LPH LQ&KDUJH3DUDPHWHU'LVFRYHU\5HT UHGXFHG E\WKHHODSVHG WLPH >9*@ ,I DQ (9&& ZDQWV WR UHVXPH D SUHYLRXVO\ SDXVHG 9* &RPPXQLFDWLRQ 6HVVLRQ LW VKDOO VHQGWKH SDUDPHWHU ($PRXQW LQ &KDUJH3DUDPHWHU'LVFRYHU\5HT UHGXFHG E\ WKH HQHUJ\ WKDW ZDVDOUHDG\FKDUJHG>9*@ ,I >9*@ DSSOLHV WKH (9&& VKDOO WDNH FDUH WKDW >9*@ LV IXOILOOHG DV ORQJ DVQR&36WDWH$(RU)ZDVGHWHFWHGLQWKH(9&&DVGHILQHG LQ ,(&>9*@ :KHQ VHQGLQJ WKH ILUVW 6HVVLRQ6HWXS5HT PHVVDJH DIWHU FRQQHFWLQJ WKH (9 ZLWK WKH (96(SOXJLQ WKH(9&&VKDOOVHWWKHSDUDPHWHU 6HVVLRQ,' LQWKHPHVVDJHKHDGHU HTXDO WR]HUR >9*@ 7KH KHDGHU RI DQ\PHVVDJH VHQW E\ WKH (9&& GXULQJ DQ DFWLYH9*&RPPXQLFDWLRQ6HVVLRQVKDOO LQFOXGH WKH 6HVVLRQ,' YDOXH UHWXUQHG E\ WKH 6(&& LQ WKH UHVSRQVH WR WKH6HVVLRQ6HWXS5HT LQLWLDWLQJ WKHFXUUHQWO\DFWLYH 9*&RPPXQLFDWLRQ 6HVVLRQ >9*@ $Q (9&& FDQ UHVXPH D FKDUJLQJ VHVVLRQ E\ VHQGLQJ D 6HVVWLRQ6HWXS5HT ZLWK D PHVVDJHKHDGHU LQFOXGLQJ WKH 6HVVLRQ,' YDOXH IURP WKH SUHYLRXVO\ SDXVHG 9* &RPPXQLFDWLRQ6HVVLRQAbbildung 2.11: Session-Handling gemäß der ISO/IEC 15118-2 Spezifikation [39]Authentifizierung und AutorisierungNachdem eine V2G Kommunikationssession aufgebaut worden ist, fordert der EVCC in derServiceDiscoveryReq den SECC dazu auf, alle oerierten Dienste aufzulisten, wobei mittelseines optionalen Filters in der Anfragenachricht spezifisch nur nach den Diensten gefragt werdenkann, welche auch vom Elektrofahrzeug unterstützt werden. Das ISO/IEC 15118-2 Dokumentbeschreibt lediglich die für den Ladeprozess relevanten Dienstekategorien. Hierzu zählen diediversen Ladedienste an sich (ein-/dreiphasiges AC-Laden oder DC-Laden), ein Installations-bzw. Aktualisierungsdienst für Vertragszertifikate sowie ein Dienst für die Nutzung derStandardprotokolle FTP, HTTP oder HTTPS, über welche weitere Mehrwertdienste angebotenwerden können. Zusätzlich erlaubt die Spezifikation, weitere (momentan noch nicht absehbare)Mehrwertdienste zu definieren und bietet somit eine gewisse Zukunftssicherheit und Flexibilität.Nachdem der SECC in der ServiceDiscoveryRes die zur Verfügung stehenden Dienstesowie die möglichen Bezahloptionen Contract (vertragsbasiertes PnC-Ladeszenario) undExternalPayment (EIM) kommuniziert hat, kann das Elektrofahrzeug für alle Dienste, die esin Anspruch nehmen möchte, mittels des ServiceDetailReq/-Res Nachrichtenpaars weitereDetails und Parameter erfragen. Die Entscheidung des EVCC für eine Bezahlmethode sowie diein Anspruch zu nehmenden Dienste werden mittels des PaymentServiceSelectionReq/-ResNachrichtenpaars übermittelt.Die optionalen Nachrichtenpaare CertificateInstallationReq und -Res sowie Certi-ficateUpdateReq und -Res werden im Falle der Bezahloption Contract genutzt, falls keinvalides Vertragszertifikat im EVCC installiert ist, welches die Autorisierung des Ladevorgangserlauben würde. Weitere Informationen bzgl. des Zertifikatsaustauschs und des Fahrstromver-trags können Kapitel 5 entnommen werden.Im Falle der vertragsbasierten Identifikation und Bezahlmethode kann mittels den optio-nalen PaymentDetailsReq und -Res Nachrichten – neben der Zertifikatskette und anderenkryptographischen Parametern – der sogenannte e-Mobility Account Identifier (EMAID)4übertragen werden. Diese ID identifiziert einen Fahrstromvertrag, welcher zwischen demElektromobilisten und seinem E-Mobilitäts-Anbieter geschlossen wurde und hat folgendeStruktur: = 4Die eMAID basiert auf der DIN SPEC 91286 [18].35Kapitel 2 Standardisierungsinitiativen für interoperable E-MobilitätsladelösungenZwei alphanumerische Zeichen für die Länderkennung (z. B. DE für Deutschland) werdengefolgt von drei alphanumerischen Zeichen für die Provider ID, welche bspw. ein Energie-versorgungsunternehmen identifiziert, und neun weiteren für die eMA Instanz, welche alsvom Provider vergebene Vertragsnummer bezeichnet werden kann. Während die Provider IDvon einer zentralen Instanz vergeben werden muss, obliegt die Wahl einer eMA Instance derfreien Entscheidung eines Elektromobilitäts-Anbieters (Providers)5. In Deutschland ist bspw.der Bundesverband der Energie- und Wasserwirtschaft (BDEW) seit 1. März 2014 für dieVergabe der Provider IDs zuständig [9]. Eine optionale Prüfsumme schließt die EMAID ab.Das steht für den optionalen Separator „-“. Ein Beispiel für eine gültige EMAID wäreDE8AA1A2B3C4D59 bzw. DE-8AA-1A2B3C4D5-9.Als letzten Schritt der Authentifizierungs- und Autorisierungsphase werden die obligato-rischen AuthorizationReq und -Res Nachrichten ausgetauscht, in welchen schließlich dieübermittelten Identifizierungsdaten mit kryptographischen Methoden verifiziert werden.Zielsetzungen und Planung des LadeprofilsNachdem das E-Fahrzeug bei der Ladestation für den Ladeprozess autorisiert wurde, beginnenEVCC und SECC, sich gegenseitig ihre jeweiligen Ladeparameter mittels des ChargePara-meterDiscoveryReq/-Res Nachrichtenpaars mitzuteilen.In der ChargeParameterDiscoveryReq-Nachricht werden unter anderem folgende energie-relevanten Mehrwertinformationen übertragen:• Benutzerdefinierter Abfahrtszeitpunkt (DepartureTime)• Benötigte Energiemenge (EAmount)• Maximale Nennspannung, gemessen zwischen einer Phase und Neutralleiter (EVMaxVoltage)• Maximaler Ladestrom pro Phase (EVMaxCurrent)• Minimaler Ladestrom pro Phase (EVMinCurrent)In Abschnitt 4.2 wird erläutert, wie genau diese Parameter in der optimierten Einplanung desE-Fahrzeugs als flexibler Verbraucher und Energiespeicher Verwendung finden und in welcherWeise die ChargeParameterDiscoveryReq-Nachricht um wertvolle Parameter standardkon-form erweitert werden kann. Die benötigte Energiemenge ist als Gesamtenergiemenge zuverstehen, welche neben der nötigen Energie für die Vollladung der Batterie auch die Energieder Nebenverbraucher (Aufwärmen der Batterie bei Unterschreitung einer Mindesttemperaturim Winter, Beheizung oder Klimatisierung des Innenraums) berücksichtigt.Die ChargeParameterDiscoveryRes-Nachricht des SECC wiederum kommuniziert die netz-seitig restriktiven Ladeparamter. Neben technischen Restriktionen wie dem ladestationsseitigmaximal erlaubten Ladestrom pro Phase und der anliegenden Nennspannung wird darüberhinaus ein sehr verschachtelter Parameter namens SASchedules übermittelt. Grundsätzlichbesteht dieser Parameter aus einem obligatorischen PMaxSchedule und einem optionalenSalesTariff. Ersteres beschreibt eine nicht zu überschreitende Lastkurve, gegeben als Funkti-on über die Zeit mit Leistungswerten pro Zeitintervall, bei deren Überschreitung der SECC denLadevorgang abbricht. Mit Hilfe einer solchen Lastkurve kann ein Verteilnetzbetreiber oder ei-ne beliebige andere steuernd einwirkende Instanz – wie bspw. das Energiemanagement-System5Als Elektromobilitäts-Anbieter ist bspw. ein Energievertrieb, welcher dedizierte Ladestromverträge fürdas Aufladen von Elektrofahrzeugen an öentlichen Ladestationen anbietet, oder auch ein Betreiber vonLadestationen zu verstehen.362.2 Standardisierung der Kommunikationsprotokolleeines Smart Home (siehe Abschnitt 3.2) – eine dynamische netzbedingte Engpasssituation überdas Protokoll dem Fahrzeug mitteilen. Ist keine netzseitige Restriktion vorhanden, so basiertPMaxSchedule lediglich auf den statischen Limitierungen, die durch die Ladestation an sichsowie das Ladekabel vorgegeben sind. Auf den Parameter PMaxSchedule wird in Abschnitt4.3.3 im Rahmen einer formalen Darstellung des Optimierungsproblems näher eingegangen.Der optionale SalesTariff zielt darauf ab, dem EVCC auf Basis von relativen Kostenin-formationen (Preislevels statt absolute Preise, oder prozentueller Anteil der CO2 Emissionen)einen tariflichen Anreiz zu bieten, das resultierende Lastprofil des Elektrofahrzeugs in einegewünschte Richtung hin zu beeinflussen. Die Kosteninformation kann sowohl als Kosten proZeit als auch Kosten pro bezogener Energie oder gar Leistungsstufe angegeben werden.Beide Parameter sollen das Elektrofahrzeug hinsichtlich seines Lastprofils beeinflussen,was auf den ersten Blick die Frage aufwirft, warum man überhaupt einen tariflichen Anreiznutzen sollte, wenn man doch mit einer Lastbegrenzungskurve das Fahrzeug direkter steuernkann. Die ursprüngliche Idee hinter der Einführung dieser beiden Parameter ist folgende:PMaxSchedule soll die statischen Limits, gegeben durch die technischen Gegebenheiten derLadestation und des Ladekabels, sowie eine dynamische und kritische Überlastsituation imNetz reflektieren, die keinesfalls überschritten, aber durchaus unterschritten werden darf. DieAusnutzung der resultierenden Fläche unterhalb von PMaxSchedule soll durch ein zeit- oderlastvariables Preissignal beeinflusst werden. Auf diese Weise soll der SECC den EVCC dazuanregen – nicht zwingen – bspw. in Zeiten eines Überschusses an Windenergie im Netz mehrEnergie abzurufen als in Spitzenlastzeiten. In letzter Instanz liegt die Entscheidungsgewaltüber den durchzuführenden Ladeverlauf beim Batterie-Management-System (BMS) (mehrhierzu im Abschnitt 4.3.6) einerseits, welches über den sicheren Betrieb der Batterie wacht,und dem EVCC andererseits, welcher versucht, den Ladevorgang für den Fahrzeugnutzermöglichst günstig durchzuführen. Dies bedeutet, dass gegebenenfalls die vorgegebene Lastkur-ve in Form des PMaxSchedule vom E-Fahrzeug nicht gänzlich ausgereizt und somit wenigerEnergie als geplant abgerufen wird. Der SalesTariff ist gegeben als Funktion über die Zeit,wobei im Gegensatz zu PMaxSchedule nicht Leistungswerte pro Zeitintervall, sondern relativePreisinformationen pro Zeitintervall übertragen werden.Nachdem nun das vom SECC vorgeschlagene Lastprofil vom EVCC empfangen wurde, wirddas BMS eine Plausibilitätprüfung durchführen und gegebenenfalls das Lastprofil entsprechendbeeinflussen. Das vom EVCC akzeptierte Lastprofil wird in der folgenden PowerDeliveryReq-Nachricht dem SECC übermittelt, woraufhin dieser die Ladestation dazu veranlasst, dieLadeschütze zu schließen, damit schlussendlich Spannung anliegt und Strom fließen kann. DasSenden von PowerDeliveryReq geht mit dem Zustandsübergang von Zustand B zu ZustandC einher, wie auch Abbildung 2.10 zu entnehmen ist.Der Parameter ChargeProgress, welcher in der PowerDeliveryReq-Nachricht enthaltenist, kann folgende drei Enumerationswerte annehmen, die den Ladeverlauf beeinflussen:• Start: Sofortiger Start des Ladeprozesses• Renegotiate: Der EVCC möchte eine Neuaushandlung des Lastprofils durchführen,welche mit dem Senden einer neuen ChargeParameterDiscoveryReq-Nachricht einge-leitet wird. Diese Entscheidung wurde üblicherweise durch den SECC in einer vorigenAntwort veranlasst.• Stop: Der Ladevorgang soll verzögert starten oder gar gänzlich gestoppt werden. DieInformation darüber, ob nur eine Pausierung stattfindet, findet sich in der letzten37Kapitel 2 Standardisierungsinitiativen für interoperable E-MobilitätsladelösungenNachricht SessionStopReq.Die PowerDeliveryRes-Nachricht beinhaltet lediglich einen sogenannten ResponseCode (wiejede andere Antwort auch) sowie einen EVSEStatus (ein Parameter, welcher zum Ende diesesAbschnitts näher erläutert wird).Ladeschleife und Neuaushandlung des LadeprofilsMit dem Austausch der PowerDeliveryReq- und -Res-Nachricht sowie dem auf Start ge-setzten Parameter ChargeProgress beginnt der eigentliche Ladevorgang, bei dem Energieübertragen wird. Bis die Batterie vollgeladen ist, eine Neuverhandlung durch den SECCangestoßen wird oder der Fahrzeugnutzer manuell einen Ladestopp initiiert, wird nun für dieDauer der folgenden Ladeschleife das ausgehandelte Lastprofil abgearbeitet.Das ChargingStatusReq/-Res Nachrichtenpaar erlaubt Plausibilitätsprüfungen der regel-mäßig vom SECC übermittelten Zählerdaten, welche eine Bilanz der bezogenen Energiemengedarstellen. Der SECC kann den EVCC dazu auordern, die Zählerdaten zu signieren, welchein der ChargingStatusRes-Nachricht enthalten sind, was den Austausch eines optionalenMeteringReceiptReq/-Res Nachrichtenpaars nach sich zieht. Diese signierten Zählerdatenkönnen sodann für Abrechnungszwecke genutzt werden, für den Fall, dass dies in manchenLändern regulatorisch vorgeschrieben wird.Terminierung des LadevorgangsSobald der Ladevorgang beendet werden soll, wird eine erneute PowerDeliveryReq-Nachrichtvon EVCC an SECC mit ChargeProgress = Stop gesendet, welche die Ladestation dazuanleiten wird, die Ladeschütze wieder zu önen und somit den Energiefluss zu stoppen. DieserVorgang wird mittels der PowerDeliveryRes-Nachricht bestätigt. Schlussendlich wird derSECC mit der SessionStopReq-Nachricht und dem darin enthaltenen Parameter Charging-Session darüber informiert, ob der Ladevorgang nur pausiert (Pause) oder gänzlich beendet(Terminate) werden soll.ResponseCodes und EVSEStatusJede Response-Nachricht übermittelt einen ResponseCode, wobei im positiven Fall meist mitOK geantwortet wird und im negativen Fall die ResponseCodes sich nachrichtenspezifischunterscheiden, um dem EVCC mehr Informationen über den Grund eines Abbruchs derKommunikationssession zu liefern.Des Weiteren enthalten die folgenden Antwort-Nachrichten zusätzlich den wichtigen Para-meter EVSEStatus, welcher dem SECC erlaubt, das Verhalten des EVCC zu beeinflussen:• ChargingStatusRes• MeteringReceiptRes• PowerDeliveryResDieser verschachtelte Parameter enthält u. a. den Parameter EVSENotification, welcher einender selbsterklärenden Werte None, StopCharging, oder ReNegotiation annehmen kann. Diejeweils geforderte Aktion muss innerhalb einer Zeitspanne erfolgen, die durch den ebenfalls inEVSEStatus enthaltenen Parameter NotificationMaxDelay vorgegeben wird. Auf diese Weiseist es der Ladestation möglich, dynamisch auf unvorhergesehene Netzsituationen zu reagierenund den Ladevorgang durch eine Neuverhandlung des Ladefahrplans daran anzupassen.382.2 Standardisierung der KommunikationsprotokolleSomit ist ein kompletter Ladevorgang eines Elektrofahrzeugs, welches mit einer Ladestationüber das Protokoll ISO/IEC 15118 kommuniziert, beschrieben.Wie bereits erwähnt, definiert die ISO/IEC 15118 nur die Kommunikation zwischen ei-nem Elektrofahrzeug und einer Ladestation. Der Kommunikationsfluss zwischen einzelnenLadestationen und einer darüber liegenden zentralen Managementinstanz, sei es ein Flotten-energiemanagementsystem, ein Verteilnetzbetreiber oder ein E-Mobilitäts-Anbieter jeglicherArt, wird im Open Charge Point Protocol (OCPP) spezifiziert, auf welches im folgendenAbschnitt eingegangen wird.2.2.2 Open Charge Point Protocol (OCPP)Das Open Charge Point Protocol ist kein ozieller internationaler Standard, sondern einoener de facto Standard, welcher vom niederländischen E-laad Konsortium ins Leben gerufenwurde. Die aktuelle OCPP 2.0 RC 1 Spezifikation6 [54] ist abwärtskompatibel zur weitver-breiteten Vorgängerversion 1.5 und bewahrt somit deren Funktionalität, erweitert sie jedochum dringend benötigte neue Funktionen, welche die Preisgestaltung von Ladevorgängen, eingesteuertes Laden basierend auf energierelevanten Mehrwertinformationen und verbesserteWartungsmöglichkeiten einer Ladestation ermöglichen. Schaut man sich den aktuellen Standder Spezifikation dieses auf Webservices basierten Protokolls an, so fällt auf, dass viele der fürdas gesteuerte Laden nötigen Parameter aus der ISO/IEC 15118 Norm übernommen wurden.Das verdeutlicht das enge Zusammenspiel zwischen diesen beiden Kommunikationsprotokollenund signalisiert einen weiteren wichtigen Schritt in Richtung interoperabler und standardi-sierter E-Mobilitätslösungen. Mittlerweile hat sich OCPP zu einer europaweiten Initiativeentwickelt und wurde sogar bereits in mehreren ähnlichen Initiativen auch außerhalb Europasadaptiert [47].Für das weitere Verständis dieser Arbeit sind tiefergehende Details zu diesem Kommunika-tionsprotokoll nicht vonnöten und finden daher keine detaillierte Betrachtung.2.2.3 IEC 61850Die IEC 61850 Norm, betitelt mit „Communication networks and systems in substations“,beschreibt ein Übertragungsprotokoll für die Schutz- und Leittechnik und hat sich als Kommu-nikationsstandard im Markt der Automatisierung von Schaltanlagen etabliert. Insbesonderedezentrale Energieerzeugungsanlagen, wie PV-Anlagen oder BHKWs, können hierüber ge-steuert werden. In der aktuellen Literatur werden Erweiterungen dieser Norm diskutiert, mitHilfe derer die Einbindung von Elektrofahrzeugen in das Smart Grid über die Steuerung vonLadestationen ermöglicht werden soll. Dieser Ansatz wird bspw. im EU-ForschungsprojektSmartV2G verfolgt7 und wurde ebenfalls bereits von Schmutzler et al. [62] [60] untersucht.Somit bildet diese Norm eine mögliche Alternative zur Kommunikation von Steuersignalen anLadestationen, welche im Niederspannungsnetz angesiedelt sind. Im weiteren Verlauf dieserArbeit wird dieser Standard jedoch nicht näher betrachtet.6Die finale Spezifikation wird für das dritte Quartal 2014 erwartet und im Rahmen der Open Charge Alliance(http://www.openchargealliance.org), einer Nachfolgeorganisation des OCPP Forums, vorangetrieben.7http://www.esk.fraunhofer.de/de/medien/pressemitteilungen/pm1402.html39Kapitel 2 Standardisierungsinitiativen für interoperable E-Mobilitätsladelösungen2.2.4 Die SAE Normenfamilie für intelligentes LadenDie ISO/IEC 15118 Norm ist nicht das einzige in der Entwicklung befindliche digitale Kom-munikationsprotokoll für das gesteuerte Laden von Elektrofahrzeugen. Der US-amerikanischeAutomobilverband Society of Automotive Engineers (SAE) startete im Jahre 2008 eine Ar-beitsgruppe zur Entwicklung der SAE J2847, eine Reihe von empfohlenen Anwendungsregeln,welche u. a. die Kommunikation zwischen Plug-in Fahrzeugen und dem öentlichen Stromnetz(SAE J2847/1-3) definiert. Diese SAE-Dokumente zielen auf die direkte Kommunikationzwischen E-Fahrzeug und dem “Netz” ab – ein Platzhalter für eine Gruppe von Entitätenwie bspw. der Energielieferant, der Netzbetreiber, ein Aggregator oder sonstige Energiedienst-leister. Dies steht beispielhaft für die unterschiedlichen Ansätze in den USA und in Europa,wonach im Gegensatz zu Europa in den USA der direkte Steuerungszugri einer Netz-Entitätauf die Endgeräte gemäß des Smart Energy Profile 2.0 (SEP 2.0) vorangetrieben wird, umeine Laststeuerung durchzuführen. Die ISO/IEC 15118 Norm hingegen spezifiziert gezielt diedirekte Kommunikation zwischen Elektrofahrzeug und Ladestation.Es gibt bereits Bestrebungen, die teils parallelen Entwicklungen aus SAE J2847 und ISO/IEC15118 zusammenzuführen und kompatibel zueinander zu gestalten. Die Spezifikationen be-züglich der aktiven Ladesteuerung, der Neuaushandlung des Lastprofils, der automatisiertenAbrechnung sowie zusätzlicher Mehrwertdienste scheinen in der ISO/IEC 15118 Norm jedochweiter vorangeschritten und ausgereifter zu sein, weshalb im weiteren Verlauf dieser Arbeitdie SAE Normen keine weitere Betrachtung finden.40KAPITEL 3VERSUCHSAUFBAU UND EVALUATIONSUMGEBUNGDie beste Voraussetzung zur Hebung des Lastverschiebepotentials von Elektrofahrzeugen istdort gegeben, wo diese Fahrzeuge lange mit der Ladestation verbunden sind, also im privatenBereich zu Hause bzw. auf halb-öentlichem Terrain wie dem Firmenparkplatz des Arbeitgebers.Um die Vorteile der Integration eines Elektrofahrzeugs in das Energienetz und dessen Eignungals mobilen Energiespeicher und Verbraucher real untersuchen zu können, wurde daher imRahmen des Forschungsprojekts iZEUS1 eine bereits bestehende Laborumgebung um hard-und softwaretechnische Komponenten erweitert. Dieser Versuchsaufbau stellt einen bereits imElektromobilitätsforschungsprojekt MeRegioMobil2 konzipierten und realisierten Prototypeneines intelligenten Haushalts mit beobachtbaren und steuerbaren Haushaltskomponentendar, das Energy Smart Home Lab (ESHL), dessen Grundriss Abbildung 3.1 zu entnehmenist. Das ESHL sowie das im Einsatz befindliche Energiemanagement-System (EMS) wurdein [6] und [3] bereits ausführlich beschrieben. Es sollen an dieser Stelle daher nur die zumVerständnis dieser Arbeit notwendigen Grundlagen über den technischen Aufbau des ESHLssowie die dem EMS zugrundeliegende Softwarearchitektur dargestellt werden.3.1 Das Energy Smart Home Lab (ESHL)Das Energy Smart Home Lab hat eine Grundfläche von ca. 60 m2. Diese ist aufgeteilt aufeine Wohnküche und zwei Schlafzimmer. Ein zusätzlicher Technikraum beherbergt z. B. dieMessinstrumente, das µ-Blockheizkraftwerk (BHKW)3 für Heizung und Warmwasserbereitung,den Solarwechselrichter sowie das zentrale EMS. Das Haus ist sowohl mit elektrischen als auchthermischen Haushalts-Komponenten ausgestattet, welche sich einerseits aus herkömmlichenund andererseits aus intelligenten Haushaltsgeräten zusammensetzen, deren Intelligenz sichdarüber definiert, dass sie ihren Zustand kommunizieren können und sich durch Steuersignalebeeinflussen lassen. Beispiele für intelligente Haushaltsgeräte, die sich in der Durchführungihrer Aufgabe sinnvoll beeinflussen lassen, sind eine Waschmaschine, ein Trockner, eineGeschirrspülmaschine oder eine Klimaanlage, die aus PCM-Kühlmodulen besteht. Unter einer1http://izeus.kit.edu2http://meregiomobil.forschung.kit.edu3Ein Mikro-Blockheizkraftwerk ist eine Anlage zur Gewinnung elektrischer Energie und Wärme, welche hierfürdas Prinzip der Kraft-Wärme-Kopplung nutzt.41Kapitel 3 Versuchsaufbau und Evaluationsumgebungsinnvollen Beeinflussung ist hier zu verstehen, dass bspw. der Zeitpunkt des Programmstarts(bei einer Waschmaschine oder einem Trockner) oder der Betrieb des BHKW zur passendenTemperierung des Warmwasserspeichers zeitlich verschoben werden können, ohne dass diesKomforteinbußen für den Hausbewohner mit sich bringen würde. Hingegen ist bspw. einzeitlich versetzter Betrieb der Herdplatte zur Zubereitung des Abendmahls für den Bewohnerwenig bis nicht akzeptabel.Neben solchen Verbrauchern sorgen Erzeuger, wie eine auf dem Dach installierte PV-Anlagemit 4,6 kWp und das bereits erwähnte Mikro-BHKW, für lokal regenerativ eingespeiste Energie.Die Bewohner des Hauses erhalten eine detaillierte Übersicht über alle aktuellen und histo-rischen Energieflüsse im Haus, den aktuell und für die nächsten 24 Stunden kommuniziertenzeitvariablen Strompreis und die Lastgrenze4 sowie weitere energierelevanten Daten mittelseiner webbasierten Anwendung, dem Energy Management Panel (EMP) [10], auf welchessie über diverse installierte Touchscreen-Displays zugreifen können. Das EMP dient nebender Sensibilisierung des Benutzers hinsichtlich Stromverbrauch und Leistungsspitzen darüberhinaus als Benutzungsschnittstelle, um mit dem EMS zu interagieren. So kann die zeitlicheFlexibilität der Bewohner bzgl. der Start- und Endzeitpunkte der intelligenten Haushaltsgeräteals auch bzgl. des Abfahrtszeitpunkts mit dem Elektroauto erschlossen werden. Der Nutzerkann z. B. auch festlegen, wie groß die gewünschte minimale Reichweite sein soll, die das Elek-trofahrzeug für unvorhergesehene Fahrten stets vorhalten sollte. Dies hat direkte Auswirkungauf die zur Rückspeisung zur Verfügung stehende Energie und den Verlauf des Ladevorgangs.Basierend auf dem von extern kommunizierten Strompreis und Lastbegrenzungssignal sowieden Benutzerpräferenzen erfolgt eine automatisierte zeitliche Einplanung der Geräte durchdas EMS, welche sich optimal auf die zu erfüllende Zielfunktion (bspw. kostenminimalerStromverbrauch, Eigenstromoptimierung) auswirken soll.Das im Projekt iZEUS zum Einsatz kommende Elektrofahrzeug ist ein Prototyp eineselektrifizierten Opel Meriva, dessen eingebaute Lithium-Ionen-Batterie eine Gesamtkapazitätvon 16 kWh aufweist, wovon jedoch nur ca. 12 kWh für das Fahren zur Verfügung stehen.Durch den speziell eingebauten Wechselrichter ist es in der Lage, Energie aus der Batterieauch wieder in das Netz bzw. das Smart Home mit einer maximalen Leistung von -4,2 kWzurückzuspeisen. Die maximale Ladeleistung beträgt 11 kW.3.2 Das Energiemanagement-System (EMS) des ESHLDas Energiemanagement-System, welches im Smart Home zum Einsatz kommt, hat die Aufga-be, sämtliche thermischen wie auch elektrischen Verbraucher zu beobachten. Basierend auf denbeobachteten Zustandsinformationen, vom Benutzer über das EMP mitgeteilten Präferenzensowie Preis- und Lastbegrenzungssignalen wird ein Gesamtlastprofil erzeugt, welches einevorher definierte Zielfunktion erfüllt. Diese Zielfunktion kann beliebig definiert werden. Solässt sich bspw. festlegen, dass der vor Ort produzierte Strom aus regenerativen Energiequellenwie der Photovoltaik-Anlage auf dem Dach oder dem µ-BHKW bestmöglich für die Deckungder eigenen Hauslast genutzt wird, anstatt die erzeugte Energie in das Netz einzuspeisen. Alsweitere Zielfunktion könnte man sich vorstellen, die Gesamtstromkosten des Haushalts zuminimieren, indem man die steuerbaren Verbraucher zeitlich verschiebt. Diese Verschiebungbasiert in diesem Fall auf einem Stromtarifsignal und einem Lastbegrenzungssignal, welches4Diese Lastgrenze ist als eine weiche Grenze zu verstehen, deren Überschreitung nicht die harte Abschaltungvon Verbrauchern zur Folge hat, sondern mit erheblichen Zusatzstromkosten einhergeht.423.2 Das Energiemanagement-System (EMS) des ESHLEnBWSolar&Wechsel&,richter,Smart,Meter,EMP,Ladesta5on,Intelligente,Haushaltsgeräte, BHKW,EMP,EMP,A/C,Beobachtet,und,steuert,elektrische/thermische,Verbraucher,&,Erzeuger,EMP,Energy'Management'Panel'(EMP)',,,,,,,,,,,,,,Visualisierung,der,Energienutzung,Erschließung,der,,Freiheitsgrade,der,Hausbewohner,EMS'Abbildung 3.1: Grundriss des Energy Smart Home Labeine dynamische obere Grenze für die kumulierte Haushaltslast definiert und dessen Über-schreitung zusätzliche Kosten verursacht. Da die monetären Vergütungen für eingespeistenStrom aus regenerativen Energiequellen über die letzten Jahre stetig gesunken sind und dieserTrend sich weiter fortsetzt, ist es für aktuell neu installierte PV-Anlagen per se lohnender,seinen produzierten Strom auch selbst zu verbrauchen [40], womit die Erfüllung der erstenZielfunktion sicherlich die zweite Zielfunktion stark beeinflusst.Die Architektur des EMS basiert auf den Prinzipien des Organic Computing [45], einForschungsbereich, welcher im Schwerpunktprogramm 1183 der Deutschen Forschungsgemein-schaft (DFG) entstanden ist. Im Rahmen des Organic Computing wurde eine sogenanntegenerische Observer/Controller Architektur konzipiert, mit Hilfe derer ein komplexes System,welches nach gewissen Zielvorstellungen zu beeinflussen ist, um generische Instanzen erweitertwird. Diese sammeln und verarbeiten (Observer) einerseits Zustandsinformationen des zubeobachtenden Gesamtsystems5 und wirken andererseits gemäß vorgegebener Richtlinien steu-ernd auf die Komponenten des Gesamtsystems ein (Controller). Insbesondere ist es erklärtesZiel, dass sich die Systemkomponenten bis zu einem gewissen Grad selbstorganisiert verhalten,um somit auch die Komplexität eines sehr heterogenen Gesamtsystems, wie es beispielsweisedas hier vorgestellte Smart Home aufweist, besser beherrschbar zu machen. Eine einzelneKomponente des Gesamtsystems Smart Home wäre beispielsweise das Elektroauto, ein intelli-genter Verbraucher wie die Spül- oder Waschmaschine oder auch die Erzeuger PV-Analge undµ-BHKW. Jedem dieser einzelnen Verbraucher und Erzeuger wird eine sogenannte Observer-Controller-Einheit (kurz: O/C-Einheit) zugewiesen. Eine Übersicht über die O/C-Architektur,welche im Smart Home zum Einsatz kommt, ist Abbildung 3.2 zu entnehmen. Im Folgendenwerden die einzelnen Komponenten dieser hierarchich aufgebauten O/C-Architektur insofern5In der Organic Computing Terminologie auch „System under observation and control“ genannt43Kapitel 3 Versuchsaufbau und EvaluationsumgebungO C O C O CO CRegistryCOM-ManagerCOM-ManagerHAL...DRV DRV DRV COMDRVCOMDRVAbbildung 3.2: Überblick über die O/C-Architektur des Energiemanagement-Systems imSmart Home (angelehnt an [3])näher beleuchtet, als dies für das weitere Verständnis der Integration des Elektroautos indas EMS hilfreich ist. Für eine tiefergehende und detailreichere Betrachtung der jeweiligenBestandteile sei der interessierte Leser auf [3] verwiesen.Hardware-Abstraktions-Schicht und TreiberAus Abschnitt 3.1 geht bereits hervor, dass sehr unterschiedliche Komponenten zum Tragenkommen, die in das Energiemanagement integriert werden müssen. Um diese Heterogenitätunter den Verbrauchern und Erzeugern beherrschen zu können, ist es sinnvoll, eine Ab-straktionsschicht zwischen den O/C-Einheiten und der gerätespezifischen Kommunikationeinzubinden. Diese Hardware-Abstraktions-Schicht (HAL) agiert als Schnittstelle zu den gerä-tespezifischen Treibern. Diese Treiber (in Abbildung 3.2 mit DRV bezeichnet) dienen wiederumdazu, die Information aus den generischen Datenobjekten, die jeweils einer Komponentenklassewie zum Beispiel der Klasse Waschmaschine, µ-BHKW oder Elektroauto zugeordnet sind, indas jeweils gerätespezifische Kommunikationsprotokoll zu übersetzen und umgekehrt.Lokale O/C-EinheitenJeder einzelnen einzubindenden Komponente ist nicht nur ein eigener Treiber zugeordnet,sondern auch eine sogenannte lokale O/C-Einheit. Während einerseits den jeweiligen ab-strakten Komponententypen wie bspw. Waschmaschine, BHKW und Elektroauto stets eineeinzelne lokale O/C-Einheit zugeordnet ist, ist es andererseits möglich, dass unterschiedlicheTreiber die gleiche lokale O/C-Einheit bedienen können. So wird den unterschiedlichen Kom-munikationsprotokollen verschiedener Hersteller eines Gerätetyps Rechnung getragen. Eine443.2 Das Energiemanagement-System (EMS) des ESHLlokale O/C-Einheit verfügt somit über gerätespezifische und präzise Steuer- und Zustands-informationen der entsprechenden Komponente. Die konkreten Zustandsinformationen deszu überwachenden physikalischen Geräts, die der Observer-Teil der O/C-Einheit sammelt,können im vorgestellten hierarchischen Ansatz somit abstrahiert an den globalen Observerweitergeleitet werden. Anweisungen, die über den globalen Controller an die entsprechendenlokalen O/C-Einheiten gesendet werden, können dann vom lokalen Controller über die HAL-Schicht und den passenden Treiber für das zu steuernde physikalische Gerät übersetzt werden.RegistrarDas Registrar ermöglicht den Informationsaustausch zwischen den einzelnen O/C-Einheitenuntereinander sowie zwischen der lokalen und der globalen O/C-Schicht und agiert somitals Middleware. Hierbei können sich die einzelnen Observer- und Controller-Einheiten beimRegistrar für bestimmte Ereignisse anmelden, um Zustandsinformationen anderer Einheitenzu erhalten.Globale O/C-EinheitWährend die lokalen Observer präzise und ausführliche Zustandsinformationen über die jeweilszugeordneten Haushaltskomponenten beziehungsweise das Elektrofahrzeug direkt über dieHAL-Schicht sammeln und auswerten, vereint der globale Observer all diese Zustandsdaten inaggregierter Form und wertet diese aus, um sie anschließend dem globalen Optimierer, welchersich in der Controller-Komponente befindet, zukommen zu lassen.Die hinsichtlich einer zu erfüllenden Zielfunktion zentral bewertende Instanz des EMSwird durch den globalen Controller verkörpert. Sämtliche Zustandsinformationen über allederzeit eingebundenen elektrischen und thermischen Verbraucher und Erzeuger, die von externkommunizierten Strompreis- und Lastbegrenzungssignale sowie vom Benutzer über das EMPvorgegebenen Präferenzen laufen hier zusammen und fließen in den im Controller angesiedeltenOptimierungsalgorithmus ein. Wie in [3] ausführlich erläutert, kommt hier ein evolutionärerAlgorithmus aus der Klasse der metaheuristischen Verfahren zum Einsatz. Eine Metaheuristikbietet die Möglichkeit, innerhalb zeitlicher und rechenkapazitätsbedingter Restriktionen einenäherungsweise Lösung für ein Optimierungsproblem zu finden, welche nicht notwendigerweisedas bestmögliche aber zumindest ein gutes Ergebnis darstellt. In [5] wurde bereits gezeigt,dass ein metaheuristisches Verfahren gerade auf einem kleinen stromsparenden System, wiees für gängige Haushalte Sinn machen würde, einem exakten Lösungsverfahren in der hiervorgestellten Komponentenumgebung vorzuziehen ist, wenn eine Lösung für das Optimierungs-problem in akzeptabler Rechenzeit gefunden werden soll. Die Funktionsweise des globalenOptimierers auf Basis eines EA ist in Abbildung 3.3 skizziert und wird im Folgenden kurzerläutert.Die aus der Gruppe der naturinspirierten Verfahren stammenden evolutionären Algorithmen[74] versuchen, den biologischen Prozess der Evolution in gewisser Weise auf die Informatikzu übertragen und die entsprechenden Vorgänge abstrahiert abzubilden. Dementsprechendsind auch einige Termini dem biologischen Äquivalent entlehnt. So definiert ein EA einenKreislauf, wie er auch in Abbildung 3.3 zu sehen ist. In diesem Kreislauf wird basierend aufeiner aus mehreren sogenannten Individuen aufgebauten Population eine Teilmenge selektiert,auf welcher wiederum die genetischen Operatoren Rekombination und Mutation angewandtwerden. Hiernach wird die neu entstandene Population aus veränderten Individuen evaluiertund hinsichtlich eines Abbruchkriteriums überprüft, ob ein erneuter Kreislauf – man spricht45Kapitel 3 Versuchsaufbau und EvaluationsumgebungGlobal O/C-unit local O/C-unit local O/C-unit local O/C-unit local O/C-unit local O/C-unit local O/C-unit P P P t t t 6:00pm 5:00pm PP WaMa PP DishWasher 2h 10 bit Individual PP CHP 43 bit 8 bit PP WaMa PP DishWasher PP CHP fitness function 1011111101 11001101 1011100111…10111 1010011101 10101101 1011000111…10111 1010010101 10001101 1011010111…10111 1010010101 10001101 1011010111…10111 P t Stopping criteria reached? 1010010101 10001101 1011010111…10111 evaluate() evaluate() evaluate() PP WaMa PP DishWasher PP CHP transform() transform() transform() PP WaMa PP DishWasher PP CHP Selection Recombination/Mutation inital/current Population EA Signals and (user) preferences Evaluation Abbildung 3.3: Globaler Optimierungsprozess im Organic Smart Home [4]463.2 Das Energiemanagement-System (EMS) des ESHLhier von einer Generation – durchgeführt werden soll. Ist die Abbruchbedingung erfüllt, soenthält die aktuelle Population den bis dahin besten Lösungskandidaten – das beste bisherberechnete Individuum. Für tiefergehende Erläuterungen zu evolutionären Algorithmen seider Leser auf Weicker [74] verwiesen.Eine Möglichkeit, ein Individuum einer Lösungspopulation zu kodieren, ist die binäre Ko-dierung, wie sie auch im Optimierer des Energiemanagments im ESHL implementiert undentsprechend in Abbildung 3.3 dargestellt ist. Wie klar zu erkennen ist, wird ein Individuumwiederum aus Teilindividuen zusammengebaut. Die Philosophie hinter dem im ESHL einge-setzten Optimierungsverfahren ist das Zusammenfügen einzelner flexibel kodierter und zulösender Teilprobleme zu einem Gesamtenergiemanagementproblem.Im hier vorgestellten Ansatz erzeugt jede Haushaltskomponente, welche am Energiemana-gement teilnimmt, ein Teilproblem (in Abbildung 3.3 mit PP für ProblemPart bezeichnet).Dieses Teilproblem kapselt die Kodierung der relevanten Parameter, welche zur Einplanung derjeweiligen Haushaltskomponente im Rahmen des Gesamtenergiemanagements vonnöten sind.Hierbei werden die entsprechenden Parameter in ihre binäre Repräsentation übersetzt undergeben einen der Haushaltskomponente (oder dem Elektrofahrzeug) zugeordneten Bitvektorindividueller Länge. Sämtliche Bitvektoren aller zu steuernden Komponenten zusammenge-nommen ergeben dann ein Individuum. In der Terminologie der evolutionären Algorithmenentspricht ein solcher Bitvektor einem Genotyp, also einer möglichen Darstellung eines Lö-sungskandidaten für ein Optimierungsproblem. Die Kapselung jedes Teilproblems umfasstneben einem solchen Bitvektor ebenso eine Kodierungsvorschrift, die die binäre Kodierung derrelevanten Paramter wieder auf ihre semantische Repräsentation, den sogenannten Phänotyp,abbildet. Man spricht hier auch von einer Genotyp-Phänotyp-Abbildung. Im Rahmen des hiervorgestellten Energiemanagementansatzes kann der Phänotyp unterschiedlicher Natur sein. ImFalle der Waschmaschine entspricht der Phänotyp bspw. dem Startzeitpunkt des eingestelltenWaschprogramms, der Phänotyp des Elektrofahrzeugs hingegen entspricht einer Lastkurve,also einer Liste von chronologisch sortierten Tupeln mit Startzeitpunkten und Leistungswerten.Aufeinanderfolgende Startzeitpunkte definieren somit ein Intervall konstanter Leistung. Dasletzte Tupel der Liste schließt einen Ladefahrplan mit dem Leistungswert 0 kW ab.In Abbildung 3.3 wird beispielhaft anhand der drei verschiedenen HaushaltskomponentenWaschmaschine, Trockner und µ-BHKW mit unterschiedlichen zeitlichen Restriktionen darge-stellt, wie die Optimierung im globalen Controller abläuft. Sobald eine am Energiemanagementteilnehmende Komponente aufgrund einer Zustandsänderung – die Waschmaschine wurdeprogrammiert und für spätestens 18 Uhr eingeplant, der Schichtspeicher des µ-BHKW unter-schreitet eine Mindesttemperatur, das Elektroauto wurde an die Ladestation angeschlossen –neu eingeplant werden muss, wird von der lokalen O/C-Einheit ein neues Teilproblem-Objekterzeugt und an den globalen Observer gesendet, welcher das Wissen über die aktuell gültigenTeilprobleme aller lokalen O/C-Einheiten hält. Wie bereits erwähnt, werden hier alle Bitvek-toren, die von den einzelnen Teilproblem-Objekten erzeugt wurden, zu einem Gesamtbitvektor,dem Individuum, zusammengefügt.Im Laufe einer jeden Generation wird jedes Individuum hinsichtlich seiner Eignung für ein op-timales Gesamtlastprofil untersucht. Hierbei wird aus jedem Teilproblem-Objekt eine Funktionaufgerufen, welcher das zum Teilproblem gehörige Bitvektor-Segment des Individuums überge-ben wird, in Abbildung 3.3 mit evaluate() bezeichnet. Diese Funktion liefert eine Lastkurveder jeweiligen Komponente, im Schaubild durch die zweidimensionalen Leistung-pro-Zeit-Diagramme (P-t-diagramme) visualisiert, sowie einen zusätzlichen Bewertungsfaktor zurück.47Kapitel 3 Versuchsaufbau und EvaluationsumgebungDie jeweilige Lastkurve wird u. a. durch Anwendung einer Genotyp-Phänotyp-Abbildungerzeugt. Der Unterschied zwischen der evaluate() und der transform() Funktion wirdz. B. anhand der Komponenten Waschmaschine und Elektrofahrzeug deutlich.Der Genotyp, der dem Teilproblem Waschmaschine zugeordnet ist, wird im Zuge der Abbil-dung auf seinen Phänotyp zu einem Startzeitpunkt dekodiert. Zusammen mit dem hinterlegtenprogrammspezifischen Lastprofil einer Waschmaschine kann hieraus das resultierende Last-profil der Waschmaschine in einem gewissen Zeitraum, dem Optimierungshorizont, ermitteltwerden. Der Optimierungshorizont entspricht einer Zeitspanne, die spezifisch und flexibelfür jeden Verbraucher und Erzeuger, der in das EMS eingebunden wird, festgelegt wird undmehrere Stunden umfassen kann. Hierbei kann dieser bspw. beim E-Fahrzeug die Zeitspan-ne von der Eingabe des Abfahrtszeitpunkts (bspw. über das EMP) bis zum tatsächlichenAbfahrtszeitpunkt umfassen, oder aus kodierungstechnischen und lastspezifischen Gründenauch eine geringere Zeitdauer gewählt werden, wie in Abschnitt 4.3.1 noch erläutert werdenwird. Der Genotyp des Teilproblems Elektrofahrzeug entspricht bereits einem Lastprofil,welches über die Zeitspanne des Optimierungshorizonts definiert ist. Unabhängig von derkonkreten Ausprägung des Phänotyps einer Komponente liefert die Funktion evaluate()stets ein zum Teilproblem gehöriges Lastprofil für die Dauer des Optimierungshorizonts.Sämtliche Lastprofile aller Komponenten werden dann zu einem Gesamtlastprofil zusammen-gefügt und einer Bewertung unterzogen, im Schaubild mit fitness function gekennzeichnet.Diese Fitnessfunktion entspricht der bereits in Abschnitt 3.2 angesprochenen Zielfunktionund bewertet bspw. die Kosten dieses Gesamtlastprofils durch Verrechnung des Stromtarifsund einer optionalen Lastgrenze, deren Überschreitung zusätzliche Kosten verursacht. Derbereits angesprochene Bewertungsfaktor, welcher durch jedes Teilproblem im Rahmen derevaluate()-Funktion zurückgeliefert wird, beeinflusst darüber hinaus die Kosten.Sobald ein vorher festgelegtes Abbruchkriterium für den EA erreicht ist, wird das resultie-rende beste Individuum ausgewählt und der jeweiligen Controller-Komponente einer jedenlokalen O/C-Einheit die entsprechende Steuerinformation für das assoziierte Gerät übermit-telt. Hierbei wird also dem lokalen Controller nach Aufruf der Teilproblem-eigenen Methodetransform() der gerätespezifische Phänotyp kommuniziert. Diese Steuerinformation leitetbspw. die Waschmaschine oder den Trockner dazu an, zum errechneten Startzeitpunkt dasimmer gleiche (oder programmspezifische) Lastprofil abzuarbeiten. Dem Elektrofahrzeug wirdhingegen das flexible Lastprofil an sich kommuniziert, welchem es zu folgen hat.Da beispielsweise die Waschmaschine eine je nach eingestelltem Waschprogramm fix vorher-sagbare Lastkurve erzeugen wird und nicht unterbrechbar ist, das Elektroauto jedoch sehrflexibel Energie laden wie auch rückspeisen kann, stellt eine geeignete eziente Kodierung fürdie Einplanung des Fahrzeugs eine größere Herausforderung dar. Diese Kodierungsansätzewerden in Kapitel 4 näher erläutert.Nachdem nun die zentralen Komponenten des EMS grundlegend eingeführt wurden, mussnun noch der Blick auf die Benutzungsschnittstelle gerichtet werden, welche es dem Bewohnerdes Smart Home und gleichzeitig Fahrer des Elektrofahrzeugs ermöglicht, seine Zielvorgabendem EMS mitzuteilen. Hinsichtlich des Elektrofahrzeugs gibt es zwei essentielle Größen, die derBenutzer vorgibt: die geplante Abfahrtszeit sowie die gewünschte Mindestreichweite, die dasE-Fahrzeug so schnell wie möglich geladen haben sollte. Da mit der Benutzungsschnittstelleim Fahrzeug und dem EMP nun zwei Eingabequellen existieren, entsteht hier ein Konfliktbezüglich der Deutungshoheit der Informationen, je nachdem aus welcher Richtung diesekommen. Mit der genaueren Betrachtung und Auflösung dieses Konflikts beschäftigt sich derfolgende Abschnitt.483.3 Der Konflikt zweier Eingabequellen – E-Fahrzeug und EMP3.3 Der Konflikt zweier Eingabequellen – E-Fahrzeug und EMPDer Observer einer lokalen O/C-Einheit hat die Möglichkeit, sich über neue Ereignisse, diemittels des Registrars kommuniziert werden, informieren zu lassen. Im Falle des Elektrofahr-zeugs interessiert sich der ihm zugeordnete lokale Observer speziell für manuelle Eingaben,die vom Benutzer über das EMP erfolgt sind, da hierüber der gewünschte Abfahrtszeitpunktsowie die gewünschte Mindestreichweite des E-Fahrzeugs angegeben werden können, wiein Abbildung 3.4 dargestellt. Diese Informationen können auch über den dem E-FahrzeugAbbildung 3.4: EMP-Benutzungsschnittstelle zur Eingabe des gewünschten Abfahrtszeit-punkts und der Mindestreichweitezugeordneten Treiber an den Observer gelangen, falls der Nutzer diese Informationen bereitsdirekt über die Benutzungsschnittstelle im Fahrzeug vor Ladebeginn hinterlegt hat. Hierbeikönnen Inkonsistenzen entstehen, die es zu lösen gilt. Folgender Ablauf verdeutlicht einenpotentiellen Konflikt zwischen diesen beiden Eingabequellen:1. Der Bewohner kehrt abends um 18 Uhr von der Arbeit zurück und verbindet dasElektroauto mit der Ladestation. Das EMP hat als Abfahrtszeitpunkt noch 8 Uhrmorgens desselben Tages gespeichert, ein Wert, welcher am vorigen Abend vom Bewohnerüber das Touch-Display eingegeben wurde.2. Der Treiber kommuniziert an den lokalen Observer den Abfahrtszeitpunkt, welchervom Elektroauto bei Initialisierung des Ladevorgangs übermittelt wurde. Dies kannein Zeitpunkt in der Zukunft oder der aktuelle Zeitpunkt sein, falls der Nutzer keinenexpliziten Abfahrtszeitpunkt über die Benutzungsschnittstelle im Auto angegeben hat,was ein sofortiges Laden nach sich ziehen würde.49Kapitel 3 Versuchsaufbau und EvaluationsumgebungDa der im EMP gespeicherte Abfahrtszeitpunkt älter als der vom Fahrzeug (und somitTreiber) übermittelte ist, hat Letzterer eine höhere Priorität. Dies führt dazu, dass dasEMP dazu veranlasst wird, sowohl Abfahrtszeitpunkt als auch minimale Reichweitedurch die vom Treiber übermittelten Werte zu ersetzen, was ein visuelles Update aufden Touch-Displays zur Folge hat.3. Ändert der Hausbewohner nun über das EMP den Abfahrtszeitpunkt oder die minimaleReichweite, so werden beide Werte als Aktualisierung an den lokalen Observer gesendetund von diesem als neue Richtlinie übernommen. Hierbei kann der Abfahrtszeitpunktauch zeitlich vor der vom Treiber kommunizierten Abfahrtszeit liegen, wichtig ist indiesem Fall nur der Zeitpunkt einer Aktualisierung der relevanten beiden Parameter.4. Ist laut des vom EMS an das E-Fahrzeug kommunizierten Lastprofils irgendwanneine Ladepause einzulegen, so wird sich das Ladesteuergerät im Elektrofahrzeug selbstabschalten, um die 12 V Batterie des Autos, welche als Stromquelle für das Steuergerätfungiert, nicht zu entladen.5. Wacht das E-Fahrzeug wieder selbständig auf, da die anvisierte Ladepause beendet ist,wird es erneut seine initialen Ladeparameter samt Abfahrtszeitpunkt und minimaleReichweite übermitteln.Schritt fünf führt nun zu einer Situation, in der entschieden werden muss, ob die vom Fahrzeugerneut aktualisierten Parameter die über das EMP gelieferten Werte überschreiben sollen,oder nicht. Eigentlich würde der Bewohner annehmen, dass die zuletzt manuell über dasEMP eingegebenen Werte maßgeblich sind (sofern der angegebene Abfahrtszeitpunkt nicht inder Vergangenheit liegt), allerdings unterscheidet sich auf den ersten Blick ein Erwachen auseiner Ladepause nicht von einem erneuten Verbinden des Fahrzeugs mit der Ladestation nacheiner zwischenzeitlichen Fahrt, da die komplette IP-basierte Kommunikation in beiden Fällenterminiert wird.Des Weiteren muss der Fall berücksichtigt werden, dass der Bewohner rein theoretisch schonmorgens vor der Abfahrt den nächsten Abfahrtszeitpunkt des darauf folgenden Morgens angibt.Nun gilt es abzuwägen, ob der Abfahrtszeitpunkt, welcher bei dem am Abend erfolgendenLadevorgang vom E-Fahrzeug kommuniziert wird, höher prior zu bewerten ist, weil diese Datenspäter aktualisiert wurden, oder der ebenfalls in der Zukunft liegende Abfahrtszeitpunkt,welcher im EMP noch gespeichert ist, den maßgeblichen Wert darstellt.Es gibt zwei Lösungsmöglichkeiten für das Problem der Deutungshoheit aktueller Werte:1. Man ergänzt die Benutzungsschnittstelle im EMS um eine Option, die festlegt, welcheEingabequelle stets zu bevorzugen ist.2. Es wird stets die aktuellste im lokalen Observer eintreende Nachricht über die Aktuali-sierung des Abfahrtszeitpunkts für die Ladesteuerung herangezogen.Gegen Option eins spricht, dass der Nutzer möglicherweise stets die Möglichkeit haben möchte,über beide Benutzungsschnittstellen den Abfahrtszeitpunkt einzugeben, ohne jeweils vorherdie Option im EMS umstellen zu müssen. Diese Flexibilität hat zudem auch den Vorteil,dass die Benutzungsschnittstelle im EMP nicht unnötig mit Optionen überfrachtet, sondernmöglichst einfach gehalten wird.Im vorliegenden Fall wurde daher Variante zwei gewählt. Nun gilt es noch dem Problemder Unterscheidung zwischen Ladepause und völlig neuem Ladeprozess zu begegnen. Die503.3 Der Konflikt zweier Eingabequellen – E-Fahrzeug und EMPISO/IEC 15118-2 Spezifikation bietet die Möglichkeit, zwischen einer Ladepause und einemgewollten Ende einer Ladesession zu unterscheiden, um der Ladestation die Haltung gewisserZustandsinformationen zu ermöglichen. Wie in Abschnitt 2.2.1, Seite 38, bereits erwähnt, liefertdie Nachricht SessionStopReq den Parameter ChargingSession, welcher darüber aufklärt,ob die Ladesession nur pausiert (Pause) oder gänzlich beendet (Terminate) werden soll. DieseZustandsinformation müsste daher vom Treiber stets an den lokalen Observer kommuniziertwerden, damit dieser die korrekte Entscheidung darüber treen kann, welcher Zeitstempelnun für die Ladesteuerung ausschlaggebend ist. Das E-Fahrzeug würde eine Terminierung derLadesession nur dann anstoßen, wenn die Batterie ihren maximalen Ladezustand erreicht hatoder der Nutzer den Ladevorgang manuell abgebrochen hat.Hat das Elektrofahrzeug nun eine Ladesession ordnungsgemäß beendet, so sind dennochzwei weitere Situationen denkbar, in denen das Fahrzeug eine neue Ladesession starten würde,obwohl es immer noch mit der Ladestation verbunden ist.1. Das Elektrofahrzeug wurde bereits vor dem Abfahrtszeitpunkt vollgeladen und ausEnergiemanagement-Sicht erscheint es sinnvoll, einen Teil der gespeicherten Energie ausdem Auto zu verwenden und zu einem späteren Zeitpunkt noch vor der Abfahrt dieselbeEnergiemenge wieder zu laden. In diesem Fall wird der Treiber das E-Fahrzeug dazuveranlassen, den Ladevorgang erneut zu initialisieren.2. Es tritt ein Fehler in der Kommunikation zwischen E-Fahrzeug und Ladestation undsomit ein Timeout auf, welcher die Reinitialisierung einer Ladesession zur Folge hätte.In beiden Fällen würde der Nutzer davon ausgehen, dass die Einstellungen, die manuell amEMP vorgenommen wurden, immer noch gültig sind. Es muss daher vermieden werden, dassder Nutzer verwirrt wird, weil aus einem ihm unersichtlichen Grund die Abfahrtszeit (und evtl.die Mindestreichweite) ohne sein Zutun verändert wurden und das Fahrzeug gegebenenfallsentgegen seiner Intention als Verbraucher neu eingeplant wird.Im ersten Fall hat der lokale Observer das Wissen darüber, dass das Elektrofahrzeug neueingeplant werden muss und kann somit die Information abspeichern, dass die Vorgabe ausdem EMP der neuen Information aus dem Fahrzeug vorzuziehen ist. Im zweiten Fall müssteder fehlerbehaftete Verbindungsabbruch vom Treiber an den lokalen Observer kommuniziertwerden.Aus den obigen Überlegungen heraus scheint der am einfachsten gangbare und robustesteWeg der zu sein, die physikalische Konnektivität des Autos mit der Ladestation zu überprüfen6und nur bei einer physikalischen Trennung des Autos von der Ladestation davon auszugehen,dass der nächste vom Auto kommunizierte Abfahrtszeitpunkt für die Einplanung zu verwendenist.Im letzten Abschnitt 3.4 dieses Kapitels wird nun auf architekturbedingte Einschränkungenbei der Kodierung des Teilproblems Elektrofahrzeug eingegangen.6Dies kann über die Messung der Spannung erfolgen, wobei eine an der Steckdose der Ladestation (Socket)anliegende Spannung von 12 V bedeutet, dass kein Elektroauto mit der Ladestation verbunden ist, eineSpannung von 9 V die Verbindung über das Ladekabel und 6 V die Ladebereitschaft des E-Fahrzeugssignalisiert (vgl. Zustand A, B und C in Abbildung 2.10).51Kapitel 3 Versuchsaufbau und Evaluationsumgebung3.4 Architekturbedingte Kodierungs-EinschränkungenErklärtes Ziel dieser Arbeit ist es, ein rückspeisefähiges Elektrofahrzeug in das bereits beste-hende Energiemanagement-Framework des Smart Home einzubinden, sodass die im Fahrzeugverbaute Batterie als flexibler Verbraucher und Energiespeicher eingeplant werden kann. Hier-bei wird zur Optimierung des Ladefahrplans ein Evolutionärer Algorithmus (EA) eingesetzt,welcher in Abschnitt 3.2 bereits beschrieben wurde.Es ist hingegen nicht Ziel dieser Arbeit, den bisherigen Optimierungsalgorithmus auf Basiseines EA sowie seine Umsetzung im globalen Optimierer zu verändern. Vor diesem Hintergrundist die Art der Kodierung, welche eine geeignete Einplanung des E-Fahrzeugs ermöglicht, andie Struktur eines obig beschriebenen Teilproblems gebunden und stellt somit die Basis fürdie Möglichkeiten der Optimierung dar. Konkret bedeutet dies, dass der Genotyp stets inForm eines Bitvektors und bspw. nicht in der Form eines gemischt ganzzahligen Individuumsvorliegen muss. Auch ist die Länge eines Bitvektors zwar generell variabel, jedoch muss zumZeitpunkt der Instanziierung eines Teilproblem-Objekts für das Elektrofahrzeug die Längedieses Bitvektors bekannt gegeben werden.Die Art der Abbildung des Elektrofahrzeug-Genotyps auf dessen Phänotyp sowie dieBetrachtung diverser noch einzuführender Restriktionen stellt in dieser Arbeit die wesentlicheStellschraube bei der Optimierung dar. Die Anzahl der Generationen, die Populationsgröße,die Mutationsrate sowie die Entscheidungsgrundlage, auf Basis derer ein Individuum selektiertwird, haben ebenfalls einen nicht zu vernachlässigenden Einfluss auf das Optimierungsergebnisund werden in Abschnitt 6.2.2 präsentiert.52KAPITEL 4INTEGRATION DES E-FAHRZEUGS IN DASENERGIEMANAGEMENTWährend im vorigen Abschnitt 3.2 die lokale O/C-Einheit als solche eher aus einem generischenBlickwinkel betrachtet wurde, dient dieses Kapitel dazu, sich die konkreten Eigenheiten einerlokalen O/C-Einheit, welche speziell für die Integration des Elektrofahrzeugs in das EMSkonzipiert wurde, näher anzuschauen. Hierbei gilt es, die Komponenten lokaler Observer,lokaler Controller, das spezifische Teilproblem sowie die Austauschobjekte zwischen Treiberund der Observer- bzw. Controller-Einheit detailliert zu beschreiben.Zuvor wird jedoch in Abschnitt 4.1 ein zusammenfassender Überblick über die kommunika-tionstechnische Einbindung des Elektrofahrzeugs in das EMS des Smart Home gegeben. Hiermitwird das Gesamtszenario „Einbindung eines Elektrofahrzeugs in das Energiemanagement einesSmart Home“ aus einer größeren Perspektive heraus anschaulich präsentiert.4.1 Makroskopische Perspektive auf das Smart Home SzenarioIn Abschnitt 2.2.1 wurde bereits erläutert, dass das Kommunikationsprotokoll ISO/IEC 15118nach einem Client-Server-Schema konzipiert ist, in welchem das Elektroauto bzw. der EVCCals Client stets Anfragen an den SECC der Ladestation (Server) stellt, auf welche dieserinnerhalb gewisser Timeout-Fristen antworten muss. In dem dieser Arbeit zugrunde liegendenVersuchsaufbau befindet sich der ISO/IEC 15118 Server nicht in der Ladestation, sondern aufdem Steuerrechner im Smart Home (ESHL), welcher das EMS beherbergt. Daher agiert dieLadestation lediglich als durchleitende Einheit für die relevanten Ladesteuerungsinformationen.Abbildung 4.1 gibt einen Überblick über das Konzept der Einbindung des E-Fahrzeugs in dasEMS des Smart Home und ist im Wesentlichen in drei Bereiche eingeteilt: das Elektrofahrzeug,das Ladeequipment (Ladekabel und Ladestation) sowie das Smart Home.Das ElektrofahrzeugIm Elektrofahrzeug sind diverse Komponenten verbaut, die im Rahmen der Ladesteuerungrelevant werden und sich somit auch in Abbildung 4.1 wiederfinden:• PLA: Der Powerline-Adapter dient dazu, die Datensignale, welche über den ControlPilot (CP) Pin (siehe Abschnitt 2.1.1 und 2.1.2) auf die Ladeleitung aufmoduliert werden,53Kapitel 4 Integration des E-Fahrzeugs in das EnergiemanagementEthernet'ESHL'PLA'PTC'EVCC'PT'CAN'Bus'PLC'OEM$C&Code$Protocol$Buffer$(Übersetzer)$ISO/IEC$15118$Client$Control''Pilot'Ladegeräte'HV;Ba= 2 kW) Ladeleistung für einen Ladevorgang zur Verfügungstehen soll. Wie bereits erwähnt, ist das Fahrzeug technisch dazu in der Lage, mit einerLeistungsbandbreite von 2 bis 11 kW zu laden, jedoch sollte stets eine eventuell einschränkendeBenutzereingabe berücksichtigt werden.Eine mathematische Abbildung dieser Restriktionen wurde bereits in [46] begonnen undsoll im folgenden Abschnitt 4.3.3 aufgegrien werden, um die nötige Korrektur eines vorge-schlagenen Lastprofils formal darstellen zu können.664.3 Das Optimierungs-Teilproblem ElektrofahrzeugTabelle 4.1: Abbildung ISO/IEC 15118-2 Parameter auf formales Modell (erweiterte Parameterdurch Unterstreichung gekennzeichnet)Param Ladeparameter [Einheit] Formale Abbildung1 DepartureTime [s] td Ø 02 EAmount [Wh] E+EV (t) > 03 EAmountDischarge [Wh] E≠EV (t) œ R4 EVMaxCurrent [A] p+EV,max > 05 EVMinCurrent [A] p+EV,min > 06 EVMaxCurrentDischarge [A] p≠EV,max < 07 EVMinCurrentDischarge [A] p≠EV,min < 08 EVSEMaxCurrent [A] p+EV SE,max > 09 EVSEMinCurrent [A] p+EV SE,min > 010 EVSEMaxCurrentDischarge [A] p≠EV SE,max < 011 EVSEMinCurrentDischarge [A] p≠EV SE,min < 012 PMaxSchedule [(s, W)] {(ti, pEV i) | i œ [n]}13 Dauer des letzten Zeitintervalls von PMaxSchedule [s] d > 04.3.3 Formale Darstellung der kodierten Parameter und RestriktionenZur Erstellung eines für das Elektrofahrzeug gültigen Lastprofils bedarf es der Einbeziehungdiverser Parameter aus der (erweiterten7) ISO/IEC 15118-2 Spezifikation, welche in Tabelle4.1 zusammengefasst und auf Variablen für das zu erstellende formale Modell abgebildet sind.Manche der gelisteten Parameter sind unterstrichen, was bedeutet, dass diese noch nichtEinzug in die ISO/IEC 15118-2 Spezifikation gefunden haben, sondern eine projektspezifischeErweiterung der Norm darstellen, um beispielsweise eine Rückspeisung zu ermöglichen. Fürdie Nominalspannung existieren in der ISO/IEC 15118-2 ebenfalls Parameter, welche aberin Tabelle 4.1 nicht aufgeführt sind. Stattdessen wurden Ladestromparameter (mit derEinheit Ampere) gleich den entsprechenden Leistungsparametern zugeordnet, basierend aufder physikalischen Berechnungsvorschrift P = U · I. Sämtliche Parameter werden im Laufedes Abschnitts näher erläutert.TEV = [tp, td] sei definiert als der Zeitraum zwischen dem Verbinden des Elektrofahrzeugsmit der Ladestation (Zeitpunkt tp) und einem benutzerdefinierten Abfahrtszeitpunkt td (sieheParam 1 aus Tabelle 4.1), wobei tp Æ t1 (der Lade- bzw. Rückspeisevorgang kann zeitlichversetzt zum Einstecken des Ladekabels stattfinden) und tn + d Æ td (Batterie kann vor demAbfahrtszeitpunkt bereits voll aufgeladen sein).Das gültige Lastprofil (siehe Param 12) ist gegeben als Funktion über die Zeit bestehendaus Tupeln mit jeweiligen Zeitpunkten ti, die den Beginn eines Zeitintervalls markieren, undden in den jeweiligen Zeitintervallen maximal gültigen Leistungswerten pEV i. Die Länge einesjeweiligen Zeitintervalls mit Beginn ti ist begrenzt durch den Beginn ti+1 des darauolgendenZeitintervalls. Die Länge des letzten Zeitintervalls ist gegeben durch die Zeitdauer d (siehe Pa-ram 13). Der Wert des Index n kann hierbei frei gewählt werden, sodass ein sehr feingranulares7Erweitert im Sinne der Beschreibung aus Abschnitt 4.2, Seite 5767Kapitel 4 Integration des E-Fahrzeugs in das EnergiemanagementLastprofil dem Fahrzeug übermittelt werden kann8.Die Länge eines Zeitintervalls ti mit Beginn ti für alle ti œ TEV , i œ [n] wird somit definiertalsti =I(ti+1 ≠ ti) falls 1 Æ i < n,d falls i = n.(4.1)Die Leistung pEV,i, mit der das Fahrzeug im i-ten Zeitslot laden oder rückspeisen soll, definiertsich u. a. über die Parameter 4 bis 11 aus Tabelle 4.1. Für alle i œ [n] und t œ TEV gilt, dasspEV,i œ [p≠max(t), p≠min] fi {0} fi [p+min, p+max(t)], (4.2)wobeip≠min = max(p≠EV,min, p≠EV SE,min), (4.3)p≠max(t) = min(p≠EV,max, p≠EV SE,max, p≠GRID,max(t)), (4.4)p+min = max(p+EV,min, p+EV SE,min), und (4.5)p+max(t) = min(p+EV,max, p+EV SE,max, p+GRID,max(t)). (4.6)p≠EV,max und p≠EV SE,max stehen für die maximal mögliche Rückspeiseleistung des Fahrzeugs(EV) beziehungsweise der Ladestation (EVSE), im Gegensatz zur max-Funktion aus (4.3) und(4.5). Die Werte für p≠EV,min und p≠EV SE,min sind entsprechend zu interpretieren.p+GRID,max(t) und p≠GRID,max(t) stehen hierbei für netzseitig vorgegebene Leistungsgrenzenfür das Laden (+) respektive Rückspeisen (-) von Energie. Wie in Abschnitt 3.2 bereitseingeführt, werden in die Optimierung des Gesamtlastprofils auch Lastbegrenzungssignalemit eingebunden. Genau genommen handelt es sich hier aber nicht um harte Lastgrenzen,die keinesfalls überschritten werden dürfen, ohne dass es zu einem Lastabwurf kommt, son-dern um weiche Lastgrenzen, deren Überschreitung lediglich erhebliche Strafkosten bei derFitnessbewertung eines Individuums nach sich ziehen.EEV (t) sei definiert als die zu jedem Zeitpunkt ti œ TEV in der Batterie gespeicherte Energie.Die initialen Werte für die vom Fahrzeug benötigte Energiemenge E+EV (tp) (siehe Param 2)und die zur Rückspeisung zur Verfügung stehende Energiemenge E≠EV (tp) (siehe Param 3)verändern sich über die Zeit wie in (4.7) und (4.8) dargestellt. Sei k der größte Index, sodasstp Æ tk Æ t Æ td, dann gilt:E+EV (t) = E+EV (tp) ≠k≠1ÿi=1(pEV,i · ti) (4.7)≠ pEV,k · (t ≠ tk)E≠EV (t) = E≠EV (tp) +k≠1ÿi=1(pEV,i · ti) (4.8)+ pEV,k · (t ≠ tk)Hierbei können die pEV,i sowohl positive (laden) als auch negative (rückspeisen) Leistungs-werte annehmen. Auch pEV,k kann theoretisch beide Vorzeichen annehmen, es ist jedoch8Laut der oziellen ISO/IEC 15118-2 Spezifikation ist die Anzahl der Tupel auf den Wert 1024 begrenzt.684.3 Das Optimierungs-Teilproblem Elektrofahrzeugdavon auszugehen, dass in der Regel das letzte Intervall des Lastprofils einen Ladevorgangwiderspiegelt, um die Batterie des Fahrzeugs zum Abfahrtszeitpunkt hin vollzuladen.Capat sei definiert als die vom Fahrer nutzbare Kapazität einer vollgeladenen Batterie9,Capap als die aktuell zur Verfügung stehende Kapazität zum Zeitpunkt tp und Capau alsdie benutzerdefinierte Mindestkapazität10, welche direkt die rückspeisefähige Energiemenge(Param 3) beeinflusst. Die zum Zeitpunkt tp benötigte Energiemenge lässt sich somit auchausdrücken alsE+EV (tp) = Capat ≠ Capap + –, (4.9)die rückspeisefähige Energiemenge hingegen alsE≠EV (tp) = Capap ≠ Capau ≠ –. (4.10)Die Variable – œ R bezeichnet hierbei die zusätzliche Energie, welche durch die Nebenverbrau-cher und den Wirkungsgrad des Wechselrichters (< 100%) benötigt wird. Ein positiver Wertfür E≠EV (t) reflektiert die zur Rückspeisung zur Verfügung stehende Energiemenge, wohingegenein negativer Wert einen sofortigen Ladebedarf signalisiert, bis die Energie zur Erreichung dervorgegebenen Mindestreichweite geladen wurde. E+EV (t) hingegen ist stets ein positiver Wert.Abbildungen 4.2 und 4.3 dienen zur Veranschaulichung der diversen Kapazitäts- und Ener-giekennwerte. Da bei Abbildung 4.2 der Ladezustand der Batterie zum Zeitpunkt tp bei 28%Abbildung 4.2: Kapazitäts- und Energiekennwerte zum Zeitpunkt tp: Beispiel mit negativemE≠EV (tp)liegt und der Nutzer eine Mindestreichweite vorgegeben hat, die 50% der gesamten nutzba-ren Batteriekapazität entspricht, muss sofort ein Ladeprozess mit der maximal verfügbarenLeistung initialisiert werden, bis Capap Ø Capau und der negative E≠EV (tp) Wert somit einenpositiven Wert erreicht. In Abbildung 4.3 hingegen liegt der Ladezustand zum Zeitpunkt tpbei 70%, ist somit größer als der eingestellte Mindestladezustand mit 40% und ermöglicht diesofortige flexible Einplanung des Fahrzeugs.9Es wird von Seiten des Batterieherstellers stets zwischen der Gesamtkapazität einer Traktionsbatterie undder für den Nutzer des Fahrzeugs zur Verfügung stehenden Batteriekapazität unterschieden. Letztere iststets geringer als die Gesamtkapazität, um schädigende Tiefenentladungen oder zu hohe Ladezustände zuvermeiden und so eine lange Lebensdauer der Batterie zu garantieren.10Die Benutzungsschnittstelle im Elektrofahrzeug bietet die Angabe eines minimalen SOC (Batterieladezustandin Prozent), das EMP ermöglicht die Angabe einer Mindestreichweite in km. Beide Werte können jedochunter Einbeziehung der fahrzeugspezifischen Batteriekapazität in kWh-Werte und somit Capau umgerechnetwerden.69Kapitel 4 Integration des E-Fahrzeugs in das EnergiemanagementAbbildung 4.3: Kapazitäts- und Energiekennwerte zum Zeitpunkt tp: Bespiel mit positivemE≠EV (tp)Die Restriktionen, welche bei der Korrektur eines vom globalen Controller vorgeschlagenenLastprofils – resultierend aus der Genotyp-Phänotyp-Abbildung des evolvierten Bitvektors –beachtet werden müssen, sind in den Formeln (4.3) bis (4.6) sowie (4.11) bis (4.15) dargestellt.0 Æ E+EV (t) Æ Capat + –, (4.11)E+EV (td) = 0, (4.12)EEV (tm) ≠ (EEV (tm) ≠ Capau) Æ EEV (ts), (4.13)Capat > 0, (4.14)Capau, Capap Ø 0. (4.15)Restriktion (4.11) besagt, dass die benötigte Energiemenge (Param 2) niemals die Kapazitätder Batterie samt benötigter Energie für die Nebenverbraucher übersteigt. Somit kann dieinsgesamt über TEV hinweg geladene Energiemenge – nach Abzug der rückgespeisten Energie-menge – diese Grenze nie überschreiten. Zum Abfahrtszeitpunkt td muss das Elektrofahrzeugeine vollständig geladene Batterie aufweisen11, was durch (4.12) zum Ausdruck gebracht wird.Zeit%t%tp%tm%Verbindung%EV%mit%EVSE%Mindestreichweite%geladen%td%Geplante%Abfahrt%flexibles%Scheduling%für%Zeitpunkte%ts%Abbildung 4.4: Übersicht über die Zeitpunkte tp, tm, ts und tdWie bereits erwähnt, muss nach Verbinden des E-Fahrzeugs mit der Ladestation sofort einLadevorgang starten, falls die noch gespeicherte Energiemenge nicht zur Zurücklegung derMindestreichweite ausreicht. Diese für die Mindestreichweite evtl. noch benötigte Energiemenge11Theoretisch könnte dem Fahrer auch ein geringerer Ladezustand zum Abfahrtszeitpunkt genügen, dies wurdejedoch im Rahmen der Projektdurchführung und Evaluation nicht berücksichtigt.704.3 Das Optimierungs-Teilproblem Elektrofahrzeugsei mit EEV (tm) (m für Mindestreichweite) gekennzeichnet, wobei tp Æ tm Æ ts Æ td gilt. Hathingegen das Fahrzeug bereits zu Beginn tp die nötige Energiemenge gespeichert, so kann einflexibles Scheduling zu den Zeiten ts (s für Scheduling) stattfinden. Jedoch ist bei der flexiblenEinplanung stets zu beachten, dass bei einem Rückspeisevorgang die im Fahrzeug gespeicherteEnergiemenge niemals EEV (tm) unterschreitet, wie in (4.13) beschrieben. Der Zusammenhangzwischen den diversen Zeitpunkten ist in Abbildung 4.4 noch einmal klar herausgestellt.Letzten Endes dürfen gemäß (4.14) und (4.15) die Kapazitätswerte nicht negativ sein.4.3.4 Beispiel der Korrektur eines Bitvektors im TeilproblemUm die nötigen Korrekturmechanismen innerhalb eines Teilproblems anschaulicher zu illus-trieren, soll an dieser Stelle ein fiktives Beispiel herangezogen werden. Es seien folgende Wertezum Zeitpunkt tp gegeben:• Anschlusszeitpunkt tp = 17:15• Geplanter Abfahrtszeitpunkt td = 19:30• Batteriekapazität Capat = 12 kWh• SOC = 20 % ( ‚= 2,4 kWh)• Benötigte Energiemenge E+EV (tp) = 9,6 kWh• Mindestreichweite (in % SOC) = 40 % ( ‚= 4,8 kWh Capau)• Rückspeisefähige Energiemenge E≠EV (tp) = -2,4 kWh• Maximale Ladeleistung p+max = 11 kW• Minimale Ladeleistung p+min = 2 kW• Maximale Rückspeiseleistung p≠max = -4,2 kW• Minimale Rückspeiseleistung p≠min = -1,2 kWAus den Ausgangsdaten geht hervor, dass zum Zeitpunkt tp ein sofortiger Ladevorgangunabdingbar ist, um die -2,4 kWh auszugleichen und somit die Mindestreichweite so schnellwie möglich gewährleisten zu können. Da zu Beginn das Fahrzeug also nicht flexibel vom EMSeinplanbar ist, fließt die Zeitspanne, in der die Batterie konstant mit 11 kW geladen werdenmuss, nicht in die Länge des Bitvektors mit ein. Dies bedeutet, dass dem globalen Observer zuBeginn ein statisches Lastprofil kommuniziert wird, auf Basis dessen nach (4.16) aufgerundet14 Minuten lang mit 11 kW geladen werden muss.2400 Wh = (11000 W ◊ x min ◊ 60 s/min) ÷ 3600 s (4.16)x min = (2400 Wh ◊ 3600 s) ÷ (11000 W ◊ 60 s)x = 13, 09 minIst diese Zeitspanne abgelaufen, wird dem globalen Observer ein neues Teilproblem kom-muniziert. Wählt man nun wie in Abschnitt 4.3.1 beschrieben den Ansatz, 14 verschiedeneLeistungsstufen mit 4 Bits zu kodieren, entscheidet sich aber für ein minimales Zeitintervallvon 15 Minuten, so ergibt sich für das Teilproblem Elektroauto ein Bitvektor der Länge71Kapitel 4 Integration des E-Fahrzeugs in das Energiemanagement4 Bits pro Intervall ◊ 4 Intervalle pro Stunde ◊ 2 Stunden = 32 Bits.Ein erster Ansatz für die Abbildung eines 4-Bit-Strings auf reale Leistungswerte könnte wiein Tabelle 4.2 aussehen.Tabelle 4.2: Abbildung eines Bitvektors der Länge vier auf Leistungswerte [kW]Bitvektor Leistung [kW] Bitvektor Leistung [kW]0000 -4,2 1000 50001 -2,5 1001 60010 -1,2 1010 70011 0 1011 80100 1 1100 90101 2 1101 100110 3 1110 110111 4 1111 0Anhand der Abbildung 4.5 wird der Zusammenhang zwischen einem Bitvektor (demGenotyp) und der resultierenden Lastkurve (dem Phänotyp) nach Anwendung der Tabelle 4.2grafisch dargestellt und der Korrekturmechanismus gemäß der bereits erwähnten Restriktionenerläutert. Nach dem initialen Ladevorgang zur Gewährleistung der Mindestreichweite ist nunder Energiegehalt von 2,4 kWh + 2,567 kWh = 4,967 kWh in der Batterie gespeichert. DerKorrekturmechanismus läuft nun in zwei Stufen ab.1. Überprüfe für jedes Zeitintervall, ob die jeweilige mit vier Bits kodierte Leistungsanfor-derunga) zu einer Unterschreitung der für die Mindestreichweite nötigen Energiemenge oderb) zu einer Überladung der Batterieführen würde. Falls einer der beiden Fälle eintritt, überprüfe, ob eine kleinere Rückspeise-bzw. Ladestufe die jeweilige Restriktion nicht verletzt und wähle diese Leistungsstufe fürdas konkrete Zeitintervall. Falls keine alternative Leistungsstufe gewählt werden kann,dann lege eine Ladepause mit 0 kW ein.2. Sobald der Genotyp einmal abgearbeitet wurde, überprüfe, ob die Batterie zum Ab-fahrtszeitpunkt nicht vollgeladen sein würde und korrigiere die Leistungsanforderungenpro Zeitintervall entsprechend. Hierbei ist eine gangbare Methode, die Leistungswertevon der Abfahrtszeit aus chronologisch rückwärts gehend nach oben zu korrigieren, umgemäß der weichen Restriktionen eine vorzeitige Vollladung der Batterie zu vermeiden.Das Ergebnis dieses Korrekturmechanismus’ kann im folgenden zeitlichen Ablauf nachverfolgtwerden.17:30 -4,2 kW ‚= -1050 Wh æ unterschreitet Mindestreichweite∆ da -1,2 kW ebenfalls nicht zulässig, keine Rückspeisung (Energielevel = 4,967 kWh)17:46 0 kW ‚= 0 Wh æ keine Restriktionsverletzung, Restzeit ausreichend zum Volladen∆ keine Aktion (Energielevel = 4,967 kWh)724.3 Das Optimierungs-Teilproblem Elektrofahrzeug0"0"0"0" 0"0"1"1" 0"1"1"0" 0"0"0"0" 1"1"1"0" 0"0"0"1" 0"0"0"1" 1"1"1"0"t"17:30" 17:46" 18:01" 18:16" 18:31" 18:46" 19:01" 19:16",4,2"kW" 0"kW" 3"kW" ,4,2"kW" 11"kW" ,2,5"kW" ,2,5"kW" 11"kW"17:30" 17:46" 18:01" 18:16" 18:31" 18:46" 19:01" 19:16"t"P"[kW]" Phänotyp)1"3"5"7"9"11",1,2",2,5",4,2"Genotyp)Genotyp,Phänotyp,Abbildung)mit)Korrekturmechanismus))Abbildung 4.5: Korrekturmechanismus bei der Genotyp-Phänotyp-Abbildung im Teilproblem18:01 3 kW ‚= 750 Wh æ keine Restriktionsverletzung, Restzeit ausreichend zum Volladen∆ laden mit 3 kW (Energielevel = 5,717 kWh)18:16 -4,2 kW ‚= -1050 Wh æ unterschreitet Mindestreichweite∆ rückspeisen mit niedrigerer Stufe -2,5 kW ‚= -625 Wh (Energielevel = 5,092 kWh)18:31 11 kW ‚= 2750 Wh æ keine Restriktionsverletzung, Restzeit ausreichend zum Volladen∆ laden mit 11 kW (Energielevel = 7,842 kWh)18:46 -2,5 kW ‚= -625 Wh æ keine Restriktionsverletzung, Restzeit ausreichend zum Volladen∆ rückspeisen mit -2,5 kW (Energielevel = 7,217 kWh)19:01 -2,5 kW ‚= -625 Wh æ Restzeit (ab 19:16) zum Volladen würde nicht ausreichen∆ laden mit 8,135 kW ‚= 2033 Wh (Energielevel = 9,25 kWh)19:16 11 kW ‚= 2750 Wh æ benötigte Energiemenge kann vollständig geladen werden∆ laden mit 11 kW (Energielevel = 12 kWh)19:30 Geplanter Abfahrtszeitpunkt erreicht, Batterie vollständig aufgeladenIn Abbildung 4.5 ist das Ergebnis der Genotyp-Phänotyp-Abbildung an der gestricheltenblauen Lastkurve abzulesen, während die korrigierte Lastkurve, die eine den Restriktionenentsprechend gültige Lösung liefert, als orangefarbene durchgezogene Linie dargestellt ist.73Kapitel 4 Integration des E-Fahrzeugs in das EnergiemanagementLetzten Endes wird nach der Genotyp-Phänotyp-Abbildung und Durchführung der Korrek-turmechanismen das vom evolutionären Algorithmus vorgeschlagene Teilindividuum (welchessich auf das E-Fahrzeug bezieht), also der Genotyp, in seiner Struktur nicht modifiziertund fließt somit unverändert in die nächste Generation an möglichen Lösungen mit ein. DieSelektion des Individuums für die nächste Population hängt allein von seiner Fitness ab, waseine Ähnlichkeit zum sogenannten Baldwin-Lerneekt darstellt.Der Wert der Fitness errechnet sich bei einer Stromkosten-basierten Optimierungsfunktiondurch die simple Multiplikation der resultierenden Lastkurve mit dem Strompreis und Ad-dition von Strafkosten für die Überschreitung einer optionalen Lastbegrenzungskurve sowieder Addition von Bewertungsfaktoren wie der Verletzung weicher und harter Restriktio-nen das Elektrofahrzeug betreend. Eine mathematische Darstellung der entsprechendenBewertungsfunktion ist [3], Abschnitt 5.2 zu entnehmen.4.3.5 Die Wahl einer geeigneten Bitvektor-RepräsentationDie in Tabelle 4.2 vorgestellte Abbildung eines 4-Bit Bitvektors auf Leistungswerte ist einevon mehreren Möglichkeiten, die, wie sich zeigt, nach Anwendung der obig beschriebenenKorrekturen sehr unterschiedliche Auswirkungen auf das vom evolutionären Algorithmus alsLösung präsentierte Lastprofil des Elektrofahrzeugs haben. Beispielsweise haben Beobachtun-gen gezeigt, dass die im Verhältnis zu den positiven Leistungsstufen ohnehin zahlenmäßigunterrepräsentierten Rückspeisestufen mit dieser Abbildung seltener zum Einsatz kommen alsmit einer Abbildung, bei der für negative Leistungswerte nicht die beiden höchstwertigstenBits des 4-Bit Bitvektors auf 0 gesetzt sein müssen. Tabelle 4.3 verdeutlicht bezogen auf dieRückspeisestufen eine solche alternative Abbildung, wobei hier die Stufe -2,5 kW doppelt zumEinsatz kommt.Tabelle 4.3: Modifizierte Abbildung eines 4-Bit-Strings auf negative LeistungswerteBitvektor Leistung [kW]1000 -4,20100 -2,50010 -2,50001 -1,2Eine solche binäre Kodierung und Abbildung des Bitvektors auf reale Leistungswertebringt jedoch Probleme hinsichtlich der sogenannten Hamming-Klippe mit sich [58]. EineHamming-Klippe beschreibt den Eekt, dass benachbarte Phänotypen (mit einer Distanz von1) durch völlig voneinander verschiedene Genotypen repräsentiert werden, deren Nachbarschaftweit größer als 1 ist. Als erläuterndes Beispiel sollen die Werte aus Tabelle 4.2 dienen: DerLeistungswert (Phänotyp) 4 kW unterscheidet sich vom Leistungswert 5 kW durch eine Distanzvon 1 kW. Deren jeweilige genotypische Repräsentation 0111 (für 4 kW) und 1000 (für 5 kW)unterscheiden sich jedoch in allen 4 Bits voneinander, was eine Hamming-Distanz von 4ergibt. Umgekehrt betrachtet würde das Kippen des niedrigwertigsten Bits des Bitvektors1110, welcher 11 kW repräsentiert, zum Bitvektor 1111 führen, welcher nach der vorgestelltenAbbildung 0 kW entspricht und somit eine Hamming-Klippe mit einer Distanz von 11 in sichbirgt.744.3 Das Optimierungs-Teilproblem ElektrofahrzeugDieses Phänomen ist vor allem für solche evolutionäre Verfahren problematisch, welche einemutationsbasierte Suche nach einer optimalen Lösung verwenden, bei der ein Genotyp durchdas Flippen einzelner Bits mutiert wird, da hier eine höhere Gefahr besteht, sich in lokalenMinima zu verfangen [58] [15].Um das Problem einer Hamming-Klippe zu umgehen, wurde die sogenannte Gray-Kodierungentwickelt, bei der die Hamming-Distanz zwischen zwei Genotypen, deren phänotypischeRepräsentation sich durch 1 unterscheidet, auch stets 1 beträgt. Eine binäre Kodierung lässtsich durch eine einfache Abbildungsvorschrift auf die Gray-Kodierung abbilden und umgekehrt,die Anzahl der Bits bleibt identisch. Folglich muss für die Abbildung eines 4-Bit-Bitvektorsauf entsprechende Leistungswerte eine Abbildungsvorschrift gemäß Tabelle 4.4 zum Einsatzkommen.Tabelle 4.4: Abbildung eines 4-Bit-Strings auf Leistungswerte mittels Gray-KodierungBitvektor Leistung [kW] Bitvektor Leistung [kW]0000 0 1100 80001 0 1101 90011 2 1111 100010 3 1110 110110 4 1010 -4,20111 5 1011 -2,50101 6 1001 -1,20100 7 1000 0Auch hier ergibt sich wieder der Fall, dass sich für Rückspeisestufen das Muster „10“ für diebeiden höchstwertigsten Bits des 4-Bit-Bitvektors ergeben muss, jedoch wird dies zugunstender Überwindung der Hamming-Klippe in Kauf genommen. Der Leistungswert 1 kW wird hieraufgrund der technischen Restriktion durch das gegebene Elektrofahrzeug auf 0 kW abgebildet.Man hätte hierfür auch bspw. den Wert 2 kW wählen können.Experimentelle Untersuchungen haben darüber hinaus die Vermutung bestätigt, dass dieseKodierung immer noch einen weiteren Eekt mit sich bringt: das Verhältnis von Rückspeise-zu den restlichen Aktionen (laden oder Ladepause einlegen) entspricht 3 : 16. Dies bedeutet,dass statistisch gesehen in fast jedem vierten Intervall eine Rückspeiseaktion durchgeführtwerden soll. Damit in nur zur aktuellen Hauslast passenden Momenten Energie rückgespeistwird (siehe weiche Restriktion „Sinnvolle Rückspeisung“), muss die Rückspeisung entsprechendfür den globalen Optimierer mit Strafkosten versehen werden. Treten die Rückspeisevorgängejedoch verhältnismäßig häufig auf, so müssten die Strafkosten extrem hoch angesetzt werden,um diese eher selten benötigten Vorgänge einzuschränken. Dies würde jedoch wiederum dieWahrscheinlichkeit, dass einmal sinnvoll Energie rückgespeist wird, evtl. verringern.Um diesem Eekt zu begegnen, könnte man beispielhaft fünf statt vier Bits für die Kodierungder Leistungswerte nutzen, um das Verhältnis auf 3 : 32 zu heben. Die zusätzlichen 16Werte könnten bspw. alle auf 0 kW (Ladepause) oder einigermaßen gleichverteilt auf dieübrigen Ladezustände verteilt werden, wobei bei der Verteilung stets die Hamming-Klippe zubeachten ist. So würde eine Abbildung eines 5-Bit-Bitvektors auf entsprechende Leistungswerte75Kapitel 4 Integration des E-Fahrzeugs in das Energiemanagementbspw. gemäß Tabelle 4.5 aussehen. Durch die Abbildung aller zusätzlichen 16 Werte auf denLeistungswert 0 kW würde das E-Fahrzeug nicht zu übermäßig vielen Ladevorgängen animiertund darüber hinaus auch einer Oszillation entgegengewirkt.Zieht man jedoch in Erwägung, wie in Abschnitt 4.3.1, Seite 60 beschrieben, das zurVerfügung stehende Optimierungszeitfenster in mehrere kleinere Fenster zu unterteilen, umden Bitvektor klein zu halten, so könnte sich eine solche 5-Bit-Kodierung aufgrund einesLadepausenanteils von über 50 % wieder negativ auswirken. Eine Evaluation dieses Aspektsist entsprechend Abschnitt 6.2 zu entnehmen.Ein weiterer Nebeneekt dieser Kodierung ist selbstverständlich die Vergrößerung desSuchraums durch das zusätzliche Bit pro Zeitintervall.Tabelle 4.5: Abbildung eines 5-Bit-Bitvektors auf Leistungswerte mittels Gray-KodierungBitvektor P [kW] Bitvektor P [kW] Bitvektor P [kW] Bitvektor P [kW]00000 0 01100 8 11000 0 10100 000001 0 01101 9 11001 0 10101 000011 2 01111 10 11011 0 10111 000010 3 01110 11 11010 0 10110 000110 4 01010 -4,2 11110 0 10010 000111 5 01011 -2,5 11111 0 10011 000101 6 01001 -1,2 11101 0 10001 000100 7 01000 0 11100 0 10000 04.3.6 Berücksichtigung der Ladecharakteristik einer Lithium-Ionen-BatterieFür die flexible Einplanung des Elektrofahrzeugs als Energiespeicher wie auch Verbraucherwurde in den bisherigen Abschnitten davon ausgegangen, dass die Batterie exakt gemäß demvom Gesamtenergiemanagement überlieferten Lastprofil geladen werden kann. Kurz vor demAbfahrtszeitpunkt sollte die Batterie unter Berücksichtigung der vorgestellten Restriktionenbereits fast vollständig geladen sein. Bei einem hohen Ladezustand (bspw. > 90%) kann einLadevorgang jedoch nicht mit der maximal verfügbaren Leistung von 11 kW durchgeführtwerden (wie in Abbildung 4.5 dargestellt). Dieses Modell muss daher bzgl. der spezifischenLadecharakteristik einer Lithium-Ionen-Batterie präzisiert werden, wonach sich deren Lade-prozess in zwei Phasen einteilen lässt: eine Konstantstromphase (Constant Current – CC)und eine Konstantspannungsphase (Constant Voltage – CV). Man spricht hierbei auch vomCC-CV-Ladeverfahren.Das Ladegerät ist die Komponente im Elektrofahrzeug, welche den Ladestrom regelt undwiederum vom Batteriemanagementsystem in Abhängigkeit von Messdaten der Zell- undModulspannungen gesteuert wird. Abbildung 4.6 gibt einen Überblick über die KomponentenLadegerät, Batterie und Batteriemanagementsystem und illustriert deren Interaktion. DieAuswirkung des CC-CV-Ladeverfahrens auf den Stromfluss sowie den Zellspannungsverlauf inder Batterie wird anhand der Abbildung 4.7 deutlich, welche einen ungesteuerten Ladevorgangdarstellt.764.3 Das Optimierungs-Teilproblem ElektrofahrzeugLadegerät Batterie Batteriemanagementsystem Steuerung Messungen Abbildung 4.6: Zusammenhang der Kom-ponenten Ladegerät, Bat-terie und Batteriemanage-mentsystem [63]U I Zeit Strom Zellspannung Ladezustand Abbildung 4.7: Strom- und Zellspan-nungsverlauf beim CC-CV-Ladeverfahren [63]Die KonstantstromphaseIn der Konstantstromphase wird mit einem konstant vorgegebenen Ladestrom I so langegeladen, bis ein vom Batteriehersteller vordefinierter Spannungsschwellenwert erreicht ist.Charakteristisch für jede Art von Batterie ist, dass deren interne Zellspannung über die Zeitmit dem Ladestrom steigt. Der Ladeprozess lässt sich lediglich in der Konstantstromphasebeliebig vom EMS steuern.Die KonstantspannungsphaseIst der Spannungsschwellenwert (auch Ladeschlussspannung genannt) erreicht, so wird dieZellspannung auf konstantem Niveau gehalten, indem der Ladestrom sukzessive reduziertwird. Wie Abbildung 4.7 zu entnehmen ist, geschieht diese Reduktion in exponentiellemMaße. Der Ladevorgang wird beendet, sobald eine ebenfalls vom Batteriehersteller festgelegteminimale Stromstärke unterschritten wird. Die Dauer der CV-Phase nimmt etwa so viel Zeitin Anspruch, wie das Laden in der CC-Phase. Die Konstantspannungsphase dient dazu, dieeinzelnen Batteriezellen gänzlich zu füllen, ohne Gefahr zu laufen, diese durch einen zu hohenLadestrom zu überladen. Eine Analogie zum Wasserhahn ist hier dienlich: hier dreht manam Ende den Wasserhahn weiter zu, will man ein Glas komplett mit Wasser füllen, ohne esjedoch zum Überlaufen zu bringen.Der Zeitpunkt des Übergangs von der CC- zur CV-Phase hängt von drei Einflussfaktorenab:1. Ladezustand zu Beginn des Ladevorgangs (Start-SOC)2. Ladestromstärke während der CC-Phase3. BatterietemperaturAbbildung 4.8 vergleicht den Beginn der CV-Phase dreier Ladevorgänge des in Abschnitt3.1 beschriebenen Elektrofahrzeugs in Abhängigkeit verschiedener Batterietemperaturen beiähnlicher Leistung in der CC-Phase und gleichem initialen Ladezustand von 59 %. Hier istdeutlich zu erkennen, dass mit geringerer Batterietemperatur sich der Beginn der CV-Phase77Kapitel 4 Integration des E-Fahrzeugs in das Energiemanagementnach vorne verlegt und somit die Dauer der flexiblen Ladesteuerung verkürzt. Dies bedeutetim Umkehrschluss, dass in den kalten Wintertagen die Flexibilität der Ladesteuerung imVergleich zu warmen Sommertagen abnimmt.Abbildung 4.9 veranschaulicht den Einfluss unterschiedlicher Ladeleistungen auf den Über-gangszeitpunkt von der CC- zur CV-Phase und macht deutlich, dass mit einer höherenLadeleistung die Ladeschlussspannung auch früher erreicht wird. 0 2 4 6 8 10 12 65 70 75 80 85 90 Eingangsleistung P [kW] SOC [%] T = 17°C T = 14,5°C T = 8,5°C Abbildung 4.8: Verlauf dreier Ladevorgän-ge mit ähnlicher Leistungin der CC-Phase und Start-SOC 59 % [63] 0 2 4 6 8 10 12 70 75 80 85 90 95 Eingangsleistung P [kW] SOC [%] T = 22,5°C T = 25°C Abbildung 4.9: Verlauf zweier Ladevorgän-ge mit ähnlicher Tempera-tur und Start-SOC 50 %[63]Die Analyse der fahrzeuginternen Kenndaten des im Versuchsaufbau eingesetzten Elektro-fahrzeugs führt zu dem Schluss, dass der Übergang von der CC- zur CV-Phase zwischen denbeiden SOC-Werten 68 % und 90 % schwankt und einen Mittelwert von ca. 83 % aufweist.Angenommen, das vom globalen Controller überlieferte Lastprofil für das Elektroauto wür-de vorsehen, dass die Batterie für die Dauer der Konstantspannungsphase mit maximalerLeistung lädt, bspw. weil die PV-Anlage des Smart Home sehr viel Strom erzeugt und derStrompreis aufgrund geringer Last im Netz sehr gering ist, dann würde eine recht hohePrognoseunsicherheit bzgl. der tatsächlich vom Fahrzeug induzierten Last entstehen.Grob gesprochen würde dann etwas mehr als die Hälfte der als Last eingeplanten Energie-menge nicht abgerufen werden, wie anhand Abbildung 4.7 abgelesen werden kann. Gleicheswird mit einem spezifischen Beispiel in Abbildung 4.10 dargestellt. Dies würde im schlechtestenFalle also dazu führen, dass die Hälfte der Energie, die in der CV-Phase benötigt würde, zumAbfahrtszeitpunkt nicht geladen wäre.Laut der ISO/IEC 15118-2 Spezifikation reagiert das Elektrofahrzeug mittels der Power-DeliveryReq Nachricht auf ein von der Ladestation vorgeschlagenes Lastprofil entweder miteiner Bestätigung desselben Profils oder mit einer Modifikation nach Korrektur durch dasBMS. Somit ließe sich anhand der Abweichung vom vorgeschlagenen Profil der Beginn derKonstantspannungsphase ablesen. Dies setzt jedoch eine implementierte Schnittstelle zumBMS voraus, welche im vorliegenden Versuchsaufbau nicht zur Verfügung stand. Daher wirddas Delta der Energiemenge, welche in der CV-Phase nicht mit 11 kW geladen werden kann,approximiert und entsprechend dem Teilproblem übermittelt, damit dieses Verhalten geeignetberücksichtigt werden kann.784.4 Der lokale Controller 0 50 100 150 200 250 300 0 10 20 30 40 50 60 18:06:29 18:30:43 18:54:58 19:19:12 V A, kW Zeit Eingangsstrom Eingangsleistung Eingangsspannung 0 10 20 30 40 50 60 1 648 1295 1942 2589 3236 3883 Eingangsspannung U [V] Eingangsstrom I [A] Eingangsleistung P [kW] Zeit [s] Eingangsstrom Eingangsleistung Eingangsspannung Abbildung 4.10: Beispielhafter Verlauf von Eingangsstrom, -Spannung und -Leistung währendeines ungesteuerten dreiphasigen Ladevorgangs mit durchschnittlich 10 kW[63]4.4 Der lokale ControllerAufgabe eines lokalen Controllers ist es allgemein, die vom Gesamtenergiemanagement durchden globalen Controller übermittelten Anweisungen in für die entsprechende Haushaltskompo-nente verständliche Befehle und Informationen zu übersetzen und diese Übersetzung durchdie Hardware-Abstraktions-Schicht an den Treiber zu senden. Im Falle des Elektrofahrzeugskann die Anweisung entweder ein statisches oder ein dynamisches Lastprofil repräsentieren.Das statische Lastprofil leitet das Elektrofahrzeug dazu an, einen sofortigen Ladevorgangmit maximal verfügbarer Leistung zu starten, um schnellstmöglich die benutzerdefinierteMindestreichweite zurücklegen zu können. Das dynamische Lastprofil entspricht dem Phänotyp,welcher nach Anwendung der beschriebenen Korrekturmechanismen als gültiges Lastprofil füreine flexible Einplanung des E-Fahrzeugs übermittelt wurde. Der lokale Controller muss dasüber das Registrar kommunizierte Datenobjekt nun daraufhin überprüfen und ein einheitlichesLastprofil-Datenobjekt (ECarControllerExchange) an den ISO/IEC 15118-Treiber senden.4.5 Der ISO/IEC 15118-2 TreiberDer Treiber hat u. a. die Aufgabe, sowohl die initialen Ladeparameter, welche über die Charge-ParameterDiscoveryReq Nachricht eintreen, als auch die mittels der ChargingStatusReqNachricht gesendeten Aktualisierungen (vgl. Abschnitt 4.2, Seite 57) an den lokalen Observerim gekapselten Datenobjekt CarDetails zu übermitteln. Darüber hinaus muss dem Observermitgeteilt werden, sobald das E-Fahrzeug nicht mehr mit der Ladestation verbunden ist undsomit auch nicht mehr zur Einplanung für das Energiemanagement bereit steht.79Kapitel 4 Integration des E-Fahrzeugs in das EnergiemanagementEs kann der Fall eintreten, dass das E-Fahrzeug zwar physisch mit der Ladestation verbundenist, aber keine aktive Ladesession vorliegt, aufgrund der Lastsituation im Smart Home jedochsofort mit dem Laden oder Rückspeisen von Energie begonnen werden sollte. Eine Ladesessionkann durch einen Fehler in der Ladekommunikation (z. B. Störung der Ethernet-Verbindungoder der Kommunikation mit dem Ladesteuergerät) oder schlichtweg durch eine geplanteLadepause beendet werden. In beiden Fällen muss der Treiber dafür sorgen, dass das E-Fahrzeug eine erneute Ladesession aufbaut, im Rahmen derer das gewünschte Ladeprofilmitgeteilt werden kann. Dies kann bspw. dadurch geschehen, dass das PWM-Modul kurzfristigein anderes Signal als 5 % (siehe Abschnitt 2.1.2) anlegt, was den Ladecontroller dazu veranlasst,wieder aufzuwachen und eine neue Ladesession zu starten.In entgegengesetzter Richtung hat der Treiber die Aufgabe, das vom lokalen Controllerempfangene Lastprofil in einen passenden Datentyp gemäß der ISO/IEC 15118-2 Spezifikationzu übersetzen.Der vom lokalen Controller übermittelte Datentyp ECarControllerExchange beinhaltetden Datentyp ECarChargeSchedule, welcher wiederum aus einer Liste von ECarCharge-ScheduleEntry-Tupeln besteht. Diese Tupel setzen sich gemäß der formalen Darstellung ausAbschnitt 4.3.3 aus dem Start eines Intervalls ti sowie der Leistung pEV,i, mit welcher indiesem Intervall geladen oder rückgespeist werden soll, zusammen.Der ISO/IEC 15118-2 Parameter PMaxSchedule (siehe Param 12 aus Tabelle 4.1) ist eingutes Beispiel dafür, wie verschachtelt und komplex aufgebaut die Datentypen dieser Normsich oftmals präsentieren. Eine Aufschlüsselung des Parameters ist Tabelle 4.6 zu entnehmen.Tabelle 4.6: Verschachtelung des Datentypen PMaxScheduleParameter/Typ vom Typ enthältPMaxSchedule PMaxScheduleTypePMaxScheduleType RelativeTimeIntervalPMaxRelativeTimeInterval TimeInterval (abstrakt) startdurationPMax PhysicalValueTypePhysicalValueType MultiplierUnitValuestart Integerduration IntegerMultiplier ByteUnit Enumeration (z. B. V, A, Wh)Value ShortDer Parameter duration ist ein optionaler, da dieser nur für das letzte Zeitintervall genutztwird, um die Dauer des letzten Lade-/Rückspeisevorgangs zu bemessen. Die Zeitwerte werdenjeweils als Oset in Sekunden vom Versenden der Nachricht angegeben.804.6 Datenobjekte im Kommunikationsfluss zwischen Elektroauto und EMSUm den Speicherplatz für die nötigen Wertebereiche aller zu übermittelnden physikalischenWerte zu begrenzen, wurde für den Parameter Value der Typ Short gewählt. Für überden Wertebereich von Short hinausgehende Werte wird der Parameter Multiplier genutzt,welcher als Exponent zur Basis 10 zu verstehen ist. Der eigentliche physikalische Wert wirdfolgendermaßen berechnet.Physikalischer Wert = Value ◊ 10 ˆ Multiplier [Unit]Es sei an dieser Stelle angemerkt, dass der Treiber lediglich eine Lastbegrenzungskurve undkein weiteres optionales Strompreissignal (siehe Parameter SalesTariff aus Abschnitt 2.2.1,Seite 36) über das ISO/IEC 15118 Protokoll an das Elektrofahrzeug sendet. Die Lastbegren-zungskurve dient als direktes Steuersignal, denn das Fahrzeug wird die Leistungsobergrenzein jedem Zeitintervall voll ausnutzen, sofern aus Sicht des Batteriemanagements, welches dieAufgabe hat, den sicheren Betrieb der Batterie zu gewährleisten, nichts dagegen spricht. DasBatteriemanagement würde bspw. das Ladegerät dazu anleiten, den Ladestrom zu reduzie-ren, wenn die Batterie selbst einen kritischen Temperaturbereich überschritten hat oder derLadeprozess der Batterie sich in der Konstantspannungsphase befindet und aufgrund derLadecharakteristik einer Lithium-Ionen-Batterie (siehe Abschnitt 4.3.6) ein ladestationsseitigangeforderter Ladestrom in dieser Zeitspanne nicht zulässig ist.Der tarifliche Anreiz durch ein vom Energieanbieter kommuniziertes Strompreissignalist durch den Optimierungsvorgang des Gesamtenergiemanagements bereits im ParameterPmaxSchedule enthalten.4.6 Datenobjekte im Kommunikationsfluss zwischen Elektroautound EMSNachdem in den vorigen Abschnitten dieses Kapitels die diversen Komponenten, welche für diesoftwaretechnische Integration des Elektrofahrzeugs in das EMS des Smart Home unabdingbarsind, erläutert wurden, soll an dieser Stelle noch einmal ein zusammenhängender Überblickgegeben werden. Zu diesem Zweck ist in den Abbildungen 4.11 und 4.12 ein beispielhafterKommunikationsfluss zwischen den Komponenten EVCC, SECC, Treiber, lokaler Observerund Controller sowie dem EMP visualisiert.Wie bereits in Abschnitt 2.2.1 beschrieben und Abbildung 2.10 illustriert, beginnt eineKommunikationssession über ISO/IEC 15118 zwischen dem Client (EVCC) und dem Server(SECC) mit dem Aufbau der IP-basierten Kommunikation. Da aber erst mit dem Empfangder ChargeParameterDiscoveryReq Nachricht eine Interaktion mit dem EMS ausgelöst wird,beginnt das Sequenzdiagramm in Abbildung 4.11 mit ebendieser Nachricht.Die ChargeParameterDiscoveryReq Nachricht enthält u. a. den Parameter ACEVChargePa-rameter, welcher die Ladeparameter (ChargeParameter) im Falle des Wechselstromladens(AC) eines Elektrofahrzeugs (EV) übermittelt. Der SECC ruft nun die Methode process-ChargeParameterDiscoveryReq(ACEVChargeParameter) des Treibers auf und sendet somitdiesen Parameter an den Treiber weiter.Der Treiber kapselt sodann diese Ladeparameter in den Datentyp CarDetails, welcher diein Abschnitt 4.2, Seite 57 gelisteten Daten enthält, ergänzt um die Zustandsinformationen• Verbindungsstatus (connected) und• aktive Kommunikationssession (v2gCommSessionActive).81Kapitel 4 Integration des E-Fahrzeugs in das EnergiemanagementLokaler(ObserverSECCTreiberChargeParameterDiscoveryReqEVCC Lokaler(ControllerACEVChargeParameterChargeParameterDiscoveryRes(EVSEProcessing(=((Ongoing)ChargeParameterDiscoveryReqChargeParameterDiscoveryRes(EVSEProcessing(=((Finished)PMaxSchedule...EMPChargingStatusReqChargingStatusReqChargingStatusRes((EVSENoGficaGon(=(None)Schleifendurchlauf,(solange(EKFahrzeug(nicht2neu2eingeplant(werden(mussChargeParameterDiscoveryReq/KRes(Schleife(bis(EVSEProcessing(=(FinishedECarObserverExchange(mit(CarDetails)ECarControllerExchange(mit(List)ECarObserverExchange(mit(CarDetails)ECarConfiguraGonECarControllerExchange(mit(List)PMaxScheduleChargingStatusReqChargingStatusRes(EVSENoGficaGon(=(Regeno7a7on)PowerDeliveryReq(ChargeProgress(=Start)PowerDeliveryRes...Abbildung 4.11: Beispielhafter Kommunikationsfluss zwischen den Entitäten EVCC, SECC,Treiber, EMP sowie lokalem Observer und Controller (Teil 1/2)824.6 Datenobjekte im Kommunikationsfluss zwischen Elektroauto und EMSLokaler(ObserverSECCTreiberEVCC Lokaler(ControllerEMPPowerDeliveryReq(ChargeProgress(=Renego&ate)PowerDeliveryResChargeParameterDiscoveryReqChargeParameterDiscoveryRes(EVSEProcessing(=((Finished)PowerDeliveryReq(ChargeProgress(=Start)PowerDeliveryResChargingStatusReqChargingStatusReqChargingStatusRes((EVSENoEficaEon(=(None)ECarObserverExchange(mit(CarDetails)PowerDeliveryReq(ChargeProgress(=Stop)PowerDeliveryResSessionStopReq(ChargingSession(=Terminate)SessionStopResabortV2GSession() ECarObserverExchange(mit(CarDetails)Schleifendurchlauf,(solange(ENFahrzeug(nicht7neu7eingeplant(werden(mussAbbildung 4.12: Beispielhafter Kommunikationsfluss zwischen den Entitäten EVCC, SECC,Treiber, EMP sowie lokalem Observer und Controller (Teil 2/2)83Kapitel 4 Integration des E-Fahrzeugs in das EnergiemanagementDiese beiden Informationen lassen eine Unterscheidung zwischen einem mit der Ladestationphysikalisch nicht verbundenen Elektrofahrzeug und einer lediglich inaktiven Kommunikationzwischen Fahrzeug und Ladestation zu. Dieser Unterschied ist bspw. wichtig, um zu die-renzieren, ob neben dem aktuellen Batteriestatus ebenso die aus dem Fahrzeug stammendeAbfahrtszeit sowie minimale Reichweite an das EMP zur Aktualisierung gesendet werden soll(siehe Diskussion aus Abschnitt 4.2, Seite 59). Im Falle der Verarbeitung der initialen Ladepa-rameter werden beide Werte auf true gesetzt. Über die Methode notifyLocalObserver()des Treibers werden diese CarDetails im abstrahierten Datenobjekt ECarObserverExchangean den lokalen Observer gesendet.Der lokale Observer verarbeitet die Ladeparameter und erstellt ein Teilproblem (ein ECarEA-Part) für den evolutionären Algorithmus des Gesamtoptimierers, welches dann wiederum anden globalen Observer mit notifyGlobalObserver() gesendet wird. Bei der Verarbeitungvon CarDetails wird nun zwischen mehreren Fällen unterschieden, welche in Abbildung 4.13dargestellt werden. Die resultierenden Benachrichtigungen an den globalen Observer sindfolgendermaßen zu dierenzieren:(1) Kommunikationssession ist aktiv, Beginn einer Ladesession∆ Erstellung eines dynamischen, neu einzuplanenden Teilproblems (ECarEAPart), wobeierst nach der Zeitspanne, die zum Laden der Energie für die Gewährleistung derMindestreichweite nötig ist, das flexible Scheduling beginnen kann.(2) Kommunikationssession ist aktiv, Ladeschleife ist aktiv und eine Veränderung des SOCwurde festgestellt∆ Erstellung eines dynamischen, nicht neu einzuplanenden Teilproblems, welches dasalte Teilproblem ersetzt und lediglich die Informationen bzgl. Energiemengen undLadestatus aktualisiert.(3) Kommunikationssession ist inaktiv, E-Fahrzeug ist nicht mehr physikalisch verbunden∆ Erstellung eines statischen, neu einzuplanenden Teilproblems, welches das alte Teil-problem ersetzt und ein Lastprofil mit einem Eintrag besitzt:(Start = jetzt, Leistung = 0 kW).Aufgrund der in der ISO/IEC 15118-2 definierten Timeouts muss einerseits spätestens alle60 s eine Request-Nachricht vom EVCC an den SECC gesendet werden und andererseits im Fal-le der ChargeParameterDiscoveryReq Nachricht spätestens nach 2 s eine Response-Nachrichtvom SECC an den EVCC zurückgesendet werden. Die ChargeParameterDiscoveryRes ent-hält den vom EMS vorgeschlagenen Ladefahrplan PMaxSchedule. Da nun aber eine Rechenzeitvon kleiner 2 s für die Berechnung einer geeigneten Lastkurve für das Elektrofahrzeug (unterBerücksichtigung der Gesamtlastsituation im Smart Home) oftmals nicht ausreicht, gibt es inder Response-Nachricht den nützlichen Parameter EVSEProcessing. Dieser klärt den EVCCdarüber auf, ob der SECC bereits eine Lastkurve bereitstellen konnte (Finished) oder nochZeit benötigt (Ongoing). Dieser Mechanismus wurde in der Spezifikation eingefügt, um einerverzögerten Kommunikation zwischen einer Ladestation und dem Backend des E-Mobilitäts-Anbieters Rechnung tragen zu können. Ist der Parameter auf Ongoing gesetzt, so veranlasstdies eine Schleife, in der der EVCC so lange eine ChargeParameterDiscoveryReq Nachrichtsendet, bis EVSEProcessing = Finished in der Antwortnachricht gesetzt wurde.Wurde nun vom globalen Controller eine Lastkurve für das E-Fahrzeug an den lokalenController übermittelt, so sendet dieser das abstrahierte Lastprofil mittels des ECarCon-trollerExchange-Datenobjekts an den Treiber, welcher wiederum die Übersetzung in den844.6 Datenobjekte im Kommunikationsfluss zwischen Elektroauto und EMSCarDetails*Ladesession*ak0v?*Lade3schleife*ak0v?*Ja* Nein*Änderung*in*SOC?*Ja*Nein*(1)*Benachrich0ge*globalen*Observer*E3Fahrzeug*verbunden?*(3)*Benachrich0ge*globalen*Observer*Nein*Ja*(2)*Benachrich0ge*globalen*Observer* Tue*nichts*Nein*Ja*Abbildung 4.13: Fallunterscheidung im lokalen Observer beim Verarbeiten von vom Treibergesendeten CarDetailsISO/IEC 15118-2-typischen PMaxSchedule vornimmt und diesen Datentyp dem SECC zurVerfügung stellt.Da nun ein Ladefahrplan dem EVCC übermittelt werden konnte, erfolgt als nächstes einePowerDeliveryReq Nachricht, welche mittels des Parameters ChargeProgress den SECCdarüber informiert, dass sofort mit dem Ladeprozess begonnen (Start), eine Neuverhandlungbestätigt (Renegotiate) oder die Ladesession beendet bzw. pausiert (Stop) werden soll. EineLadepause würde bspw. dann stattfinden, wenn die erste Lade- oder Rückspeiseanforderungverzögert erfolgen wird und der Ladesteuerungscomputer sich bis dahin schlafen legt, umEnergie zu sparen. Des Weiteren beinhaltet diese Request-Nachricht auch den vom Fahrzeugakzeptierten Ladefahrplan, der prinzipiell vom vorgeschlagenen Ladefahrplan abweichenkann, im vorliegenden Versuchsaufbau aber stets akzeptiert wird und daher keine erneuteBenachrichtigung des Treibers nach sich zieht.Nun beginnt die eigentliche Abarbeitung des Ladefahrplans, im Zuge dessen Energieentweder geladen oder rückgespeist wird. Das im Treiber bereits existierende CarDetails-Objekt wird durch die Werte der in ChargingStatusReq enthaltenen Parameter eAmount,eAmountDischarge und soc aktualisiert und erneut an den lokalen Observer geschickt. Umden Datenverkehr im EMS nicht unnötig zu erhöhen, wird gemäß Abbildung 4.13 und bereitsbeschriebener Prozedur nur nach einer Erhöhung des SOC-Wertes eine neue Benachrichtigungan den globalen Observer gesendet, um somit einerseits den globalen Optimierer über dieEnergieflüsse im Fahrzeug auf dem Laufenden zu halten und andererseits die Visualisierungder aktuellen Reichweite über das EMP mit den neueren Daten stets aktuell zu halten.Zwischenzeitlich könnte der Bewohner des Smart Home über das Touch-Display die Einstel-lungen bzgl. Mindestreichweite oder Abfahrtszeitpunkt im EMP verändert haben, was sichwiederum auf den Ladefahrplan auswirken könnte und entsprechend neu eingeplant werden85Kapitel 4 Integration des E-Fahrzeugs in das Energiemanagementmuss. Da sich der lokale Observer für Nachrichten-Events vom EMP hat registrieren lassen(siehe Abschnitt 4.2, Seite 59), empfängt er ein ECarConfiguration-Objekt über das Registrarund erstellt ein neu einzuplanendes, dynamisches Teilproblem mit den aktualisierten Daten desEMP, welches erneut an den globalen Observer übermittelt wird. Sobald der lokale Controllerdas aktualisierte Lastprofil für das Elektrofahrzeug vom globalen Optimierer erhalten hat,wird in gleicher Weise wie zuvor über den Treiber ein neues PMaxSchedule dem SECC zurVerfügung gestellt.Damit während des Ladevorgangs eines Elektrofahrzeugs auf kurzfristige Engpasssituationenoder generell Änderungen im Stromnetz reagiert werden kann, enthält u. a. die Charging-StatusRes Nachricht den Parameter EVSEStatus (siehe Abschnitt 2.2.1, Seite 38), welcherwiederum den Parameter EVSENotification enthält und mitteilen kann, ob eine Neuverhand-lung des Ladefahrplans vonnöten ist (Renegotiation) oder nicht (None). Der Ladevorgangwird im Falle einer Neuverhandlung durch ein erneutes PowerDeliveryReq/-Res Nachrich-tenpaar beendet, wobei diesmal mit dem Parameter ChargeProgress = Renegotiate dieNeuaushandlung bestätigt wird. Dieser Parameter bewirkt im Übrigen, dass die Ladeschützeder Ladestation nicht wieder geönet werden und somit weiterhin Spannung anliegt, nureben kein Strom fließt, bis ein erneutes PowerDeliveryReq/-Res Nachrichtenpaar gesendetwird, diesmal mit ChargeProgress = Start. Das zwischenzeitlich ausgetauschte Charge-ParameterDiscoveryReq/-Res Nachrichtenpaar hat keinerlei Auswirkung auf den lokalenObserver, da ein erneutes Lastprofil (PMaxSchedule) ja bereits vorliegt und der SECC diesesgleich an den EVCC weiter kommuniziert. Es folgt ein weiterer Ladeprozess mit der bereitsbekannten Ladeschleife.Soll nun aus Sicht des EVCC der Ladevorgang beendet werden, so wird ein erneutesPowerDeliveryReq/-Res Nachrichtenpaar ausgetauscht, um dediziert über den Stop desLadeprozesses zu informieren. Abschließend erfolgt der Austausch des SessionStopReq/-ResNachrichtenpaares, wobei die Request-Nachricht über den Parameter ChargingSession denSECC darüber informiert, ob eine Ladesession nur pausiert (Pause) oder gänzlich beendetwerden soll (Terminate). Ersteres würde die Ladestation dazu veranlassen, gewisse Zustands-informationen für die nächste Ladesession zu speichern.Dieser beispielhafte Kommunikationsfluss ist repräsentativ für die Interaktion zwischen dendiversen Entitäten und bietet somit ein realistisches Bild.Eine Situation, die in den Abbildungen 4.11 und 4.12 nicht dargestellt wurde, ist diejenige,in der das Ladesteuergerät (also der EVCC) sich aufgrund einer Ladepause oder nach voll-ständiger Abarbeitung eines Ladefahrplans aus Energiespargründen schlafen gelegt hat, aberaufgrund einer neuen Lastsituation im Haus das Fahrzeug außerplanmäßig erneut interagierenmuss. In diesem Fall liegt es in der Verantwortung des Treibers, nach Benachrichtigung durchden lokalen Controller den EVCC zu reanimieren, woraufhin eine neue Ladesession angestoßenwerden würde.Bevor nun in Kapitel 6 eine Evaluation des hier vorgestellten Ansatzes zur Integration desElektrofahrzeugs in das Smart Home EMS durchgeführt wird, soll in Kapitel 5 auf das ThemaE-Roaming eingegangen werden. Dieses Kapitel lenkt den Fokus weg vom Smart Home undhin zu einem makroskopischeren Gesichtspunkt der E-Mobilität.86KAPITEL 5DAS E-ROAMING SZENARIOIn den vorigen Kapiteln wurde eine Form der intelligenten Einbindung eines rückspeisefähigenElektrofahrzeugs in das Energiemanagement eines Smart Home beschrieben, wobei die Batteriedes Fahrzeugs als flexibler Energiespeicher und Verbraucher genutzt wird. Dieses Smart HomeSzenario sollte u. a. die Potentiale der ISO/IEC 15118 hinsichtlich eines flexibel steuerbarenLadevorgangs zum Zwecke der optimierten Eigenstromnutzung und Senkung der Stromkostenaufzeigen und einen Einblick in die relevanten Nachrichten, Parameter und Mechanismengewähren. Ein weiterer, für den Elektromobilitätsmarkt sehr wichtiger Aspekt, welcher ebenfallsin der Norm beschrieben wird, ist das sogenannte E-Roaming.Als E-Roaming im Kontext der Elektromobilität wird landläufig die Möglichkeit bzw. dasZiel verstanden, sein Elektrofahrzeug an einer beliebigen Ladestation aufladen zu können,unabhängig davon, ob ein Vertragsverhältnis mit dem Betreiber genau dieser Ladeinfra-struktur besteht. Das heißt der Zugang zu einer Ladestation muss anbieterunabhängig undgrenzüberschreitend möglich sein, was neben rein batteriebetriebenen Elektrofahrzeugen auchfür Plug-in Hybride zunehmend relevant ist. Dieses E-Roaming-Prinzip wird vom Ansatzher gerne mit dem altbekannten Mobilfunkroaming verglichen. Das deutsche Joint VentureHubject, auf welches u. a. im Abschnitt 5.2 noch eingegangen wird, definiert E-Roamingfolgendermaßen [36]:„eRoaming ist ein Marktmodell der Elektromobilität, welches die vertragsbasierte Nutzungvon Ladeinfrastruktur als Service für Fahrer von Elektrofahrzeugen in ganz Europa ermöglichtund sich durch eine hohe Transaktionskostenezienz sowie Marktoenheit auszeichnet.“Hubject ist eine B2B Diensteplattform und verspricht eine einfach zu handhabende Business-und IT-Plattform für die automatisierte Abwicklung vertragsbasierter Geschäftsbeziehungenzwischen Energielieferanten, E-Fahrzeugherstellern, Ladeinfrastrukturanbietern und weiterenE-Mobilitäts-Geschäftspartnern. Der Endverbraucher erhält auf Basis nur eines Kundenver-trages Zugang zu diesem Netzwerk. Das Ziel der Gründungsmitglieder BMW Group, Bosch,Daimler, EnBW, Siemens und RWE ist die Realisierung eines einfachen und anbieterübergrei-fenden Zugangs zu öentlicher und semi-öentlicher Ladeinfrastruktur, wobei die regionalenund nationalen (europäischen) E-Mobilitäts-Märkte vernetzt werden sollen.Es wurde im Rahmen dieser Arbeit bereits mehrfach angedeutet, dass das sogenanntePlug-and-Charge Identifizierungsverfahren es ermöglicht, alle Aspekte der Authentifizierung,Autorisierung, Abrechnung und Ladesteuerung in einem automatisierten Prozess im Hinter-grund und ohne Nutzerinteraktion zu erledigen. Dieser Automatismus basiert auf einem vorher87Kapitel 5 Das E-Roaming Szenarioabgeschlossenen Vertragsverhältnis zwischen E-Fahrzeugnutzer und E-Mobilitätsanbieter. DerElektromobilist muss hierzu lediglich das Ladekabel mit E-Fahrzeug und Ladestation verbin-den und sich um nichts weiter kümmern. Dieses Verfahren gewinnt umso mehr an Bedeutung,je mehr induktive Ladestationen zukünftig zum Einsatz kommen werden, denn hier wünschtsich der Nutzer im Idealfall keinerlei weitere Interaktion, als das Fahrzeug über der meist imBoden eingelassenen Ladespule zu parken. Die Teile ISO/IEC 15118-6 bis -8 spezifizieren fürdiesen Anwendungsfall nicht nur die induktive Energieübertragung, sondern auch die drahtloseKommunikation der Ladeparameter.Ziel dieses Kapitels ist es nun, anhand der beschriebenen Mechanismen der ISO/IEC 15118Spezifikation darzustellen, wie ein solches E-Roaming-Szenario realisiert werden kann. Auf denersten Blick mag diese Thematik etwas losgelöst von den vorherigen Kapiteln erscheinen, siebildet jedoch eine wichtige Grundlage für die Diskussion der Zukunftsfähigkeit des ISO/IEC15118 Standards in den Abschnitten 6.1.3 und 6.1.5.5.1 Das Zertifikatskonzept gemäß ISO/IEC 15118-2Die Informationen bezüglich des Zertifikatsmanagements basieren auf einem informativenAnnex der ISO/IEC 15118-2 und stellen somit keine ozielle strikte Vorgehensweise dar,sondern eher eine Empfehlung gemäß dem besten Wissen der Autoren dieses Annexes. In [48]wurden bereits die wesentlichen Informationen zu diesem Verfahren publiziert, welche andieser Stelle durch Details u. a. zu den kryptographischen Verfahren angereichert werden.Das Zertifikatskonzept dieses Standards sieht diverse Zertifikatstypen vor, welche in einer zuetablierenden Public Key Infrastruktur (PKI) jeweils unterschiedliche Einsatzzwecke erfüllen.Eine PKI wird im Rahmen eines asymmetrischen Kryptographieverfahrens mit privaten undöentlichen Schlüsseln dafür genutzt, die Authentizität eines öentlichen Schlüssels sowieseinen zulässigen Anwendungs- und Geltungsbereich mittels signierten digitalen Zertifikatenzu überprüfen. Weitere Hintergrundinformationen zur Funktionsweise von asymmetrischenKryptographieverfahren sowie einer PKI können bspw. [11] entnommen werden. Um dasZertifikatskonzept, welches in diesem informativen Annex beschrieben wird, besser verstehenzu können, müssen zuerst ein paar Anforderungen erklärt werden, die einerseits von der Auto-mobilindustrie (fortlaufend OEM genannt) und andererseits bspw. von E-Mobilitätsanbietern(im Standard abstrakt als „secondary actors“ bezeichnet) aufgestellt werden.5.1.1 Anforderungen aus Sicht eines OEMsEin OEM hat das Interesse, die Kosten für jegliche im Fahrzeug verbauten Komponenten,insbesondere auch Steuereinheiten wie den EVCC, möglichst gering zu halten. Solche Kostenlassen sich aufgrund der Skaleneekte einer weltweiten Serienproduktion schon bei wenigenCentbeträgen deutlich reduzieren, weshalb auch ein genaues Auge auf die im Fahrzeugverbauten Speicherelemente und den benötigten Speicherplatz für die Kommunikation mitdem SECC geworfen wird. Des Weiteren ist ein manueller Eingri bzw. eine Wartung einer imFahrzeug verbauten Kommunikationskomponente durch eine Werkstatt für den Fahrzeugnutzermit Unkosten und Zeitaufwand verbunden, was zugunsten der Nutzerakzeptanz möglichstvermieden werden sollte.Die einfachste Art und Weise, ein Zertifikat im Fahrzeugspeicher ohne späteren Aufwandzu installieren, ist zur Produktionszeit des Fahrzeugs. Dies bringt es jedoch mit sich, dass885.1 Das Zertifikatskonzept gemäß ISO/IEC 15118-2ein solches Zertifikat eine besonders lange Laufzeit haben müsste, mindestens so lange wiedie Nutzungsdauer eines Fahrzeugs, die – orientiert man sich an der Garantiezeit für einenim Fahrzeug verbauten Lithium-Ionen-Akku – im Schnitt 8 bis 10 Jahre beträgt. Solcheeher statischen Zertifikate können als sogenannte Root Zertifikate1 in einer PKI zum Einsatzkommen.Jedoch ist es durchaus denkbar und wahrscheinlich, dass der Vertrag, den ein Elektromobilistmit seinem E-Mobilitätsanbieter zum Zwecke der Autorisierung an öentlichen Ladestationenabschließt, und das entsprechende Vertragszertifikat noch nicht zum Zeitpunkt der Produktiondes Fahrzeugs existieren. Darüber hinaus kann es vorkommen, dass ein Kunde seinen E-Mobilitätsanbieter mit der Zeit wechseln möchte und somit auch ein solches Vertragszertifikatfür das Plug-and-Charge Identifizierungsverfahren an die Gültigkeitsdauer des Vertragesgebunden ist. Aus diesen angeführten Gründen kann ein statisches Root Zertifkat, wie eszur Produktionszeit in das Fahrzeug integriert werden könnte, nicht für alle Zwecke in einerPKI genutzt werden. Ein viel praktischeres weil flexibleres Verfahren wäre die Installationeines solchen nicht-statischen Vertragszertifikats über das digitale KommunikationsprotkollISO/IEC 15118.Da, wie bereits erwähnt, selbst durch geringe Einsparungen im Bereich persistenter Speicherdie Kosten durch die Skaleneekte im Massenmarkt erheblich gesenkt werden können, solltedie Speichergröße eines solchen Vertragszertifikats, die Zertifikatskette von Root Zertifikat biszum Vertragszertifikat sowie die Anzahl der abgespeicherten Root Zertifikate ebenfalls auf einMinimum reduziert werden.5.1.2 Anforderungen aus Sicht eines E-MobilitätsanbietersDer Betrieb einer PKI und die Ausstellung von Zertifikaten sollten möglichst geringen bürokra-tischen Aufwand erzeugen, infolge dessen die Abstimmungsprozesse zwischen den verschiedenenFirmen, die Teile einer PKI bilden, ebenfalls auf ein Minimum reduziert werden sollte.Ein erster Ansatz wäre, alle an einer PKI beteiligten E-Mobilitätsanbieter (weltweit) in einergemeinsamen Gruppe zu vereinen, welche auf ein und dasselbe Root Zertifikat zugreift, welchesdann verteilt und in jedes Fahrzeug installiert wird. Alle weiteren Vertragszertifikate, welchedurch die diversen E-Mobilitätsanbieter erstellt werden, könnten dann direkt von diesem RootZertifikat abgeleitet und als vertrauenswürdig eingestuft werden, indem sie mit dem privatenSchlüssel des Root Zertifikats signiert werden. Anhand des öentlich zugänglichen Schlüsselsdes Root Zertifikats kann diese Signatur dann mit einem entsprechenden kryptographischenAlgorithmus entschlüsselt und die Echtzeit und Vertrauenswürdigkeit dieser Signatur und imUmkehrschluss des Vertragszertifikats überprüft werden. Einzige Voraussetzung wäre, dassman sich auf die Vertrauenswürdigkeit einer obersten Zertifizierungsstelle, einer sogenanntenRoot Certificate Authority (Root-CA), einigt.Es stellt sich jedoch in der Realität als eher schwierig heraus, eine oberste Zertifizierungsstelleweltweit zu etablieren, auf welche sich sämtliche Länder aller Kontinente einigen können. Ausdiesem Grunde bietet sich ein alternativer Ansatz an, welcher mehrere Zertifizierungsstellenund Zertifikatstypen auf unterschiedlichen hierarchischen Stufen vorsieht. So könnte manbspw. für jeden der fünf Kontinente eine Zertifizierungsstelle errichten, welche jeweils ein RootZertifikat erstellt. Des Weiteren ließe sich für jedes Land eines Kontinents eine Zwischen-Zertifizierungsstelle einrichten, die wiederum die darunter liegenden Zertifizierungsstellen eines1Im Deutschen auch Wurzel- oder Stammzertifikat genannt. Dies ist ein unsigniertes oder selbstsigniertesPublic-Key-Zertifikat einer obersten Zertifizierungsstelle (Root-CA), welches dazu verwendet wird, dieGültigkeit aller untergeordneten Zertifikate zu validieren.89Kapitel 5 Das E-Roaming Szenariojeden E-Mobilitätsanbieters zertifiziert, welcher in letzter Instanz die Vertragszertifikate fürseine direkten Kunden ausstellt. Dieser hierarchische Zertifizierungsansatz, in welchem diejeweiligen Zwischen-Zertifizierungsstellen eigenverantwortlich weitere Zertifikate ausstellenund signieren können, erleichtert die Zertifikatsverwaltung und wird im besagten Annex desISO/IEC 15118-2 vorgestellt.Eine weitere Anforderung aus Sicht eines E-Mobilitätsanbieters, in diesem Fall eines La-destationsbetreibers, ist die Reduktion der Kommunikationskosten für den Betrieb einerLadestation. Dies bedeutet also, dass es vorteilhaft wäre, wenn die Ladestation währenddes gesamten Ladevorgangs oine bliebe und nicht für jeden Identifizierungsvorgang eineOnline-Verbindung (über UMTS, GSM, LAN) aufbauen müsste.5.1.3 Zertifikatstypen gemäß ISO/IEC 15118-2Bevor in Abschnitt 5.1.4 auf die resultierenden Entscheidungen für das Zertifikatskonzepteingegangen wird, müssen ein paar Begriichkeiten eingeführt werden, welche für das weitereVerständnis des Konzepts unerlässlich sind.V2G Root ZertifikateDie V2G Root Zertifikate sind global gültige (top-level) Zertifikate der PKI. Sie bilden dieoberste Vertrauensinstanz, auf Basis derer sämtliche weiteren abgeleiteten Zertifikate auf ihreEchtzeit und Vertrauenswürdigkeit überprüft werden können. Die entsprechenden privatenSchlüssel sind im Besitz der jeweiligen Zertifizierungsstellen (Root-CAs). V2G ist eine Abkür-zung für Vehicle-to-grid.Mobility Operator Root ZertifikatDieser Zertifikatstyp wird dafür genutzt, über eine Kette von Sub-CAs die Vertragszertifikatezu signieren.Vertragszertifikat (Blattzertifikat)Im Falle des Plug-and-Charge Identifizierungsmodus’ an einer Ladestation kommt diesesZertifikat zum Einsatz, welches ein gültiges Vertragsverhältnis zwischen Elektromobilist undE-Mobilitätsanbieter widerspiegelt. Es wird im EVCC zusammen mit dem entsprechendenprivaten Schlüssel abgespeichert. Das Elektrofahrzeug greift sodann auf dieses digitale Zertifi-kat zurück, um gegenüber der Ladestation die Existenz eines gültigen Fahrstromvertrageszu verifizieren. Vertragszertifikate sind von einem Mobility Operator Root Zertifikat abgeleitet.SECC Zertifikat (Blattzertifikat)Mit Hilfe dieses Zertifikats wird die Ladestation gegenüber dem E-Fahrzeug authentifiziert.Der zugehörige private Schlüssel ist im SECC abgespeichert. SECC Zertifikate (in Abbildung5.1 mit „EVSE Leaf Certificate“ bezeichnet) sind von V2G Root Zertifikaten abgeleitet.OEM Provisioning Zertifikat (Blattzertifikat)Ein OEM Provisioning Zertifikat (Bereitstellungszertifikat) wird individuell für jedes Elektro-fahrzeug ausgestellt und zur Produktionszeit im EVCC des Fahrzeugs installiert. Es dient zurVerifizierung der Identität des entsprechenden Elektrofahrzeugs zu Beginn eines Bereitstel-lungsprozesses (siehe Abschnitt 5.1.5) und ist vom OEM Root Zertifikat abgeleitet.905.1 Das Zertifikatskonzept gemäß ISO/IEC 15118-2OEM Root ZertifikatDas OEM Root Zertifikat wird zur Signierung eines OEM Provisioning Zertifikats genutzt.Jeder OEM kann sein eigenes (top-level) Root Zertifikat erzeugen und dieses dann an dieE-Mobilitätsanbieter und Clearingstellen verteilen. Das Root Zertifikat eines OEMs ist nichtBestandteil einer globalen PKI, d.h. es ist auch nicht zwangsweise von einem V2G RootZertifikat signiert.Abbildung 5.1 liefert einen zusammenfassenden Überlick der verschiedenen Zertifikatstypen.,62)',6(,62,(& ±$OOULJKWVUHVHUYHG ( 2YHUYLHZRIWKHUHVXOWLQJFHUWLILFDWHVWUXFWXUH)LJXUH(²2YHUYLHZFHUWLILFDWHVWUXFWXUH)LJXUH (SURYLGHV DYLVXDO RYHUYLHZ RIWKHUHVXOWLQJFHUWLILFDWHVWUXFWXUHDQGUHOHYDQW YDOLGLW\ SHULRGV$V RQH FDQ VHH WKH 2(0 3URYLVLRQLQJ &HUWLILFDWHV DUH LQGHSHQGHQW IURP WKH 3., RI WKH VHFRQGDU\ DFWRUVEHORZ WKH JOREDO URRW FHUWLILFDWHV 7KH URRW FHUWLILFDWH RI DQ 2(0 3URYLVLRQLQJ &HUWLILFDWH LV FUHDWHG E\ WKH2(0 LWVHOI 7KHUHIRUH WKHUH LVQRQHHG WRKDYHDORQJHUFHUWLILFDWHFKDLQ )RUDQ H[SODQDWLRQRI WKHXVDJHRIWKH 2(0 5RRW &HUWLILFDWH DQG WKH 2(0 3URYLVLRQLQJ &HUWLILFDWH UHIHU WR $QQH[ ,W LV KRZHYHU DOORZHG WRUHXVH D 9* 5RRW DV D 0RELOLW\ 2SHUDWRU 5RRW &HUWLILFDWHRUDQ2(05RRW&HUW LILFDWH VXJJHVWHGZLWKGRWWHGOLQHV$OOFHUWLILFDWHFKDLQVKDYH DPD[LPXPOHQJWKRILHLQFOXGLQJWKHURRWFHUWLILFDWHFHUWLILFDWHVDUH LQYROYHG 7KH FHUWLILFDWH FKDLQ RI DQ 6(&& LV WUDQVPLWWHG WR WKH (9&& WR HQDEOH DQ DXWKHQWLFLW\ FKHFN RI WKH 6(&&EHIRUH D7/6FRQQHFWLRQ LVHVWDEOLVKHGFIDERYH LQRUGHU WRDYRLG PDQLQWKHPLGGOH DWWDFNV7KH FHUWLILFDWH FKDLQ RI D &RQWUDFW &HUWLILFDWH LV WUDQVPLWWHG LQWR WKH(9&&ZLWKRXWD 5RRW&$7KLV OLPLWV WKHWUDQVPLVVLRQ WRFHUWLILFDWHVEXWWKLVDOVRPHDQVWKDWWKHYHKLFOH FDQQRWYHULI\ LWVRZQ&RQWUDFW&HUWLILFDWH (SURYLGHV DQH[DPSOH RIVLPSOLILHG FHUWLILFDWHPDQDJHPHQW LQSULYDWH HQYLURQPHQWVAbbildung 5.1: Überblick über die diversen Zertifikatstypen, welche im Rahmen des Plug-and-Charge Identifikationsmodus’ gemäß ISO/IEC 15118-2 zum Einsatz kommen[39]Sämtliche in der oberen Auflistung als „Blattzertifikat“ gekennzeichneten Zertifikate ent-sprechen den Zertifikaten am untersten Ende der vier-elementigen Verifizierungskette, dasheißt, dass keine weiteren Zertifikate mehr von ihnen abgeleitet (signiert) werden können. Indiesem Überblick sind ebenfalls sogenannte Provisioning Sub-CAs (Prov Sub-CA) aufgeführt.Die Rolle des Certificate Provisioning Service, also des Validierungsdienstes, kann auch durchden Mobility Operator (der E-Mobilitätsanbieter), dem CPO (Charge Point Operator =Ladestationsbetreiber) oder eine gänzlich andere Instanz ausgeführt werden. Ein solcherValidierungsdienst hat die Aufgabe zu überprüfen, ob die Zertifikate, die zur Prüfung der91Kapitel 5 Das E-Roaming Szenariojeweiligen Signatur verwendet werden, gesperrt und damit bereits vor Ende ihres regulärenGültigkeitszeitraums ungültig wurden. Das Online Certificate Status Protocol (OCSP) ist dasentsprechende Internet-Protokoll, über welches die Validierung durchgeführt werden kann.5.1.4 Resultierende Entscheidungen als Basis für das ZertifikatskonzeptBasierend auf den vorgestellten Anforderungen eines OEMs und E-Mobilitätsanbieters, welchein mancher Hinsicht widersprüchlich sind, wurde ein Konzept für die Erstellung, Verteilung,Nutzung und Verwaltung diverser Zertifikate für das Plug-and-Charge Szenario erstellt. DiesesZertifikatskonzept stellt an gewissen Stellen einen Kompromiss dar, der zwischen den verschie-denen Interessensgruppen geschlossen wurde.Speichergröße eines einzelnen ZertifikatsJegliches Zertifikat soll dem X.5092 Format entsprechen, welches ein strikt hierarchischesSystem von vertrauenswürdigen Zertifizierungsstellen voraussetzt. Die Größe eines solchenZertifikats soll 800 Bytes nicht überschreiten, was u. a. dadurch erreicht werden kann, dassirrelevante Informationen wie die Adresse des Zertifikatsausstellers ausgespart werden.Länge einer ZertifikatsketteBei der Länge der Zertifikatskette einer solchen PKI treten die konfligierenden Interessen derOEMs und der E-Mobilitätsanbieter zutage. Während einerseits der Speicherplatz im EVCCfür abzuspeichernde Zertifikate möglichst gering gehalten werden soll, verringert andererseitseine entsprechend lange Zertifikatskette den Abstimmungsaufwand zwischen verschiedenenFirmen, die direkt Vertragszertifikate ausstellen möchten, und oziellen Organisationen, dieals vertrauenswürdige oberste Zertifizierungsstelle auftreten. Als Kompromiss hat man sichauf eine maximal vierstufige Zertifikatskette geeinigt, bestehend aus dem Root Zertifikat(erstellt von der Root-CA), gefolgt von maximal zwei Zwischen-Zertifikaten (ausgestelltdurch sogenannte Sub-CAs) und dem finalen Blattzertifikat (Vertragszertifikat oder SECC-Zertifikat), welches das Ende der Kette bildet. Diese vierstufige Zertifikatskette ist neben denZertifikatstypen an sich ebenfalls durch Abbildung 5.1 illustriert.Konkret könnte man sich die Instanzen dieser Kette folgendermaßen vorstellen: Auf jedemKontinent könnte eine einzelne Organisation (Root-CA) dafür zuständig sein, ein V2G RootZertifikat auszustellen. Nun könnte eine beliebige Anzahl an untergeordneten Zertifizierungs-stellen errichtet werden, die bspw. entweder jeweils ein Land dieses entsprechenden Kontinents(Sub-CA auf Landesebene) oder – gemäß der Deutung aus Abbildung 5.1 – einen Ladesta-tionsbetreiber (CPO Sub-CA 1) bzw. E-Mobilitätsanbieter (MO Sub-CA 1) repräsentieren.Bei entsprechend großen Firmen ist es nicht unüblich, dass diverse Zertifizierungsstellen fürverschiedene Zwecke zum Einsatz kommen, wie etwa eine Sub-CA für Mitarbeiterzertifikateoder eine Sub-CA für SSL-Zertifikate, die allesamt unter einer gemeinsamen Firmen Root-CAstehen. Ein E-Mobilitätsanbieter könnte somit eine eigene weitere Zwischenzertifikatsstel-le (MO Sub-CA 2) betreiben, die eigens dafür genutzt wird, Ladestromverträge (ContractCertificate) mit ihrem privaten Schlüssel zu signieren.Laut der Spezifikation müssen lediglich Ladestationsbetreiber-Zertifikate sowie Ladesta-tionszertifikate von der V2G Root abgeleitet werden (mandatory certification), wohingegenE-Mobilitätsanbieter entscheiden können, ob sie selbst eine Root-CA samt der damit ein-hergehenden hohen Sicherheitsrichtlinien betreiben oder diese Aufgabe lieber einer bereits2http://www.ietf.org/rfc/rfc2459.txt925.1 Das Zertifikatskonzept gemäß ISO/IEC 15118-2bestehenden V2G Root-CA übergeben wollen (optional certification).Anzahl der Root ZertifikateAls Kompromisslösung wird gefordert, mindestens ein V2G Root Zertifikat im EVCC eines E-Fahrzeugs zu installieren, wobei ein Minimum an fünf (entsprechend der Anzahl der Kontinente)solcher Zertifikate empfohlen wird.Für den SECC wird ein Minimum an zehn V2G Root Zertifikaten gefordert, was u. a. mitsich überschneidenden Gültigkeitsdauern auslaufender und neuer Zertifikate begründet wird.Diese größere Anzahl an zu speichernden Zertifikaten ist dadurch begründet, dass die Speicher-größe eines SECC (noch) nicht in der Art einem Kostendruck durch Skaleneekte ausgesetztist, wie es beim EVCC der Fall ist.Gültigkeit eines Root ZertifikatsDa Root Zertifikate möglichst selten installiert werden sollten, idealerweise einmal zur Pro-duktionszeit des Elektrofahrzeugs, wurde festgelegt, dass ein solches Zertifikat eine Gültigkeitvon 40 Jahren haben soll. Dieser Zeitraum deckt die übliche Nutzungsdauer eines Fahrzeugsbei weitem ab.Gültigkeit eines OEM Provisioning ZertifikatsNeue OEM Bereitstellungszertifikate sollen eine Gültigkeit von 30 Jahren aufweisen.Installation von VertragszertifikatenVertragszertifikate sollen über die Mechanismen des ISO/IEC 15118 Kommunikationspro-tokolls installiert und aktualisiert werden, insbesondere kommen hier die NachrichtenpaareCertificateInstallationReq/-Res und CertificateUpdateReq/-Res zum Einsatz.Gültigkeit von VertragszertifikatenDie minimale Gültigkeitsdauer eines solchen Zertifikats beträgt 4 Wochen, es sei denn dieGültigkeitsdauer eines abgeschlossenen Vertrags ist kürzer.Gültigkeit von SECC ZertifikatenDie Gültigkeitsdauer eines SECC Zertifikats ist nicht näher angegeben, es ist in der Spezifika-tion lediglich von einer „kurzen“ Zeitdauer die Rede.5.1.5 Initialer Bereitstellungsprozess (Certificate Provisioning)Es wurde bereits motiviert, dass die Installation eines Vertragszertifikats möglichst durcheinen automatisierten Prozess geschehen sollte, um den damit verbundenen Aufwand sowie dieKosten für den Elektromobilisten auf ein Minimum zu reduzieren. Jener Prozess wird in derISO/IEC 15118-2 Spezifikation als „Certificate Provisioning“ bezeichnet, was soviel bedeutetwie Zertifikatsbereitstellung. Mit Hilfe des CertificateInstallationReq/-Res Nachrich-tenpaares kann das vom E-Mobiliäts-Anbieter bereitgestellte Vertragszertifikat im Fahrzeuginstalliert werden. Im Zuge dieser Zertifikatsbereitstellung bedarf es weniger Prozessschritte,die nur zum Teil über das Ladeprotokoll abgewickelt werden können und zusammenfassend inAbbildung 5.2 dargestellt werden.Im ersten Schritt 1 wird in jedes neu produzierte Elektrofahrzeug ein individuelles OEMProvisioning Zertifikat samt des dazugehörigen privaten Schlüssels installiert, welches vom93Kapitel 5 Das E-Roaming Szenario1" Fahrzeugproduk-on/Erstellung/eines"OEM""Provisioning.Zer1fikats/(individuell/für/jedes/EV)/Installa-on/in/EVCC/2" Fahrzeugübergabe/an/Kunden/Zert..ID"(inkl./privatem/Schlüssel)/Übergabe/Zer1fikats.ID"(Zert..ID)"an/Kunde/(z.B./InfoFBlaG,/Fahrzeughandbuch,/...)/3" Abschluss/eines/Ladestromvertrags/Zert..ID"LadestromF/vertrag/+"An/Vertragspartner/senden/(EFMobilitätsFAnbieter,/z.B./EVU)/EVU"Zert..ID"Erstellung/Vertragszer1fikat"u./Verknüpfung/mit/Zert.FID/Informiere/Clearingstelle/(CS)/CS"+"4" Erster/Ladevorgang/mit/diesem/Ladestromvertrag/CS"Überprüfe/OEM/ProvisionsFZer-fikat/und/iden-fiziere/Vertragszer-fikat/(inkl./privatem/Schlüssel)/EVSE"Abbildung 5.2: Prozessschritte im Zuge der Bereitstellung des Vertragszertifikats (angelehntan [39])945.1 Das Zertifikatskonzept gemäß ISO/IEC 15118-2OEM Root Zertifikat abgeleitet und mit dessen privaten Schlüssel signiert wurde. Jedes OEMProvisioning Zertifikat ist mit einer eindeutigen Kennung, der Zertifikats-ID, ausgestattet.Sobald nun ein Kunde ein neues Elektrofahrzeug kauft 2, wird er über die Zertifikats-ID des im Fahrzeug installierten Provisioning Zertifikats informiert. Dies kann bspw. übereine Information im Fahrzeughandbuch, ein separates Informationsblatt oder auch einenOnlinezugang zur entsprechenden OEM-Plattform geschehen.Bei Abschluss eines neuen Fahrstromvertrages 3, mit Hilfe dessen der Kunde sich an öentli-chen Ladestationen für das Aufladen seines Elektrofahrzeugs autorisieren lassen möchte, sendetder Fahrzeugnutzer die Zertifikats-ID des OEM Provisioning Zertifikats zusammen mit seinemunterschriebenen Vertrag an seinen Vertragspartner. Dies kann z. B. ein Energieversorgungsun-ternehmen (EVU) oder ein beliebiger anderer E-Mobilitätsanbieter sein. Der Vertragspartnerordnet nun die Zertifikats-ID dem entsprechenden Vertrag in seinem IT-System zu und erstelltein neues Vertragszertifikat, welches ebenfalls an die übermittelte Zertifikats-ID des Provisio-ning Zertifikats gebunden ist. Die Information über einen bestehenden Fahrstromvertrag inZusammenhang mit der Zertifikats-ID des Provisioning Zertifikats des Kunden wird sodann aneine Clearingstelle (Abrechnungsstelle) des entsprechenden Landes weitergeleitet. Idealerweisewird bei dieser Benachrichtigung gleich das entsprechende Vertragszertifikat mitgeliefert, umbeim späteren Autorisierungsprozess an der Ladestation Kommunikationsverzögerungen zuvermeiden.Wann immer der Elektromobilist sein Elektrofahrzeug an einer öentlichen Ladestationladen möchte 4, weist sich die Ladestation gegenüber dem Fahrzeug mittels des Authen-ticationReq/-Res Nachrichtenpaars als vertrauenswürdig aus. Anschließend legen beidegemeinsam einen Sitzungsschlüssel zur abgesicherten Datenübertragung fest. Weitere Detailszum Schlüsselaustausch können auch Abschnitt 6.1.3 entnommen werden. Im weiteren Verlaufsendet der EVCC das OEM Provisioning Zertifikat an die Ladestation. Im Falle des erstenLadevorgangs überhaupt geschieht dies mittels der CertificateInstallationReq Nachricht,im Falle eines abgelaufenen Gültigkeitsdatums mittels der CertificateUpdateReq Nachricht.Diese wiederum leitet das Zertifikat bspw. über das Open Charge Point Protocol (OCPP),auf welches in Abschnitt 2.2.2 bereits eingegangen wurde, an das Backend des Ladestationsbe-treibers weiter. In nächster Instanz kommuniziert das Backend mit der Clearingstelle über einProtokoll, welches diese zur Verfügung stellt. Ein deutschland- und europaweit prominentesBeispiel für ein solches Clearingstellen-Protokoll ist das Open InterCharge Protocol (OICP),welches in Abschnitt 5.2.1 näher betrachtet wird. Falls in einem Land keine Clearingstelleexistiert, so wird diese Information an alle der Ladestation bekannten E-Mobilitätsanbieterweitergeleitet. Die Clearingstelle überprüft dann, ob das OEM Provisioning Zertifikat gültigist, indem der öentliche Schlüssel des entsprechenden OEM Root Zertifikats, welches vomOEM der Clearingstelle bereits zur Verfügung gestellt wurde, zur Verifikation herangezogenwird. Daraufhin wird überprüft, ob bei der Clearingstelle ein Vertragszertifikat registriert ist,welches der Zertifikats-ID des Provisioning Zertifikats zugeordnet wurde.Im letzten Schritt wird das passende Vertragszertifikat (inkl. der Zertifikatskette, die zurValidierung des Vertragszertifikats vonnöten ist) und der dazugehörige private Schlüssel (dieserwiederum über ein symmetrisches Kryptoverfahren verschlüsselt, siehe Abschnitt 6.1.3) andie Ladestation und von dieser mittels der CertificateInstallationRes Nachricht an dasElektrofahrzeug gesendet.Auf den ersten Blick erscheint das Zertifikatskonzept sowie das Bereitstellungsprozedere alsein komplexer Mechanismus, welcher sich erst als praktikabler Ansatz beweisen muss, sobald95Kapitel 5 Das E-Roaming Szenariodie entsprechenden Akteure am Markt dies in ihren Lösungen umsetzen.Im März 2014 hat Hubject damit begonnen, die angeblich weltweit erste produktive E-Mobility-Zertifizierungsstelle für Stammzertifikate in Betrieb zu nehmen [34]. Somit trittdieses Joint Venture als erste europäische Root-CA zur Ausstellung der V2G Root Zertifikatefür Automobilhersteller, Ladeinfrastrukturbetreiber und Fahrstromanbieter auf. Das Wissenum die Richtlinien und die entsprechende Technologie, die zum Betreiben einer PKI vonnötenist, wird hierbei von der IT-Sicherheitsfirma secunet3 bereitgestellt.Das hier vorgestellte Zertifikatsverfahren ist das bis dato einzig beschriebene Verfahren,welches ein E-Roaming Szenario im Bereich der Elektromobilität ermöglicht. Somit könnenAnwendungsfälle abgedeckt werden, in denen ein Elektromobilist öentliche Ladestationennutzen möchte, die nicht von seinem Vertragspartner direkt verwaltet werden, sei es anbieter-übergreifend auf nationaler Ebene oder gar international. Das Hubjet-Netzwerk umfasst bereitseuropäische Roaming-Partner aus Belgien, Frankreich, Österreich, Finnland, den Niederlandenund der Schweiz. Dies mindert die Reichweitenangst der E-Fahrzeug-Nutzer und erhöht dieAkzeptanz für die E-Mobilität im Allgemeinen, da somit ein Kunde bspw. nicht mehr mehrereRFID-Karten verschiedener Hersteller mit sich führen muss, um sich an der entsprechendenLadestation zu authentifizieren und zu autorisieren.Je mehr Marktteilnehmer sich einer solchen E-Roaming-Plattform anschließen, umso besserlässt sich die Vision eines nutzerfreundlichen und einfachen E-Roaming-Prozesses realisieren.Ziel ist es, dass sich der Kunde keine Gedanken um die Möglichkeit, an einer beliebigenöentlichen Ladestation seine Batterie wieder aufzuladen, mehr machen muss. Bevor nun inAbschnitt 5.2 anhand des Joint Ventures Hubject, welches als Clearingstelle im oben genanntenKontext auftreten möchte, dargelegt wird, wie ein solches Roamingnetzwerk aufgebaut seinkönnte, soll im folgenden Abschnitt der Vollständigkeit halber noch auf das vereinfachteZertifikatsmanagement-Konzept im privaten Umfeld eingegangen werden.5.1.6 Vereinfachtes Zertifikatsmanagement im privaten UmfeldDas bisher beschriebene Prozedere des Zertifikatsmanagements ist vor allem auf das Ladenan öentlichen Ladestationen ausgerichtet. Jedoch ist davon auszugehen, dass das Gros derLadevorgänge im privaten Bereich zu Hause oder am Arbeitsplatz an sogenannten halb-öentlichen Ladestationen erfolgen wird. Gerade für den Betreiber einer elektrifiziertenUnternehmensflotte sind folgende Aspekte interessant:• Es ist kein E-Mobilitätsanbieter involviert, über den die bezogene elektrische Energieabgerechnet werden müsste. Das bedeutet auch, dass keine Kommunikation in einBackend nötig ist, was zusätzliche Tarifkosten mit sich bringen würde.• Die Instandhaltung und der Betrieb einer Ladestation müssen einfach und kostengünstigsein, sodass es keiner manuellen Interaktionen mehr bedarf. Kurzlebige Zertifikate sindnicht geeignet.• Es sollte dennoch möglich sein, den einzelnen E-Fahrzeugen eine Ladekurve zu kommu-nizieren, um einen gesteuerten Ladevorgang realisieren zu können.Für das Zertifikatsmanagement im semi-öentlichen und privaten Umfeld liefert die ISO/IEC15118-2 Spezifikation ebenfalls einen Vorschlag, wie Zertifikate einzusetzen sind, wie bereitsin [48] vorgestellt.3http://www.secunet.com965.2 Das Hubject-Modell – Clearingstelle und Anbieter eines E-Mobilitäts-MarktplatzesFür jeden privaten oder halb-öentlichen Bereich (Firmenparkplatz) steht ein sogenannteseinzigartiges Private Operator Root Zertifikat zur Verfügung, welches bspw. vom Liefe-ranten/Hersteller der Ladestationen erstellt und dem Privatnutzer bzw. Fuhrparkbetreiberausgehändigt wurde. Jede Ladestation in diesem speziellen Umfeld wird dann mit einem SECCZertifikat ausgestattet, welches direkt vom Private Operator Root Zertifikat signiert wurde,es gibt hier keine Sub-CAs (vgl. Abbildung 5.1). Diejenigen E-Fahrzeuge, welche in dem spezi-ellen Umfeld laden möchten, bedürfen ebenfalls der Installation des speziell zugeschnittenenPrivate Operator Root Zertifikats, um beim Aufbau einer abgesicherten TLS-Verbindungzur Ladestation auch überprüfen zu können, ob das SECC-Zertifikat tatsächlich vom PrivateOperator Root Zertifikat abstammt.5.2 Das Hubject-Modell – Clearingstelle und Anbieter einesE-Mobilitäts-MarktplatzesDas Rollenmodell hinter Hubject sowie das grobe Konzept eines nutzerfreundlichen Roaming-Vorgangs wird in Abbildung 5.3 illustriert:Abbildung 5.3: Hubject Rollenmodell im E-Roaming Szenario (Quelle: Hubject.com)97Kapitel 5 Das E-Roaming SzenarioEs werden grunsätzlich zwei verschiedene Geschäftsrollen nach dem Hubject-Marktverständnisunterschieden, die ein Marktteilnehmer einnehmen kann: Ladestationsbetreiber oder E-Mobilitätsanbieter.Der Ladestationsbetreiber ist für den Betrieb der Ladeinfrastruktur sowie die Versorgungder einzelnen Ladestationen mit Energie zuständig. Diese Rolle kann bspw. von Energiever-sorgungsunternehmen, aber auch von neuen Akteuren am Markt eingenommen werden, wiebspw. auch einem OEM, der sein eigenes Ladestationsnetzwerk für seine Fahrzeuge betreibt.Am Beispiel der Firma Tesla und ihrer Pläne, auch in Deutschland ein flächendeckendes Netzan Schnellladestationen (Supercharger) aufzustellen, tritt diese Rolle besonders deutlich zuTage. Allerdings ist es noch unklar, ob sich Tesla einem Netzwerk wie Hubject önen würde,da die Firma ihre Supercharger als Premiumangebot für Teslakunden oeriert und somitder Fall eintreten könnte, dass zukünftig ein Tesla-Fahrer nicht mehr an einer Supercharger-Schnellladestation laden kann, weil z. B. ein BMW-Fahrer diese gerade blockiert. Es sollteerwähnt werden, dass streng genommen das Betreiben der Ladeinfrastruktur vom Energiever-sorgerstatus zu trennen ist, da diese Rolle nicht immer auf einen Marktakteur vereint werdenkann. Diese Trennung wird im abgebildeten Rollenmodell jedoch nicht streng vollzogen. Esbietet lediglich eine einfach verständliche Darstellung, in welcher nicht jeder mögliche Partner-status abgebildet wird. Insbesondere die Fahrzeughersteller und Flottenbetreiber finden sichhier nicht wieder.Der E-Mobilitätsanbieter bietet den Kunden Dienstleistungen rund um die E-Mobilität an,im speziellen bspw. Fahrstromverträge. Ein Partner des Hubject-Netzwerks kann auch beideRollen auf sich vereinen, wie es z. B. beim Gründungsmitglied RWE der Fall ist.Das Konzept eines nutzerfreundlichen Roaming-Vorgangs würde laut Abbildung 5.3 nunfolgendermaßen ablaufen: Ein Fahrer eines Elektrofahrzeugs schließt einen Vertrag mit demE-Mobilitätsanbieter seines Vertrauens ab, welcher als Partner im Hubject-Netzwerk registriertsein muss. Fährt dieser Kunde nun eine Ladestation eines Hubject-Partners an, um dort sein E-Fahrzeug zu laden, so authentifiziert und autorisiert er sich über eines der angebotenen Medien.Bisher ist die Identifikation über eine RFID-Karte des Vertragspartners oder die Hubject-eigeneApp möglich, mit Hilfe derer man den auf der Hubject-zertifizierten Ladestation aufgebrachtenQR-Code scannen kann. Zukünftig soll auch der Weg über den Plug-and-Charge Mechanismusmöglich sein. Die Ladestation kommuniziert diese Benutzerdaten samt der Ladestations-ID andas Ladestations-Management-System des Ladestationsbetreibers über das Protokoll OCPP.Dieses Backend-System muss informationstechnisch an die Hubject-Plattform angebundensein, welches über das OICP-Protokoll (siehe Abschnitt 5.2.1) realisiert wird. Über dieseIT-Plattform, welche vom Gründungsmitglied Bosch Software Innovations konzipiert wurdeund betrieben wird, ist es nun möglich, relevante Informationen zwischen allen Partnern desHubject-Netzwerks auszutauschen, die entsprechenden Autorisierungsvorgänge somit durchzu-führen und Abrechnungsprozesse für die Nutzung des Roaming-Dienstes unter den Partnernanzustoßen. Das Kunden-Management-System des Vertragspartners des Elektromobilisten istebenfalls an die IT-Plattform angebunden und kann die Nutzung der Ladesäule basierend aufden Authentifizierungsdaten autorisieren.Laut einer Pressemitteilung4 vom 4. April 2014 sind europaweit bereits 2000 Ladepunktean das Hubject-Netzwerk angeschlossen.Hubject ist nicht das einzige existierende Roaming-Netzwerk, aber das europaweit bis-her größte und ambitionierteste Unternehmen in diesem Bereich. Weitere etablierte und in4http://www.hubject.com/pdf/PM_hubject_20140404.pdf985.2 Das Hubject-Modell – Clearingstelle und Anbieter eines E-Mobilitäts-MarktplatzesDeutschland aktive E-Roaming-Netzwerke sind bspw. Trianel, eine europaweite Stadtwerke-Kooperation, und die smartlab Innovationsgesellschaft, welche die Plattform http://ladenetz.de betreibt, über die bereits 33 Stadtwerke miteinander kooperieren. Die beiden Aachener Un-ternehmen, die zusammen nun 88 Stadtwerke vereinen, unterzeichneten auf der E-world 20145einen Kooperationsvertrag, dessen Ziel die gemeinsame Entwicklung eines Geschäftsmodells ist,welches letzten Endes einen barrierefreien Zugang zur Ladeinfrastruktur für Elektromobilistenbereitstellen soll [69].Um Synergien bestmöglich zu nutzen, wäre es eher hinderlich, wenn diese unterschiedlichenRoaming-Netzwerke in Konkurrenz zueinander treten würden. Angesichts der stellenweisenoch recht geringen Auslastung öentlicher Ladestationen ist eine Kooperation innerhalbdieser E-Roaming-Netzwerke sogar vorteilhaft für jeden Ladestationsbetreiber, da somitder Energiedurchsatz insgesamt erhöht werden könnte. Daher verfolgt Hubject ein Konzept,welches sich „Hubbing the Hub“ nennt und über die Abbildung 5.4 verdeutlicht werden soll. © Hubject GmbH 2013 Auf die Vorteile eines Spoke models bzw. Hub and Spoke-Ansatzes zur Reduktion von Komplexität, Kosten und Intransparenz wird auch in der Telekommunikationsindustrie und der Finanzindustrie bereits verwiesen. Insgesamt kann mit diesen Modellen ein effizientes, freies und nachhaltiges Marktwachstum - unter Berücksichtigung von Effizienzfaktoren wie Systemsicherheit, Gebühren und Geschwindigkeit - gewährleistet werden. Abbildung 5.4: Hubject Rollenmodell im E-Roaming Szenario [33]Im linken B ld „Meshed network“ ist das Szenario ve bildlicht, in welchem eine Vielzahlan bilateralen Nutzungsverträgen nötig ist, damit jeder Kunde eines E-Mobilitätsanbietersan den Ladestationen eines anderen Anbieters sein Fahrzeug laden kann. Das mittlere Bildillust iert den Fall eines gemeinsam vertraglichen Rahm nwerks und ein r technischenSchnittstelle, wie es Hubject anbietet, auf welches sich alle E-Mobilitätsanbieter einigen. ImFalle bereits existierender Rahmenwerke, die verschiedene Akteure in einem Netzwerk untereinem jeweiligen Dach vereinen, wie es z. B. mit Trianel oder smartlab der Fall ist, könnendiese Netzwerke über das „Hubbing the Hub“ Speichenmodell (Spoke model) gemeinsam mitder Hubject Plattform verbunden werden. Es bedarf dann lediglich einer Verbindung zwischeneinem Vertreter des Netzwerks und der Hubject Plattform.5http://www.e-world-essen.com/de/99Kapitel 5 Das E-Roaming Szenario5.2.1 Das Open InterCharge Protocol (OICP)Hubject veröentlichte sein Open InterCharge Protocol [32] im April 2013. Der Informations-austausch zwischen der Hubject Plattform und dem IT-System eines E-Mobilitätsanbieters(E-Mobility Provider (E-MP)) bzw. Ladestationsbetreibers (Charge Point Operator (CPO))basiert mit Version 1.0 des Protokolls auf SOAP-Nachrichten (Simple Object Access Pro-tocol), über die die folgenden fünf Dienste oeriert und in Anspruch genommen werden können.HubjectAuthorizationDieser Dienst muss von Hubject sowie den E-MPs oeriert werden und dient der Autorisationeines Ladevorgangs an einer Ladestation. Die Autorisation kann über mehrere Stufen erfolgen.In erster Linie wird das Backend-System des CPO versuchen, den Ladevorgang anhand derAuthentifizierungsdaten selbst zu autorisieren. Ist dem CPO dieser Nutzer nicht bekannt,so wird eine HubjectAuthorizeStart Nachricht an Hubject gesendet, welche die ID desCPOs und die Authentifikationsdaten (z. B. die Vertrags-ID) beinhalten muss und optionaldie Ladepunkt-ID6 mitführen kann. Anschließend gibt es drei Optionen:1. Hubject versucht oine die Authentifizierungsdaten einem gültigen Vertrag mit ei-nem registrierten E-MP zuzuordnen. Diese Daten können von den E-MPs durch denHubjectAuthenticationData-Dienst bereitgestellt werden.2. Falls keine Autorisierung oine möglich ist, wird versucht, die HubjectAuthorizeStartNachricht direkt an den entsprechenden E-MP weiterzuleiten. Im Falle der Authentifizie-rung mittels eines QR-Codes oder des Plug-and-Charge Mechanismus wird bereits dieVertrags-ID mitgeliefert, anhand derer der zugehörige E-MP ausfindig gemacht werdenkann. Dieser wird dann mit einer Bestätigung oder Ablehnung der Anfrage antworten.Ist aus technischen Gründen der E-MP nicht kontaktierbar, wird die Autorisierungebenfalls als fehlgeschlagen gewertet.3. Falls der zugehörige E-MP nicht aus den Authentifizierungsdaten abgeleitet werden kann,wie es bei einer RFID-Karte der Fall ist, so sendet Hubject in einer Broadcast Nachrichtdie Authentifizierungsanfrage an alle E-MPs weiter, die über die Hubject-Plattform ineinem Vertragsverhältnis mit dem CPO der betreenden Ladestation stehen.Ist der Ladevorgang erst einmal autorisiert, so werden wichtige Sessiondaten, wie bspw. dieSessionID, EVSEID und die Authentifikationsdaten, persistiert. Die im OICP definiertenNachrichten, welche dem HubjectAuthorization-Dienst zugeordnet sind, erlauben nebender Ladeautorisation direkt vor Ort an der Ladestation auch eine Fernbedienung bspw. übereine App. Im Anschluss an eine Ladesession wird ein sogenannter ChargeDetailRecord demE-MP bereit gestellt, welcher über die bezogene Energiemenge informiert.HubjectEvseSearchDieser Dienst muss ebenfalls sowohl von Hubject als auch von den E-MPs oeriert werdenund dient dazu, in einem bestimmten Gebiet sämtliche Ladestationen aller CPOs aufzulisten,mit denen der E-MP über die Hubject Marktplattform einen Vertrag abgeschlossen hat. Somitkann einem Nutzer über eine vom E-MP bereitgestellte graphische Benutzungsschnittstelle einesolche Übersicht dargestellt werden. Innerhalb einer HubjectSearchEvse Nachricht müssendie ProviderID des E-MP sowie geographische Angaben, seien es Geokoordidaten oder eine6Eine Ladestation (EVSE) kann mit mehreren Ladepunkte ausgestattet sein.1005.2 Das Hubject-Modell – Clearingstelle und Anbieter eines E-Mobilitäts-Marktplatzesbestimmte Adresse, samt optionaler einschränkender Parameter wie bspw. der Umkreis desSuchfeldes enthalten sein.Diese Dienstbeschreibung macht noch einmal das Geschäftsverständnis des Hubject Kon-sortiums deutlich: Anstatt diverser Schnittstellen für die Kommunikation zwischen mehre-ren proprietären Systemen soll lediglich eine B2B-Marktplattform mit einer einheitlichenIT-Schnittstelle geschaen werden, über welche die teilnehmenden Partner bilaterale Roaming-Verträge mit freier Preisgestaltung abschließen können. Dies bedeutet, dass ein E-MP nichtnotwendigerweise sogleich mit allen Partnern des Hubject-Netzwerks ein Roaming-Abkommengeschlossen hat, sobald er selbst Partner des Netzwerks geworden ist. Zugleich bedeutet dies fürden Nutzer, dass er bei einer Ladestationssuche, die er über eine Benutzungsschnittstelle seinesVertragspartners (E-MP) durchführt, nicht notwendigerweise alle an das Hubject-Netzwerkangebundene Ladestationen auf der Ergebnisliste finden wird. Es sollte jedoch das Ziel sein,dass sich alle Vertragspartner untereinander tariflich einig werden, sodass für den Endkundender bestmögliche Nutzen gewährleistet werden kann.HubjectEvseDataDieser Dienst wird nur von Hubject angeboten und erlaubt es, Authentifizierungsdatenzwischen verschiedenen Hubject Partnern auszutauschen. Die Beschreibung des HubjectAu-thorization-Dienstes legt dar, wie über die Hubject IT-Plattform Autorisierungsanfragenonline an den entsprechenden E-MP weitergeleitet werden können. Mit Hilfe des HubjectEvse-Data-Dienstes ist es einerseits den E-MPs möglich, Authentifizierungsdaten auf die HubjectIT-Plattform hochzuladen und andererseits ermöglicht es den CPOs, diese Daten auf ihreeigenen Systeme herunterzuladen. Dies hat den Vorteil, dass im Idealfall eine Autorisierungeiner Ladeanfrage direkt durch das IT-System des entsprechenden CPOs erfolgen kann, ohnedass eine zeitliche Verzögerung über die Hubject IT-Plattform vonnöten ist.HubjectEvseStatusHubject erlaubt es, dynamische und statische Informationen über Ladestationen über seinePlattform zwischen verschiedenen Partnern auszutauschen. Dieser Dienst wird bspw. vonE-MPs in Anspruch genommen, um einem Kunden über eine Benutzungsschnittstelle die Listealler Ladestationen in einem angegebenen radialen Umfeld zusammen mit ihrem Belegungs-status anzuzeigen, ggf. mit der Option, eine freie Ladestation gleich zu reservieren.Die Sicherheitsaspekte betreend kann an dieser Stelle keine Aussage zum OICP gemachtwerden, da das Protokoll hierzu keinerlei Auskunft gibt.Hubject ist im Bereich des E-Roaming nicht die einzige Initiative, jedoch scheint sie mitAbstand die größte Anzahl an Partnern im operativen Betrieb zu haben.Darüber hinaus existiert mit e-clearing.net7 ein Zusammenschluss der drei europäischenLadenetzbetreiber Blue Corner (Belgien), Ladenetz.de (Deutschland) und e-laad.nl (Nieder-lande). Die Kunden von e-clearing.net können basierend auf dem auf SOAP-Nachrichtenbasierenden, oenen Open Clearing House Protocol (OCHP) somit an allen bisher ca. 1.500Ladestationen, die zu diesem Bezahlsystem-Verbund gehören, ihre Fahrzeuge aufladen. ImRahmen dieser Arbeit wird jedoch nicht näher auf dieses Netzwerk eingegangen.Stattdessen soll abschließend das europäische Forschungsprojekt Green eMotion kurz beleuch-tet werden, dessen 43 Partner aus Industrie- und Automobilunternehmen, Stromversorgern,Stadtverwaltungen sowie Forschungseinrichtungen das Ziel verfolgen, einen kundenfreundlichen7http://www.e-clearing.net101Kapitel 5 Das E-Roaming Szenariound interoperablen E-Mobilitäts-Marktplatz auf Basis einer B2B-Plattform zu entwickeln undzu demonstrieren.5.3 Green eMotion – Europäischer Marktplatz aus derForschungsperspektiveDas Projekt Green eMotion wurde am 31. März 2011 von der Europäischen Kommission insLeben gerufen und hat eine Laufzeit von vier Jahren, innerhalb derer die Grundlagen für eineneuropaweiten Massenmarkt der Elektromobilität geschaen werden sollen8. Mit einem Pro-jektbudget von 42 Millionen Euro soll ein europäischer virtueller Marktplatz für E-Mobilitäts-Dienste implementiert werden, welcher dazu dient, in ausgewählten Demonstrationsregionenin ganz Europa die Interoperabilität eines verbraucherfreundlichen E-Mobilitäts-Systems sowiesinnvolle E-Mobilitäts-Mehrwertdienste zu testen.Im Rahmen dieses Projekts wird eine IT-Infrastruktur samt der nötigen Schnittstellenzur Erstellung, Verwaltung und Nutzung diverser Dienste für einen solchen europäischenMarktplatz definiert und implementiert. In der Terminologie von Green eMotion wird zwi-schen dem „Green eMotion EV Services Market“ und einem „Green eMotion Marketplace“unterschieden, wobei das Konzept vorsieht, dass mehrere Marktplätze im EV Services Marktkoexistieren können und die darin von „Service Providern“ zur Verfügung gestellten Diensteüber Marktplatzgrenzen hinweg von „Service Requestern“ genutzt werden können. Der GreeneMotion Marketplace agiert hierbei als Dienstvermittler für B2B E-Mobilitäts-Dienste.Es wird zwischen vier verschiedenen Dienstkategorien unterschieden:• Core ServicesBasisdienste, die zur Nutzung aller anderen Dienste zwingend notwendig sind unddas Fundament des Green eMotion Marktplatzes darstellen. Beispiele hierfür sind dieRegistrierung der jeweiligen B2B Geschäftspartner, die Erstellung von Dienstnutzungs-verträgen, die Registrierung und Überwachung der Dienste sowie die Abrechnung derDienstenutzung.• Value Added ServicesB2B-Dienste, welche einen Mehrwert über die Funktionalität der Basisdienste fürden Endkunden (Basic End User Services) hinaus bieten, speziell hinsichtlich desE-Mobilitätskontextes, wobei dies keine Einschränkung darstellen soll. Die Abgrenzungzu den Basisdiensten ist nicht immer trennscharf, jedoch könnten unter Mehrwert-diensten bspw. die Reservierung von Ladepunkten, das Lastmanagement sowie einCO2-Berichtswesen verstanden werden.• Clearing House ServicesDiese Art Dienste ermöglichen die Abwicklung von Roamingprozessen von bspw. grenz-überschreitenden Ladevorgängen. Bei Clearing House Services wird zwischen den zweiKategorien Vertragsabwicklung und Finanztransaktionsabwicklung unterschieden.• Basic End User ServicesDie Basisdienste für Endkunden stellen die minimal nötige Funktionalität für ein ver-braucherfreundliches und interoperables E-Mobilitätserlebnis dar. Hierzu zählt u. a. dasAunden verfügbarer Ladestationen in einem gewissen Umkreis.8http://www.greenemotion-project.eu/1025.3 Green eMotion – Europäischer Marktplatz aus der ForschungsperspektiveAbbildung 5.5 zeigt eine architektonische Übersicht über die Struktur des Green eMotion EVService Market. Hierbei ist zu sehen, dass die Service Requester Inanspruchnehmer andererB2B-Dienste (Value Added Services und Clearing House Services) sind, um ihren Endkundenwiederum Dienste anbieten zu können, die sich ggf. aus der Nutzung fremder Mehrwertdiensteergeben. Service Requester können gegenüber anderen B2B-Akteuren des Marktplatzes auchals Service Provider auftreten. GA MOVE/FP7/265499/Green eMotion WP 3: Deliverable 3.2 Page 16 of 60 Figure 3-1: Architectural Overview GeM EV Service Market 3.2 Marketplace Level As described above the GeM Marketplace acts as a Business-to-Business (B2B) Service Broker. The consumer has a contractual relationship with an End User Service Provider. The End User Service Provider is offering Basic End User and/or Value Added Services to consumers. The relations are depicted in Figure 3-2. (Note: The white boxes in the diagram simply reflect a certain service of the corresponding service type).To fulfil its service it acts as Service Requester and uses Core Services and/or Clearing House Services provided on the Marketplace. The End User Service Provider (B2C) might also use other Basic End User or Value Added Services offered on the Marketplace to fulfil its service. As a prerequisite a contractual relationship has to be established between the business partners clarifying the terms and conditions under which a service can be used. The Basic End User Services will most likely run in the End User Service Provider environment. In addition the Marketplace will also offer an environment to run these services, if the (End User-) Service Provider has no own capabilities to host and execute these services. Abbildung 5.5: Architektur des Green eMotion EV Servcie Market [30]Wie bereits angesprochen, können mehrere Marktplätze koexistieren, die entweder völligunabhängig voneinander agieren oder eine Verbundstruktur (hierarchisch, peer-to-peer) ein-gehen. Die E-Mobilitätsdienste können über einen solchen Marktplatz oder auch über eineirekte bilaterale Vertragsbezi hung zwische B2B-Diensteanbiet rn oeri werden.Es werden diverse Marktrollen definiert, die ein Marktakteur einnehmen kann, um als ServiceProvider, Service Requester oder gar beides zu agieren. Hierzu zählen bspw. Stromversorger,Verteilnetzbetreiber, Übertragungsnetzbetreiber, Automobilhersteller, Diensteanbieter für E-F hrzeugnu zer, La einfrastrukturbetre ber, Mobilitäts-Diensteanbieter und Stadtverwaltung.Wie zu erkennen ist, ergeben sich hier Parallelitäten zwischen dem Ansatz von Hubject unddem von Green eMotion. Ein Endkunde muss stets nur eine Vertragsbeziehung mit einemder Marktakteure unterhalten, um die Dienste anderer Akteure, wie bspw. das Laden anfremder Ladeinfrastruktur, in Anspruch nehmen zu können. Es ist jedoch auch klar ersichtlich,dass der Rahmen, den Green eMotion sich gesteckt hat, um einiges weiter gefasst ist als derRahmen des Joint Ventures Hubject, welches sich bisher nur auf die Abrechnungsdienste fürdas E-Roaming (Clearing House Services) fokussiert.Abschließend soll mit Abbildung 5.6 deutlich gemacht werden, wie komplex die Referenzar-chitektur für die angesprochene B2B-Diensteplattform aufgebaut ist. Die grün eingefärbten103Kapitel 5 Das E-Roaming SzenarioFelder kennzeichnen Elemente der Plattform, welche im Rahmen der Demoregionen realisiertund erprobt werden sollen. GA MOVE/FP7/265499/Green eMotion WP 3: Deliverable 3.2 Page 22 of 60 For the Green eMotion demonstration project, the focus will be on a subset of the identified architectural building blocks. Figure 3-5: Reference Architecture - Demonstration Focus Note: The service execution location/domain is not finalized yet. The decision if a certain Basic End User Service, a Value Added Service and a Clearing House Service is executed in Marketplace Service Execution Domain or in the Service Providers own IT Environment will be taken later. 3.2.2 Operational View The operational view describes how the above described Reference Architecture is hosted and run in a production environment. For the operation of the GeM Marketplace two main options were considered: 1. Conventional approach with dedicated hardware systems to host the Marketplace system 2. Cloud environment to host the Marketplace system For the GeM Marketplace the best choice is the cloud option. The most compelling reason of the cloud approach is the flexibility of resource allocation. The Marketplace might start with only a few business services, but the cloud infrastructure enables it to scale up in an easy way, without the need of manual migration to other systems and with costs reflecting the actual usage of resources. Even for a small scale Marketplace deployment it can benefit from the high availability and fail over capabilities of an underlying cloud infrastructure to recover from hardware or software failures. Furthermore the cloud infrastructure helps separating concerns of the Marketplace operator and the IT infrastructure provider. Both roles can be accomplished by different organizations. In addition business partners of the Marketplace planning to sell services, but don’t have own computing resources, can use resources on the cloud to develop, test Abbildung 5.6: Referenzarchitektur – Demonstrationsfokus [30]104KAPITEL 6EVALUATIONBei der Kommunikation mit dem Elektrofahrzeug wird auf den internationalen StandardISO/IEC 15118 gesetzt, um zum einen das Untersuchungsszenario durch die Nutzung einesgenormten Kommunikationsprotokolls so realistisch und zukunftsfähig wie möglich zu gestaltenund andererseits die Eignung dieser Norm für das gesteuerte Laden u. a. im Heimbereichaufzuzeigen. Daher wird in Abschnitt 6.1 zuerst eine Bewertung der Zukunftsfähigkeit derISO/IEC 15118 Norm anhand des zweiten Teils (ISO/IEC 15118-2) vorgenommen, bevor imweiteren Verlauf dieses Kapitels auf die konkreten Ergebnisse eingegangen wird, die durch dieEinbindung des Elektrofahrzeugs in das EMS des Smart Home erzielt werden konnten.6.1 Zukunftsfähgikeit der ISO/IEC 15118 NormMöchte man einen internationalen Standard bewerten, so bieten sich in erster Linie diefolgenden Kriterien an:• Akzeptanz• Erweiterbarkeit• Sicherheit• Ezienz• KomplexitätLetzten Endes haben die Bewertungskriterien Komplexität, Erweiterbarkeit, Ezienz undSicherheit auch eine direkte Auswirkung auf die Akzeptanz, dennoch soll in Abschnitt 6.1.1die Akzeptanz mehr vor dem Hintergrund der bereits laufenden Aktivitäten in der Automobil-industrie, der Energiewirtschaft und der Ladeinfrastrukturbetreiber verstanden werden.6.1.1 AkzeptanzEs mag auf den ersten Blick eher in einer vagen Vermutung münden, einen Kommunikations-standard, welcher erst kürzlich als international gültiger Standard (IS) veröentlicht wurde105Kapitel 6 Evaluation(siehe Tabelle 2.1), hinsichtlich seiner Akzeptanz zu bewerten. Die entsprechenden Markt-teilnehmer im Elektromobilitätsmarkt möchten natürlich ihre Investitionskosten möglichstgering halten und fürchten demnach überhöhte Implementierungsausgaben für einen Standard,dessen technische Spezifikation sich auf dem Weg zum IS noch im Wandel befand. Dennochlassen sich schon jetzt Anzeichen dafür finden, wie breit dieser Standard Unterstützung findet.Weltweit beginnen Hersteller von Elektroautos und Ladeinfrastruktur sowie diverse Zulie-ferfirmen, die Anforderungen des Ladestandards umzusetzen und bringen bereits jetzt schonProdukte auf den Markt. Tabelle 6.1 liefert eine Übersicht über Firmen, die bereits ersteProdukte, welche die Spezifikationen in ISO/IEC 15118-2 oder -3 umsetzen, verkaufen. BeiFirmen, denen ein konkretes Produkt zugeordnet werden kann, ist das Produkt vermerkt,andernfalls ist ein Hinweis auf das Projekt gegeben, an welchem die Firma beteiligt ist.Eine Kurzvorstellung der Projekte soll darüber hinaus die Beziehung zum ISO/IEC 15118Standard verdeutlichen. Das Joint Venture Hubject [35] wurde bereits in Kapitel 5 vorgestellt.openV2GDas Open-Source-Projekt openV2G [68] wurde durch die Siemens Corporate Technology unddie TU Dortmund ins Leben gerufen und hat zum Ziel, eine freie Referenzimplementierungauf Basis der Programmiersprache C zur Verfügung zu stellen. Die mittlerweile erhältlicheVersion 0.8 basiert auf dem FDIS-Status der ISO/IEC 15118-2.eNteropDas vom BMWi geförderte Projekt eNterop [67] hat sich zum Ziel gesetzt, eine Referenzplatt-form für automatisierbare Testabläufe in Software und Hardware zu realisieren, um Firmenund Institutionen die Möglichkeiten zu bieten, ihre Implementierung der ISO/IEC 15118-2und -3 auf Standardkonformität hin zu überprüfen. Somit wird die Interoperabilität diverserLösungen gefördert, was einen wichtigen Schritt hin zu einer funktionierenden E-Mobilitätbedeutet. Hierbei werden die Teile ISO/IEC 15118-4 und -5 zu Grunde gelegt, welche entspre-chende Konformitätstests für die Teile 2 und 3 der Norm beschreiben.SecMobilDas ebenfalls vom BMWi im Rahmen von IKT für Elektromobilität II geförderte Projekt Sec-Mobil [23] bearbeitet Fragestellungen bzgl. der IT-Sicherheit im Kontext der Elektromobilität.Es werden u. a. diverse Standards, insbesondere Eichvorschriften und BSI-Anforderungen fürein sicheres eMetering sowie die ISO/IEC 15118-2 Norm beachtet und Anregungen für dieWeiterentwicklung solcher Standards gegeben.Vor dem Hintergrund der bereits bestehenden Produktpalette und Forschungsprojekte, diedie ISO/IEC 15118 Norm adressieren, und der Tatsache, dass sich gar Teile der Norm nochim Entwicklungsstadium befinden, ist die Bedeutsamkeit und Akzeptanz dieser Spezifikationals vergleichsweise hoch einzustufen. Der Konsens, der zwischen den am Standard arbeitendendrei unterschiedlichen Industriezweigen – Automobilindustrie, Energiewirtschaft und Ladein-frastrukturhersteller – auf internationaler Ebene mit Beitragenden aus der EU, den USA,Japan, China und Südkorea erreicht werden konnte, unterstreicht diese Aussage.Darüber hinaus wird im „Technischen Leitfaden Ladeinfrastruktur“ [50], welcher von derNationalen Plattform Elektromobilität herausgegeben wurde, empfohlen, „bei größeren Instal-lationen [. . . ] zumindest die Möglichkeit einer Nachrüstung der Kommunikationsmöglichkeitnach ISO/IEC 15118“ zu bedenken. Zudem wird darin erwähnt, dass für den in Abschnitt 2.1.11066.1 Zukunftsfähgikeit der ISO/IEC 15118 NormTabelle 6.1: Übersicht über bereits bestehende Firmen-Aktivitäten bzgl. ISO/IEC 15118Firma Tätigkeitsbereich Produkt / ProjektmitgliedAuronik Anbieter von Infotainment- und Na-vigationstechnologie für die Automo-bilindustrieSoftwarestacks (ECommStack), Test-suites und Steuergeräte [8]BMW Automobilhersteller BMW i3 und BMW i8 (angekündigt),Gesellschafter bei Hubject, Projekt-mitglied eNteropBosch Software zur Steuerung der E-Roaming Prozesse über Hubject-NetzwerkeMobility Starter Package [12]ContinentalAGAutozulieferer Projektmitglied eNteropDaimler Automobilhersteller Smart, A-Klasse und E-Klasse (ange-kündigt), Gesellschafter bei Hubject,Projektmitglied eNterop und SecMo-bil, Projekt mit RWE und Universityof California San Diego [59]Ebee SmartTechnolo-gies GmbHTechnologieanbieter für dieEnergieversorgungs- und Auto-mobilindustrieKompakter Ladepunkt [20]EnBW Energieversorger Gesellschafter bei HubjectESCRYPTGmbHEmbedded Security Konsortialführer SecMobilInSys Industrielle Datenkommunikation INSYS Powerline GP [38]KEBA Ladeinfrastrukturanbieter KeContact M10 [41]RWE Energieversorger und Ladeinfrastruk-turanbieterProjektmitglied eNterop und Gesell-schafter bei Hubject, Projekt mitDaimler und University of CaliforniaSan Diego [59]Siemens Elektronik und Energietechnik Konsortialführer eNterop, Projekt-mitglied openV2G und Gesellschafterbei HubjectSMA Hersteller von Solar-Wechselrichtern Projektmitglied INEESVectorInformatikEntwicklung von Embedded Electro-nicsMICROSAR IP und CANoe.IP [71]VW Automobilhersteller Projektmitglied eNterop107Kapitel 6 Evaluationeingeführten Ladestandard Combined Charging System die Kommunikation über ISO/IEC15118 zwingend erforderlich ist.6.1.2 ErweiterbarkeitDas in Abbildung 2.9 abgebildete Vehicle-to-grid Transfer Protocol (V2GTP), angesiedelt aufder Sitzungsschicht, ist ein innerhalb der ISO/IEC 151182-Spezifikation definiertes Kommuni-kationsprotokoll basierend auf TCP/TLS zwischen zwei sogenannten „V2GTP entities“, alsodem EVCC und dem SECC. Die Protokolldefinition schreibt einen aus 8 Byte bestehendenHeader und einen Payload mit einer maximalen Größe von 4 GB vor, wie Abbildung 6.1 zuentnehmen ist. Die Protokollversion, auf die sich beide Kommunikationspartner mittels der,62)',6(,62,(& ±$OOULJKWVUHVHUYHG >9*@ $ 9*73 HQWLW\ SURYLGLQJ D GHVWLQDWLRQ SRUW VKDOO VXSSRUW DW OHDVW RQHFRQQHFWLRQRQ WKH ORFDOSRUW9*B'67B7&3B'$7$ DVGHILQHG LQ7DEOH >9*@ $ 9*73 HQWLW\ SURYLGLQJ DGHVWLQDWLRQSRUWPD\VXSSRUWPXOWLSOHVLPXOWDQHRXVFRQQHFWLRQVRQWKHORFDOSRUW9*B'67B7&3B'$7$ DVGHILQHG E\7DEOH >9*@ $ 9*73 HQWLW\ XVLQJ D VRXUFH SRUW VKDOO VXSSRUW DW OHDVW RQH FRQQHFWLRQ RQ WKH ORFDO SRUW9*B65&B7&3B'$7$ DVGHILQHG LQ7DEOH >9*@ $ 9*73 HQWLW\ XVLQJ D VRXUFH SRUW PD\ VXSSRUW PXOWLSOH FRQQHFWLRQV RQ WKH ORFDO SRUW9*B65&B7&3B'$7$ DVGHILQHG LQ7DEOH (VSHFLDOO\IRUDQ(9&&DQGDQ6(&&WKH IROORZLQJ DSSOLHV >9*@ 7KH (9&&VKDOOXVHDVRXUFHSRUW9*B65&B7&3B'$7$ DVGHILQHG LQ7DEOH >9*@ 7KH 6(&&VKDOOSURYLGH DGHVWLQDWLRQSRUW9*B'67B7&3B'$7$ DVGHILQHG LQ7DEOH >9*@ 7KH (9&& VKDOO VXSSRUW DW OHDVW RQH FRQQHFWLRQ IRU D 9* &RPPXQLFDWLRQ 6HVVLRQ RQ SRUW9*B65&B7&3B'$7$ >9*@ 7KH 6(&& VKDOO VXSSRUW DW OHDVW RQH FRQQHFWLRQ IRU D 9* &RPPXQLFDWLRQ 6HVVLRQ RQ SRUW9*B'67B7&3B'$7$>9*@ 7KH (9&& VKDOO XVH WKH SRUW 9*B'67B7&3B'$7$ UHWXUQHG LQ WKH ODVW 6(&& 'LVFRYHU\UHVSRQVHPHVVDJHUHIHU WRVXEFODXVH IRU FRQQHFWLQJ WKH6(&& 3URWRFRO'DWD8QLW 6WUXFWXUH7KH 9*733'8FRQVLVWVRIDKHDGHU DQGDERG\VHFWLRQDVVKRZQ LQ)LJXUH)LJXUH²9*730HVVDJHVWUXFWXUH7KH SD\ORDG FRQWDLQV WKH DSSOLFDWLRQ GDWD HJ D 9* PHVVDJH 7KH KHDGHU VHSDUDWHV WKH SD\ORDGV LHLQGLYLGXDO 9*73PHVVDJHVZLWKLQDE\WHVWUHDPDQGJLYHV LQIRUPDWLRQ IRU WKHSD\ORDG SURFHVVLQJ 7KH 9*73PHVVDJH KHDGHU VWUXFWXUH LV VKRZQ LQ )LJXUH DQGGHVFULEHG LQ7DEOH7KHVXSSRUWHGSD\ORDGW\SHVDUHGHVFULEHG LQ7DEOH %\WH1R3URWRFRO9HUVLRQ ,QYHUVH3URWRFRO9HUVLRQ3D\ORDG7\SH 3D\ORDG/HQJWK+HDGHU)LHOG)LJXUH²9*730HVVDJHKHDGHUVWUXFWXUHAbbildung 6.1: Header-Struktur einer V2GTP-Nachricht [39]supportedAppProtocol-Nachricht (siehe Abschnitt 2.2.1, Seite 33) geeinigt haben, wird imersten Byte übertragen, gefolgt von ihrer bitweisen Inversen, die für eine Verifikation genutztwird. Die mit zwei Bytes Länge im Standard definierten Payloadtypen sind in Tabelle 6.2aufgelistet. Mit den letzten beiden Bytes des Headers wird über die eigentliche Länge derNachricht informiert. Eine Payloadlänge von bis zu 4 GB erscheint angesichts des Einsatz-zwecks in eingebetteten Systemen wie dem Elektrofahrzeug, wo die Speichergröße aufgrundder Skaleneekte beim Automobilbau einen wichtigen Kostenfaktor darstellt und meist geringgehalten wird, als zu groß und wird sehr wahrscheinlich nie ausgenutzt werden. Vielmehrwurde sich hierbei am Standard ISO 134001 orientiert, welcher bereits im Automobilbereichzum Einsatz kommt. Die aktuelle Spezifikation [39] erlaubt das Senden einer Nachricht mitTabelle 6.2: Übersicht über die in einer V2GTP-Nachricht erlaubten Payloadtypen (nach [39])Payloadtyp Wert Payloadtyp Name0x000 – 0x8000 Reserviert0x8001 EXI-kodierte V2G-Nachricht0x8002 – 0x8FFF Reserviert0x9000 SDP Request-Nachricht0x9001 SDP Response-Nachricht0x9002 – 0x9FFF Reserviert0xA000 – 0xFFFF Herstellerspezifische Nutzungeinem dem EVCC oder SECC unbekannten Payloadtyp, ohne dass die Kommunikationssessiondaraufhin abgebrochen wird. Als Folge wird die Nachricht mit dem der jeweiligen Gegenseiteunbekannten Payloadtyp einfach ignoriert.1“Road vehicles - Diagnostic communication over Internet Protocol (DoIP) – Part 2: Transport protocol andnetwork layer services", http://www.iso.org/iso/catalogue_detail.htm?csnumber=537661086.1 Zukunftsfähgikeit der ISO/IEC 15118 NormWie in Abschnitt 4.2, Seite 57 bereits erklärt, wurden die Nachrichten ChargeParameter-DiscoveryReq und ChargingStatusReq um gewisse Parameter erweitert, die u. a. für In-formationen bzgl. der Rückspeisung von Energie eingeführt wurden. Nun gibt es generellzwei Möglichkeiten, eine solche Parametererweiterung der Nachrichten durchzuführen unddennoch eine standardkonforme Implementierung zu gewährleisten, wie in den nächsten beidenAbsätzen erläutert wird.Direkte Änderung der NachrichtendefinitionDas EXI-Format verfolgt den Ansatz, Schemainformationen aus einem XML-Schema in eineEXI-Grammatik zu transformieren, da diese EXI-Grammatik um einiges leichter zu prozessie-ren ist als die Schemainformation einer XSD-Datei und somit einen Geschwindigkeitsvorsprungmit sich bringt. Ein EXI-Bytestrom wird unter der Verwendung desselben XML-Schemassowohl erzeugt wie auch wieder dekodiert. Ist nun ein Element einer zu übermittelndenNachricht wie bspw. der Paramter eAmountDischarge für die rückspeisefähige Energiemengenicht im der Nachricht zugeordneten XML-Schema definiert und mit einem sogenanntenNamespace versehen, so ist dieser Parameter als Schemaabweichung nach [73] zu kodieren [39].Hierbei werden unbekannte einfache Datentypen evtl. datentypkonform auch wieder kodiert,wohingegen komplexere unbekannte Datentypen im Klartext übertragen werden. Für dieseSchemaabweichung wird eine Ausnahmebehandlung im entsprechenden EXI Codec benötigt,was wiederum die Implementierung des Codecs aufwändiger macht.Separates Schema und neuer PayloadtypÜblicherweise wird jeder EXI-kodierten Nachricht im V2GTP-Header gemäß Tabelle 6.2 derPayloadtyp mit dem Wert 0x8001 zugewiesen. Will man aber eine Parametererweiterung derNachrichten vornehmen, ohne das entsprechende XML-Schema ebenfalls anzupassen – was eineInkompatibilität zum oziellen Standard und somit zu standardkonformen Implementierungenanderer Hersteller mit sich bringen würde – oder eine Schemaabweichung in Kauf zu nehmen,so gibt es die Möglichkeit, einfach zusätzlich einen weiteren Payloadtyp, bspw. mit dem Wert0xA000, zu verwenden. Hierbei sind jedoch folgende Schritte zu beachten, die am Beispieleiner erweiterten ChargeParameterDiscoveryReq-Nachricht verdeutlicht werden:1. Es muss ein separates Nachrichtenobjekt erstellt werden, welches bspw. ChargeParame-terDiscoveryReqExtension heißen könnte. Für diese Nachricht muss man sich nun füreine der beiden folgenden Optionen entscheiden:a) Man erstellt ebenfalls ein separates XML-Schema, gegen das die Nachricht validiertwerden kann, um sie wiederum im EXI-Format kodieren zu können.b) Man wählt eine beliebige Datenkodierung, welche generisch von der Applikationgeparst werden kann, wie bspw. das sehr flexible JSON-Format2.Hierbei ist es wichtig, dass die entsprechend gewählte Kodierung einer Kennung zugeord-net ist, die beiden Seiten (EVCC und SECC) bekannt ist. Dies kann bspw. mit einemspeziellen Payloadtyp verknüpft werden. So könnte man eine separate EXI-Kodierungmit dem Payloadtyp 0xA000 und eine JSON-Kodierung mit dem Payloadtyp 0xA001versehen.2. Im Zustandsautomaten des SECC muss ein weiterer Zustand implementiert sein, welcher2JSON steht für JavaScript Object Notation und ist ein ebenfalls kompaktes Datenformat in für Mensch undMaschine einfach lesbarer Textform.109Kapitel 6 Evaluationden Inhalt dieser zusätzlichen Nachricht entweder direkt vor oder direkt nach demEmpfang einer ChargeParameterDiscoveryReq-Nachricht verarbeiten kann.3. Da Nachrichten mit unbekannten Payloadtypen laut der ISO/IEC 15118-2-Spezifikationeinfach ignoriert werden, muss lediglich auf Fahrzeugseite, also auf Seiten des EVCC,darauf geachtet werden, dass innerhalb von 60 s3 die Nachricht mit dem passendenPayloadtyp gesendet wird, falls zum neuen Payloadtyp (z. B. 0xA000) keine Response-Nachricht erfolgte.Im Rahmen dieser Arbeit wurde der erste Ansatz gewählt (Direkte Änderung der Nachrich-tendefinition), da dieser weniger Implementierungsaufwand bedeutete und der verwendeteEXI Codec4 [55] diese Schemaabweichung bereits unterstützt.Ein weiterer Aspekt der Erweiterbarkeit dieses Standards betrit die Auswahl von Mehrwert-dienstleistungen. Im Rahmen der ServiceDiscoveryReq/-Res sowie ServiceDetailReq/-Res Nachrichten können Informationen zwischen EVCC und SECC ausgetauscht werden,welche die Nutzung von diversen Diensten ermöglichen. Tabelle 6.3 listet die bereits in derSpezifikation beschriebenen, für den Ladeprozess relevanten Dienste samt ID, Name undKategorie auf.Tabelle 6.3: Definition von ID, Kategorie und Name eines Dienstes (nach [39])ServiceID ServiceName ServiceCategory Beschreibung0 Reserviert durch ISO/IEC1 AC_DC_Charging EV Charging Alle Dienstleistungen bezo-gen auf das Gleich- bzw.Wechselstromladen2 Certificate ContractCertificate Dienst zum Installieren/Ak-tualisieren eines Vertragszer-tifikats3 InternetAccess Internet Dienst zur Nutzung von Stan-dardprotokollen wie HTTP,HTTPS, FTP, etc.4 UseCaseInformation EVSEInformation Dienst zum Austausch vonInformationen über die Lade-station mit Bezug zu einemAnwendungsfall5 – 60000 Reserviert durch ISO/IEC60001 -60535Reserviert für implementie-rungsspezifische AnwendungHierzu zählen die diversen Ladedienste an sich (ein-/dreiphasiges AC-Laden oder DC-Laden),ein Installations- bzw. Aktualisierungsdienst für Vertragszertifikate sowie ein Dienst für dieNutzung der Standardprotokolle FTP, HTTP oder HTTPS. Man könnte sich vorstellen, dass3Abschnitt 2.2.1 ging bereits darauf ein, dass nie mehr als 60 Sekunden zwischen zwei aufeinander folgendenAnfragen vergehen dürfen, weil ansonsten ein Timeout, welcher die Kommunikationssession beendet,ausgelöst wird.4Dieser EXI-Codec ist unter der GNU General Public License version 2 verfügbar und somit in nicht-kommerziellen Projekten einsetzbar.1106.1 Zukunftsfähgikeit der ISO/IEC 15118 Normüber den Dienst mit der ServiceID 3 Mediadaten über ein Streamingportal zu Entertainment-Zwecken während eines Ladevorgangs übertragen werden oder auch ein Softwareupdate fürden EVCC. Für sämtliche Dienste, die jetzt noch nicht ersichtlich sein mögen und nicht vonder ISO oder IEC standardisiert werden müssen, steht eine Bandbreite von 5535 ServiceIDszur Verfügung. Somit wird eine gewisse Zukunftssicherheit und Flexibilität gewährt, sofernE-Fahrzeughersteller und Ladeinfrastrukturbetreiber sich auf eine gemeinsame Definition vonDiensten einigen können, die sie in ihre jeweiligen Implementierungen integrieren.6.1.3 SicherheitSämtliche Aspekte, die funktionale Sicherheitsrisiken durch Überspannung oder Überstrombetreen, müssen durch die korrekte Implementierung des bereits in Abschnitt 2.1.2 vorgestell-ten Standards IEC 61851 abgedeckt werden. Im Rahmen der IT-Sicherheit hingegen müssenfür die Kommunikation über das ISO/IEC 15118-2 Protokoll und die übermittelten Datenfolgende drei Aspekte erfüllt sein:• Vertraulichkeit: Der Inhalt einer Nachricht darf nur vom vorgesehenen Empfängerkreisgelesen werden dürfen, jedoch nicht von unauthorisierten Dritten.• Integrität: Eine unautorisierte Modifikation des gesendeten Nachrichteninhalts mussverhindert bzw. zumindest erkannt werden.• Authentizität: Es muss festgestellt werden können, ob die kommunizierenden Partnerauch wirklich diejenigen sind, die sie behaupten zu sein. Auch muss die Echtheit derübertragenen Nachrichten festgestellt werden können.Die ISO/IEC 15118-2 Spezifikation unterstützt Authentizität und Integrität durch die Erstel-lung und Überprüfung von XML-basierten Signaturen. Vertraulichkeit wird durch Ver- undEntschlüsselung mittels asymmetrischer Kryptographie sichergestellt. Diese Sicherheitsme-chanismen werden auf unterschiedlichen Schichten durchgeführt, welche im Folgenden nundetailliert beleuchtet werden.Sicherheit auf der TransportschichtAuf der Transportschicht des ISO/OSI-Schichtenmodels steht das TLS-Protokoll (TransportLayer Security) zur Verfügung (vgl. Abbildung 2.9), welches ein Verschlüsselungsprotokollzur sicheren Datenübertragung im Internet darstellt. Neben dem ebenfalls auf Schicht vierbefindlichen Protokoll TCP (Transmission Control Protocol) gehört TLS auch zu der Familieder zustandsbehafteten und zuverlässigen Übertragungsprotokolle. Die Nutzung von TLS fürsämtliche Kommunikationsabläufe zwischen dem Ladesteuergerät im Elektrofahrzeug (EVCC)und dem in der Ladestation (SECC) ist jedoch nicht in jedem Fall zwingend erforderlich, wieAbbildung 6.2 entnommen werden kann.Der ISO/IEC 15118 Standard definiert vier sogenannte „Message Sets“, welche sich anhandder in Abschnitt 2.2.1, Seite 32 bereits vorgestellten Identifizierungsmodi EIM und Plug-and-Charge (hier: PnC) sowie der Ladevarianten AC- und DC-Laden unterscheiden lassen:• AC-Laden im EIM-Modus• DC-Laden im EIM-Modus• AC-Laden im PnC-Modus111Kapitel 6 EvaluationISO 15118-2:2014(E) 20 © ISO 2014 – All rights reserved Table 3 — TLS implementation / support for EIM Identification Modes Other Environment (not trusted) Trusted Environment c Allowed Message Sets a DC EIM AC EIM DC EIM, VAS AC EIM, VAS DC EIM AC EIM DC EIM, VAS AC EIM, VAS EVCC TLS support optional optional mandatory mandatory optional optional mandatory mandatory SECC TLS support mandatory mandatory mandatory mandatory optional optional mandatory mandatory TLS usage negotiation using SDP b EV decides, EVSE shall accept EVs decision EV decides, EVSE shall accept EVs decision EV shall use TLS, EVSE shall reject, if EV uses no TLS EV shall use TLS, EVSE shall reject, if EV uses no TLS refer to Table 4 refer to Table 4 EV shall use TLS, EVSE shall reject, if EV uses no TLS EV shall use TLS, EVSE shall reject, if EV uses no TLS a This refers to messages as defined in this standard. In case of VAS, of course any other connections (which are not part of this standard) are possible b Rejecting means to stop communication c See Section 3 for a definition NOTE 8 Not supporting TLS in the SECC might lead in general to aborted charging sessions with particular EVs as it is in the responsibility of the EV to accept sessions without TLS. Table 4 — SDP handshake with AC and DC EIM Identification Mode in trusted environment EVCC TLS support SECC TLS support SDP request by EVCC SDP response SECC EVCC has TLS support SECC has TLS support EVCC signals TLS SECC shall respond TLS EVCC signals TCP SECC shall respond TCP SECC has no TLS support EVCC signals TLS SECC can indicate that it does no support TLS with indicating "0x10 = No transport layer security" in its SDP response. The EV can decide, if it wants to establish TCP without TLS, or otherwise stop the communication setup. EVCC signals TCP SECC shall respond TCP EVCC has no TLS support SECC has TLS support EVCC signals TCP SECC shall respond TCP SECC has no TLS support EVCC signals TCP SECC shall respond TCP NOTE 9 For the Message Set "EIM AC" and "EIM DC" it is in the responsibility of the EV to decide on not using TLS and accepting the risk of an unsecured connection. NOTE 10 If TLS is applied, it is always used with unilateral (EVSE-side) authentication. If TLS is not used, there is no EVSE side authentication towards the EV as well as further protection of the communication channel on transport layer. NOTE 11 Any functional safety related risks occurring through overvoltage and overcurrent (accidental or purposeful) need to be addressed by implementing the related electrical safety standards (e.g. IEC 61851 and ISO 17409) Any functional safety related risks occurring through overvoltage and overcurrent are to be handled according requirements listed below: [V2G2-643] The EVSE shall support the safety measures described in IEC 61851-1 and IEC 61851-22 to protect against overvoltage and overcurrent when using the AC EIM Identification Mode [V2G2-644] The EVSE shall support the safety measures described in IEC 61851-1 and IEC CDV 61851-23 to protect against overvoltage and overcurrent when using the DC EIM Identification Mode. B55EB1B3C7662F79D1B59483A53B9F2F82C98BEEB793988779DC7BACD7FE148328DA401B96F45F8A84EC66225A03F999E32883F01DFD7F5CB6696E9913FB25951F3097A80B794DE94D2E000710C17414B2A77F31B4ADBD97E2756FD840965320EA14BD83B38FD1BEA25ABB35A0A7Normen-Download-Beuth-Karlsruher Institut für Technologie (KIT)-KdNr.7597109-LfNr.6601215001-2014-04-16 15:50Abbildung 6.2: Vorgaben für TLS-Unterstützung durch EVCC und SECC [39]• DC-Laden im PnC-ModusJe nach Art der Identifizierung des Elektromobilisten (EIM z. B. mittels RFID-Karte, PnC= vertragsbasierte Authentifizierung und Autorisierung) nd der La eart sind also teilsunterschiedliche Nachrichten a zuwenden, welche in der vorlieg nd n T b lle unterschiedenwerden. VAS steht für angebotene Mehrwertdienste.Im Falle des PnC-Identifizierungsmodus stellt eine TLS-Verschlüsselung die notwendigeVoraussetzung dar. Im EIM-Fall hingegen werden ein paar Ausnahmen erlaubt. Hiernach musseine Ladestation nur dann TLS unterstützen, wenn sie sich nicht in einer vertrauenswürdigenUmgebung befindet. Für das Fahrzeug ist diese Vorgabe zusätzlich nur auf die Nutzung vonMehrwertdiensten beschränkt. In der vertrauenswürdigen Umgebung ist selbst im Falle, dasskeine Mehrwertdienste genutzt werden, ladestationsseitig die Verwendung von TLS optional.Eine vertrauenswürdige Umgebung wird in der Spezifikation folgendermaßen definiert:„Closed user group (e.g. members of car sharing system) with some pre-distributed tokenfor access to the SECC charging service (e.g. key to home garage, RFID token for car sharing),which is something where a person or instance is responsible for, for example (not limited to)a person with its home garage, a car sharing operator or a taxi operator.“Es ist anzunehmen, dass aufgrund des höheren Implementierungsaufwands für eine TLS-Verschlüsselung und der damit einhergehenden Kosten diese Ausnahmen eingeführt wurden,was jedoch eine Sicherheitslücke darstellt, die niemals hätte genormt werden dürfen.Im Falle des Einsatzes von TLS kommen, wie in Kapitel 5 bereits eingeführt, SECC-Zertifikate zum Einsatz, um die Ladestation gegenüber dem E-Fahrzeug zu authentifizieren.Für die Authentifikation des Fahrzeugs gegenüber der Ladestation bzw. einer dahinter liegendenInstanz werden hingegen auf Applikationsebene die Vertragszertifikate eingesetzt.Es wird in der Norm vorgeschrieben, dass X.509v3 Zertifikate nach IETF RFC 52805 einge-setzt werden müssen, da hierüber Erweiterungen bzgl. sogenannter Elliptic Curve-Parametergenutzt werden können. Auf die Verwendung von elliptischen Kurven in den eingesetztenkryptographischen Verfahren wird im folgenden Absatz eingegangen.5http://www.ietf.org/rfc/rfc5280.txt1126.1 Zukunftsfähgikeit der ISO/IEC 15118 NormSicherheit auf der ApplikationsschichtSämtliche spezifizierte Nachrichten sind über XML-Schemata definiert und werden entspre-chend beim Nachrichtenaustausch zunächst in XML-Dateien serialisiert und durch einenEXI-Decoder in ein binäres XML-Format konvertiert, bevor sie gesendet werden. Entsprechendwerden auf der Applikationsschicht für spezifische Nachrichten XML-Signaturen angewandt,um die Authentizität der ausgetauschten Nachrichten sicherzustellen. So werden bspw. der inder ChargeParameterDiscoveryRes-Nachricht enthaltene Parameter SalesTariff, welcherdie optionalen Preisinformationen sowie die Lastgrenze (vgl. SalesTariff und PMaxSchedulein Abschnitt 2.2.1, Seite 36) beinhaltet, sowie auch ganze Nachrichten wie AuthorizationReqund MeteringReceiptReq signiert. Eine vollständige Liste aller signierten Parameter undNachrichten ist in Abbildung 6.3 dargestellt.ISO 15118-2:2014(E) © ISO 2014 – All rights reserved 45 Table 13 — Overview of applied XML based signatures XML Message protected fields signing entity (sender) verifying entity (receiver) AuthorizationReq message body / all fields (if GenChallenge present) EVCC SECC CertificateUpdateReq message body / all fields EVCC; signed with Contract Certificate, chain transmitted in message body element secondary actor CertificateUpdateRes ContractSignatureCertChain ContractSignatureEncryptedPrivateKey DHpublickey eMAID secondary actor: Certificate Provisioning Service EVCC; certificate chain stored after successful verification CertificateInstallationReq message body / all fields EVCC; signed with OEM Provision Certificate, transmitted in message body element secondary actor CertificateInstallationRes ContractSignatureCertChain ContractSignatureEncryptedPrivateKey DHpublickey ContractID secondary actor: Certificate Provisioning Service EVCC; certificate chain stored after successful verification MeteringReceiptReq message body / all fields (optionally) EVCC SECC ChargeParameterDiscoveryRes SalesTariff (optional, required for PnC) secondary actor: Mobility Operator Sub-CA 2 EVCC Table 14 — Overview of applied encrytion XML Message protected fields encrypting entity (sender) decrypting entity (receiver) CertificateUpdateRes ContractSignatureEncryptedPrivateKey secondary actor EVCC CertificateInstallationRes ContractSignatureEncryptedPrivateKey secondary actor EVCC [V2G2-652] Each V2G Entity shall be able to generate XML signatures as specified in Table 13. [V2G2-653] Each V2G Entity shall be able to verify XML signatures as specified in Table 13. 7.9.2.5 Certificate Provisioning The Mobility Operator creates credentials for the EVCC, consisting of a Contract Certificate including a private key, which has been asymmetrically encrypted specifically for that EVCC. The Mobility Operator then forwards the credentials to the Certificate Provisioning Service. The Certificate Provisioning Service asserts the correctness and authenticity of the credentials with a signature and relays the signed message fragment to the SECC, who compiles a CertificateInstallationRes or CertificateUpdateRes message and transmits that to the EVCC. The Certificate Provisioning service is considered trustworthy. It is therefore not required that the EVCC is able to verify the certificate it has received. The role "Certificate Provisioning Service" can be assumed, for example, by the mobility operator himself, the SECC operator, a completely stand-alone service, or (under careful consideration of the security implications) even the EVCC itself. B55EB1B3C7662F79D1B59483A53B9F2F82C98BEEB793988779DC7BACD7FE148328DA401B96F45F8A84EC66225A03F999E32883F01DFD7F5CB6696E9913FB25951F3097A80B794DE94D2E000710C17414B2A77F31B4ADBD97E2756FD840965320EA14BD83B38FD1BEA25ABB35A0A7Normen-Download-Beuth-Karlsruher Institut für Technologie (KIT)-KdNr.7597109-LfNr.6601215001-2014-04-16 15:50Abbildung 6.3: Übersicht aller XML-basierten Signaturen [39]Diese Signaturen sind vor allem dann sin voll, wenn die Authentizität und Integritätgewisser Daten über den über TLS abgesicherten Kommunikationskanal hinaus gewährleistetwerden muss, wie es bei der Kommunikation zwischen einer Ladestation und einer drittenInstanz dahinter der Fall ist, sei es der Ladestromanbieter oder ein Energiemanagementsystem.Für die Signatur kommen mehrere Richtlinien zum Einsatz:1. Verwendung des Elliptic Curve Digital Signature Algorithm (ECDSA)2. Hash-Operationen mittels SHA-256 (Hashwert hat eine Bitlänge von 256 Bit) nach NISTFIPS PUB 180-4113Kapitel 6 Evaluation3. Schlüssellänge für ECC-basierte asymmetrische Kryptographie von 256 BitDer Vorteil der Verwendung von elliptischen Kurven bei der Erstellung von Signaturen sollanhand des Schlüsselaustauschverfahrens erläutert werden.Dieselben elliptischen Kurven, welche für ECDSA zum Einsatz kommen, finden auch in derVariante des Die-Hellman Schlüsselaustauschs statt, welche für ISO/IEC 15118-2 spezifiziertwurde. Das Die-Hellman Protokoll (DH-Protokoll) zum Schlüsselaustausch beschreibt einVerfahren, mittels welchem zwei kommunizierende Entitäten ein gemeinsames Geheimnisüber einen unsicheren Kanal durch Anwendung asymmetrischer Kryptographie austauschenkönnen. Durch die Information, die beide Entitäten ausgetauscht haben, kann letzten Endesein Sitzungsschlüssel abgeleitet werden, mit Hilfe dessen die Verschlüsselung von weiterenInformationen durch symmetrische Verfahren wie AES (Advanced Encryption Standard)erfolgen kann. Weitere Informationen zum DH-Verfahren können [11] entnommen werden.Das Schlüsselaustauschverfahren ist im Rahmen einer Ladekommunikation für die Installati-on sowie die Aktualisierung von Vertragszertifikaten nötig. Um die Anzahl der auszutauschen-den Nachrichten und somit auch Rechenzeit zu reduzieren, kommt im Rahmen der ISO/IEC15118-2 Spezifikation eine Variante des DH-Verfahrens zum Einsatz: das Elliptic Curve Die-Hellman (ECDH). In diesem Verfahren, dessen grundlegende Funktionsweise in Abbildung6.4 visualisiert ist, wird mit einem kurzlebigen und einem statischen („ephemeral-static“)öentlichen Schlüssel gearbeitet. Hierbei bleibt der öentliche Schlüssel QV des Empfängers(EVCC) stets unverändert, also statisch, und ist dem Sender (SA, steht für Secondary Actor,bspw. E-Mobilitätsanbieter) stets bekannt. Im Falle der erstmaligen Installation eines Ver-tragszertifikats (CertificateInstallationRes) entspricht der öentliche Schlüssel QV demöentlichen Schlüssel im OEM Provisioning-Zertifikat (vgl. Kapitel 5). Im Falle der Aktuali-sierung eines nicht mehr gültigen Vertragszertifikats (CertificateUpdateRes) entspricht deröentliche Schlüssel QV dem des bereits existierenden Vertragszertifikats.Der Sender jedoch kreiert einen kurzlebigen öentlichen Schlüssel, in Abbildung 6.4 mitQe,U bezeichnet, und sendet diesen über die Ladestation an den EVCC. Beide Parteienmüssen sich zu Beginn noch auf ein sogenanntes Generatorpolynom G einigen, mit Hilfedessen beide die Berechnung des gemeinsamen geheimen Sitzungsschlüssels Z durchführenkönnen. Mit Hilfe von Z kann dann folglich der private Schlüssel des zu installierendenVertragszertifikats verschlüsselt übertragen und vom EVCC wieder entschlüsselt werden, ohnedass eine Antwortnachricht vom EVCC an den SA vonnöten wäre. Der öentliche SchlüsselQV des EVCC ist im Vorfeld mittels einer algebraischen Operation auf den beiden ParameternG und dV errechnet worden. Der private Schlüssel dV des OEM-Provisioning-Zertifikats istjedoch nur dem EVCC bekannt.Das ECDH-Verfahren wäre nicht mehr sicher, wenn ein Angreifer sich zwischen die beidenKommunikationspartner schalten und Nachrichten verändern könnte, ohne dass dies bemerktwürde. Zu diesem Zweck werden die während des ECDH-Verfahrens ausgetauschten Para-meter mittels des ECDSA-Verfahrens zusätzlich digital signiert, wobei dieselben statischenSchlüsselpaare (dV , QV ) (privater Schüssel, öentlicher Schlüssel) Verwendung finden.Eine Datenverschlüsselung (nicht Kommunikationskanalverschlüsselung mittels TLS) imZuge einer Ladekommunikation über ISO/IEC 15118 findet nur für den bereits erwähntenprivaten Schlüsssel des Vertragszertifikats statt. Dieser mit ContractSignatureEncrypted-PrivateKey bezeichnete Parameter wird über die Nachrichten CertificateInstallationResund CertificateUpdateRes mittels einer AES 128 Bit Verschlüsselung im CBC (Cipher Block1146.1 Zukunftsfähgikeit der ISO/IEC 15118 NormISO 15118-2:2014(E) 322 ISO 15118-2:2014(E) PreconditionBoth parties use the same Z: de,UQV= de,UdVG = dVde,UG = dVQe,USender U (Secondary Actor)Generate ephemeral key pair (de,U,Qe,U))Qe,U:= de,U GCompute Z = dVQe,UQe,UReceiver V (EVCC)Static key pair (dV,QV)QV:= dV GPublic Key QVCompute Z = de,UQVElliptic Curve secp256v1 using base point G Figure G.1 — Ephemeral-static Diffie-Hellman key agreement (informational depiction, do not use for implementation) G.3 Key pairs The EVCC reuses the key pair that it also uses for ECDSA signatures, i.e. the key pair whose public key is stored in its current Contract Certificate respectively OEM Provisioning Certificate (depending on the message type). In both cases, the certificate and thus its public key is already known to the SA. The SA can therefore pre-compute new certificates and private keys for the EVCC and encrypt these with a session key without any message from the EVCC. The next time the EVCC connects to the SA (via the SECC), the pre-computed encrypted message can be retrieved and decrypted after only a single message from the SA, without any cryptographic processing on the side of the SA, and without any further message from the EVCC. The SA uses ephemeral keys and hence the session keys will be different for each certificate and private key distribution. Note however that the ephemeral-static Diffie-Hellman protocol does not provide perfect forward secrecy, i.e. if the static private key of the EVCC is leaked to an adversary, then this adversary can decrypt any past and future communication between SA and EVCC, and also generate signatures, as the key for signatures is the same as the encryption key. B55EB1B3C7662F79D1B59483A53B9F2F82C98BEEB793988779DC7BACD7FE148328DA401B96F45F8A84EC66225A03F999E32883F01DFD7F5CB6696E9913FB25951F3097A80B794DE94D2E000710C17414B2A77F31B4ADBD97E2756FD840965320EA14BD83B38FD1BEA25ABB35A0A7Normen-Download-Beuth-Karlsruher Institut für Technologie (KIT)-KdNr.7597109-LfNr.6601215001-2014-04-16 15:50Abbildung 6.4: ECDH-Schlüsselaustausch mit kurzlebigem und statischem öentlichem Schlüs-sel [39]Chaining) Mode übertragen6. Der Initialisierungsvektor IV oll hierbei zufällig generiert wer-den, ebenfalls eine Länge von 128 Bit haben und niemals wiederverwendet werden.Die Gestal der zu verwe denden elliptischen Kurve wird in Abbildung 6.4 mit „s cp256v2“bezeichnet, wobei hier eine Schlüssellänge von 256 Bit vorgeschrieben wird. Die Ver endungvon elliptischen Kurven im Schüsselaustausch bzw. in der Signatur hat den charmantenVorteil, dass darauf basierende Verfahren mit erheblich kürzeren Schlüsseln bei vergleichbarerSicherheit ausk mmen [49] [21]. Die Sicherheit d s Die-Hel man-Verfahrens beruht aufder Schwierigkeit, den diskreten Logarithmus in endlichen Körpern zu berechnen. DiesesProblem, sowie die Faktorisierung ganzer Zahlen, gestaltet sich in elliptischen Kurven nochmalsdeutlich schwieriger. Daher können bei gleichem Sicherheitsniveau kürzere Schlüssellängen6Dies erfolgt gemäß NIST Special Publication 800-38A: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.115Kapitel 6 Evaluationverwendet werden und auf elliptischen Kurven basierende Kryptosysteme sogar deutlichschneller sein als bisher bekannte Verfahren wie bspw. RSA. Jedoch kommt es in punktoSchnelligkeit und Sicherheit des Verfahrens auch stets auf die konkrete Implementierung derSpezifikation an. Tabelle 6.4 stellt die benötigten Schlüssellängen in Bits für die asymmetrischenKryptoverfahren RSA und DH der benötigten Schlüssellänge für ECDH gegenüber. DieTabelle ist so zu interpretieren, dass ausgehend von der Länge eines Sitzungsschlüssels fürein symmetrisches Kryptoverfahren, wie bspw. AES, die Schlüssellänge für RSA bzw. DH,über welche der Sitzungsschlüssel sicher kommuniziert werden muss, vorgeschrieben wird. Dasamerikanische National Institute of Standards and Technology (NIST) hat hierbei im Vergleichzur europäischen Vereinigung ECRYPT, dem European Network of Excellence in Cryptology,leicht abweichende Empfehlungen. Man sieht deutlich, dass die symmetrischen Schlüssellängendie benötigten Schlüssellängen für RSA und DH in einem viel schnelleren Maß ansteigen lassenals diejenigen für ECDH. Somit bieten EC-basierte Kryptosysteme eine höhere Sicherheit proansteigender symmetrischer Schlüssellänge als RSA oder DH. Elliptische Kurven eignen sichdaher besonders gut für den Einsatz im Kommunikationsprotokoll ISO/IEC 15118, welchesauf eingebetteten Systemen mit beschränkter Rechenkapazität und Speicherplatz zum Einsatzkommt.Tabelle 6.4: Vergleich der Verschlüsselungsstärken basierend auf diversen Sicherheitsniveaus[49] [21]Symmetrisch RSA und DH (NIST) RSA und DH (ECRYPT) ECDH80 1024 1248 160112 2048 2432 224128 3072 3248 256192 7680 7936 384256 15360 15424 512Die hier vorgestellten Verfahren bieten eine solide Grundlage, auf Basis derer eine sichereLadekommunikation zwischen Elektrofahrzeug und Ladestation sowie dahinter liegender drit-ter Systeme möglich ist. Wie bereits erwähnt, wurde jedoch mit der optionalen Verwendungvon TLS eine unnötige Sicherheitslücke eingeführt, die dazu führen kann, dass ein Angreiferin einer sogenannten vertrauenswürdigen Umgebung nach obiger Definition bspw. die Lastbe-grenzungskurve (PMaxSchedule), die vom SECC an den EVCC gesendet wird, manipulierenund mit seiner eigenen Signatur versehen könnte. Der EVCC kann die Authentizität desSenders aufgrund fehlender Zertifikate dann nicht überprüfen. Es ist somit leicht ein Szenariodenkbar, in welchem sämtliche E-Fahrzeuge eines betrieblichen Fuhrparks – was ebenso als„car sharing operator“ verstanden werden kann – eine Überlastsituation herbeiführen, die zuerheblichen Kosten und auch Stromausfällen führen kann.Des Weiteren ist zu beachten, dass das ECDH keine sogenannte „perfect forward secrecy“garantiert. Hierunter ist in der Kryptographie folgende Eigenschaft von Schlüsselaustausch-verfahren (wie dem DH oder ECDH) zu verstehen: Bei einem Verlust bzw. dem Aufdeckendes privaten (statischen) Schlüssels können der ausgehandelte Sitzungsschlüssel und somitalle zukünftigen sowie vergangenen Kommunikationen nicht aufgedeckt werden. Im Falle desECDH könnte somit nicht nur die Kommunikation zwischen Secondary Actor und EVCC ent-schlüsselt werden. Vielmehr könnten auch die Zählerdaten, welche vom EVCC optional signiertund für Abrechnungsprozesse in manchen Ländern verwendet werden, manipuliert und diese1166.1 Zukunftsfähgikeit der ISO/IEC 15118 Normmanipulierten Daten mit der korrekten Signatur des gestohlenen privaten Schlüssels versehenwerden. Da der private Schlüssel des Vertragszertifikats auf Seiten des E-Mobilitätsanbietersgeneriert wurde, bestehen somit sogar zwei Angrispunkte, um diesen Schlüssel zu stehlen,sofern der private Schlüssel nach Generierung auch lokal gespeichert wurde.Zu guter Letzt ist ein implementiertes kryptographisches Verfahren immer nur so sicher,wie sich bei der Implementierung korrekt an die ozielle Spezifikation gehalten wurde.6.1.4 EzienzEine Beurteilung der Ezienz des Protokolls lässt sich anhand der Kriterien• eziente Verarbeitung der Nachrichten und• Nachrichtengröße und Speicherbedarfdurchführen. Durch die Verwendung des Ecient XML Interchange (EXI) Formats fürdie binäre Repräsentation von XML-basierten Nachrichten und die Verarbeitung der EXI-Grammatik statt der Schemainformation einer XSD-Datei im Kommunikationscontrollerkann ein erheblicher Geschwindigkeitsvorsprung erreicht werden. Schmutzler et al. [61] habeneine frühe Version des ISO/IEC 15118 Standards hinsichtlich der Kodierungsezienz desEXI-Formats in diversen Modi quantitativ untersucht. Hierbei wurde die auch im Rahmendieser Arbeit verwendete EXIficient-Bibliothek [55] genutzt. Das Einsparungspotential derEXI-kodierten Nachrichten im Vergleich zur Nachrichtengröße von XML-Nachrichten kannAbbildung 6.5 entnommen werden.MessagePatternXML schema informedEXI schema informedEXI strict byte pkdEXI strict bit pkdCompr. FactorCompr. RateMessagePatternXML schema informedEXI schema informedEXI strict byte pkdEXI strict bit pkdCompr. FactorCompr. RateSessionSetupReq 637 69 72 67 9,5 10,52% SessionSetupRes 792 42 52 37 21,4 4,67%ServiceDiscoveryReq 781 278 281 276 2,8 35,34% ServiceDiscoveryRes 1013 83 89 77 13,2 7,60%S&PSelectionReq 813 64 68 60 13,6 7,38% S&PSelectionRes 563 33 35 31 18,2 5,51%PaymentDetailsReq 556 46 52 44 12,6 7,91% PaymentDetailsRes 545 33 35 31 17,6 5,69%PowerDiscoveryReq 1127 61 69 53 21,3 4,70% PowerDiscoveryRes 2773 138 166 115 24,1 4,15%LineLockReq 643 34 37 31 20,7 4,82% LineLockRes 778 37 41 32 24,3 4,11%PowerDeliveryReq 1172 50 58 43 27,3 3,67% PowerDeliveryRes 543 33 35 31 17,5 5,71%MeteringStatusReq 490 32 34 30 16,3 6,12% MeteringStatusRes 1338 94 114 84 15,9 6,28%MeteringReceiptReq 1025 114 123 108 9,5 10,54% MeteringReceiptRes 547 33 35 31 17,6 5,67%Arithmetic Mean 805 83 88 79 10,2 10,11% Arithmetic Mean 988 58 67 52 19,0 5,49%Max 1172 278 281 276 27,3 35,34% Max 2773 138 166 115 24,3 7,60%Min 490 32 34 30 2,8 3,67% Min 543 33 35 31 13,2 4,11%a) b)Fig. 7. Quantitative Overview of V2G Request (a) and Response (b) Message Sizes in XML and various EXI modesa) b)020040060080010001200XML schema informed EXI strict byte pkd EXI strict bit pkd050010001500200025003000XML schema informed EXI strict byte pkd EXI strict bit pkdbytebyteFig. 8. Comparison of V2G Request (a) and Response (b) Message Sizes in XML schema-informed and EXI strict mode (byte packed & bit packed)negotiations, interoperability and usability. The investigationson the application layer protocol provide first results in termsof data encoding efficiency. The results show that utilizing EXIfor data encoding limits the maximum number of transferedbytes to less than 300bytes for the worst case message pattern.Moreover, the RAM allocation needed for the in- and outputmessage buffers are decreased to only 23.4% and 4.2% of thesize for the equivalent XML based approach. The analysis alsoprovides means to quantitatively identify protocol specificationflaws targeting at efficient memory utilization for highlyembedded devices.ACKNOWLEDGMENTThe authors would like to thank Siemens Corporate Tech-nology and the project partners RWE, SAP Research, Ewald& Guenter, TU-Berlin and TU-Dortmund for collaborationin standardization efforts and fruitful discussions during theresearch project e-mobility. The work in this paper was partlyfunded by the German Federal Ministry of Economics andTechnology (BMWi) as part of the e-mobility project withreference number 01ME09012.REFERENCES[1] National Institute of Standards and Technology, Framework andRoadmap for Smart Grid Interoperability Standards, Release 1.0. NISTSpecial Publication 1108, January 2010.[2] IEC TC/SC 23 62196-x, Plugs, socket-outlets, vehicle couplers and vehi-cle inlets Conductive charging of electric vehicles, Geneva, Switzerland.[3] IEC TC/SC 69 61851-x, Electric vehicle conductive charging system,Geneva, Switzerland.[4] ISO/IEC 15118-x, Vehicle to grid communication interface, Geneva,Switzerland.[5] S. Kaebisch, A. Schmitt, M. Winter, and J. Heuer, “Interconnectionsand communications of electric vehicles and smart grids,” in SmartGrid Communications (SmartGridComm), 2010 First IEEE InternationalConference on, 2010, pp. 161 –166.[6] IEC TC/SC 57 61850-7-420, Communication networks and systems forpower utility automation - Part 7-420, Geneva, Switzerland, 2009.[7] IEC TC/SC 57 61850-7-2, Basic communication structure for substa-tion and feeder equipment - Abstract communication service interface(ACSI), Geneva, Switzerland, 2003.[8] J. Schneider and T. Kamiya, “Efficient XML Interchange (EXI)Format 1.0,” W3C, Tech. Rep., December 2009. [Online]. Available:http://www.w3.org/TR/2009/CR-exi-20091208/[9] G. Moritz, “DPWS for 6LoWPAN,” IETF Internet Draft, Tech. Rep.,June 2010. [Online]. Available: http://tools.ietf.org/html/draft-moritz-6lowapp-dpws-enhancements-01[10] D. Sturek, Z. Shelby, D. Lohman, M. G. Stuber, and S. Ashton, “SmartEnergy Requirements for 6LowApp,” IETF Internet Draft, Tech. Rep.,October 2009. [Online]. Available: http://tools.ietf.org/html/draft-sturek-6lowapp-smartenergy-00[11] Z. Shelby, M. Luimula, and D. Peintner, “ Efficient XML Encoding and6LowApp,” IETF Internet Draft, Tech. Rep., October 2009. [Online].Available: http://tools.ietf.org/html/draft-shelby-6lowapp-encoding-00[12] ZigBee Alliance and HomePlug Powerline Alliance liason, “SmartEnergy Profile 2.0 Application Protocol Specification (Draft 0.7),” Tech.Rep., April 2010.[13] S. Kaebisch, D. Peintner, J. Heuer, and H. Kosch, “Efficient andFlexible XML-Based Data-Exchange in Microcontroller-Based SensorActor Networks,” International Conference on Advanced InformationNetworking and Applications Workshops, vol. 0, pp. 508–513, 2010.125Abbildung 6.5: Quantitative Übersicht über ISO/IEC 15118 Nachrichtengrößen in XML unddiv rsen EXI-Modi [61]Die Größen der jeweiligen Request- (Tabelle a) und Responsenachrichten (Tabelle b) wurdendurch die Instanziierung jeder Nachricht mit allen optionalen Parametern und Attributensowie der Verwendung maximal möglicher Werte für jedes Element bestimmt. Dieser worst-case-Test ist relevant für die Bestimmung minimal nötiger Puergrößen der In- und Output-Puer der eingebetteten Kommunikationscontroller. Hierbei konnte gezeigt werden, dass diemittlere Kompressionsrate der EXI-Kodierung bei den Request-Nachrichten bei 10 % liegt,die Response-Nachrichten weisen gar eine noch bessere mittlere Kompressionsrate von 5,5 %auf. Der Grund für diese unterschiedlichen Kompressionsraten liegt in der Entropie der XML-Datenstruktur begründet, welche dem EXI-Encoder übergeben wird. Je geringer die Entropi ,desto besser die Kompression, was bspw. anhand Tabelle a deutlich wird. Die darin gelisteteNachricht ServiceDiscover Req ist für diesen Ausreißer maßgeblich erantwortlic . Dies117Kapitel 6 Evaluationrührt daher, dass in dieser Nachricht ein String-Parameter enthalten ist, welcher den Umfangder angefragten Ladedienste begrenzen kann und bis zu 256 Zeichen enthalten kann. DieserZeichenkettenparameter ist für die hohe Entropie verantwortlich. Im Vergleich dazu fällt dieGröße der PowerDiscoveryRes Nachricht7 mit 2773 Bytes im XML-Format um einiges größeraus, was u. a. auf die vielen tief verschachtelten Parameter (vgl. Tabelle 4.6 als Aussschnitt desSalesTariff Parameters) zurückzuführen ist. Dennoch ist die Entropie um einiges geringer,was in einer sehr guten Kompressionsrate von 4,15 % resultiert.Des Weiteren wurde darauf geachtet, dass kryptographische Verfahren eingesetzt werden,die mit relativ kurzen Schlüssellängen in asymmetrischen Kryptoverfahren bei vergleichsweisehohen Sicherheitsniveaus auskommen, wie in Abschnitt 6.1.3 gezeigt wurde. Dies kann ebenfallsGeschwindigkeitsvorsprünge im Vergleich zu bspw. RSA mit sich bringen. Letzten Endeswurde für die Größe eines zu speichernden Zertifikats die Vorgabe eingeführt, dass 800 Bytesnicht überschritten werden dürfen, was z. B. dadurch erreicht werden kann, dass irrelevanteInformationen wie die Adresse des Zertifikatsausstellers ausgespart werden.6.1.5 KomplexitätDie ISO/IEC 15118-2 Spezifikation umfasst ganze 350 Seiten, auf denen 849 Anforderungen(Requirements)8 gelistet werden. Die Komplexität einer solchen Spezifikation lässt sich zwarnicht mit metrischen Methoden objektiv messen, aber schon allein diese beiden Zahlen lassenes erahnen. Hinzu kommt, dass thematisch zusammengehörige Informationen wie bspw. zurSicherheitsthematik über diverse Kapitel und Anhänge verstreut sind. Dies ist zwar derinhaltlichen Strukturierung des Dokuments geschuldet und teilweise auch nachvollziehbar,jedoch schadet es der Übersichtlichkeit und bringt somit bei der ersten Auseinandersetzungmit diesem Dokument eine gewisse komplexe Hürde mit sich.Im Laufe der Standardisierung stieg durch neu eingeführte Funktionalitäten die Anzahlder niedergeschriebenen Anforderungen in größerem Maße an, als dies für das Verständnisdes Lesers zuträglich ist. So wurden Anforderungen, die im Laufe der Zeit von verschiedenenAutoren mit unterschiedlichem Kenntnisstand des gesamten Dokuments eingebracht wurden,nicht immer mit bereits bestehenden ähnlichen Anforderungen zusammengefasst, was u. a. auchdem Zeitdruck geschuldet ist, dem ein solches Normungsdokument oft unterliegt.Abbildung 6.6 soll einen Eindruck davon verschaen, mit wie vielen verschiedenen Anforde-rungen die jeweiligen Zustandsübergänge im SECC beim Anwendungsfall Wechselstromladenbehaftet sind. Diese Komplexität bringt eine gewisse Fehleranfälligkeit bei der Implementie-rung dieser Spezifikation mit sich. Aus diesem Grunde wurde eine Plattform ins Leben gerufen,deren Zweck die Erreichung eines gemeinsamen Verständnisses über die Implementierung dieserNorm ist. Diese ISO/IEC 15118 User Group9 soll somit die Interoperabilität unterschiedlicherImplementierungen sicherstellen und darüber hinaus eventuelle fehlerhafte Darstellungen deraktuell bestehenden Spezifikationen dokumentieren. Gesammelte Erkenntnisse aus dieser UserGroup können in eine Neuauflage der ISO/IEC 15118-2 einfließen.Nachdem nun im ersten Teil des Evaluationskapitels die Zukunftsfähigkeit des ISO/IEC15118 Protokolls anhand der Kriterien Akzeptanz, Erweiterbarkeit, Sicherheit, Ezienz undKomplexität analysiert worden ist, wird im zweiten Teil das in Abschnitt 4.3 vorgestellte7In der finalen Spezifikation entspricht dies der ChargeParameterDiscoveryRes Nachricht.8Die größte Requirement-ID ist die 914, was bedeutet, dass 65 Requirements im Laufe der Entwicklung vomDIS zum FDIS überarbeitet wurden und technische Änderungen mit sich brachten.9http://iso15118.fzi.de/redmine/1186.1 Zukunftsfähgikeit der ISO/IEC 15118 NormISO 15118-2:2014(E) 202 © ISO 2014 – All rights reserved Process supportedAppProtocolReqInitialWait for supportedAppProtocolReqStop Communication Session - ErrorProcess SessionSetupReqWait for SessionSetupReqWait for Serv iceDiscov eryReqNegativ e Response MessageProcess Serv iceDiscov eryReqWait for Serv iceDetailDescriptionReq or Serv icePaymentSelectionReqProcess Serv iceDetailReqProcess Serv icePaymentSelectionReqWait for PaymentDetailsReq or AuthorizationReq or CertificateInstallationReq or CertificateUpdateReqProcess CertificateInstallationReqProcess CertificateUpdateReqWait for PaymentDetailsReqProcess PaymentDetailsReqWait for AuthorizationReqProcess AuthorizationReqWait for ChargeParameterDiscov eryReqProcess ChargeParameterDiscov eryReqWait for ChargingStatusReqProcess ChargingStatusReqWait for ChargingStatusReq or PowerDeliv eryReqProcess MeteringReceiptReqWait for PowerDeliv eryReqProcess PowerDeliv eryReqProcess SessionStopReqStop Communication Session - No Error Response ForkError ForkWait for MeteringReceiptWait for SessionStopReq[V2G2-566][V2G2-538][V2G2-575][V2G2-577][V2G2-578][V2G2-537][V2G2-574][V2G2-538][V2G2-562][V2G2-573][V2G2-537][V2G2-565][V2G2-537][V2G2-538][V2G2-687][V2G2-563][V2G2-564][V2G2-570][V2G2-688][V2G2-576][V2G2-537][V2G2-579][V2G2-538][V2G2-729][V2G2-571][V2G2-572][V2G2-574][V2G2-568][V2G2-567][V2G2-569][V2G2-812][V2G2-537][V2G2-567][V2G2-538][V2G2-580][V2G2-581][V2G2-538][V2G2-813][V2G2-542][V2G2-550][V2G2-537][V2G2-538][V2G2-545][V2G2-546][V2G2-539][V2G2-544][V2G2-537][V2G2-538][V2G2-548][V2G2-537][V2G2-538][V2G2-543][V2G2-540][V2G2-537][V2G2-538][V2G2-536][V2G2-537][V2G2-556][V2G2-560][V2G2-561][V2G2-537][V2G2-559][V2G2-538][V2G2-557][V2G2-558][V2G2-547][V2G2-555][V2G2-549][V2G2-559][V2G2-562][V2G2-537][V2G2-553][V2G2-538][V2G2-551][V2G2-552][V2G2-541][V2G2-554] Figure 103 — SECC Communication states for AC V2G messaging B55EB1B3C7662F79D1B59483A53B9F2F82C98BEEB793988779DC7BACD7FE148328DA401B96F45F8A84EC66225A03F999E32883F01DFD7F5CB6696E9913FB25951F3097A80B794DE94D2E000710C17414B2A77F31B4ADBD97E2756FD840965320EA14BD83B38FD1BEA25ABB35A0A7Normen-Download-Beuth-Karlsruher Institut für Technologie (KIT)-KdNr.7597109-LfNr.6601215001-2014-04-16 15:50Abbildung 6.6: Zustandsautomat des SECC für das Wechselstromladen [39]119Kapitel 6 EvaluationOptimierungsteilproblem evaluiert. Hierbei soll das resultierende Kodierungsschema hinsicht-lich der Eignung des Elektrofahrzeugs, kostenoptimal als Verbraucher und Energiespeicher zufungieren, untersucht werden.1206.2 Evaluation des ausgewählten Kodierungsschemas für das Elektrofahrzeug6.2 Evaluation des ausgewählten Kodierungsschemas für dasElektrofahrzeugDas in Abschnitt 3.1 vorgestellte Energy Smart Home Lab (ESHL) kann über das Energiemanagement-System, welches in Abschnitt 3.2 eingeführt wurde, sowohl in einem realen Wohnszenarioals auch auf Basis einer Simulation betrieben werden. Die Simulation bietet die Möglichkeit,Auswirkungen unterschiedlicher Optimierungsmechanismen gezielt zu untersuchen und gegen-überzustellen. Der zweite Teil des Evaluationskapitels gliedert sich somit in die folgenden dreiAbschnitte:1. Auswertung des Lastprofils einer realen Wohnphase (Herbst 2013), in der das E-Fahrzeugüber Mode 3 (vgl. Abschnitt 2.1.2) und somit nicht gesteuert geladen wurde2. Auswertung diverser Lastprofile rein simulativer Wohnphasen, in welchen das E-Fahrzeugmittels eines vom Optimierer vorgegebenen Lastprofils gesteuert lädt und rückspeist,wobei teils reale Daten aus der Wohnphase im Herbst 2013 zugrunde gelegt werden3. Auswertung des Lastprofils einer weiteren realen Wohnphase (Frühjahr 2014), in welcherdas E-Fahrzeug bereits über ISO/IEC 15118 mit dem Energiemanagement-Systemkommuniziert und mittels eines vom Optimierer vorgegebenen Lastprofils gesteuert lädtund rückspeist6.2.1 Auswertung der realen Wohnphase im Herbst 2013Sämtliche Zuleitungen zu den einzelnen Haushaltskomponenten, den Einspeisern PV-Anlageund BHKW sowie der Ladestation, über die das Elektrofahrzeug angeschlossen ist, sind mitMesseinrichtungen sowie schaltbaren Relais ausgestattet. Auf diese Weise kann einerseitsder aktuelle Zustand aller elektrischen Komponenten genau erfasst und andererseits dieStromzufuhr vom Energiemanagement ein- bzw. ausgeschaltet werden.Im Rahmen der Projektlaufzeit von iZEUS wurde im Herbst 2013 eine mehrwöchige Wohn-phase mit Probanden durchgeführt, welche die eingesetzten Optimierungsmechanismen aufihre Praxistauglichkeit testen sollten. Bei den Probanden handelte es sich um ein jungesberufstätiges Paar. Das Elektrofahrzeug wurde u. a. für eine Pendlerstrecke von ca. 28 km(14 km pro Arbeitsweg) genutzt. In dieser achtwöchigen Wohnphase wurden mehrere Va-riationen von zeitvariablen Preissignalen und Lastgrenzsignalen getestet, um einerseits einesozioökonomische Untersuchung der Benutzerfreundlichkeit und andererseits eine technischeAuswertung der autonomen Optimierung des Energiemanagements durchführen zu können.Im Zuge dieser Evaluation soll der Fokus auf der technischen Auswertung der Optimierungliegen.Die in Kapitel 4 diskutierte Konzeption und Implementierung eines Optimierungsteilpro-blems für das Elektrofahrzeug war zum Zeitpunkt der Wohnphase im Herbst 2013 noch nichtvollständig in das Energiemanagement integriert, weshalb in dieser Zeit das Elektrofahrzeugnach Mode 3 und somit nicht intelligent geladen wurde. Eine beispielhafte Woche aus dieserWohnphase ist in Abbildung 6.7 dargestellt und soll nun kurz erläutert werden.In diesem Auszug der vierten Woche der Herbstwohnphase sind die zeitlich flexibel steu-erbaren Haushaltsgeräte, zu denen die Waschmaschine, der Trockner und die Spülmaschinegehören, als aggregierter Lastgang neben der restlichen, lediglich beobachtbaren Haushaltslast(erzeugt durch bspw. Ofen, Herdplatte, Kaeemaschine und Licht) abgebildet. Der Lastgangdes Elektrofahrzeugs sowie das Einspeiseprofil des BHKWs sind separat ausgewiesen. Der121Kapitel 6 EvaluationAbbildung 6.7: Auswertung der Lastgänge einzelner Verbraucher sowie des BHKWs in der 4.Woche (Wohnphase 2013)1226.2 Evaluation des ausgewählten Kodierungsschemas für das Elektrofahrzeugzeitvariable Strompreis ist als grau schattierte Fläche im Hintergrund illustriert, die ent-sprechende Skala ist der rechten y-Achse zu entnehmen. Die Lastgrenze, welche eine weicheGrenze darstellt, deren Überschreitung lediglich zusätzliche Kosten verursacht, jedoch nichtzur Abschaltung des Verbrauchers führt, ist mit der roten Linie gekennzeichnet.Das in Abschnitt 3.1 vorgestellte Elektrofahrzeug ist zwar in der Lage, dreiphasig miteiner maximalen Leistung von 11 kW zu laden, jedoch wird aus Abbildung 6.7 deutlich, dassvon den Probanden die maximale Ladeleistung auf 2 kW begrenzt wurde, um die Lastgrenzedurch die zusätzliche Nutzung anderer Haushaltsgeräte nicht zu überschreiten. Die Parkzeitendes Elektrofahrzeugs am Smart Home sind durch die schwarzen horizontalen Balken aufder x-Achse illustriert. Hierdurch ist ebenfalls deutlich erkennbar, dass das Fahrzeug – bisauf Freitag – nicht sofort nach der Rückkehr von der Arbeit bzw. sich daran anschließenderEinkaufswege mit der Ladestation verbunden wurde. Stattdessen wurde immer explizit daraufgeachtet, den Ladevorgang erst dann zu starten, wenn der Strompreis auf das Minimumvon 10 ct/kWh gefallen war, was an den überwiegend in den späten Abendstunden naheMitternacht stattfindenden Ladevorgängen ersichtlich wird.Weiterhin fällt auf, dass die steuerbaren Haushaltsgeräte nie zum Zeitpunkt des teuerstenStrompreises mit 40 ct/kWh, sondern fast immer in den günstigsten Zeitslots (10 ct/kWh)liefen.Das BHKW diente in dieser Wohnphase als einzige Einspeisequelle, eine Photovoltaik-Anlagestand für diesen Zeitraum nicht zur Verfügung. Die Einspeisevorgänge wurden durch dasEnergiemanagement veranlasst, einerseits induziert durch die Lastsituation im Smart Home,andererseits durch thermische Restriktionen wie die Unterschreitung einer Schwelltemperaturdes Schichtspeichers für die Warmwasserversorgung. Eine erzwungene Erhöhung der Wasser-temperatur im Schichtspeicher geht auch stets mit der Erzeugung elektrischer Energie einher.Dies erklärt auch, weshalb elektrische Energie nicht nur während einzelner Ladevorgänge desElektrofahrzeugs oder der Nutzung diverser Haushaltsgeräte erzeugt wurde, sondern auch inden eher seltenen Zeiträumen dazwischen, in denen keine signifikante Hauslast vorlag.Da während dieser Wohnphase die von den Benutzern eingestellten Freiheitsgrade10 nichterfasst wurden, ist eine identische Nachbildung dieser Wohnphase in der Simulation leidernicht möglich. So hätte diese Wohnphase als Benchmark genutzt werden können, um einfast identisches Vergleichsszenario nachzubilden, in welchem stattdessen die Batterie desE-Fahrzeugs auf intelligente, vom Energiemanagement vorgegebene Weise geladen und sogarEnergie rückgespeist würde. Nichtsdestotrotz sollen die realen Ankunfts- und Abfahrtszei-ten mit dem Elektrofahrzeug sowie die jeweiligen Batterieladezustände (Start-SOC) in derSimulation abgebildet werden. Abschnitt 6.2.2 wird daher neben den Batterie- und Fahrzeug-kenndaten auch das Strompreis- und Lastbegrenzungssignal für diese beispielhafte Woche imHerbst 2013 aufgreifen und verschiedene Simulationsszenarien gegenüberstellen.Hierzu bedarf es zusätzlicher Informationen, die über die im Smart Home aufgezeichnetenDaten nicht bereitgestellt wurden. Es ließe sich zwar über die gemessene Spannung an derSteckdose der Ladestation ermitteln, über welchen Zeitraum das Elektrofahrzeug mit eben-dieser auch über den Ladevorgang hinaus verbunden war, jedoch fehlt für die Ermittlungder gesamten Standdauer – und somit der zeitlichen Flexibilität für die Ladung – der An-kunftszeitpunkt am Smart Home. Des Weiteren lässt sich der Ladezustand der Batterie bei10Unter einem Freiheitsgrad soll hier die Zeitspanne zwischen der Programmierung der HaushaltskomponenteWaschmaschine, Trockner oder Spülmaschine und dem vom Hausbewohner vorgegebenen, spätest möglichenEndzeitpunkt für die Abarbeitung des jeweils eingestellten Programms verstanden werden.123Kapitel 6 EvaluationAnkunft am Smart Home anhand der Lastkurve nur unpräzise berechnen, da die Informa-tion über die benötigte Energie der Nebenverbraucher im E-Fahrzeug fehlt. Diese fehlendenInformationen lassen sich jedoch über die Logdaten des Elektrofahrzeugs direkt ermitteln.Die Ankunfts- und Abfahrtszeitpunkte ergeben sich durch eine Korrelation des Zeitstempelsmit den aufgezeichneten GPS-Koordinaten. Aus diesen Informationen resultieren die bereitsdargestellten schwarzen Balken. Die Werte für den benötigten Energiegehalt (eAmount) sowiedie zur Rückspeisung zur Verfügung stehende Energiemenge (eAmountDischarge) lassen sichanhand des aufgezeichneten Ladezustands (SOC), der bekannten Batteriekapazität sowie deseingestellten Mindestladezustands, welcher eAmountDischarge direkt beeinflusst, berechnen.Es wird für das Simulationsszenario angenommen, dass stets die minimal einstellbare Mindest-reichweite von 18 km ( ‚= 30 % SOC) gilt. Die resultierenden Informationen aus den Logdatendes Fahrzeugs sind in Tabelle 6.5 gelistet.Tabelle 6.5: Standzeiten am Smart Home sowie energierelevante Daten des Elektrofahrzeugsin Woche 4 der HerbstwohnphasePräsenz ESHL Ladebeginn Start-SOC Ladeende End-SOC LadedauerFr 23:09 – Sa 19:22 23:12 27 % 04:40 100 % 5 h 27 minSa 23:19 – So 11:36 9:28 71 % 11:35 98 % 2 h 6 minSo 17:40 – Mo 08:09 00:04 61 % 02:41 97 % 2 h 36 minMo 16:34 – Mo 20:00 – 68 % – 68 % –Mo 22:46 – Di 07:16 23:48 46 % 03:33 96 % 3 h 45 minDi 18:15 – Mi 15:24 21:03 33 % 01:49 98 % 4 h 45 minMi 19:39 – Do 11:52 22:34 53 % 01:46 97 % 3 h 12 minDo 16:51 – Fr 09:24 22:10 70 % 00:14 98 % 2 h 4 min6.2.2 Lastgänge simulativer WohnphasenDie Simulationsumgebung des EMS stellt diverse Parameter zur Verfügung, über die der cha-rakteristische Lastgang eines simulierten Haushalts beeinflusst werden kann. Die wesentlichenKenngrößen sind die folgenden:• Anzahl der Bewohner (2 bis 5)• Simulierte (steuerbare wie auch nicht steuerbare) Haushaltsgeräte• Einsatz eines BHKWs als steuerbarer dezentraler Erzeuger• Einsatz einer PV-Anlage als nicht steuerbarer dezentraler Erzeuger• Nutzung eines Elektrofahrzeugs mit konfigurierbaren Batteriekennwerten• Ankunfts- und Abfahrtszeiten des Elektrofahrzeugs sowie die SOC-Werte bei Ankunft• Simulationszeitraum während eines Jahres• Zeitvariables Strompreissignal• Zeitvariables Lastbegrenzungssignal1246.2 Evaluation des ausgewählten Kodierungsschemas für das ElektrofahrzeugZiel des evolutionären Algorithmus ist die Bestimmung eines kostenminimalen Gesamt-lastgangs über alle simulierten beobachtbaren und steuerbaren Haushaltskomponenten unddezentralen Erzeuger. Die Stellgrößen für den evolutionären Algorithmus wurden so gewählt,wie sie auch schon in [3] Verwendung fanden. Es hat sich gezeigt, dass durch Veränderungendieser Parameter keine nennenswerten Verbesserungen hinsichtlich eines kostenoptimalenLastprofils erzielt werden konnten. Daher finden die hier gelisteten Werte Anwendung:• Anzahl Individuen pro Generation: 100• Anzahl Generationen: 100• Mutationsrate: 0,095• Selektionswahrscheinlichkeit: 0,80• Turnierselektion mit zwei Individuen (Binary Tournament) [74]• Das jeweils beste Individuum wird in die Nachfolgegeneration übernommen (Elitismus)Da jedes Individuum einzeln evaluiert wird, ergeben sich aus einer Population von 100 Indivi-duen und 100 Generationen insgesamt 10.000 Evaluationen.Die Kosten für den von der PV-Anlage und dem BHKW erzeugten und selbst verbrauch-ten Strom liegen bei 0 ct/kWh. Daher ist es aus Sicht einer kostenbasierten Optimierungsinnvoll, einen möglichst hohen Eigenstromverbrauch zu erzielen. Es werden im Rahmender durchgeführten Simulationen vom Optimierungsalgorithmus keine Einspeisevergütungenberücksichtigt, da davon ausgegangen wird, dass es stets günstiger ist, den selbst erzeugtenStrom zur Deckung der lokalen Haushaltslast zu verwenden (vgl. auch Integrationsszenario 1aus Abschnitt 1.1 und [40]).In den folgenden Auswertungen der durchgeführten Simulationen soll das Potential gezeigtwerden, welches ein gesteuertes Lade- und Rückspeiseverhalten des E-Fahrzeugs auf Basis derEntscheidungen des Energiemanagements sowohl für die Steigerung des Eigenstromverbrauchsals auch insgesamt für die Senkung der Stromkosten mit sich bringt. Die Höhe der Kostenein-sparung hängt in erheblichem Maße auch von der Spreizung des zeitvariablen Strompreissignalsab, also der Dierenz zwischen dem teuersten und dem günstigsten Strompreis.Das Lade- und Rückspeiseverhalten des Elektrofahrzeugs lässt sich am besten anhandeines dargestellten Wochenlastgangs analysieren, weshalb die Simulation eines gesamtenJahres und somit die Jahresdurchschnittswerte in dieser Evaluation nicht im Fokus stehen.In Abschnitt 6.2.1 wurde eine beispielhafte Woche aus der Wohnphase im Herbst 2013diskutiert, die als Grundlage für die Simulationen in diesem Abschnitt dient. Abschnitt6.2.3 hingegen wird auf eine beispielhafte Woche im Mai 2014 eingehen. Der wesentlicheUnterschied dieser beiden Wohnphasen liegt darin, dass im Gegensatz zur zweiten Wohnphasein der ersten kein gesteuerter Lade- geschweige denn Rückspeisevorgang stattfand, sonderngemäß Mode 3 (vgl. Abschnitt 2.1.2) geladen wurde. Um eine gewisse Vergleichbarkeit dersimulierten Wohnphasen mit real durchgeführten Wohnphasen zu ermöglichen und ebensosaisonale Unterschiede zu berücksichtigen, wird jeweils dieselbe beispielhafte Woche imFrühjahr und im Herbst simuliert. Ebenso kommen in der Simulation dieselben zeitvariablenStrompreis- und Lastbegrenzungssignale zum Einsatz, wie sie auch in der entsprechendenWoche der realen Wohnphase Verwendung fanden. Selbiges gilt auch für das Mobilitätsprofildes Elektrofahrzeugs.125Kapitel 6 EvaluationDie Simulation der Haushaltsgeräte basiert auf Erfahrungswerten vergangener Wohnphasenim ESHL während der Durchführung des Forschungsprojekts MeRegioMobil, Details hierzusind [3] zu entnehmen. Es werden die Lastgänge von insgesamt fünf Haushaltsgeräten simuliert:1. Geschirrspülmaschine (steuerbar)2. Waschmaschine (steuerbar)3. Trockner (steuerbar)4. Ofen (nur beobachtbar)5. Herdplatte (nur beobachtbar)Darüber hinaus wird zusätzlich eine gewisse Grundlast simuliert, wie sie bspw. durch Standby-Geräte erzeugt wird. Während eine zeitliche Verschiebung der Haushaltsgeräte Ofen undHerdplatte aus Benutzungskomfortsicht nicht infrage kommt, ist es bei den drei KomponentenGeschirrspülmaschine, Waschmaschine und Trockner nicht unbedingt erforderlich, dass diesesofort nach Beladung und Programmierung starten. Der jeweilige Programmstart kann dahervom Energiemanagement zeitlich flexibel gesteuert werden, sodass diese Geräte kostenoptimaleingeplant und zum voreingestellten Endzeitpunkt spätestens ihren Programmablauf beendethaben. Hierfür werden ebenfalls zufällige Freiheitsgrade simuliert.Die zu simulierende PV-Anlage hat eine Leistung von 4,6 kWp und entspricht der realenPV-Anlage, welche während des Projektzeitraums von MeRegioMobil auf dem ESHL in-stalliert war. Aufgrund von Umbaumaßnahmen steht diese PV-Anlage real nicht mehr zurVerfügung, weshalb sie auch nicht in den dargestellten Lastgängen aus Abschnitt 6.2.1 und6.2.3 zu finden ist. Das simulierte PV-Einspeiseprofil entspricht einem saisonal abhängigenStandardeinspeiseprofil für die südwestliche Region Deutschlands, in welcher sich auch dasSmart Home befindet.Das BHKW hat eine Einspeiseleistung von 5,2 kW. Die simulierten Einspeisevorgängesind einerseits durch die Lastsituation im Smart Home und andererseits durch thermischeRestriktionen wie die Unterschreitung einer Schwelltemperatur des Schichtspeichers für dieWarmwasserversorgung induziert. Eine erzwungene Erhöhung der Wassertemperatur imSchichtspeicher geht auch stets mit der Erzeugung elektrischer Energie einher.Es werden im Folgenden nun 16 Konstellationen simuliert, welche in Tabelle 6.6 zusammen-gefasst sind. Dieser Abschnitt wird auf die ersten acht Simulationen der Herbstsaison eingehenund die Ergebnisse darstellen, während die Simulationsergebnisse aus der Frühjahrssaison imZuge des Abschnitts 6.2.3 präsentiert werden.Sämtliche Simulationen werden mit einem identischen Initialisierungsvektor gestartet, wel-cher sicherstellt, dass identische Konfigurationen gemäß Tabelle 6.6 bei mehreren Durchläufenauch stets dieselben Ergebnisse liefern. Lediglich die hier präsentierten “Stellschrauben” Perso-nenanzahl, Saison sowie Erzeuger- und Verbraucherkonstellation führen zu unterschiedlichenGesamtlastgängen.Zusätzlich sei erwähnt, dass als minimale Lade- bzw. Rückspeisedauer ein Zeitintervall von10 Minuten gewählt wurde. Dies ermöglicht einerseits eine ausreichende Reaktionsfähigkeitauf die Hauslast und wirkt andererseits einer zu starken Oszillation des E-Fahrzeuglastprofilsentgegen. Das Fahrzeug kann, wie auch im realen Szenario, mit maximal 11 kW und minimal2 kW laden sowie mit den Leistungsstufen -1,2 kW, -2,5 kW und -4,2 kW Energie rückspeisen.1266.2 Evaluation des ausgewählten Kodierungsschemas für das ElektrofahrzeugTabelle 6.6: Simulationsdurchläufe mit diversen ParameterkonstellationenPV + BHKW Herbst 2013 Frühjahr 20142 Personen 5 Personen 2 Personen 5 Personenohne A: EV optimiert E: EV optimiert I: EV optimiert M: EV optimiertB: EV unopt. F: EV unopt. J: EV unopt. N: EV unopt.mit C: EV optimiert G: EV optimiert K: EV optimiert O: EV optimiertD: EV unopt. H: EV unopt. L: EV unopt. P: EV unopt.Simulation A: 2 Personen, ohne PV und BHKW, E-Fahrzeug optimiertDa weder PV-Anlage noch BHKW als Einspeisequelle zur Verfügung stehen, muss dasElektrofahrzeug dazu genutzt werden, durch gezielte Rückspeisevorgänge die Stromkostenzu reduzieren. So ist in dieser Simulation (vgl. Abbildung 6.8) beispielhaft zu erkennen,dass gezielt Samstagmittag, Mittwochmittag/-nachmittag sowie Donnerstagabend sowohlsteuerbare als auch nicht steuerbare Haushaltsgeräte durch Rückspeisevorgänge mit Energieaus der Fahrzeugbatterie versorgt werden. Nicht alle Rückspeisevorgänge erscheinen demBetrachter auf Anhieb sinnvoll, was zu einem gewissen Grad dem Zufälligkeitscharakter desevolutionären Algorithmus zuzuschreiben ist. Wie bereits in Abschnitt 3.2 beschrieben, lieferteine Metaheuristik nicht notwendigerweise das bestmögliche Ergebnis, aber eine in gegebenerRechenzeit hinreichend gute Lösung.Es ist des Weiteren deutlich zu erkennen, dass bei Ankunft am Freitagabend die 27 %SOC zu einem sofortigen Ladevorgang mit maximaler Leistung von 11 kW führen. WeitereLadevorgänge mit dieser Leistung sind fortan nur noch kurz vor Abfahrt zu verzeichnen. Diesist folgendermaßen zu begründen:Das jeweilige Zeitfenster, welches dem Teilproblem Elektrofahrzeug zur Optimierung zurVerfügung steht, ist auf drei Stunden begrenzt, um die Länge des Bitvektors (Genotyps) inGrenzen zu halten. Erst im letzten Zeitfenster, welches den Abfahrtszeitpunkt mit einschließt,sorgt der Optimierungsalgorithmus dafür, dass das Fahrzeug zum Abfahrtszeitpunkt einevollgeladene Batterie aufweist. Wie bereits in Abschnitt 4.3.4 beschrieben, werden hierbeiin einem Korrekturmechanismus die Zeitintervalle des letzten Zeitfensters vom Abfahrts-zeitpunkt aus chronologisch rückwärts durchlaufen und die entsprechend maximal möglicheLeistungsstufe festgesetzt, bis sämtliche benötigte Energie geladen wurde. Es gilt für denOptimierer die Prämisse, dass das Fahrzeug einerseits so schnell wie möglich den vorgegebenenminimalen Ladezustand aufweisen und andererseits zum Abfahrtszeitpunkt vollgeladen seinmuss. Aufgrund dieser harten Restriktionen, wie sie in Abschnitt 4.3.2 eingeführt wurden,werden eventuell auftretende Zusatzkosten vernachlässigt.Darüber hinaus fällt auf, dass das E-Fahrzeug fast durchgehend mit der minimal möglichenLadeleistung zu den vorwiegend günstigen Zeitintervallen mit 10 ct/kWh und 25 ct/kWh gela-den wurde. Auch die steuerbaren Haushaltsgeräte kamen meist in diesen Zeitslots zum Einsatz.Simulation B: 2 Personen, ohne PV und BHKW, E-Fahrzeug unoptimiertIn Szenario B, welches im Gegensatz zu Szenario A den ungesteuerten Ladevorgang desElektrofahrzeugs darstellt (vgl. Abbildung 6.9), wird gleich bei Ankunft am Smart Homedamit begonnen, die Batterie vollzuladen. Dies führt dazu, dass entsprechend oft mit 11 kWzum teuersten Strompreis von 40 ct/kWh geladen wird, wie es bspw. am Montag, Dienstag,Mittwoch und Donnerstag der Fall ist. Die steuerbaren Haushaltsgeräte hingegen werden niezu Zeiten des teuersten Strompreises betrieben, der überwiegende Teil sogar zum günstigsten127Kapitel 6 EvaluationTarif von 10 ct/kWh.Es lässt sich somit feststellen, dass der ungesteuerte Ladevorgang zumindest in einemSzenario ohne dezentral einspeisende Energiequellen einen kostentechnischen Nachteil mit sichbringt, wie es auch in Tabelle 6.7 nachzulesen ist.Simulation C: 2 Personen, mit PV und BHKW, E-Fahrzeug optimiertIn Simulation C werden zum ersten Mal auch die Einspeisequellen PV-Anlage sowie BHKWmit einbegzogen. Das PV-Einspeiseprofil entspricht wie bereits erwähnt einem StandardE0-Einspeiseprofil für die südwestliche Region Deutschlands im Monat November. Das BHKWwird sowohl elektrisch als auch thermisch geführt betrieben. Dies bedeutet, dass das BHKWnicht nur dann elektrische Energie erzeugt, wenn das Energiemanagement eine hohe ge-plante Last im Haus feststellt, sondern auch, sobald die vordefinierte Grenztemperatur desWarmwasserschichtspeichers Gefahr läuft, unterschritten zu werden. Die Temperatur desSchichtspeichers darf jedoch auch eine gewisse Grenztemperatur nicht überschreiten, wasu. a. dazu führen kann, dass das BHKW keine elektrische Energie erzeugt, obwohl dies vomEnergiemanagement aufgrund der Hauslast so vorgesehen wäre.Aufgrund der Tatsache, dass die energierelevanten Mehrwertinformationen (aktueller Ener-giebedarf, rückspeisefähige Energiemenge, aktueller SOC, gewünschter Abfahrtszeitpunkt) desE-Fahrzeugs über den ISO/IEC 15118 Treiber dem Energiemanagement-System zur Verfügunggestellt werden, kann das BHKW entsprechend eingeplant werden. In dieser Simulation (vgl.Abbildung 6.10) ist daher eine sehr hohe Korrelation zwischen Ladephasen mit insbesonderehoher Ladeleistung und Einspeisevorgängen durch das BHKW mit standardmäßig -5,2 kWfestzustellen. Wie bereits in Simulation A festgestellt, finden in dieser Simulation die Lade-vorgänge mit 11 kW kurz vor dem Abfahrtszeitpunkt statt, um eine vollgeladene Batteriezu gewährleisten. Ähnlich zu Simulation A sind auch hier die favorisierten Ladevorgängemit der minimal möglichen Ladeleistung von 2 kW festzustellen, überwiegend im günstigstenZeitabschnitt mit 10 ct/kWh.Simulation D: 2 Personen, mit PV und BHKW, E-Fahrzeug unoptimiertIn diesem letzten simulierten 2-Personen-Haushalt-Szenario (vgl. Abbildung 6.11) wird dasElektrofahrzeug wiederum nicht gesteuert geladen, sondern über den analogen Mode 3-Mechanismus. Deshalb liegen dem Energiemanagement-System auch keine planbaren Infor-mationen für die zu erwartende Last durch das E-Fahrzeug vor. Daher kann das BHKWauch nicht gezielt Energie für diese Ladephasen bereitstellen. Lediglich die Ladevorgänge amDienstag- und Mittwochabend korrelieren mit einem Ladevorgang des E-Fahrzeugs, wobeidies mit der drohenden Unterschreitung der Schichtspeichertemperatur zu tun haben dürfteund daher eher eine zufällige zeitliche Übereinstimmung darstellt.Simulation E bis H: 5 Personen in einer HerbstwocheDie Simulationen E bis H (vgl. Abbildung 6.12 bis 6.15) ähneln den Simulationen A bis D,mit dem Unterschied, dass die Nutzung steuerbarer wie beobachtbarer Haushaltsgeräte demProfil eines 5-Personen-Haushalts statt eines 2-Personen-Haushalts entspricht. Es sind hierbeiähnliche Tendenzen zu erkennen, wie sie bereits diskutiert wurden.In allen dargestellen Simulationsläufen wurde der Übersichtlichkeit wegen auf die Visua-lisierung einer Summenlastkurve verzichtet. Es ist jedoch festzuhalten, dass die einzigenMomente, in denen die jeweiligen Lastgrenzen überschritten wurden, diejenigen sind, in denen1286.2 Evaluation des ausgewählten Kodierungsschemas für das Elektrofahrzeugdas Elektrofahrzeug entweder geladen wurde, um den eingestellten Mindestladezustand beiAnkunft oder eine vollgeladene Batterie kurz vor der Abfahrt zu gewährleisten. Dies bedeutet,dass durch das Scheduling des Energiemanagements stets erfolgreich eine extreme Verteuerungdes Strompreises vermieden wurde, sofern nicht explizit aufgrund von Restriktionen desElektrofahrzeugs mit höherer Priorität dagegen gesteuert wurde. Letzten Endes können aberauch diese Lastgrenzenüberschreitungen in zukünftigen Arbeiten durch ein weiter optimiertesDesign des globalen Optimierers vermieden werden. Bisher ist es dem Teilproblem Elektrofahr-zeug nicht möglich, im Zuge des Durchlaufens des evolutionären Algorithmus (vgl. Abbildung3.3) das Strompreis- bzw. Lastbegrenzungssignal in die Evaluation miteinzubeziehen. Wennalso der Reparaturmechanismus, welcher bspw. die Restriktion “vollgeladene Batterie zumAbfahrtszeitpunkt” sicherstellt, aktiv wird, so kann nicht festgestellt werden, ob bspw. einLadevorgang mit 11 kW kurz vor Abfahrt die Lastgrenze überschreiten würde und es daherevtl. sinnvoller wäre, mit geringerer Leistung dafür aber länger zu laden.Bepreisung der simulierten GesamtlastgängeDie Gesamtlast Pges(t) der simulierten Wochenlastgänge zum jeweiligen Zeitpunkt t ergibtsich gemäß (6.1) aus der Addition der kumulierten Last aller steuerbaren wie beobachtbarenHaushaltsgeräte und des Elektrofahrzeugs auf der Verbraucherseite mit dem Einspeiseprofil derPV-Anlage, des BHKWs und der rückgespeisten Energie des E-Fahrzeugs auf der Erzeugerseite.Pges(t) = PHaus(t) + PP V (t) + PBHKW (t) + PEV (t) (6.1)Die Kosten K(t) für ein Intervall t ergeben sich gemäß (6.2) aus dem Produkt der GesamtlastPges(t)11 und dem zeitvariablen Strompreissignal SPS(t), falls die Gesamtlast pro Zeitabschnittdas jeweils geltende Lastbegrenzungssignal LBS(t) nicht überschreitet. Für die Zeitabschnitte,in denen die Lastgrenze überschritten wird, wird ein zusätzlicher Straaktor SF hinzugerechnet.Dieser Straaktor entspricht in den real durchgeführten Wohnphasen sowie den Simulationendem Fünachen des jeweils geltenden Strompreises.Die der Optimierung zugrunde liegende Zielfunktion berücksichtigt keinerlei Einspeise-vergütungen aus den bereits erwähnten Gründen. Für die von der PV-Anlage eingespeisteelektrische Energie, die die Haushaltslast zum jeweils gegebenen Zeitpunkt übersteigt, wirdjedoch eine Einspeisevergütung von 14,07 ct/kWh für die Herbstwochen sowie 13,14 ct/kWhfür die Frühjahrswochen zugrunde gelegt. Diese Vergütungssätze entsprechen den Vorgabenaus §32 Abs. 2 Erneuerbare-Energien-Gesetz für Dachanlagen bis 10 kWp [14]. Bisher geltennoch keine Einspeisevergütungen für aus der Fahrzeugbatterie eingespeiste Energie, da – bisauf den Mitsubishi Outlander – auf dem Markt noch keine Fahrzeuge existieren, die technischdazu in der Lage wären. Im Rahmen der vorgestellten realen Wohnphasen sowie Simulationenwird jedoch für aus dem Fahrzeug rückgespeiste Energie, die die Hauslast übersteigt, dergleiche Vergütungssatz wie für die PV-Anlage angesetzt.Energie, welche über PV-Anlage und E-Fahrzeug hinaus durch das BHKW in das Netzeingespeist wird, wird dagegen mit einem Vergütungssatz von 5,41 ct/kWh bepreist [13].11Bei der Berechnung der Kosten entspricht t einem Intervall, somit entspricht Pges(t) hierbei der gemitteltenLast in diesem Intervall.129Kapitel 6 EvaluationSämtliche Vergütungssätze werden in (6.2) unter EST (Einspeisetarif) zusammengefasst.K(t) =Y__]__[Pges(t) ◊ SPS(t) falls 0 Æ Pges(t) Æ LBS(t),Pges(t) ◊ SPS(t) + SF ◊ (Pges(t) ≠ LBS(t)) ◊ SPS(t) falls Pges(t) > LBS(t),Pges(t) ◊ EST falls Pges(t) < 0.(6.2)Die Gesamtkosten Kges berechnen sich gemäß (6.3), wobei T der Dauer einer simuliertenWoche entspricht:Kges =ÿtœTK(t) (6.3)Die Zielfunktion, die die Kosten für den Gesamtfahrplan des Haushalts im jeweils aktuellenOptimierungshorizont T œ T minimiert, entspricht somit:min(Kges) (6.4)Tabelle 6.7 listet die Stromkosten aller simulierten Wochenlastgänge im Herbst auf, wobeidie Simulationen mit den ungesteuerten Ladevorgängen in der rechten Kostenspalte zu findensind.Tabelle 6.7: Stromkosten aller simulierten Wochenlastgänge im Herbst (inkl. Strafkosten fürLastgrenzenüberschreitung)Simulation Kosten [Ä] Simulation Kosten [Ä]Simulation A 40,43 Simulation B 73,38Simulation C 10,54 Simulation D 49,45Simulation E 47,41 Simulation F 88,83Simulation G 16,41 Simulation H 57,90Würde man die extreme Verteuerung der Stromkosten bei Überschreitung der Lastbegren-zungskurve außer Acht lassen, so würden sich die Stromkosten auf die Beträge laut Tabelle6.8 belaufen:Tabelle 6.8: Stromkosten aller simulierten Wochenlastgänge im Herbst (keine Strafkosten fürLastgrenzenüberschreitung)Simulation Kosten [Ä] Simulation Kosten [Ä]Simulation A 28,78 Simulation B 30,18Simulation C 9,22 Simulation D 16,65Simulation E 38,75 Simulation F 41,46Simulation G 13,47 Simulation H 21,11Es ist somit deutlich zu erkennen, dass das vom Energiemanagement vorgegebene optimierteLastprofil für das Elektrofahrzeug in allen simulierten Szenarien einen Kostenvorteil mitsich bringt. Im Falle der simulierten Lastgrenze können mittels eines gesteuerten Lade- undRückspeisevorgangs die Hälfte bis zu ca. drei Viertel der Stromkosten eingespart werden, wasein erhebliches Potential darstellt.1306.2 Evaluation des ausgewählten Kodierungsschemas für das ElektrofahrzeugDie Werte gemäß Tabelle 6.8 liegen der Annahme zugrunde, dass in naher Zukunft noch keineLastgrenze – bspw. vom Energievertrieb in Absprache mit dem Netzbetreiber – über ein SmartMeter an das Energiemanagement eines Haushalts kommuniziert werden wird, aber eine hohePreisspreizung von 10 ct/kWh bis zu 40 ct/kWh als Anreiz für einen gesteuerten Ladevorgangrealistisch wäre. Hierbei sind die Einsparpotentiale im Falle fehlender Einspeisequellen wiePV-Anlage oder BHKW erheblich geringer, können jedoch im entgegengesetzten Fall einDrittel bis knapp die Hälfte der Kosten ausmachen.131Kapitel 6 EvaluationAbbildung 6.8: Simulation A (Herbst, 2 Personen, ohne PV/BHKW, EV-Last gesteuert)1326.2 Evaluation des ausgewählten Kodierungsschemas für das ElektrofahrzeugAbbildung 6.9: Simulation B (Herbst, 2 Personen, ohne PV/BHKW, EV-Last ungesteuert)133Kapitel 6 EvaluationAbbildung 6.10: Simulation C (Herbst, 2 Personen, mit PV/BHKW, EV-Last gesteuert)1346.2 Evaluation des ausgewählten Kodierungsschemas für das ElektrofahrzeugAbbildung 6.11: Simulation D (Herbst, 2 Personen, mit PV/BHKW, EV-Last ungesteuert)135Kapitel 6 EvaluationAbbildung 6.12: Simulation E (Herbst, 5 Personen, ohne PV/BHKW, EV-Last gesteuert)1366.2 Evaluation des ausgewählten Kodierungsschemas für das ElektrofahrzeugAbbildung 6.13: Simulation F (Herbst, 5 Personen, ohne PV/BHKW, EV-Last ungesteuert)137Kapitel 6 EvaluationAbbildung 6.14: Simulation G (Herbst, 5 Personen, mit PV/BHKW, EV-Last gesteuert)1386.2 Evaluation des ausgewählten Kodierungsschemas für das ElektrofahrzeugAbbildung 6.15: Simulation H (Herbst, 5 Personen, mit PV/BHKW, EV-Last ungesteuert)139Kapitel 6 Evaluation6.2.3 Auswertung der realen Wohnphase im Frühjahr 2014Im Frühjahr 2014 wurde erneut eine Wohnphase mit zwei Probanden durchgeführt, wobeies sich in diesem Fall um zwei junge berufstätige Frauen handelte. Die Energiemanagement-Software, welche hierbei zum Einsatz kam, konnte im Gegensatz zur Herbst-Wohnphasedie Lade- und Rückspeisephasen des Elektrofahrzeugs flexibel im Rahmen der gegebenenRestriktionen steuern. Tabelle 6.9 listet die Ankunfts- und Abfahrtszeiten am Smart Home, dieLadezustände der Batterie zum jeweiligen Ankunftszeitpunkt sowie die jeweils im E-Fahrzeugeingestellte maximale Ladeleistung.Tabelle 6.9: Standzeiten am Smart Home sowie energierelevante Daten des Elektrofahrzeugsin Woche 2 der FrühjahrswohnphasePräsenz ESHL Start-SOC Max. Ladeleistung [kW]– Mo 26.05.14 07:54 – 11Mo 20:54 – Di 07:48 57 4Di 18:22 – Mi 08:10 66 3Mi 20:12 – Do 12:02 48 2Do 12:12 – Fr 07:36 65 2Fr 17:32 – Fr 20:52 51 2Fr 22:11 – Sa 08:01 39 2Mo 20:17 47 2Wie aus diesen Daten ersichtlich wird, wurde die im Fahrzeug eingestellte Mindestreichweitevon 30 % bei Ankunft nie unterschritten, weshalb in Abbildung 6.16 zur Ankunftszeit auchkeine Ladevorgänge mit der jeweils maximalen Ladeleistung zu verzeichnen sind. Da sichdie vorgegebene Lastgrenze – zumindest in dieser beispielhaften Woche – sukzessive vonTag zu Tag reduzierte, wurde von den Hausbewohnerinnen und gleichzeitig Fahrerinnen desE-Fahrzeugs die maximal mögliche Ladeleistung über die Benutzungsschnittstelle im Fahrzeugebenfalls reduziert.Die Ladevorgänge fanden erneut fast ausschließlich außerhalb der teuersten Zeitintervallestatt. Überraschend hingegen ist die Tatsache, dass im Prinzip keine Rückspeisevorgänge zuverzeichnen sind. Der Optimierungsrahmen – also der Optimierungsalgorithmus an sich, dieKodierung des Genotyps für das Elektrofahrzeug samt Gewichtungsfaktoren für Lade- undRückspeiseaktionen, die Ankunfts- und Abfahrtszeiten sowie Strompreis- und Lastbegrenzungs-signal – für die reale Wohnphase als auch die in Anhang A aufgeführten Simulationen I bis P istidentisch. Dennoch weisen die Simulationen im Gegensatz zum realen Wohnszenario vereinzeltRückspeisevorgänge auf. Dies zeigt, dass es schwierig ist, geeignete Gewichtungsfaktoren –sprich Kosten für das Laden und Rückspeisen – festzulegen, die für sehr unterschiedliche Kon-stellationen stets sehr gute Ergebnisse liefern. Es ist nicht ganz ersichtlich, weshalb in dieserWoche keine Rückspeisevorgänge durchgeführt wurden. Auch das BHKW lieferte nicht stetszu den Zeiten elektrische Energie, zu denen die steuerbaren Haushaltsgeräte Last erzeugten.Tabelle 6.10 listet analog zur Tabelle 6.7 die Stromkosten aller simulierten Wochenlastgängeim Frühjahr auf.Würde man die extreme Verteuerung der Stromkosten bei Überschreitung der Lastbegren-zungskurve erneut außer Acht lassen, so würden sich die Stromkosten auf die Beträge lautTabelle 6.11 belaufen:1406.2 Evaluation des ausgewählten Kodierungsschemas für das ElektrofahrzeugTabelle 6.10: Stromkosten aller simulierten Wochenlastgänge im Frühjahr (inkl. Strafkostenfür Lastgrenzenüberschreitung)Simulation Kosten [Ä] Simulation Kosten [Ä]Simulation I 43,78 Simulation J 52,63Simulation K 10,51 Simulation L 24,15Simulation M 51,90 Simulation N 63,49Simulation O 11,29 Simulation P 26,69Tabelle 6.11: Stromkosten aller simulierten Wochenlastgänge im Frühjahr (keine Strafkostenfür Lastgrenzenüberschreitung)Simulation Kosten [Ä] Simulation Kosten [Ä]Simulation I 26,46 Simulation J 21,94Simulation K 5,17 Simulation L 5,64Simulation M 37,73 Simulation N 31,72Simulation O 6,70 Simulation P 6,83Unter dem Gesichtspunkt einer größtmöglichen Korrelation zwischen erzeugter Haushaltslastund eingespeister elektrischer Energie bietet der bisher eingesetzte Optimierungsalgorithmussowie die Kodierung des Genotyps für das Elektrofahrzeug (und auch das BHKW) Potentialfür Verbesserungen. Betrachtet man die Kosten für die Frühjahrswohnphase gemäß Tabelle6.10 so wird jedoch deutlich, dass ein gesteuertes Lastprofil für das Elektrofahrzeug in allensimulierten Konstellationen, welche einen Straaktor für das Überschreiten der Lastgrenzeberücksichtigen, einen erheblichen Kostenvorteil mit sich bringt. Selbiges Fazit ergibt sichauch für die Simulationen der Herbstwohnphase. Tabelle 6.11 zufolge, welche wiederum dieKosten ohne Berücksichtigung eines Straaktors für das Überschreiten der Lastgrenze wider-spiegelt, scheint dieser Kostenvorteil nicht gegeben. Dies oenbart das Verbesserungspotentialhinsichtlich der Architektur des Energiemanagement-Systems: Das Teilproblem selbst kannbei der Evaluation eines gerätespezifischen Lastprofils nicht auf das aktuell gültige zeitvariableStrompreis- bzw. Lastbegrenzungssignal zugreifen. Jedoch könnte auf diese Weise ein kosten-günstigeres Lastprofil gewährleistet werden, indem nicht pauschal mit voller Leistung kurz vorAbfahrt, sondern bei Bedarf über einen längeren Zeitraum mit geringerer Leistung geladenwird, um einen Ladezustand von 100 % zu erreichen. Im Falle der Simulationen aus Tabelle6.11 korrelierte der jeweilige Abfahrtszeitpunkt recht häufig mit einem teuren Preissignal.141Kapitel 6 EvaluationAbbildung 6.16: Auswertung der 2. Woche der Wohnphase im Frühjahr 2014142KAPITEL 7ZUSAMMENFASSUNG UND AUSBLICKAbschließend wird in Abschnitt 7.1 ein zusammenfassender Überblick über die Kernaspektedieser Arbeit präsentiert, bevor in Abschnitt 7.2 dem Leser potentiell anknüpfende Forschungs-tätigkeiten aufgezeigt werden.7.1 ZusammenfassungDie vorliegende Arbeit beschäftigt sich mit dem Potential einer vorteilhaften kommunikations-technischen Einbindung von Elektrofahrzeugen in das Smart Grid, einem in der Entstehungbefindlichen kommunikationstechnisch intelligent vernetzten Energienetz. Hierbei werden imSpeziellen die folgenden drei Aspekte beleuchtet:1. Die digitale Kommunikation zwischen Elektrofahrzeug und Ladestation zum Zweckeeines gesteuerten Lade- bzw. Rückspeisevorgangs, die auf dem standardisierten ProtokollISO/IEC 15118 basiert2. Die Integration dieses Protokolls in ein spezielles Energiemanagement-System einesHaushalts, auf Basis dessen sich das Elektrofahrzeug als flexibler Verbraucher undEnergiespeicher nutzen lässt3. Die Beschreibung eines E-Roaming-Verfahrens zur anbieter- und länderübergreifendenNutzung von Ladeinfrastruktur mittels diverser, teils standardisierter Kommunikations-schnittstellenIm Rahmen des ersten Aspekts wurde ein Auszug aus der aktuellen Normungslandschaftpräsentiert, welcher alle relevanten, für das Verständnis dieser Arbeit notwendigen Stan-dardisierungsinitiativen auf Hard- und Softwareseite präsentiert. Dieses normungstechnischeHintergrundwissen dient im Zusammenhang mit der im ersten Kapitel motivierten Zielset-zung, das Elektrofahrzeug als flexiblen Verbraucher und Energiespeicher in das Energienetzeinzubinden, als wichtige Voraussetzung, um dem Leser die Notwendigkeit des digitalenKommunikationsprotokolls ISO/IEC 15118 schlüssig darzulegen. Diese Norm befindet sichin Teilen noch im Standardisierungsprozess und spiegelt den Konsens gleich drei verschie-dener Industriezweige – Automobilhersteller, Ladeinfrastrukturbetreiber sowie die Vertreterder Energiewirtschaft – wider. Mittels dieser Kommunikationsschnittstelle ist es erstmals143Kapitel 7 Zusammenfassung und Ausblickmöglich, energierelevante Mehrwertinformationen zwischen Elektrofahrzeug und Ladestationsowie daran angebundender Systeme zu übertragen und somit einen planbaren, gesteuertenLadevorgang zu realisieren, welcher Lasten im Stromnetz geeignet verschieben, die regenerativverfügbare Energie besser ausnutzen und somit auch Stromkosten senken lässt. Insbesonderekönnen durch eine ezientere Ausnutzung der verfügbaren Ressourcen und dem besserenEinklang von Erzeugung und Verbrauch hohe Kosten für den Netzausbau vermieden bzw.reduziert werden.Das ISO/IEC 15118 Protokoll wurde darüber hinaus anhand der fünf Kriterien Akzeptanz,Erweiterbarkeit, Sicherheit, Ezienz und Komplexität evaluiert, um dem Leser eine aussage-kräftige Bewertung der Zukunftsfähigkeit dieser Norm präsentieren zu können.Um das ISO/IEC 15118 Protokoll sowie die angesprochenen Potentiale nicht nur theo-retisch zu betrachten, wurde ein Prototyp dieses Protokolls implementiert und in einemrealen Umfeld getestet, der sich auf den zweiten angesprochenen Aspekt bezieht. Diese realeEvaluationsumgebung besteht aus einem Prototypen eines intelligenten Haushalts mit beob-achtbaren und steuerbaren Haushaltskomponenten – dem Energy Smart Home Lab (ESHL)–, welches sich mit einer Grundfläche von 60 m2 und einer Aufteilung in eine gemütlicheWohnküche sowie zwei Schlafzimmer als geeignetes Umfeld für Wohnphasen mit Proban-den präsentiert. Über eine an das ESHL angebrachte Ladestation ist das Elektrofahrzeugin der Lage, mit dem Energiemanagement-System energierelevante Mehrwertinformationenwie bspw. benötigte Energiemenge, zur Rückspeisung zur Verfügung stehende Energiemen-ge und geplanter Abfahrtszeitpunkt auszutauschen. Hierfür wurde ein sogenannter Treiberentwickelt, welcher die ladestationsseitige Kommunikationsschnittstelle des ISO/IEC 15118Protokolls adaptiert und die Mehrwertinformationen in Datenobjekte übersetzt, die mit demEnergiemanagement-System ausgetauscht werden können. Gemäß der Architektur diesesEnergiemanagement-Systems, welches auf den Prinzipien des Organic Computing basiert, wur-de darüber hinaus eine sogenannte Observerkomponente zum Sammeln und Verarbeiten derZustandsinformationen des Elektrofahrzeugs sowie eine Controllerkomponente zur steuerndenEinwirkung auf den Lade- und Rückspeisevorgang entwickelt.Einen wesentlichen Teil dieser Arbeit macht die Kodierung der bereits angesprochenenund weiterer energierelevanter Mehrwertinformationen zur geeigneten Verarbeitung durchden Optimierungsalgorithmus, welcher auf einem evolutionären Verfahren basiert, aus. ImVergleich zu den diversen, im ESHL befindlichen steuerbaren Haushaltsgeräten wie Wasch-maschine, Trockner und Geschirrspülmaschine stellt die Berechnung eines kostenminimalenLastprofils für das Elektrofahrzeug ein deutlich schwierigeres Optimierungsproblem dar. Diesist dadurch begründet, dass ein Ladevorgang keinen atomaren Ausführungsblock darstellt,wie es etwa bei der Waschmaschine der Fall ist, sondern aufgrund der diversen Lade- undsogar Rückspeisestufen sowie der Möglichkeit, das Lastprofil recht feingranular zu gestalten,sich eine Vielzahl an möglichen Lösungen ergeben, aus denen unter zeitlicher und rechenkapa-zitätsbedingter Restriktionen ein nahezu optimales sowie gültiges Lastprofil berechnet werdenmuss. Als gültiges Lastprofil das Elektrofahrzeug betreend ist ein Lastprofil zu verstehen,welches sämtliche harten Restriktionen, gegeben durch technische Spezifika bzgl. der Batterieoder durch Benutzervorgaben, nicht verletzt.Im Rahmen diverser durchgeführter Simulationen konnte gezeigt werden, dass das erarbei-tete Konzept – gemeint ist die kommunikationstechnische Einbindung des Elektrofahrzeugs indas Energiemanagement anhand der besprochenen Komponenten und des Kodierungsschemas– die Stromkosten in einem 2- bzw. 5-Personenhaushalt im Vergleich zu einem ungesteuerten1447.2 AusblickLadevorgang erheblich senken kann. Dies setzt allerdings voraus, dass externe Anreizssignale,die die aktuelle Netzsituation in geeigneter Weise abbilden, vom Energieanbieter an einsolches Energiemanagement-System kommuniziert werden. Diese Signale können zeitvariablePreissignale mit signifikanter preislicher Spreizung, Lastbegrenzungssignale oder gar eineKombination dieser beiden sein.Der dritte und letzte große Aspekt dieser Arbeit beschäftigt sich damit, wie ein benut-zerfreundliches E-Roaming-Verfahren realisiert werden kann, welches es dem Elektromobilis-ten erlaubt, unabhängig von seinem Stromliefervertrag die Batterie seines Elektrofahrzeugsanbieter- und länderübergreifend an öentlicher Ladeinfrastruktur aufzuladen. Hierbei liegtder Fokus wiederum auf den technischen Schnittstellen, insbesondere werden die Voraus-setzungen, die hierfür bereits im ISO/IEC 15118 Protokoll geschaen wurden, sowie dasfür einen E-Roaming-Marktplatz ausgelegte Open InterCharge Protokoll analysiert und diezusammenhängende Funktionsweise erläutert. Dieser Aspekt erscheint etwas losgelöst von denrestlichen Kapiteln, beleuchtet jedoch im Gegensatz zum Smart Home Szenario einen ehermakroskopischen Aspekt der Elektromobilität und rundet somit die betrachtete Thematik ab.7.2 AusblickIn der vorliegenden Arbeit wurde speziell das erste der drei in Abschnitt 1.1 vorgestelltenIntegrationsszenarien untersucht, in welchem die Entkopplung von Erzeugung und Verbrauchals ein wichtiger Baustein der Energiewende gesehen wird. Die beiden anderen Szenarien,deren Fokus einerseits auf der Realisierung einer unterbrechungsfreien Stromversorgung undandererseits auf der Erbringung von Netzdienstleistungen für die Netz- und Spannungsqualitätliegt, wurden hingegen nicht näher betrachtet. Die existierende Test- und Evaluationsumge-bung – bisher repräsentiert durch das Smart Home (ESHL) – könnte mittels eines sogenannten4-Quadrantenstellers erweitert werden, um eine “hardware-in-the-loop” Testumgebung zurealisieren. Mit Hilfe eines solchen 4-Quadrantenstellers können unterschiedlichste Netzzustän-de, wie bspw. Überlastsituationen, große Spannungsbandschwankungen oder Kurzschlüsse,für das Smart Home emuliert und somit die Echtzeitfähigkeit des Elektrofahrzeugs auf dieProbe gestellt werden. Hierbei würden Verbrauchs- und Einspeisewerte des Smart Home mess-technisch erfasst und einer Netzsimulationssoftware als Eingangsgrößen übergeben werden.Diese Software könnte dann gemäß der zu simulierenden Netzsituation die entsprechendenSpannungskurven für den Netzwerkknoten, an welchem das Smart Home angeschlossen ist,errechnen und demzufolge die Parameter für den 4-Quadrantensteller bereitstellen. Der 4-Quadrantensteller wiederum würde die gewünschte Netzsituation am Hausanschlusspunkt desSmart Home generieren.Solche Szenarien könnten dann mittels zweier Methoden untersucht werden:1. Das Elektrofahrzeug ist mit einer Komponente zur Netzüberwachung ausgestattet undweist selbständig den fahrzeuginternen Ladestromrichter dazu an, bspw. Oberschwingungs-und Verzerrungsblindleistung durch Verschiebung des Blindleistungsfaktors (cos ) zukompensieren. Durch eine Korrektur des Verhältnisses zwischen Scheinleistung undWirkleistung am Ladestromrichter können Spannungsschwankungen lokal ausgeglichenwerden.2. Das Elektrofahrzeug ist nicht mit einer solchen Netzüberwachungskomponente ausge-stattet, erhält jedoch über das ISO/IEC 15118 Protokoll die zusätzliche Information,145Kapitel 7 Zusammenfassung und Ausblickwelchen Blindleistungsfaktor es am Ladestromrichter einzustellen hat. Hierfür müsstevon einer externen Entität – bspw. dem Netzbetreiber – ein entsprechendes Signal andas Energiemanagement-System des Smart Home gesendet werden. In Abschnitt 6.1.2wurde bereits erläutert, wie eine standardkonforme Erweiterung des Protokolls um einenParameter wie diesen umgesetzt werden kann.In einem zweiten Schritt wäre es von Vorteil, den globalen Optimierer zu modifizieren. Dieserkönnte bspw. dahingehend verändert werden, dass man zwar das Optimierungsverfahren aufBasis eines evolutionären Algorithmus beibehält, jedoch die mögliche Struktur des Genotypsverändert, sodass dieser nicht nur in Form eines Bitvektors, sondern auch als gemischtganzzahliges Individuum kodiert werden kann. Dies könnte unter Umständen das Lastprofildes Elektrofahrzeugs dahingehend besser gestalten, dass eine höhere Korrelation zwischensteuerbarer Hauslast und Einspeiseverhalten des E-Fahrzeugs erwirkt wird und die Stromkostendadurch weiter gesenkt werden.Des Weiteren kann gemäß der aktuellen Architektur des globalen Optimierers das Teil-problem selbst bei der Evaluation eines gerätespezifischen Lastprofils nicht auf das aktuellgültige zeitvariable Strompreis- bzw. Lastbegrenzungssignal zugreifen. Wie in Abschnitt 6.2.2,Seite 128 bereits erwähnt, könnte auf diese Weise jedoch ein kostengünstigeres Lastprofilgewährleistet werden, indem nicht pauschal mit voller Leistung kurz vor Abfahrt, sondernbei Bedarf über einen längeren Zeitraum mit geringerer Leistung geladen wird, um einenLadezustand von 100 % zu erreichen.In einer Studie zu “Markthochlaufszenarien für Elektrofahrzeuge” des Fraunhofer Institutsfür System- und Innovationsforschung [75] wurde ein interessantes ökonomisches Potential fürgewerbliche Flotten identifiziert, die bereits 30 % des E-Fahrzeug-Neuwagenmarktes ausmachen.Die momentan noch gegenüber vergleichbaren Fahrzeugen mit Verbrennungsmotor höherenAnschaungskosten für Elektrofahrzeuge sind einerseits in den Kosten für die Traktionsbatterie1und andererseits in den Kosten für den (teils hybriden) Antriebsstrang begründet. Hingegensind die laufenden Kosten gegenüber Fahrzeugen mit Verbrennungsmotor um ein Vielfachesgeringer, da zum Einen die Stromkosten für die Zurücklegung derselben Strecke nur einenBruchteil der Kraftstopreise ausmachen und zum Anderen geringere Wartungskosten zuerwarten sind (weniger mechanische Bauteile, kein Ölwechsel nötig, etc.). Gerade vor diesemHintergrund erscheint der Einsatz von Elektrofahrzeugen in gewerblichen Fuhrparks besonderssinnvoll. Je mehr Strecken diese Fahrzeuge zurücklegen, umso schneller amortisieren sich diehöheren Investitionskosten.Zudem ist gerade in firmeninternen Fuhrparks eine hohe Planbarkeit für die zurückzule-genden Strecken gegeben, da über das Fuhrparkmanagementsystem die zweckgebundenenReservierungen (Geschäftstermin, Warenauslieferung, etc.) der Elektrofahrzeuge erfasst undsomit entsprechend optimierte Ladefahrpläne für die einzelnen Ladestationen auf dem Fir-mengelände berechnet werden können. Somit kann nicht nur dafür gesorgt werden, dass dieeinzelnen Elektrofahrzeuge rechtzeitig den jeweils nötigen Ladezustand aufweisen, sondernauch die Stromkosten gesenkt werden. Der Grundpreis für den Stromtarif Gewerbetreibenderwird nämlich an der höchsten Leistungsabnahme über das gesamte Jahr gesehen bemessen,was eine zeitliche Koordinierung der Ladevorgänge untereinander und mit evtl. weiterenEnergieverbrauchern erforderlich macht, um die Kosten niedrig zu halten. Die Orchestrierung1Die Kosten für Lithium-Ionen Batterien sind in den letzten Jahren über die Erwartung hinaus stark gesunken,sodass die Batterie möglicherweise innerhalb von einem oder zwei Jahren kein Kostenargument mehrdarstellen müsste.1467.2 Ausblickder Energieflüsse in einem elektrifizierten Fuhrpark stellt daher ein weiteres, über den SmartHome-Anwendungsfall hinausgehendes und sehr spannendes Energiemanagement-Szenariodar.Die Firma Dataforce erhebt in Zusammenarbeit mit dem Kraftfahrtbundesamt regelmä-ßig Statistiken zum elektromobilen Fahrzeugbestand in deutschen Fuhrparks. Aus diesenStatistiken heraus ließe sich, zusammen mit Zusatzinformationen über die installierte Ladein-frastruktur des jeweiligen Fuhrparks, eine Bedarfsanalyse für ein Lademanagement ableiten.Abschließend bleibt zu sagen, dass der im Rahmen dieser Arbeit entwickelte Prototypdes ISO/IEC 15118 Protokolls zwar nicht alle Aspekte der Norm widerspiegelt – auf dieImplementierung der Sicherheitsmechanismen wie TLS wurde bspw. verzichtet – aber derexistierende Code einer standardkonformen Implementierung entspricht. Die Schnittstelle zumEnergiemanagement-System des Smart Home (der Treiber) lässt sich mit minimalem Aufwandfür beliebig andere Energiemanagement-Systeme anpassen. Somit ist eine Verwertung derbestehenden Arbeit über den akademischen Horizont hinaus gewährleistet.147ANHANG ASIMULATIONSERGEBNISSE WOHNPHASE FRÜHJAHR 2014In diesem Anhang sind die Simulationsläufe I bis P, welche jeweils der in Abschnitt 6.2.3ausgewerteten Woche der Wohnphase im Frühjahr 2014 entsprechen, enthalten.149Anhang A Simulationsergebnisse Wohnphase Frühjahr 2014Abbildung A.1: Simulation I (Frühjahr, 2 Personen, ohne PV/BHKW, EV-Last gesteuert)150Abbildung A.2: Simulation J (Frühjahr, 2 Personen, ohne PV/BHKW, EV-Last ungesteuert)151Anhang A Simulationsergebnisse Wohnphase Frühjahr 2014Abbildung A.3: Simulation K (Frühjahr, 2 Personen, mit PV/BHKW, EV-Last gesteuert)152Abbildung A.4: Simulation L (Frühjahr, 2 Personen, mit PV/BHKW, EV-Last ungesteuert)153Anhang A Simulationsergebnisse Wohnphase Frühjahr 2014Abbildung A.5: Simulation M (Frühjahr, 5 Personen, ohne PV/BHKW, EV-Last gesteuert)154Abbildung A.6: Simulation N (Frühjahr, 5 Personen, ohne PV/BHKW, EV-Last ungesteuert)155Anhang A Simulationsergebnisse Wohnphase Frühjahr 2014Abbildung A.7: Simulation O (Frühjahr, 5 Personen, mit PV/BHKW, EV-Last gesteuert)156Abbildung A.8: Simulation P (Frühjahr, 5 Personen, mit PV/BHKW, EV-Last ungesteuert)157LITERATURVERZEICHNIS[1] IEC 62196: Stecker, Steckdosen, Fahrzeugsteckvorrichtungen und Fahrzeugstecker - Kon-duktives Laden von Elektrofahrzeugen. 2010[2] ACEA - European Automobile Manufacturers’ Association: ACEA positionand recommendations for the standardization of the charging of electrically chargeablevehicles. http://www.acea.be/uploads/publications/Updated_ACEA_position_on_charging_ECVs.pdf, Mai 2012. – [Zugri am 09.05.2014][3] Allerding, F. : Organic Smart Home - Energiemanagement für Intelligente Gebäude,Karlsruher Institut für Technologie (KIT), Dissertation, 2013[4] Allerding, F. ; Mauser, I. ; Schmeck, H. : Customizable Energy Management inSmart Buildings using Evolutionary Algorithms. In: Proceedings der EvoStar 2014, 2014[5] Allerding, F. ; Premm, M. ; Shukla, P. ; Schmeck, H. : Electric Load Managementin Smart Homes Using Evolutionary Algorithms. In: Proceedings of the main Europeanevents on Evolutionary Computation. Malaga, Spain : J.-K. Hao and M. Middendorf,Apr. 2012[6] Allerding, F. ; Schmeck, H. : Organic Smart Home - Architecture for EnergyManagement in Intelligent Buildings. In: Proceedings des Workshops Organic Computing(ICAC), 2011[7] alphaEOS AG: Projektsteckbrief ’B10 – Case Study House for The Future’. Febr. 2014[8] Auronik GmbH: Auronik Produkte. http://www.auronik.de/produkte/, . – [Zugriam 09.05.2014][9] BDEW: Fahren von Elektroautos wird noch kun-denfreundlicher. http://www.bdew.de/internet.nsf/id/20140228-pi-fahren-von-elektroautos-wird-noch-kundenfreundlicher-de, .– [Zugri am 09.05.2014][10] Becker, B. ; Kellerer, A. ; Schmeck, H. : User Interaction Interface for EnergyManagement in Smart Homes. In: Proceedings of the 3rd IEEE PES Conference onInnovative Smart Grid Technologies (ISGT), 2012159Literaturverzeichnis[11] Bless, R. ; Mink, S. ; Blaß, E.-O. ; Conrad, M. ; Hof, H.-J. ; Kutzner, K. ;Schöller, M. : Sichere Netzwerkkommunikation. Springer, 2005[12] Bosch Software Innovations: Bosch Software Innovations schat E-Mobility-Lösung mit übergreifenden Standards. http://www.bosch-si.com/de/newsroom/news/pressemitteilungen/pressemitteilungen-17280.html, 2013. – [Zugri am09.05.2014][13] Bundesamt für Wirtschaft und Ausfuhrkontrolle: BAFA: KWK-Zuschlag.http://www.bafa.de/bafa/de/energie/kraft_waerme_kopplung/stromverguetung/kwk-anlagen_bis_50kw/kwk-zuschlag/index.html, 2014. – [Zugri am 30.05.2014][14] Bundesnetzagentur: Photovoltaikanlagen: Datenmeldungen sowie EEG-Vergütungssätze. 2014[15] Chakraborty, U. K. ; Janikow, C. Z.: An analysis of Gray versus binary encoding ingenetic search. In: Information Sciences 156 (2003), Nr. 3–4, S. 253 – 269. – EvolutionaryComputation[16] Christoph M. Schwarzer (ZEIT Online): Der Anfang vomEnde des Ladeelends. http://www.zeit.de/mobilitaet/2014-04/elektroauto-akku-infrastruktur-ladesaeulen, Apr. 2014. – [Zugri am 09.05.2014][17] Die Bundesregierung: Nationaler Entwicklungsplan Elektromobilität. http://www.bmbf.de/pubRD/nationaler_entwicklungsplan_elektromobilitaet.pdf, Aug. 2009.– [Zugri am 09.05.2014][18] DIN: DIN SPEC 91286 – Elektromobilität – Schemata für Identifikatorenfür E-Roaming – Contract ID und EVSE ID. http://www.spec.din.de/cmd?level=tpl-art-detailansicht&committeeid=0&artid=145915787&bcrumblevel=2&languageid=de, Nov. 2011. – [Zugri am 09.05.2014][19] DIN - Deutsches Institut für Normung: Developing International Standards.http://www.din.de/cmd?cmsrubid=57966&level=tpl-unterrubrik&menurubricid=57966&cmssubrubid=57983&menuid=47565&languageid=en&menusubrubid=57983&cmsareaid=47565, . – [Zugri am 09.05.2014][20] Ebee Smart Technologies GmbH: Der Ladepunkt Berlin. http://www.ebeesmarttechnologies.de/?portfolio=ladepunkt-3/, . – [Zugri am 09.05.2014][21] ECRYPT II – European Network of Excellence in Cryptology II: ECRYPT2Yearly Report on Algorithms and Keysizes (2008-2009). http://www.ecrypt.eu.org/documents/D.SPA.7.pdf, Jul. 2009. – [Zugri am 09.05.2014][22] electrive.net – Der Branchndienst für Elektromobilität: eMobility-Dashboard Deutschland. http://www.electrive.net/wp-content/uploads/2014/03/eMobility-Dashboard-Deutschland-2012-2013.pdf, . – [Zugri am 09.05.2014][23] ESCRYPT GmbH: Sicheres eMetering. https://www.secmobil.com/index.php?id=7,. – [Zugri am 09.05.2014][24] Ester, P. ; Seitz, T. ; Becks, T. ; Pietsch, J. : Umfeldanalyse IKT für Elektromobilität2013. Aug. 2013. – Geschäftsstelle der Begleitforschung IKT für Elektromobilität II160Literaturverzeichnis[25] Europäische Kommission: EU launches clean fuel strategy. http://europa.eu/rapid/press-release_IP-13-40_en.htm, Jan. 2013. – [Zugri am 09.05.2014][26] Europäisches Parlament: Klimaschutzpolitik: Abgeordne-te fordern verbindliche Ziele bis 2030. http://www.europarl.europa.eu/news/de/news-room/content/20140203IPR34510/html/Klimaschutzpolitik-Abgeordnete-fordern-verbindliche-Ziele-bis-2030, 2014. –[Zugri am 09.05.2014][27] Europäisches Parlament: Richtlinie des Europäischen Parlaments unddes Rates über den Aufbau der Infrastruktur für alternative Kraftstoe.http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML+AMD+A7-2013-0444+120-120+DOC+PDF+V0//de, Apr. 2014. – [Zugri am 09.05.2014][28] Fraunhofer ESK: Kommunikation für das Energie-management bei E-Fahrzeugen.http://www.esk.fraunhofer.de/de/projekte/SMARTV2G.html, . – [Zugri am09.05.2014][29] Gottwalt, S. ; Schuller, A. ; Flath, C. ; Schmeck, H. ; Weinhardt, C. : Assessingload flexibility in smart grids: Electric vehicles for renewable energy integration. In:Power and Energy Society General Meeting (PES), 2013 IEEE, 2013, S. 1–5[30] Green eMotion: Development of a European Framework for Electromobility – Deliver-able 3.2: ICT Reference Architecture. http://www.greenemotion-project.eu/upload/pdf/deliverables/D3_2-ICT-Reference-Architecture-V1_2-submitted.pdf, Apr.2012. – [Zugri am 09.05.2014][31] HomePlug Alliance: HomePlug Green PHY™ Specification. http://www.homeplug.org/tech/homeplug_gp, . – [Zugri am 09.05.2014][32] Hubject: Open InterCharge Protocol v1.1. http://www.hubject.com/pdf/closed/v_1.1_Open_Intercharge_Protocol_(OICP).pdf, . – [Zugri am 09.05.2014][33] Hubject: Informationen über eRoaming. http://hubject.de/pdf/Hubject_ueber_eRoaming.pdf, 2013. – [Zugri am 09.05.2014][34] Hubject: Erste Zertifizierungsstelle für emobility-Zertifikate geht in Betrieb. http://www.hubject.com/pdf/PM_hubject_20140331.pdf, Apr. 2014. – [Zugri am 09.05.2014][35] Hubject GmbH: Hubject – Connecting EMobility Networks. http://www.hubject.com/,. – [Zugri am 09.05.2014][36] Hubject GmbH: Informationen über eRoaming. http://www.hubject.com/pdf/Hubject_ueber_eRoaming.pdf, . – [Zugri am 09.05.2014][37] IEC: IEC 61851-1: Elektrische Ausrüstung von Elektro-Straßenfahrzeugen – KonduktiveLadesysteme für Elektrofahrzeuge – Teil 1: Allgemeine Anforderungen. 2012[38] INSYS MICROELECTRONICS GmbH: Smart Charging nach ISO 15118 –Kommunikation über HomePlug Green PHY. http://www.insys-icom.de/icom/de/application-notes/AN174, 2013. – [Zugri am 09.05.2014]161Literaturverzeichnis[39] ISO: ISO 15118-2:2014: Road vehicles – Vehicle-to-Grid Communication Interface– Part 2: Network and application protocol requirements. http://www.iso.org/iso/catalogue_detail.htm?csnumber=55366, Apr. 2014. – [Zugri am 09.05.2014][40] Kaschub, T. ; Jochem, P. ; Fichtner, W. : Steigerung des Elektrizitätseigenverbrauchsvon Heim-Fotovoltaikanlagen durch Elektrofahrzeuge. In: uwf UmweltWirtschaftsForum21 (2013), Nr. 3-4, S. 243–250. – ISSN 0943–3481[41] KEBA AG: KEBA – Produkte – KeContact M10. http://www.keba.com/de/energieautomation/kemove-elektromobilitaet/produkte/kecontact-m10/ihr-nutzen/, . – [Zugri am 09.05.2014][42] Kovacs, A. ; Marples, D. ; Schmidt, R. ; Morsztyn, R. : Integrating EVs into theSmart-Grid. In: ITS Telecommunications (ITST), 2013 13th International Conferenceon, 2013, S. 413–418[43] Landesagentur für Elektromobilität und Brennstoffzellentechno-logie Baden-Württemberg GmbH: LivingLab BWe mobil – Die Pro-jekte des baden-württembergischen Schaufensters Elektromobilität stellen sichvor. http://www.e-mobilbw.de/files/e-mobil/content/DE/Publikationen/PDF/Schaufenster_Projektuebersicht_RZ_Web.pdf, . – [Zugri am 09.05.2014][44] Mitsubishi Motors: Mitsubishi Motors to Launch MiEV Power BOX 1500Watt Power Feeder for its Electric Vehicles. http://www.mitsubishi-motors.com/publish/pressrelease_en/corporate/2012/news/detail0834.html, 2014. – [Zugriam 09.05.2014][45] Müller-Schloer, C. ; Schmeck, H. ; Ungerer, T. : Organic Computing – A ParadigmShift for Complex Systems. Birkhäuser, 2011 (Autonomic Systems)[46] Mültin, M. ; Gitte, C. ; Schmeck, H. : Smart Grid-Ready Communication ProtocolsAnd Services For A Customer-Friendly Electromobility Experience. In: GI-Edition -Lecture Notes in Informatics (LNI) Bd. P-220, 2013, S. 1470–1484[47] Mültin, M. : Wie IKT die eMobilität und das Smart Grid verbindet. In: Neue Mobilität13 (2013), Okt., S. 26–27[48] Mültin, M. ; Schmeck, H. : Plug-and-Charge and E-Roaming - Capabilities of theISO/IEC 15118 For The E-Mobility Scenario. In: at – Automatisierungstechnik Band 62(2014), März, Nr. Heft 4, S. 241–248[49] National Security Agency: The Case for Elliptic Curve Cryptography. http://www.nsa.gov/business/programs/elliptic_curve.shtml, Jan. 2009. – [Zugri am09.05.2014][50] Nationale Plattform Elektromobilität: Technischer Leitfaden Ladeinfrastrut-kur. http://www.elektromobilitaet.din.de/sixcms_upload/media/3310/NPE_AG_4_Technischer_Leitfaden_Ladeinfrastruktur.pdf, . – [Zugri am 09.05.2014][51] Nationale Plattform Elektromobilität: Die deutsche Normungs-RoadmapElektromobilität – Version 2. http://www.dke.de/de/std/Documents/E-Mobility_Normungsroadmap_V2.pdf, Jan. 2012. – [Zugri am 09.05.2014]162Literaturverzeichnis[52] Nationale Plattform Elektromobilität: Fortschrittsbericht der Nationalen Platt-form Elektromobilität (Dritter Bericht). 2012[53] New Energy Promotion Council: Toyota City Low-carbon Society VerificationProject (Smart Melit). http://jscp.nepc.or.jp/en/toyota/, 2014. – [Zugri am09.05.2014][54] Open Charge Alliance: Open Charge Point Protocol 2.0 RC1. http://openchargealliance.org/documents.php, Nov. 2013. – [Zugri am 09.05.2014][55] Peintner, D. : EXIficient. http://exificient.sourceforge.net, . – [Zugri am09.05.2014][56] Phoenix Contact: Combined AC/DC Charging System Type 2.http://www.phoenixcontact-emobility.com/de/produkte/e-connectivity/combined-acdc-charging-system-type-2, . – [Zugri am 09.05.2014][57] Rolink, J. ; Horenkamp, W. ; Rehtanz, C. : Ladeinfrastrukturen für die Netzin-tegration von Elektrofahrzeugen. In: at – Automatisierungstechnik (2012), Febr., S.84–91[58] Rothlauf, F. : Representations for Genetic and Evolutionary Algorithms. Springer,2006[59] RWE: Erstmals in den USA: Innovative RWE-Ladetechnik für Elektroautos.http://www.rwe.com/web/cms/de/37110/rwe/presse-news/pressemitteilungen/pressemitteilungen/?pmid=4010901, Apr. 2014. – [Zugri am 09.05.2014][60] Schmutzler, J. ; Andersen, C. A. ; Wietfeld, C. : Evaluation of OCPP and IEC61850 for Smart Charging Electric Vehicles. In: Proceedings of EVS27: 27th ElectricVehicle Symposium Bd. 2013, 2013, S. 1–12[61] Schmutzler, J. ; Wietfeld, C. : Analysis of message sequences and encoding eciencyfor electric vehicle to grid interconnections. In: Vehicular Networking Conference (VNC),2010 IEEE, 2010, S. 118–125[62] Schmutzler, J. ; Andersen, C. A. ; Wietfeld, C. : Distributed Energy ResourceManagement for Electric Vehicles using IEC 61850 and ISO/IEC 15118. In: Proceedingsof VPPC 2012: 8th IEEE International Vehicle Power and Propulsion Conference Bd.2012, IEEE, 2012, S. 1–6[63] Schorn, K. : Erstellung eines Batteriemodells zur Approximation eines optimierten Lade-und Rückspeiseprofils, Karlsruher Institut für Technologie, Institut AIFB, Bachelorarbeit,2012[64] Schuller, A. ; Dietz, B. ; Flath, C. M. ; Weinhardt, C. : Charging Strategies forBattery Electric Vehicles: Economic Benchmark and V2G Potential. In: Power Systems,IEEE Transactions on PP (2014), Nr. 99, S. 1–9[65] Schuller, A. ; Rieger, F. : Assessing the Economic Potential of Electric Vehicles toProvide Ancillary Services: The Case of Germany. In: Zeitschrift für Energiewirtschaft37 (2013), Nr. 3, S. 177–194163Literaturverzeichnis[66] Siegfried Best (Hüthig Verlag: Deutsche Autohersteller setzen mit LudwigsburgerErklärung Standards. http://www.huethig.de/2011/07/15/deutsche-autohersteller-setzen-mit-„ludwigsburger-erklarung“-standards/, . – [Zugri am 09.05.2014][67] Siemens AG: eNterop Projekt. http://www.enterop.net, . – [Zugri am 09.05.2014][68] Siemens Research and Development: OpenV2G Project. http://openv2g.sourceforge.net, . – [Zugri am 09.05.2014][69] smartlab: Trianel und smartlab arbeiten im Rahmen ihrer E-Mobilitäts-Angebote zusammen. http://smartlab-gmbh.de/aktuelles/meldungen/meldungen-mit-tt-news/detailansicht-meldungen/article/trianel-und-smartlab-arbeiten-im-rahmen-ihrer-e-mobilitaets-angebote-zusammen.html, Febr. 2014. – [Zugri am 09.05.2014][70] VDE: VDE: Die Steckerfrage für Elektroautos ist geklärt. http://www.vde.com/de/Verband/Pressecenter/Pressemeldungen/Fach-und-Wirtschaftspresse/2013/Seiten/2013-03.aspx, Jan. 2013. – [Zugri am 09.05.2014][71] Vektor Informatik GmbH: Lösungen für Elektromobilität. http://vector.com/vi_electric_vehicles_de.html, 2013. – [Zugri am 09.05.2014][72] Volkswagen AG: INEES – Intelligente Netzanbin-dung von Elektrofahrzeugen zur Erbringung von Systemdienst-leistungen. http://www.erneuerbar-mobil.de/de/projekte/foerderung-von-vorhaben-im-bereich-der-elektromobilitaet-ab-2012/kopplung-der-elektromobilitaet-an-erneuerbare-energien-und-deren-netzintegration/inees, Mai 2013. – [Zugri am 09.05.2014][73] W3C: Ecient XML Interchange (EXI) Format 1.0 (Second Edition). http://www.w3.org/TR/exi/, . – [Zugri am 09.05.2014][74] Weicker, K. : Evolutionäre Algorithmen (2. Auflage). Teubner, 2007[75] Wietschel, M. ; Plötz, P. ; Kühn, A. ; Gnann, T. : Markthochlaufszenarien fürElektrofahrzeuge / Fraunhofer Institut für System- und Innovationsforschung ISI. 2013. –Forschungsbericht164

Smart Energy made in Germany

Abstract

Extracted data

Smart Energy made in Germany

Abstract

Extracted data

Related items

Related items