Seite 39 / 67
Mit der Integration der lokalen LLEM Module – UniCharge Master und Einbindung in das lokale Lastmanagement EBE Charge Server der EBE Mobility gelingt der Aufbau einer lokalen Instanz – lokales Lastmanagement und gesteuerte Ladung an einem Standort um hier die aufgebaute Niederspannungsverteilung und Standortinfrastruktur gegen Überlast zu schützen. Die Subzähler übergeben in den definierten Protokollen (OCPP 1.5 / EBE CPP) die Cluster Summenwerte an das übergeordnete Ladestellenmanagementsystem OCC und erlauben darüber die Disposition und Verwaltung von Ladepunkten und Ladestationen an einem Standort.
Abbildung 16 Aufbau – Netzstruktur Niederspannungsverteilung, Wien Prater Garage, E-Ladestationen geregelt über Charge Server lokal mit Anbindung an OCC LLEM Modul, EBE Mobility & Green Energy GmbH
Seite 40 / 67
2.2.3.2.5 Definition Ladearten und Ladetypen
Siehe Anhang Beilage V – LADEMODI und LADEARTEN
2.2.3.2.6 Beschreibung LLEM Leitprozess
Prämissen:
Zum Zeitpunkt der Anfrage wird ermittelt, ob und mit welcher Ladeleistung die Anfrage erfüllt werden kann.
Ein nachträgliches Ändern der geplanten Ladestrategie (Verschieben oder Aussetzen einer zu Beginn zugesagten Ladung) ist derzeit nicht realisiert, da hierzu die geschäftlichen/fachlichen Vorgaben noch zu klären sind (ist es überhaupt zulässig bzw. unter welche Bedingungen ist es ggf. zulässig, dass jemand zwar angesteckt hat, aber aufgrund von Prioritätsänderungen letztendlich keinerlei Ladung erfährt).
Für die Steuerung der Reservierungen ebenso wie das Zulassen von Spontan-Tankern muss die Ladezeit beschränkt sein, da sonst keine Planbarkeit besteht.
Aus Gründen der Verwaltbarkeit ist die Reservierbarkeit auf Reservierungsintervalle festgelegt (derzeit 30 Minuten - konfigurierbar) – beginnend jeweils zur vollen Stunde.
Dies bedeutet auch, dass ein lokales Autorisieren an der Ladestelle an solchen Ladestellen unterbunden werden muss, da sonst das Zentralsystem keine Steuer-Mechanismen zur Ablehnung/Verschiebung von Transaktionen zur Verfügung hat.
Um für LLEM & Reservierungen geeignet zu sein, müssen LS so konfiguriert werden können, dass sie entweder keine lokalen Whitelists verwenden oder dass die Inhalte dieser Liste zentral gesteuert werden können. Vorzugsweise ist die Autorisierungsreihenfolge „Zuerst zentral – dann lokal“.
An Ladestellen, an denen Last- und Energie-Management betrieben bzw.
Reservierungen möglich sind, ist eine Kommunikation mit dem Kunden unbedingt erforderlich, um einen „Spontan-Tanker“ (jemand der ohne Reservierung zu einer Ladestelle kommt) informieren zu können, wenn:
- In unmittelbarer Zukunft eine Reservierung ansteht
- Aus Lastmanagement-Gründen ein Laden erst zu einem späteren Zeitpunkt möglich ist.
Seite 41 / 67
Für die Kommunikation mit dem Kunden, um ihn über Abweichungen seiner Anforderungen zum Zeitpunkt der Reservierung oder des Ladebeginns informieren zu können, wird einerseits eine mobile App eingesetzt (für jene Nutzergruppe, die reservieren darf) und andererseits wird für Spontan-Tanker über SMS kommuniziert (Umsetzung in MISCH), wenn seine Ladeanfrage nicht zu 100% erfüllt werden kann.
Die Kommunikation erfolgt nicht über eine Anzeige an der Ladestelle, da es hierfür zum jetzigen Zeitpunkt keine standardisierte Regelung gibt.
Außerdem werden SMS als Erinnerungsfunktion benutzt, um über bevorstehende Ereignisse zu informieren:
• Beginn / Ende einer Reservierung
• Verfall einer Reservierung
• Ende der zulässigen Park-/Tankdauer
Steuerung Überblick:
Um über die Möglichkeit eines Ladevorgangs an einem Ladepunkt entscheiden zu können, muss man sowohl die Verfügbarkeit der Steckdose als auch die Verfügbarkeit des Stromes prüfen. Denn jemand kann sein Auto noch angesteckt haben, obwohl die Transaktion bereits beendet ist und er keinen Strom mehr zieht.
Das Steuerungsmodul führt zu jedem Ladepunkt einen Kalender, dem entnommen werden kann, ob in einem bestimmten Zeitintervall sowohl Stecker als auch Strom verfügbar sind.
Einträge in den Kalender verursachen sowohl Reservierungen als auch Spontan-Tank-Vorgänge. Systemtechnisch wird dabei Spontan-Tanken wie Reservierung für „sofort“
betrachtet.
Verfügbarkeit von Strom:
Grundsätzlich kann man unterscheiden in 2 Arten von Lastprofilen:
Statisches Lastprofil: dieses wird bei Produktivstart erstellt und im System hinterlegt.
Dynamisches Lastprofil: die Baseline wird hier ebenfalls bei Produktivstart erstellt und im System hinterlegt; durch die periodisch gelieferten tatsächlichen Mess-Verbrauchswerte könnte die Profilkurve als eine Art „selbstlernendes System“
periodisch (=täglich) angepasst und verbessert werden
LLEM prüft nie real-time gegen reale Last, sondern gegen die für die Ladeinfrastruktur festgelegte maximale Anschluss- und Abgabeleistung. Für die Steuerung der LS werden beide Profilkurven gleich behandelt.
Es muss systemtechnisch ein Cluster von Ladestellen gebildet werden können, die an einem Zuleitungsstrang hängen und der definiert, wie viel Strom in einer Zeitscheibe verteilt werden kann. Einem Cluster kann wieder ein Cluster übergeordnet werden.
Seite 42 / 67
Konzept Ladestrategie:
Was verstehen wir unter Ladestrategie:
Für einen Cluster von LS, die an einem gemeinsamen Anschluss hängen, wird festgelegt: Welches Auto bekommt wann – mit welcher Zeitscheibe – wieviel Strom.
Grundsätzlich gibt es mehrere Möglichkeiten, eine Strategie zu erstellen, abhängig vom verfolgten Ziel; Beispiele sind:
möglichst gleichverteilter Stromverbrauch,
abhängig von billig verfügbarer Überkapazität oder „grünem Strom“,
möglichst schnelle Abfertigung des Kunden
möglichst preisgünstig für den Kunden
Wir gehen in LLEM von der Prämisse aus, den Kunden möglichst schnell abzufertigen.
Wann muss die Strategie neu berechnet werden:
Mit jedem neu eintreffenden oder abfahrenden Kunden
Mit jeder neuen, geänderten oder gecancelten Reservierung
Das Lastprofil wird über den Tag als fest vorgegeben angenommen und muss daher nur im Tageswechsel, wenn aus dem selbstlernenden System das Profil angepasst wird, neu in die Ladestrategie einbezogen werden (derzeit nicht umgesetzt).
Ablauf zur Berechnung einer Ladestrategie
Für jeden LS-Cluster und jede Clustergruppe gibt es auf x-Minuten-Basis (x ist konfigurierbar und derzeit auf 30 Minuten eingestellt) eine Kurve des verfügbaren Stromes.
Für jeden LP gibt es den Wert seiner Stromabgabe in Kw.
Für jeden LP in dem LS-Cluster gibt es einen Reservierungskalender, wo pro Zeiteinheit eine Strommenge zur Verfügung steht. In dem sind einerseits die tatsächlichen Reservierungen bzw. aktuellen Ladungen eingetragen, andererseits aber auch nicht verfügbare Zeitscheiben, weil zu diesem Zeitpunkt nicht genügend Strom vorhanden ist, um auch diesen LP zu bedienen.
Mit dem Eintreffen eines Fahrzeuges an einem LP bzw. mit jeder Reservierungsanfrage wird der Reservierungskalender dieses LP auf Machbarkeit der Ladung/Reservierung geprüft, und zwar nach folgendem Algorithmus::
Prozessablauf zur Prüfung der Verfügbarkeit:
1. Auswahl LP
2. Ermittle max. Verweildauer (kann vom LP abhängig sein; derzeit über alle LP als gleich angenommen)
3. Ermittlung des Zeitintervalls zw. Start und Ende, wo der LP (=Parkplatz) frei ist Gibt es ein Zeitintervall, wo der LP physisch frei ist
4. Bestimmen/Auslesen von Grenzwerten o Ladeleistung des LP
o Max. Anschlussleistung der gesamten LS o Max. Anschlussleistung des Clusters der LS
Seite 43 / 67
o Max. Anschlussleistung von übergeordneten Clustergruppen
5. Bestimmen der Differenz zwischen Grenzwert und bereits vergebenem Strom je Zeitintervall
6. Ermittle alle zusammenhängenden Intervalle, wo Leistung LP = Verfügbarer Strom 7. Prüfung, ob es mindestens 1 Intervall gibt
Wenn für 1 Intervall Strom verfügbar
8. Info an den Kunden: Reservierungsdauer und zugesagte Stromlieferung Gibt es kein Zeitintervall,
o Wo LP frei &
o Wo Strom verfügbar:
9. entsprechende Info an den Kunden
Seite 44 / 67 Abbildung 17 LLEM Prozess Reservierung, NTT Data, eigene Darstellung
2.2.3.2.7 LLEM Leitprozess Reservierung
Lastmanagement ist nicht nur für sogenannte Spontan-Tank-Transaktionen von Bedeutung, sondern insbesondere auch für Reservierungen (Integration MISCH). Denn es ist wenig zufriedenstellend, wenn man zwar die Steckdose im Vorhinein reservieren kann, man aber dann Vorort dennoch nicht tanken kann, weil z. B. andere Reservierungen bereits den verfügbaren Strom benötigen.
Wenn eine Reservierung vom System bestätigt wird, bedeutet das eine verbindliche Zusage über die Stromlieferung. Dementsprechend muss im Reservierungsprozess auch das Lokale Lastmanagement involviert sein.
Im Rahmen von MISCH wird folgende Funktionalität für Reservieren zur Verfügung gestellt und mit LLEM integriert:
• Individual-Reservieren für einen bestimmten User
• Nur an speziell dafür gekennzeichneten LP möglich
• Je LP gibt es eine max. Reservierungsdauer
• Reservierungen sind unbeschränkt im Vorhinein möglich
• Man kann Reservierungen anlegen, anzeigen, stornieren
• Nicht eingehaltene Reservierungen werden nach einer Toleranzzeit automatisch gelöscht
Reservieren im Kontext von OCPP 1.5
OCPP 1.5 sieht mit Reserve Now nur ein sofortiges Reservieren eines Ladepunktes vor, was in den meisten Use Cases keine befriedigende Lösung darstellt.
Denn entweder führt dies zu einer unnötig langen Blockierung des LP, ohne dass getankt wird, wenn der Benutzer bereits bei Fahrtantritt sichergehen will, dass er zum gewünschten Zeitpunkt am gewünschten Ort eine freie Ladestelle mit Ladekapazität vorfindet.
Oder der Benutzer müsste erst kurz vor Eintreffen am LP eine Reservierung absetzen mit dem Risiko, dass er dann keine freien LP findet.
Daher muss diese Steuerung im Backend erfolgen.
Eine Reservierung kann durch den Endbenutzer über eine Mobile App durchgeführt werden:
Hierfür muss sich der User zuerst einloggen, da eine Reservierung nur für registrierte Benutzer möglich ist.
Nach Auswahl des Ladepunktes, an dem die Reservierung durchgeführt werden soll (über eine Liste oder über die Karte) muss das Reservierungsdatum und die frühest gewünschte Uhrzeit ausgewählt werden.
Dann zeigt die App alle Zeitslots dieses Tages ab der eingegebenen Uhrzeit an.
Seite 45 / 67
Intervalle, die nicht mehr reserviert werden können, sind ausgegraut.
Für die Anzeige dieses Kalenders mit den für eine Reservierung verfügbaren Zeitslots wird auch das Lokale Lastmanagement involviert, um nicht nur die Verfügbarkeit der Steckdose, sondern auch die Verfügbarkeit von Strom zu überprüfen.
Abbildung 18 LLEM Reservierung über mobile App, NTT Data, eigene Darstellung
TESTFÄLLE:
Testfall1:
Infrastruktur:
1 Cluster hat eine maximale Anschlussleistung von 800kw
In dem Cluster gibt es nur 1 Ladestelle mit einer maximalen Anschlussleistung von 100kw. D.h. die Ladestelle kann immer bis zu ihrem Maximum belastet werden, da der Cluster-Anschlusswert bedeutend höher ist.
Die Ladestelle selbst hat 3 LP:
o 2 LP mit jeweils einer maximalen Abgabeleistung von 50 kw (in Summe also 100 kw)
o 1 LP mit jeweils einer maximalen Abgabeleistung von 22 kw.
Die maximale Ladedauer an diesem LP beträgt 2 Stunden; das Zeitintervall beträgt 30 Minuten.
Belegung:
Es liegt bereits eine Reservierung A1 am LP 1 vor: für 4 Intervalle von 8:00 – 10:00, die 50 kw der verfügbaren Kapazität von 100 kw belegt.
Es liegt eine weitere Reservierung A2 am LP 3 vor: für 4 Intervalle von 9:00 – 11:00, die 22 kw der verfügbaren Kapazität belegt.
Nun kommt ein Spontan-Tanker um 8:40 an den LP 2.
Seite 46 / 67
Die im vorangegangenen Kapitel genannten Prämissen kommen nun zu Tragen:
Die beiden Reservierungen belegen zwischen 9:00 und 10:00 72 kw der verfügbaren 100 kw, sodass ein weiterer Ladevorgang mit 50kw nicht mehr gestartet werden kann.
Eine Ladung wird nur dann gestartet, wenn mindestens in mindestens für 1 ganzes Zeitintervall Strom zur Verfügung steht.
Verteilstrategie ist eine Verschiebung der Ladung.
D.h. der Spontan-Tanker darf sein Auto anstecken (der Parkplatz steht ja ab sofort zur Verfügung); die Ladung wird aber erst zeitversetzt beginnen, sobald um 10:00 wieder ausreichend Strom zur Verfügung steht.
Abbildung 19 Testfall 1 mit Dummy Daten , NTT Data, eigene Darstellung
Testfall2:
Idente Rahmenbedingungen wie in Testfall1.
Hier kommt allerdings der Spontan-Tanker bereist um 8:10, sodass mehr als ein ganzes Intervall ab dem Ansteckzeitpunkt Strom zur Verfügung steht. Also wird der Tankvorgang sofort gestartet und um 9:00, wenn die 2. Reservierung beginnt, vorzeitig beendet.
Abbildung 20 Testfall 2 mit Dummy Daten, NTT Data eigene Darstellung
Testfall3:
Idente Rahmenbedingungen wie in Testfall1.
Hinzukommt, dass es im Cluster 1 (800 kw) neben der Ladestelle 1 (100 kw) noch eine zweiten LS-Cluster2 gibt, der um 10:30 780 kw Strom belegt.
In diesem Fall muss für die Verfügbarkeitsprüfung für den Spontan-Tanker A3 neben dem maximalen Anschlusswert der LS und der belegten Energie auf der Ladestelle auch der Anschlusswert des Clusters und dessen verbrauchte Gesamtenergie berücksichtigt werden.
Seite 47 / 67 Abbildung 21 Testfall 3´mit Dummy Daten, NTT Data, eigene Darstellung
2.2.3.2.8 Schnittstellen
Im Folgenden finden sich die Schnittstellen, die in den beiden Use Cases
Reservierung
Spontan-Ladung
Unter Berücksichtigung des lokalen Lastmanagements benötigt werden.
Im Sinne einer möglichst breiten Nutzbarkeit der Funktionalität wurde darauf Wert gelegt, dass alle Operationen mit OCPP1.5 kompatiblen Ladestellen möglich sind.
Mobile App
Anfrage, ob Reservierung für contractKey mit dem nächsten Intervall ansteht oder mit aktuellem Intervall bereits begonnen hat
Bei Spontantankern wird gepüft ob LP und Energie vorhanden ist (sofern LLEM aktiviert ist)
Abbildung 22 LLEM/MISCH Architektur, NTT Data, eigene Darstellung
Die Architektur besteht aus folgenden Modulen:
Mobile App (android)
LLEM (Lokales Lastmanagement)
MISCH (Reservierung)
OCC (Ladestellenmanagement)
Seite 48 / 67
Ladestellen-Controller
2.2.3.2.8.1 Mobile App/LLEM/MISCH/OCC Use Case 1 - Reservierung:
(1) Wenn der registrierte und eingeloggte Benutzer der App einen von ihm ausgewählten Ladepunkt zu einem ausgewählten Termin reservieren möchte, fragt die mobile Applikation über ein Web-Service den Reservierungskalender an, um die TimeSlots anzeigen zu können, an denen sowohl die Steckdose frei als auch Strom (lokales Lastmanagement) verfügbar ist.
(2) Der Benutzer wählt 1-n Timeslots unter Berücksichtigung der maximalen Ladedauer an diesem Ladepunkt zur Reservierung aus und schickt die Anfrage an das LLEM/MSICH-Modul, das nochmals eine Prüfung durchführt, ob sich in der Zwischenzeit an der Verfügbarkeit etwas geändert hat.
(3) Wenn die Reservierung nach wie vor möglich ist, wird die Reservierung im Kalender gespeichert.
(4) Es erfolgt eine Rückmeldung an den Benutzer über die erfolgreiche Reservierung des Ladepunktes
Use Case 2 – Spontan-Ladung:
(1) Ein Spontan-Tanker möchte an einem Ladepunkt, an der sowohl Reservierungen möglich sind als auch lokales Lastmanagement betrieben wird, laden.
(2) Wenn der Benutzer der App die Ladung startet, erfolgt im OCC standardmäßig eine Autorisierung, die im Falle eines LLEM gesteuerten LP zuerst eine Prüfung auf Stromverfügbarkeit und bevorstehende Reservierung durchführt.
(3) LLEM/MISCH schickt dem OCC eine Bestätigung über die Verfügbarkeit des LP.
(4) Der OCC führt dann weitere Autorisierungsschritte – auch Roaminganfragen – durch.
(5) Er informiert dann das LLEM/MISCH-Modul über das Autorisierungsergebnis.
(6) Bei erfolgreicher Autorisierung wird dann der LP entsprechend für die maximale Ladedauer im Kalender als nicht verfügbar eingetragen und der OCC wird vom LLEM/MISCH Modul mit dem Start der Ladung beauftragt.
(7) OCC führt ein remote start transaction (OCPP1.5) durch.
(8) Verzögerte Ladung:
Wenn aufgrund des Lastmanagements angefragte Ladungen nicht sofort starten können, werden sie mit einem Starttermin in der Zukunft – analog zu einer Reservierung - im Kalender eingetragen. Ein Scheduler prüft dann periodisch, ob ein verzögerter Ladevorgang gestartet werden muss und beauftragt zum gegebenen Zeitpunkt den OCC mit dem Start der Ladung.
2.2.3.2.8.2 Proprietäre Schnittstellen EBE CPP
Zur Kommunikation zwischen Ladestationen und zentralen Backendsystemen – Ladestellenmanagementsystem dient das EBE CPP (EBE Charge Point Protokoll) als Kommunikationsprotokoll zwischen den EBE Ladestationen und dem Verwaltungsserver.
Seite 49 / 67
Über dieses Protokoll werden Anfragen von der Ladestation an den Verwaltungsserver geschickt und gibt darüber hinaus Werte und Parameter von der Ladestation an das Ladestellenmanagement zurück. Durch die Integration von zusätzlichen Werten und Parametern können zusätzliche Felder und Werte flexibler integriert und schneller umgesetzt werden.
2.2.3.2.8.3 Open Charge Point Protocol OCPP 1.5
Der Kommunikationsstandard OCPP 1.5 für wurde von der Open Charge Alliance (OCA) mit Industriepartner und Ladestationsherstellern entwickelt und definiert. Dieser Standard ist neben proprietären Protokollen und Schnittstellen der aktuell am weitest verbreitete Standard für Kommunikationsschnittstellen zwischen Ladestationen und Ladestellenmanagementsystemen. Da dieser jedoch sehr eng gefasst ist und in den Beschreibungen für Werte und Parameter wenig Spielraum lässt sind dynamische Prozesse und Abläufe wie beispielsweise Smart Charging oder die Übernahme von Smart Meter Werten nur bedingt möglich.
2.2.3.2.8.4 Open Charge Point Protocol OCPP 2.0
Mit dem Dokument der Open Charge Alliance OCA OCPP 2.0 / Release Candidate 211 (Stand 03.11.2014) geht die Open Charge Alliance www.openchargealliance.org in die Umsetzung einer strukturierten und in Modulen aufgebauten Implementierung einer lokalen Ladestationsplattform und Kommunikation Schnittstelle zu zentralen Backendsystemen mit einer effizienten Spezifikation für Hardware- und Softwareschnittstellen um die zukünftigen Aufgabe von Liegenschaften- und Ladestationsanforderungen erfüllen zu können.
Die OCA verfolgt dabei den Weg von einem Core Modul, welches die Basisimplementierung darstellt, um zusätzliche Dienste und Services anbieten zu können. Die Basisfunktionen aus den bekannten OCPP 1.2 / 1.5 Protokoll werden in dem „Core“ Element des OCPP 2.0 abgebildet und durch neue Module „profiles“ erweitert. Dadurch ergeben sich zusätzliche und Möglichkeiten und weiterentwickelte use cases.
Die OCA setzt im OCPP 2.0 auf den neuen Websocket Transportkanal und einer JSON Codierung. Dadurch ergeben sich weitere Verbesserungen und eine höhere Effizienz für Netzwerk und Kommunikationselemente. Die OCPP 2.0 setzt auf eine JSON [ J ] Implementierung. OCPP 1.2. und 1.5 nutzt weiterhin SOAP [ S ]. Werden zukünftig Systeme implementiert werden die die unterstützen Protokolle mit [ J ] für JSON und [ S ] für SOAP bezeichnet. Beispielsweise OCPP2.0-J oder OCPP 1.5-S. werden sowohl JSON als auch SAOP unterstützt wird dies wie folgt gekennzeichnet OCPP2.0-JS.
Mit OCPP 2.0 werden zukünftige Standards und Protokolle wie ISO 15118 (V2G Kommunikation), welche auf einer high level Kommunikation zwischen EV und Infrastruktur
11 http://www.openchargealliance.org/?q=node/4170
Seite 50 / 67
aufsetzen, möglich gemacht und ergänzende Module im Bereich Smart Charging, Pricing und Reservierung angeboten.
Abbildung 23 Open Charge Alliance – OCPP 2.0 Core Profile
Die wesentlichen Änderungen und Erweiterungen zum OCPP 1.5 stellen die Module Pricing, Smart Charging und Monitoring & Control von Ladstationen dar. Diese Module können flexibel und unabhängig voneinander aufgesetzt und implementiert werden. Die
nachfolgende Übersicht zeigt die Teilmodule aus dem OCPP 2.0. / Release Candidate 2
Abbildung 24 OCPP 2.0 Übersicht Core Profile und ergänzende Module
Smart Charging Profile
Das Smart Charging Profile ermöglicht dem Betreiber, Zentralsystem und Ladepunkt / Ladestation bei einer eingeschränkten Energie-Verfügbarkeit / Netzanschlussreserve im Laufe eines Ladevorganges eine kontrollierte, geregelte Ladung durchzuführen. Es kann
Seite 51 / 67
als lokale Instanz, autonom oder über ein Zentralsystem verwaltet die Ladeleistungen freigeben oder begrenzen. Es kann auf übergeordneter Ebene als Lastausgleich für Überkapazitäten und zu Engpasszeiten für Erneuerbare Energiequellen genutzt werden.
OCPP 2.0 setzt in diesem Fall auf einer V2G Kommunikation auf. OCPP wurde entwickelt, um für die Kommunikation zwischen Fahrzeug (EV) und Ladestation (EVSE) nach der ISO / IEC 15118-Standard [15118] zu unterstützen. Allerdings wird erwartet, dass in den kommenden Jahren, die Mehrheit von Elektrofahrzeugen weiterhin den das PWM-Signal [61851] als Steuersignal nutzt, so dass mit dem Vorliegen des Smart Charging Profiles alle Anstrengungen unternommen werden, um das intelligente Laden an diesem Punkt zu unterstützen.
Aufbauend auf dem LLEM Aktivitäten (NNT Data) und dem lokalen Lastmanagement der EBE Mobility können diese Erkenntnisse, Erfahrungen und Elemente im Smart Charging Profile eingesetzt und verwertet werden. Das Smart Charging Profile lässt autonome wie auch zentral gesteuerte Szenarien zu.
2.2.3.2.8.5 ISO 15118
Die ISO 15118 spezifiziert als künftiger Standard die Kommunikation zwischen Elektrofahrzeugen (EV), einschließlich Batterie-Elektrofahrzeuge und Plug-In-Hybridfahrzeuge und zwischen den Elektro-Ladestationen den Versorgungsanlagen (EVSE).
Die ISO 15118 beschreibt die Kommunikation der generischen Geräte Electric Vehicle Communication Controller (EVCC) und der Supply Equipment Communication Controller (SECC), ISO 15118 beschreibt die Kommunikation zwischen diesen Komponenten. Die ISO 15118 wird für das Laden von Elektrostraßenfahrzeuge standardisiert, soll aber auch zukünftig für andere Fahrzeugtypen gelten.
Diese Kommunikationsschnittstellen zwischen Elektrofahrzeug (EV) und Ladeinfrastruktur ermöglicht eine tatsächliche V2G (Vehicle to Grid) Kommunikation auf einem High Level – IP basierenden Standard und Kommunikationsprotokollen. Vorerst ist nur die ISO 15118-1:2013 Road vehicles - Vehicle to grid communication interface - Part 1: General information and use-case definition12 veröffentlicht. Die darauf aufbauenden Standards und Teile sind teilweise erst im Entwurf bzw. noch in Bearbeitung. Mit einer Verfügbarkeit und Implementierung dieses Standards in Elektrofahrzeuge und Ladeinfrastruktur / Ladestationen ist nicht vor 2017 zu rechnen.
12 http://www.iso.org/iso/catalogue_detail.htm?csnumber=55365
Seite 52 / 67
2.2.3.2.9 OCC LLEM Modul
Im Folgenden sind jene Funktionalitäten im OCC beschrieben, die zur Administration der Daten für ein lokales Lastmanagement erforderlich sind.
Aufbauend auf den Erkenntnissen und Festlegung bei der Definition des LLEM Leitprozesses und alle Umsetzung in den nun umgesetzten LLEM Modulen basieren auf den aktuell implementierten Kommunikationsprotokollen OCPP 1.5 und EBE CPP. In den LLEM Spezifikationen und Modulen konnten den Anforderungen, nun dem im OCPP 2.0 erstmals in einer Draft version zum 03.11.2014 verfügbaren neuen Standards – Smart Charging – an ein
Aufbauend auf den Erkenntnissen und Festlegung bei der Definition des LLEM Leitprozesses und alle Umsetzung in den nun umgesetzten LLEM Modulen basieren auf den aktuell implementierten Kommunikationsprotokollen OCPP 1.5 und EBE CPP. In den LLEM Spezifikationen und Modulen konnten den Anforderungen, nun dem im OCPP 2.0 erstmals in einer Draft version zum 03.11.2014 verfügbaren neuen Standards – Smart Charging – an ein