Anzeige
Anzeige

Offener Standard für Elektrofahrräder

Genormt treten

Aktuell gibt es auf dem Light-Electric-Vehicle(LEV)-Markt eine Vielzahl proprietärer Lösungen zur Kommunikation der Komponenten untereinander und zur Kommunikation mit einem Ladegerät. Der Markt wird zudem von einigen wenigen Systemherstellern dominiert und die Fahrradhersteller haben wegen fehlender Kompatibilität kaum Möglichkeiten, Komponenten unterschiedlicher Hersteller einzusetzen.
Wunsch vieler Fahrradhersteller ist der nach austauschbaren Komponenten verschiedener Leistungsklassen und Funktionalitäten, insbesondere die Möglichkeit, Elekt-rofahrräder an öffentlichen Ladestationen zu laden. Diesen Zielen hat sich der EnergyBus e.V. verschrieben. Dem im Jahr 2007 gegründeten Verein gehören aktuell 64 Mitgliedsfirmen an. Sie haben sich zum Ziel gesetzt, den EnergyBus-Standard zu entwickeln und zu fördern. Der Verein kann bereits erste Erfolge vermelden: Innerhalb des nationalen Radverkehrsplans verpflichtet sich z.B. die Bundesregierung bis 2020 eine bundesweite, herstellerunabhängige Lade-infrastruktur für Light Electric Vehicles (LEV) zu schaffen. Auch die internationale Standardisierung des Standards als LEV-Kommunikationsstandard ist im Rahmen der ISO und IEC gestartet. Seit Sommer 2012 läuft das erste Pilotprojekt zum Test einer Ladeinfrastruktur von EnergyBus-Pedelecs. Neben der Kommunikation wurde auch ein spezieller Steckverbinder für EnergyBus standardisiert, der sich durch folgende Eigenschaften auszeichnet: – Spannung bis zu 48V – Stromstärke bis zu 40A – 2 Pins für Strom (Powerline) – Pins für 12V Hilfsspannung – 2 Pins für CAN – Magnetischer Schutz vor Verpolung Zu Beginn der Entwicklung wurde aufgrund der Flexibilität und Robustheit das Bussystem CAN als physikalisches Medium für den Standard festgelegt. Um dafür ein Kommunikationsprotokoll zu definieren, wurde 2007 eine Kooperation mit dem Verein CAN in Automation e.V. eingegangen. Das CANopen-Protokoll bietet eine große Anzahl von standardisierten Diensten. Die wichtigsten davon sind die PDOs, Prozess-Datenobjekte zur Echtzeitübertragung von Prozessdaten ohne Protokolloverhead, und die SDOs, Service-Datenobjekte zum wahlfreien Zugriff auf alle definierten Parameter eines CANopen-Gerätes. Zudem ist in den CANopen-Kommunikations- und Applikationsprofilen eine Mindestmenge von Parametern (Objektverzeichnis) definiert, welches jedes Gerät unterstützen muss. CANopen-Applikationsprofile definieren im Gegensatz zu Kommunikations- oder Geräteprofilen eine komplette Anwendung, in der Komponenten ohne Neukonfiguration ausgetauscht werden können. Die Applikationsprofile legen somit viele Geräteeigenschaften fest und reduzieren die Flexibilität von CANopen auf das für die Anwendungen benötigte Maß. Die EnergyBus-Kommunikation ist in dem CANopen-Applikationsprofil CiA 454 beschrieben. Das Profil definiert eine Menge von virtuellen Geräten mit bestimmten Eigenschaften und Parametern. Ein oder mehrere virtuelle Geräte können wiederum in einem physikalischen Gerät zusammengefasst sein. Für Pedelecs sind bisher definiert: – Akku – Ladegerät – Motorsteuerung (MCU) – Display (HMI) – EnergyBus Controller als Netzwerk-Master (EBC) – Security Device Des Weiteren definiert das CAN-open-Applikationsprofil CiA 454 die Parameter im Objektverzeichnis, notwendige Statusmaschinen sowie die per PDO zu sendenden Prozessdaten, deren Intervall und weitere Eigenschaften. EnergyBus-Geräte werden in aktive und passive Geräte eingeteilt. Aktive Geräte wie Akku, Ladegerät oder Motorsteuerung sind mit der Powerline bis zu 48V verbunden, wogegen passive Geräte nur über die 12V-Hilfsspannung versorgt werden.

Zwei Akkus pro Pedelec

Alle EnergyBus-Geräte müssen die nachfolgenden Parameter – bei CANopen-Objekte genannt – umfassen und über EnergyBus auslesbar bereithalten. Dazu gehören unterstützte virtuelle Geräteprofile, Gerätestatus, Gerätefähigkeiten und Nennspannung. Für einen Akku kommen die Parameter (Objekte) für aktive Geräte hinzu; dies sind maximaler Eingangs- und Ausgangsstrom, maximal- und Minimalspannung, erlaubte Peak-Werte für Eingangs- und Ausgangsströme, aktuelle Strom und Spannungswerte sowie Anforderung einer Spannungs-/Strombegrenzung. Zusätzlich gilt es, die Akku-spezifischen Parameter Akku-Typ, aktuelle Kapazität, Nennkapazität und Temperatur anzugeben. Die Spezifikation definiert weitere optionale Parameter für jeden Gerätetyp: für Akkus beispielsweise die Anzahl der Tiefentladungen oder die bisher abgegebene Gesamtkapazität. Der Vorteil der Standardisierung besteht nun darin, dass alle EnergyBus-kompatiblen Akkus die genannten Parameter auf die gleiche Art und Weise bereitstellen und sich entsprechend konfigurieren lassen. In einem EnergyBus-Netzwerk kann es mehrere Akkus geben. Somit ist es beispielsweise denkbar, dass zur Erhöhung der Kapazität gelegentlich ein zweiter Akku am Pedelec angeschlossen ist. Durch die genormte Kommunikation ist die Ansteuerung möglich. Der EnergyBus Controller (EBC) ist der zent-rale CANopen- und Steuerungs-Master im EnergyBus-Netzwerk. Er ist außerdem für die Konfiguration und Überwachung aller EnergyBus-Geräte im Netzwerk zuständig. Zudem führt er für jedes Gerät eine Kompatibilitätsprüfung durch und schaltet die Powerline nur frei, sofern alle aktiven Geräte im Netzwerk ihre Bereitschaft signalisieren. Ein Akku wird dadurch nie mit einer falschen Spannung geladen. Zudem überwacht der EBC zur Laufzeit alle Teilnehmer im Netzwerk und reagiert auf eventuelle Geräteausfälle oder -fehler. Damit auch Akkus außerhalb eines Elektrofahrrads geladen werden können, enthält das Ladegeräte auch einen EBC, der in diesem Fall aktiv wird.

Erweiterungen für isolierte Stromnetze

Isolierte Stromnetze finden sich beispielsweise auf mit Solarenergie versorgten Höfen in abgelegenen Regionen. Unter Federführung des Fraunhofer-Instituts für Solare Energiesysteme ISE wurde mit der Standardisierung der Energieverwaltung in solchen Netzen begonnen und ein Universal Energy Supply Protocol (UESP) entwickelt, das auch als CANopen-Applikationsprofil standardisiert werden sollte. Aufgrund der großen Schnittmenge zwischen LEV-Applikationen und der Energie-Verwaltung in isolierten Stromnetzen wurde entschieden, diese beiden Anwendungsfälle in dem CANopen-Applikationsprofil CiA 454 ‚EnergyBus‘ zu vereinen. Dies führte vielfach zu einer Abstraktion und Generalisierung der Komponenten. Aus Ladegeräten wurden Spannungswandler, die nun alle Arten von Strom- und Spannungsquellen abdecken. Zudem wurden weitere virtuelle Geräte für generische Lasten und Generatoren eingefügt. Damit bieten sich nun Erweiterungs- und Kopplungsmöglichkeiten der beiden Anwendungsfelder. Sowohl solarbetriebene Ladestationen als auch die Verbindung der Pedelec-Batterien mit dem Stromnetz eines Wohnmobils – eines isolierten Stromnetzes – sind angedacht, sodass mittelfristig die Batterien eines Elektrofahrrads vom Wohnmobil aus geladen werden können und das Elektrofahrrad wieder Energie an das Wohnmobil abgeben kann, sodass es zukünftig vielfältige Anwendungen der LEV-Ladeinfrastruktur geben kann.

Empfehlungen der Redaktion

Das könnte Sie auch interessieren

Durch die Digitalisierung steigt der Software-Anteil in Geräten und Maschinen aller Art. Während Sicherheit und Effizienz zu den zentralen Faktoren gehören, die nahezu jede Software-Entwicklung heute erfüllen muss, stellen viele Branchen individuelle Anforderungen an das jeweilige Projekt. Um diese umfassend abzudecken, hat Perforce Software 2019 die US-Firma Rogue Wave Software übernommen. Mit deren Lösung Klocwork hat der Spezialist für Versionskontrolle und Enterprise-DevOps nun zwei Lösungen zur statischen Code-Analyse im Portfolio – neben Klocwork auch seine Lösung Helix QAC. Beide Lösungen sind für unterschiedliche Szenarien optimiert, wodurch sie sich für den Einsatz in verschiedensten Kontexten eignen.
‣ weiterlesen

Anzeige

Das Industrial Internet of Things (IIoT) benötigt eine robuste und zuverlässige Architektur. Denn das sichere Funktionieren aller beteiligten Komponenten ist die Grundlage der darauf aufbauenden Geschäftsmodelle. Ungeplante Ausfälle, potenzielle Angriffsflächen oder kompromittierbare Daten sind dabei nicht akzeptabel. Das IIC hat sich dieses Themas angenommen und eine Referenzarchitektur mit Security-Framework veröffentlicht. Diese fordert nicht zuletzt die Entwickler auf, Sicherheitsaspekte frühzeitig zu berücksichtigen – angefangen bei der Software-Qualität.‣ weiterlesen

Anzeige

Die Welt der eingebetteten Systeme durchläuft eine bedeutende Entwicklung, die sich auf die Rolle des Echtzeitbetriebssystems (RTOS) und den Entwurf von Anwendungen auswirkt, die auf Determinismus, höchste Zuverlässigkeit und Leistung angewiesen sind. Einmal isoliert und zweckmäßig gebaut, fügen eingebettete Systeme schnell neue Funktionen wie mehr Konnektivität, Wiederverwendbarkeit und Flexibilität hinzu. Sie werden zunehmend durch Software definiert. Gleichzeitig haben sich die grundlegenden Anforderungen an ein RTOS nicht geändert.‣ weiterlesen

Anzeige

Autonomes Fahren beschäftigt nicht nur die Automobilhersteller, sondern auch Studenten vieler Fachrichtungen, die sich für eine Karriere in der Automobil-Branche vorbereiten. Im internationalen Konstruktionswettbewerb ‚Formula Student‘ vergleichen sie sich und tauschen ihre Ideen aus. Das Team Ecurie Aix der RWTH Aachen setzt dafür in seinem aktuellen Rennwagen auf ein Mini-ITX Industrie-Motherboard von Kontron. Beim Einsatz wird es vom Kontron-Vertriebspartner Aaronn Electronic unterstützt. ‣ weiterlesen

Anzeige

Model Engineering Solutions startet die diesjährige Webinar-Reihe mit dem Thema ISO in zehn Schritten. Im einstündigen Webinar erfahren Sie, wie Sie einen ISO-konformen Software-Entwicklungsprozess erlangen. ‣ weiterlesen

Anzeige

Der Industrieverband AIM-D und die nanotron Technologies GmbH haben am 7. September 2012 den neuen AIM-Arbeitskreis RTLS für Echtzeit-Lokalisierungssysteme (RTLS) im Deutschen Institut für Normung (DIN) in Berlin gestartet. Die Leitung des Arbeitskreises übernimmt Dr. Jens Albers, CEO von nanotron Technologies. ‣ weiterlesen

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige