-
Die vorliegende Erfindung betrifft eine Diagnostikanordnung für einen Ladepark, in dem mindestens ein Elektrofahrzeug aufgeladen werden kann. Insbesondere wird eine Kommunikations- bzw. Software-Architektur der Diagnostikanordnung beschrieben. Ferner wird ein Verfahren zur Diagnostikkommunikation für den Ladepark beschrieben.
-
Ladestationen bieten, vergleichbar mit einer konventionellen Mineralöl-Tankstelle für Autos mit Verbrennungsmotoren, die Möglichkeit, mindestens eine Traktionsbatterie eines Elektrofahrzeuges aufzuladen. Meist wird durch Anschluss der jeweiligen Ladestation an ein Niederspannungsnetz mit Trenntransformator oder ein Mittelspannungsnetz eines Energieversorgers ein Ladestrom bereitgestellt, der einem an der Ladestation geparkten Elektrofahrzeug zugeführt wird. Befinden sich an einem solchen Anschluss mehrere Ladestationen, und/oder werden zum gleichen Zeitpunkt mehrere Elektrofahrzeuge an diesen Ladestationen aufgeladen, ergibt sich die Notwendigkeit, eine endliche Stromkapazität des Anschlusses zum Mittelspannungsnetz möglichst effektiv zu verteilen. Gegebenenfalls gilt es auch, dabei einen jeweiligen Ladestand der Traktionsbatterie des jeweiligen Elektrofahrzeuges zu berücksichtigen. Jedenfalls sind so wechselseitig Informationen auszutauschen, welche an unterschiedlichen Stellen in einem aus den Ladestationen und den zu ladenden Elektrofahrzeugen gebildeten System auftreten, und wofür Kommunikationsmittel bereitgestellt werden müssen.
-
Gegebenenfalls ist ein Datenaustausch mit Steuergeräten des Ladeparks von Nöten, um bspw. an einem Terminal Informationen von einem Steuergerät abzufragen oder dieses zu beeinflussen. Bekannt ist hierzu, dass dies bislang nur in Gänze von einem mit einem Backend-Server vernetzen Ladepunkt an sich möglich ist, wobei die Daten zu Auswertung in einer großen HTML-Datei bereitgestellt werden.
-
Die Druckschrift
DE 10 2016 209 192 A1 beschreibt hierzu eine Ladestation für Elektrofahrzeuge, welche eine Steuerung der Ladestation und eine Mensch/Maschinen-Schnittstellenvorrichtung in Kommunikation mit der Steuerung beinhaltet. Die Steuerung sieht eine drahtlose Kommunikation mit einem Remoteserver vor.
-
In der Druckschrift
DE 10 2016 005 630 A1 wird eine Datenverarbeitungseinheit offenbart, welche einerseits eine erste Schnittstelle zu aufzuladenden Kraftfahrzeugen, anderseits eine zweite Schnittstelle zu einer Vielzahl von Ladestationen aufweist. Ein Informationsaustausch erfolgt mit einer jeweiligen Ladestation mit der zentralen Datenverarbeitungseinheit.
-
Die Kommunikation mit einer einzelnen Ladestation wird einem Benutzer in der Druckschrift
DE 10 2014 214 613 A1 zur Verfügung gestellt. Der Benutzer kann mit einer Steuereinheit in der Ladestation Daten austauschen, bspw. zur Identifikation des Benutzers oder zum Ladevorgang.
-
Für einen Benutzer ist eine Möglichkeit zur Abfrage von Informationen bzgl. benachbarter, also mit einem gleichen Mittelspannungsnetzanschluss verbundener Ladestationen im Stand der Technik nicht vorgesehen. Beim Laden mehrerer Elektrofahrzeuge an solchen Ladestationen und Unterbrechung der Kommunikation mit einem dies überwachenden Backend-Server, kann eine solche Information aber von Bedeutung sein, da eine Ladestromabgabe an einem Mittelspannungsnetzanschluss begrenzt ist. Außerdem wäre es für einen Benutzer wichtig, auch Diagnostikwerte von Steuergeräten der Ladestation beim Ladevorgang abfragen zu können, was bislang nur zentral von einem Backend-Server möglich ist.
-
Vor diesem Hintergrund ist es eine Aufgabe der vorliegenden Erfindung, eine Diagnostikanordnung für den Kommunikationsaustausch, der bzgl. eines Ladevorganges einer Traktionsbatterie an mindestens einer Ladestation auftritt, bereitzustellen. Der Kommunikationsaustausch soll sowohl während des Ladevorganges wie auch unabhängig davon, bspw. um Messwerte eines aktuellen Systemzustandes oder zu einer Abfrage eines Fehlerspeichers, möglich sein. Insbesondere gilt es, Struktur und Kommunikationsmittel vorzusehen, um Datenaustausch mit weiteren Ladestationen als die mindestens eine Ladestation an dem einen Anschluss zu einem Versorgungsnetz betreiben zu können. Schließlich soll ein Verfahren zur Verfügung gestellt werden, mit dem Diagnostikkommunikation mit einzelnen Steuergeräten der Diagnostikanordnung ermöglicht wird.
-
Zur Lösung der voranstehend genannten Aufgabe wird eine Diagnostikanordnung für einen Ladepark vorgeschlagen, wobei der Ladepark eine Mehrzahl von Komponenten und eine Netzwerkanordnung umfasst. Die Komponenten umfassen ein zentrales Gateway, mindestens ein Steuergerät und eine am zentralen Gateway angeordnete Diagnostikdatenbank, wobei die Diagnostikdatenbank mindestens eine Datei zur Diagnostik des mindestens einen Steuergeräts bereitstellt. Weiter stellt die Netzwerkanordnung ein Kern-Netzwerk zwischen der Mehrzahl von Komponenten bereit, wobei über das Kern-Netzwerk mindestens das mindestens eine Steuergerät mit dem zentralen Gateway verbunden ist. Zusätzlich weist die Netzwerkanordnung einen Backend-Server auf, welcher eine Backend-Datenbank mit den gleichen Diagnostikinformationen wie auf der Diagnostikdatenbank des zentralen Gateways umfasst und der ebenfalls mit dem zentralen Gateway verbunden ist. Ein Datenbankauszug stellt eine Liste zur Verfügung stehenden Diagnostiken bzw. Diagnostikfunktionen bereit. Das mindestens eine Steuergerät weist Mittel zu einer Diagnose und/oder Übermittlung mindestens eines Wertes zu mindestens einem Zustand des Steuergerätes auf, wobei der mindestens eine Zustand mindestens einem Messwert und/oder einem Konfigurationsparameter und/oder einer Programmroutinenanweisung und/oder einer Steuergeräteanweisung und/oder einer Fehlermeldung zugeordnet ist.
-
Dem Backend-Server stehen auf der Backend-Datenbank genauso wie dem zentralen Gateway auf der Diagnostikdatenbank jeweilig die gleichen in gleichem Format abgelegten Diagnostikinformationen zur Verfügung. Es ist denkbar, dass diese Diagnostikinformationen als Daten in einer zentralen Konfigurationsdatei für ein durch Ladepark und Backend-Server gebildetes Gesamtsystem vorliegen. Die abgespeicherten Daten können bspw. ein XML-Format aufweisen. In den Daten der Diagnostikdatenbank ist festgelegt, welche Zustände des mindestens einen Steuergeräts generell im Ladepark abgefragt oder beeinflusst werden können. So ist in der Diagnostikdatenbank z. B. eine „zeitliche Länge eines Aktualisierungsintervalls“, das sogenannte „heart beat interval“, als Konfigurationsparameter abgelegt. Weitere Beispiele sind „Timeout“ (Auszeit bzw. Ausfallzeit), „Location“ (Standort). Weiter ist in den Daten der Diagnostikdatenbank festgelegt, welche Identifikationszahlen jeweilig mit den jeweiligen abfragbaren Zuständen verbunden sind. Als Beispiel ist hier zu einer Fehlermeldung „Steuergerät defekt“ die Identifikationszahl 0x10000 genannt.
-
Es ist denkbar, dass die über das zentrale Gateway mit dem Kern-Netzwerk verbundene Diagnostikdatenbank des Ladeparks alle zu einer Abfrage und/oder Beeinflussung des mindestens einen Steuergeräts, im Falle von mehreren Steuergeräten der jeweiligen Steuergeräte, notwendigen Dateien beherbergt bzw. zur Verfügung stellt. Mit deren Hilfe kann das zentrale Gateway oder der Backend-Server den mindestens einen Zustand des mindestens einen Steuergeräts auslesen und für einen Benutzer in „Klartext“, d. h. für einen Benutzer lesbar, konvertieren bzw. darstellen. Es ist aber auch denkbar, dass die Diagnostikdatenbank nur die lokal zu dem mindestens einen Steuergerät des Ladeparks notwendigen Daten gespeichert hat und diesbezüglich keine Kommunikation mit dem Backend-Server stattfindet.
-
In Ausgestaltung der erfindungsgemäßen Diagnostikanordnung ist das mindestens eine Steuergerät, das mit dem zentralen Gateway und der Diagnostikdatenbank über das Kern-Netzwerk kommunizieren kann und/oder bei dem Diagnostikinformationen lokal gespeichert sind, mindestens einer der Komponenten ausgewählt aus einer Gruppe bestehend aus mindestens einem Kühlmodul, mindestens einem Leistungselektronikmodul, mindestens einer Ladekontrolle, mindestens einer Ladesäule mit einem durch das mindestens eine Kühlmodul gekühlten Ladekabel samt Ladekabelstecker zugeordnet, insbesondere von dieser mindestens einen Komponente umfasst oder darin integriert.
-
In weiterer Ausgestaltung der erfindungsgemäßen Diagnostikanordnung umfasst das mindestens eine Steuergerät mindestens einen Sensor, der dazu ausgelegt ist festzustellen, ob ein messbarer Zustand vorliegt, und daraufhin im positiven Fall diesen messbaren Zustand des mindestens einen Steuergeräts einen Wert zuzuordnen und im negativen Fall eine Fehlermeldung zu generieren. Der mindestens eine Sensor kann bspw. durch einen Temperatursensor gebildet sein, der sich bspw. an einem Ladekabel der Ladesäule befindet. Es ist denkbar, dass die Fehlermeldung Informationen über eine entweder nicht vorhandene Komponente oder über eine nicht funktionierende Komponente oder über eine unterbrochene Kommunikation oder über eine fehlerhafte Kommunikation zum Inhalt hat.
-
In noch weiterer Ausgestaltung der erfindungsgemäßen Diagnostikanordnung weist die Diagnostikanordnung zusätzlich am zentralen Gateway ein Frontend-Modul aufweist. Das Frontend-Modul, dem der Datenbankauszug zugeordnet ist, ist dazu ausgelegt, mit den Komponenten des Ladeparks über das Kern-Netzwerk zu kommunizieren. Das Frontend-Modul stellt bspw. einem Benutzer-Terminal mit Hilfe des Datenbankauszuges mehrere anwählbare Menüpunkte zu den Diagnostiken zur Verfügung.
-
In weiterer Ausgestaltung der erfindungsgemäßen Diagnostikanordnung ist das Kern-Netzwerk ein Ethernet-basiertes Netz, in dem das zentrale Gateway mit weiteren Komponenten über jeweilige Glasfaserleitungen und/oder Kupferleitungen verbunden ist.
-
In noch weiterer Ausgestaltung der erfindungsgemäßen Diagnostikanordnung kann das zentrale Gateway mit dem Backend-Server über eine Funktechnologie, insbesondere Mobilfunk, über DSL, über Ethernet und/oder über WLAN und/oder eine Kombination daraus gekoppelt sein. Dabei kann die Funktechnologie bspw. durch GSM, UMTS oder LTE gebildet sein.
-
In Ausgestaltung der erfindungsgemäßen Diagnostikanordnung ist die Diagnostikanordnung dazu konfiguriert, einen Datenaustausch innerhalb des Kern-Netzwerks ohne Einbindung des Backend-Servers zu realisieren. Hierbei wird auf der Basis der zuletzt übermittelten und im Ladepark bspw. zur Adressierung umgesetzten Werte und Parameter eine Diagnose oder Diagnoseanfrage ermöglicht. Im zentralen Gateway ist hierzu ein HTML-Tester vollständig installiert. Bei Verbindung mit einem Benutzer-Terminal kann der HTML-Tester angezeigt werden, so dass alle Diagnosefunktionen verfügbar und auswählbar sind. Dadurch kann auch ohne Verbindung mit dem Backend-Server eine Diagnose trotzdem ausgeführt werden.
-
Ferner wird ein Verfahren zur Diagnostikkommunikation von Steuergeräten eines Ladeparks unter Nutzung einer voranstehend beschriebenen erfindungsgemäßen Diagnostikanordnung beansprucht, wobei durch das zentrale Gateway entweder jedes Steuergerät einzeln oder eine Gruppe von Steuergeräten oder eine Untergruppe von Steuergeräten adressiert wird. Die Adressierung wird durch Bildung einer globalen Identifikationszahl durchgeführt. Für die Diagnostikkommunikation wird eine Diagnostik-Identifikationszahl gebildet, bei der die Diagnostik-Identifikationszahl einen Zustand des adressierten Steuergeräts, der adressierten Gruppe von Steuergeräten oder der adressierten Untergruppe von Steuergeräten betrifft.
-
Ein jeweiliges Steuergerät des Ladeparks kann mindestens einer der nachfolgenden Komponenten des Ladeparks zugeordnet sein: mindestens einem Kühlmodul, mindestens einem Leistungselektronikmodul, mindestens einer Ladekontrolle, mindestens einer Ladesäule mit einem durch das mindestens eine Kühlmodul gekühlten Ladekabel samt Ladekabelstecker, einer Transformatorstation, welche einen Kontrollserver umfasst. Der Kontrollserver kann wiederum durch ein zentrales Gateway bzw. einen Ladepark-Management-Server, auch als LMS abgekürzt, gebildet werden. In Ausgestaltung kann ein jeweiliges einer jeweiligen der voranstehend genannten Komponenten zugeordnetes Steuergerät in das jeweilige Steuergerät integriert bzw. von dem jeweiligen Steuergerät umfasst sein. In diesem Sinne stellt nicht nur das mindestens eine Steuergerät eine Komponente des Ladeparks, sondern darüber stellen auch die jeweiligen dem mindestens einen Steuergerät zugeordneten Komponenten jeweilige Komponenten des Ladeparks dar.
-
Bei der Adressierung einzelner Steuergeräte als Komponenten des Ladeparks und damit mittelbar auch der den jeweiligen einzelnen Steuergeräten zugeordneten Komponenten des Ladeparks wird durch Bildung einer globalen Identifikationszahl jedem Steuergerät eine eineindeutige Netzwerkadresse zugewiesen. Die globale Identifikationszahl wird aus einer Reihe von auf den Ladepark bezogener Werte gebildet, wobei ein erster Wert auf eine Gruppe von dem jeweiligen Steuergerät zugeordneten Komponenten, ein zweiter Wert auf einen Typ der dem jeweiligen Steuergerät zugeordneten Komponenten, bspw. Leistungselektronikmodul oder Ladekontrolle, ein dritter Wert auf eine Steuergerätenummer des jeweiligen Steuergeräts oder eine Gruppennummer, und ein vierter Wert auf eine jeweilige Verteilergruppe bezogen ist bzw. wird. Diese Aufgabe, d. h. die Bildung und Zuweisung der jeweiligen globalen Identifikationszahl wird durch das zentrale Gateway ausgeführt. Des Weiteren ist jedes Steuergerät im Ladepark mit seiner jeweiligen MAC-Adresse an seine jeweilige IPv6-Adresse gekoppelt. Eine Zuordnung zwischen MAC-Adresse und IPv6-Adresse kann dem Backend-Server vom zentralen Gateway bei einer Initialisierung der Netzwerkanordnung des Ladeparks mitgeteilt werden. Demgegenüber wird die globale Identifikationszahl je nachdem, welche Komponenten bzw. davon umfasste Steuergeräte oder Gruppen von Komponenten bzw. davon umfassten Steuergeräte angesprochen werden sollen, im zentralen Gateway gebildet. Anhand dieser globalen Identifikationszahl ist jedoch eindeutig ein Ansprechen einer dezidierten Komponente bzw. eines dezidierten Steuergeräts bzw. einer dezidierten Gruppe von Komponenten bzw. davon umfassten Steuergeräten über das zentrale Gateway möglich.
-
Während die globale Identifikationszahl der Adressierung einzelner Steuergeräte als Komponenten des Ladeparks und damit mittelbar auch der den jeweiligen einzelnen Steuergeräten zugeordneten Komponenten des Ladeparks dient, bezieht sich die Diagnostik-Identifikationszahl auf einzelne Diagnosefunktionen. Diese Diagnosefunktionen betreffen den mindestens einen Zustand des mindestens einen Steuergerätes, im Falle von mehreren Steuergeräten eines jeweiligen Steuergeräts oder einer Gruppe von Steuergeräten, wobei, wie voranstehend aufgeführt, dem mindestens einen Zustand ein Messwert und/oder ein Konfigurationsparameter und/oder eine Programmroutinenanweisung und/oder einer Steuergeräteanweisung und/oder einer Fehlermeldung zugeordnet ist.
-
Die ein jeweiliges Steuergerät betreffende Diagnosefunktion kann bspw. auf eine Funktion wie „Licht an Ladesäule ein- oder ausschalten“ als ein Stellgliedtest abzielen. Weist das Steuergerät einen Zustand zu einem messbaren Wert auf, bspw. eine Temperatur bezogen auf das Ladekabel an der Ladesäule, so umfasst die diesbezügliche Diagnosefunktion eine Bestimmung dieser Temperatur und Rückübermittlung an das zentrale Gateway zur Weiterverarbeitung, d. h. Umwandlung in Klartext und Darstellung an einem Benutzer-Terminal.
-
Eine Gruppe von Steuergeräten kann bspw. alle Steuergeräte einer Kühlgruppe oder eines Ladepunktes aufweisen. Damit können zum Beispiel Steuergeräte eines Kühlmoduls, zweier Leistungselektronikmodule, zweier Ladekontrollen und zweier Ladesäulen umfasst sein. Bei diesem Beispiel würden dann bspw. die Steuergeräte der beiden Ladekontrollen eine Untergruppe bilden.
-
Durch eine Ausgestaltung einer erfindungsgemäßen Diagnostikanordnung und mittels einer Ausführungsform des erfindungsgemäßen Verfahrens steht jedes Steuergerät oder eine Gruppe davon in kommunikativer Verbindung mit dem zentralen Gateway. Damit ist vorteilhaft eine Diagnose bzw. eine Messwertdiagnose, die von dem zentralen Gateway gesteuert und koordiniert wird, von Gruppen von Steuergeräten, Untergruppen davon oder sogar einzelnen Steuergeräten ermöglicht. Im Stand der Technik ist dies nur für alle Steuergeräte einer mit dem Backend-Server vernetzten Ladestation, welche bislang allein als Ladepunkt adressiert wurde, bekannt, wobei Diagnosedaten zumeist aus einer einzelnen, großen HTML-Datei ausgelesen werden müssen. Ferner ist durch die aufgezeigte Architektur eine Eingrenzung der Diagnose möglich, während bislang seitens des Backend-Servers nur eine pauschale, nicht genau eingrenzbare Diagnose in Gang gesetzt werden konnte.
-
Eine kommunikative Verbindung ist im Rahmen der vorliegenden Offenbarung als eine Verbindung zu verstehen, über welche Signale/Daten gesendet und/oder empfangen werden können. Eine kommunikative Verbindung umfasst dabei mindestens eine physikalische Schnittstelle, eine elektronische Schnittstelle oder eine Daten-Schnittstelle, wobei eine kommunikative Verbindung auch Kombinationen dieser Schnittstellen umfassen kann. Über eine kommunikative Schnittstelle können Signale/Daten zwischen miteinander verbundenen Einheiten, wie hier dem zentralen Gateway und einem jeweiligen Steuergerät, direkt oder mittelbar über ein oder mehrere zwischengeschaltete Einheiten, wie bspw. einen Prozessor o. ä. übermittelt werden. Logische und/oder physikalische Kanäle können bei der kommunikativen Verbindung verwendet werden.
-
In einer Ausführungsform des erfindungsgemäßen Verfahrens wird zur Diagnostikkommunikation eine Datentransfernachricht angelehnt an den Open-Charge-Point-Protocol-Standard oder an den Unified-Diagnostic-Services-Standard gebildet. Der aus dem Stand der Technik bekannte Open-Charge-Point-Protocol-Standard ist ein freies universelles Anwendungsprotokoll, das die Kommunikation zwischen Ladestationen für Elektrofahrzeuge und einem zentralen Verwaltungssystem standardisiert. Als Teil des erfindungsgemäßen Verfahrens wird die Datentransfernachricht aus einer Message-Identifikationszahl, welche die Diagnoseanforderung beinhaltet, aus der Diagnostik-Identifikationszahl und aus der globalen Identifikationszahl gebildet. Näheres wird nachfolgend in Zusammenhang mit 3 beschrieben.
-
In einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens wird die Diagnostikkommunikation mittels den jeweiligen Komponenten, insbesondere den jeweiligen Steuergeräten zugeordneten WebSockets, d. h. webbasierten Programmierschnittstellen, realisiert. Das zentrale Gateway setzt ein erstes WebSocket zur Kommunikation mit dem Backend-Server ein und dann weiter für jede mit dem zentralen Gateway in kommunikativer Verbindung stehende Komponente des Ladeparks ein gesondertes, dieser zugeordnetes WebSocket. Zwar läuft auf jeder Komponente, insbesondere auf jedem Steuergerät, des Ladeparks eine individuelle Logik, aber die Verbindung zum Backend-Server muss zwangsläufig über das zentrale Gateway bzw. das jeweilige dort hinterlegte WebSocket erfolgen. Demnach agiert das zentrale Gateway quasi als Router gegenüber dem Backend-Server für die Kommunikation des Backend-Servers mit den einzelnen Komponenten des Ladeparks. Die im zentralen Gateway hinterlegten WebSockets für die einzelnen Komponenten des Ladeparks stellen quasi eine Simulation bzw. eine virtuelle Darstellung der jeweiligen Komponenten des Ladeparks gegenüber dem Backend-Server dar. Demnach wird hier eine Kommunikation mit dem Backend-Server für verschiedene virtuelle WebSockets realisiert, wobei der Backend-Server nur eine IP-Adresse, nämlich die des zentralen Gateways anspricht.
-
Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
-
Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
- 1 zeigt einen schematischen Überblick eines Ladeparks gemäß einer Ausgestaltung der erfindungsgemäßen Diagnostikanordnung.
- 2 zeigt schematisch eine Diagnostikkommunikation gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens, welches auf einer Ausgestaltung der erfindungsgemäßen Diagnostikanordnung ausgeführt wird.
- 3 zeigt schematisch einen Aufbau einer Datentransfer-OCPP-Nachricht gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens.
- 4 zeigt schematisch ein weiteres Beispiel der Diagnostikkommunikation gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens.
- 5 zeigt schematisch anhand eines Ablaufdiagramms eine Bestimmung einer Service-Identifikationszahl gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens.
- 6 zeigt schematisch anhand eines Ablaufdiagramms eine Typ-Bestimmung einer Komponente des Ladeparks gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens.
-
In 1 wird ein schematischer Überblick eines Ladeparks 100 gemäß einer Ausgestaltung der erfindungsgemäßen Diagnostikanordnung gezeigt. Ein zentrales Gateway befindet sich zusammen mit einer ihm zugeordneten Diagnostikdatenbank in einer Trafostation 106 und kommuniziert von dort über eine Datenverbindung mit einem Backend-Server 102. Die Trafostation 106 ist durch elektrische Leitungen 108 mit einem Versorgungsnetz, bspw. eines Energieversorgers verbunden. Als Baumtopologie beschrieben, werden ausgehend von dem zentralen Gateway in der Trafostation 106, welches einer Wurzel entspricht, Äste 118 zu den Komponenten PowerBox 112, hier beispielhaft dreifach vorhanden, und CoolingBox 110 gebildet. Jeweilig einer PowerBox 112 sind als Blätter jeweilig zwei Ladesäulen 114 mit jeweilig einem Ladekabel zugeordnet. Zusätzlich gibt es Äste von der CoolingBox 110 zu den wärmeerzeugenden PowerBoxen 112 und zu den Ladesäulen 114 mit den zu kühlenden Ladekabeln.
-
In 2 wird schematisch gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens eine Diagnostikkommunikation gezeigt, welche auf einer Ausgestaltung der erfindungsgemäßen Diagnostikanordnung 200 ausgeführt wird. Ein Datenbankauszug 220, welcher eine Teilmenge der Diagnostikdatenbank 290 ist, stellt in einem ersten Schritt 201 eine Liste auswählbarer Menüpunkte mit Diagnoseanfragen einem Frontend-Modul 250 des zentralen Gateways 270 bereit, welches die Liste für einen Benutzer 240 an einem Benutzer-Terminal visualisiert. Das Frontend-Modul 250 wird hier als ein dem Benutzer nahes Verarbeitungsmodul zu einer im Hintergrund ablaufenden komplexen Software (hier einer auf dem zentralen Gateway 270 ablaufenden Ladeparksteuerung) verstanden. In einem zweiten Schritt 202 wählt der Benutzer 240 einen Menüpunkt aus, welcher in einem dritten Schritt 203 von dem Frontend-Modul 250 einem Backend-Modul 260 mitgeteilt wird. Das Backend-Modul 260 wird hier als dem zentralen Gateway 270 bzw. dem Ladepark-Management-Server nahes Verarbeitungsmodul zu der im Hintergrund ablaufenden komplexen Software verstanden. Das Backend-Modul 260 ermittelt nun in einem vierten Schritt 204 gemäß dem Datenbankauszug 220 eine Diagnostik-Identifikationszahl zu der vom Benutzer 240 ausgewählten Diagnoseanfrage. In einem fünften Schritt 205 wird aus der Diagnoseanfrage, der Diagnostik-Identifikationszahl, und einer globalen Identifikationszahl eine Open-Charge-Point-Protocol-Nachricht, kurz OCPP-Nachricht, gebildet und von dem Backend-Modul 260 an das zentrale Gateway 270 übermittelt. Das zentrale Gateway 270 erfragt in einem sechsten Schritt 206 bei einer dem zentralen Gateway 270 zugeordneten Diagnostikdatenbank 290 unter der Diagnostik-Identifikationszahl abgespeicherte Dateien, und stellt daraus in einem siebten Schritt 207 eine Diagnostikanforderung an ein Steuergerät 280 zusammen. In einem achten Schritt 208 meldet das Steuergerät 280 eine Diagnostikantwort an das zentrale Gateway 270 zurück. Von der Diagnostikdatenbank 290 bezieht das zentrale Gateway 270 in einem neunten Schritt 209 Informationen zur Umsetzung der Diagnostikantwort in Klartext und übermittelt diesen in einem zehnten Schritt 210 als Teil einer OCPP-Nachricht an das Backend-Modul 260. In einem elften Schritt 211 übermittelt das Backend-Modul 260 den neuesten Stand zu der ursprünglich ausgewählten Diagnoseanfrage an das Frontend-Modul 250, welche ein Ergebnis am Terminal für den Benutzer 240 anzeigt.
-
In 3 wird schematisch ein Aufbau 400 einer Datentransfer-OCPP-Nachricht 410 gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens gezeigt. Die Datentransfer-OCPP-Nachricht 410 ist aus drei Blöcken 411, 412 und 413, 414 und 415, 416 aufgebaut. Der erste Block 411, 412 enthält eine Bezeichnung „Message-Identifikationszahl“ 411 mit einem Wert 412. Der zweite Block 413, 414 enthält eine „data“-Liste 413 mit mindestens einer angefragten Messung 414. Der dritte Block 415, 416 enthält eine „globale Identifikationszahl“ 415 mit einem Wert 416.
-
Anhand des Beispiels „Temperaturmessung an Steuergerät 0xF01“ wird im Folgenden eine mögliche Datentransfer-OCPP-Nachricht 410 zusammengesetzt: Der Message-Identifikationszahl bzw. Service-Identifikationszahl 411 sei in 420 eine Wert 412 „9“ zugewiesen, der einem Menüpunkt „Einlesen ausgewählter Messungen“ entspricht. Dies soll in Anlehnung an einen Unified-Diagnostic-Services-Standard (UDS) einem Diagnostik-Service 0x22 entsprechen, der vom zentralen Gateway an das jeweilige Steuergerät gesendet werden muss. Im zweiten Block 413, 414 soll in 430 aus einer möglichen „data“-Liste 413 angefragter Messungen 414 die „Temperatur“ ermittelt werden, deren Diagnostik-Identifikationszahl von dem zentralen Gateway bestimmt werden muss und als 0x1001 erhalten wird. Aus den beiden in 420 und 430 erhaltenen Werten wird in 450 eine Diagnoseanfrage vorbereitet, welche sich für das Beispiel aus der Service-Identifikationszahl 0x22 und der Diagnostik-Identifikationszahl 0x1001 zu einer als Diagnoseanfrage zu sendenden Zahl 0x22 10 01 ergibt. Schließlich enthält der dritte Block 415, 416 die globale Identifikationszahl, die bestimmt, an welche Steuergeräte die Diagnoseanfrage geschickt wird. Hierzu wird eine Protokolldateneinheit-Identifikationszahl, kurz auch PDUID, vorbereitet, die die nötigen Informationen aufweist und hier beispielhaft den Wert 0x0aaaaF01 hat, wobei „aaaa“ gemäß des Typs und einer Kennzahl des jeweiligen Steuergerätes bestimmt wird. Damit wird in 460 die Diagnoseanfrage mittels Transmission-Control-Protocol 401, kurz TCP, wie folgt gesendet: PDUID: 0x0aaaaF01, Länge 3, Message 0x22 10 01.
-
4 zeigt schematisch ein weiteres Beispiel 700 der Diagnostikkommunikation gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens. Das zentrale Gateway 720 steht in einer Backend-Kommunikation 723 mit dem Backend-Modul 730 mittels Open-Charge-Point-Protocol, wobei eine einen Messwert beinhaltende Diagnose-Antwort nur als physikalischer Wert, also in Klartext ausgetauscht wird. Dem zentralen Gateway 720 ist eine Diagnostikdatenbank 710 zugeordnet, mit der das zentrale Gateway 720 unmittelbar kommuniziert 721. Schließlich betreibt das zentrale Gateway 720 mit einem jeweiligen Steuergerät 740 eine Diagnostikkommunikation 724 mittels Transfer-Control-Protocol, wobei diese nur kodierte Werte beinhaltet.
-
Als Beispiel sei eine Diagnoseanfrage bezüglich einer Temperatur an einem Steuergerät dargestellt: Zuerst fordert der Backend-Server 730 eine „Temperatur-Messung“ an. In Anlehnung an den UDS-Standard konvertiert das zentrale Gateway 720 die Diagnoseanfrage „Temperatur-Messung“ in eine Message-Identifikationszahl 0x22 (für den Service „Messung an Steuergerät“) und eine Diagnostik-Identifikationszahl, bspw. 0x1001 (für „Temperatur“), woraufhin vom zentralen Gateway 720 „0x22 10 01“ an das Steuergerät 740 übermittelt wird. Das Steuergerät 740 verarbeitet die Anfrage und schickt bspw. die Antwort „0x62 10 00 03 43“. Die entspricht dem kodierten Wert 835 (0x343 =3*256+4*16+3=768+64+3=835). Das zentrale Gateway 720 erhält die Daten (0x343) und konvertiert sie zu einem Klartext-Wert. In diesem Beispiel wäre die Temperatur mit der Formel y=x*0.1-50 zu konvertieren, wobei x ein von dem Steuergerät 740 übermittelter Rohwert ist, und y der Klartext-Wert, der dann vom zentralen Gateway 720 weiter zum Backend-Modul 730 geschickt wird. Demgemäß ergibt sich: y=835*0.1-50=23,5 Grad Celsius. Das zentrale Gateway 720 schickt also „23,5° C“ als String zum Backend-Modul 730, welcher dies, gegebenenfalls über das aus 2 bekannte Frontend-Modul (dort Bezugszeichen 250) für den Benutzer auf einer Anzeigeeinheit visualisiert.
-
In 5 wird schematisch anhand eines Ablaufdiagramms 800 eine Bestimmung einer Service-Identifikationszahl gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens gezeigt. Zu Beginn erfolgt in 810 eine Aufforderung, die Service-Identifikationszahl zu bestimmen. In 820 wird nun in einer Datenbank nach einem Eintrag gesucht, der letztlich in einer globalen Datenbank gefunden werden sollte. Je nach Ausgang der Suche in 820, wird in 801 verzweigt. Konnten keine weiteren Einträge gefunden werden 831, so wird in 830 eine Parameterlänge bestimmt und daraus ein kodierter Wert bezogen. Daraufhin wird in 840 ein Parametertyp aus der Datenbank geholt. In 802 wird verzweigt, je nachdem, ob es sich dabei um einen konstanten Wert 882 handelt, wodurch man den kodierten Wert als Ergebnis der Bestimmung benutzt 880 (und wieder zu 801 gelangt, oder ob der Parameter sich auf einen einfachen oder komplexen Typ referenziert 852 und in 850 der referenzierte Typ des Parameters ermittelt wird). In 803 wird entschieden, ob es sich bei dem ermittelten referenzierten Typ um einen komplexen Typ 873, also um eine Tabelle, eine Struktur oder ein Feld handelt, oder ob es sich um einen einfach Typ 863, also um einen Integer, einen String, eine Texttafel oder eine Byte-Reihe handelt. Für den Fall des komplexen Typs 873 wird in 870 der kodierte Wert benutzt, um einen Untertyp zu bestimmen und dann über 875 erneut in 850 den referenzierten Typ des Parameters zu ermitteln. Dieser Vorgang 804 sollte solange ausgeführt werden, bis alle Unterparameter eines Parameters als einfacher Typ bestimmt sind. Ist dies schließlich der Fall, so wird in 860 der kodierte Wert in physikalische Werte umgesetzt. Damit wird über 861 zum nächsten Parameter gegangen und in 801 je nach Vorhandensein weiterer Parameter verzweigt. Sind keine weiteren Parameter mehr vorhanden 891, so ist die Service-Bestimmung in 890 beendet.
-
In 6 wird schematisch anhand eines Ablaufdiagramms 1100 eine Typ-Bestimmung von einem Diagnose-Parameter für ein Steuergerät des Ladeparks gemäß einer Ausführungsform des erfindungsgemäßen Verfahrens gezeigt. Das Ablaufdiagramm 1100 wird auf dem zentralen Gateway durchlaufen, nachdem der Benutzer eine Menüauswahl getroffen hat und eine Aufgabe an einen durch den Benutzer bzw. die Menüauswahl gewünschten Komponenten- und/oder Funktions-Typ, insbesondere Steuergeräte-Typ formuliert werden soll. Eine Steuergerät-Typ kann dabei bspw. durch die Zuordnung des Steuergeräts zu einer bestimmten übergeordneten Komponente, wie bspw. zu einem Kühlmodul, einem Leistungselektronikmodul oder zu einer Ladekontrolle definiert bzw. gegeben sein.
-
Nach Beginn 1101 erfolgt die Aufforderung 1110, einen Typnamen aus einem Parameter oder komplexen Typ zu erhalten. Es folgt eine Suche des Typs in einer Steuergeräte-spezifischen Datenbank 1120 und je nach Ausgang der Suche wird in 1102 verzweigt. Wird der Typ nicht gefunden 1123, wird in einer globalen Steuergeräte-Datenbank 1130 erneut gesucht. Wird der Typ aber in 1120 gefunden 1124, liegt dieser als kodierter Wert vor. Dann wird in 1140 festgestellt, ob der kodierte Wert interpretiert werden kann, also ob es für den kodierten Wert Interpretationsdetails gibt, d. h. bspw. ob eine Diagnostik-Identifikationszahl gefunden wurde. In 1103 wird zu 1143 verzweigt, wenn es keine Interpretationsdetails gibt und in der globalen Regler-Datenbank 1130 nach dem Typ gesucht werden soll. Je nach Ausgang der Suche des Typs in der globalen Steuergeräte-Datenbank 1130 wird in 1104 verzweigt. Wurde der Typ nicht gefunden 1135, so wird der Typ in einer globalen Diagnostikdatenbank 1150 gesucht. Wurde der Typ in 1130 gefunden 1136 (und liegt als kodierter Wert vor), so wird in 1160 gesucht, ob der kodierte Wert interpretiert werden kann, also ob es für den kodierten Wert Interpretationsdetails (bspw. ob die Diagnostik-Identifikationszahl gefunden wurde) gibt. In 1105 wird zu 1165 verzweigt, wenn es keine Interpretationsdetails gibt und in der globalen Diagnostikdatenbank 1150 nach dem Typ gesucht werden soll. Je nach Ausgang der Suche des Typs in der globalen Diagnostikdatenbank 1150 wird in 1106 verzweigt. Wurde der Typ nicht gefunden 1157, so wird in 1170 gemeldet, dass ein Interpretationsfehler vorliegt. Wurde der Typ aber gefunden 1158, so wir in 1180 gesucht, ob der kodierte Wert interpretiert werden kann, also ob es für den kodierten Wert Interpretationsdetails (bspw. ob die Diagnostik-Identifikationszahl gefunden wurde) gibt. Ist dies nicht der Fall wird in 1107 zu 1187 verzweigt und in 1170 der kodierte Typ (ohne Interpretationsdetails) gemeldet. Konnte allerdings in 1140 oder in 1160 oder in 1180 der kodierte Wert interpretiert werden, so kommt es jeweilig über 1149, 1169 bzw. 1189 zu der Feststellung 1190, dass der Typ und der kodierte Wert des Typs in der jeweiligen Datenbank interpretiert werden konnte. Das Ablaufdiagramm endet in 1108. In dem kleinen Schaubild 1199 wird die Hierarchie der jeweiligen Datenbanken aufgezeigt: die Steuergeräte-spezifische Datenbank 1120 bildet eine Untermenge der globalen Steuergeräte-Datenbank 1130, welche wiederum eine Untermenge der globalen Diagnostikdatenbank 1150 bildet.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- DE 102016209192 A1 [0004]
- DE 102016005630 A1 [0005]
- DE 102014214613 A1 [0006]
