EnergyBus Implementation Hints

Some implementation hints for EnergyBus in light-electric vehicles such as e-bikes:

All components

    • Differ between Sleep and Deep Sleep. The typical EnergyBus low power mode is called ‘Sleep’ and means, that the devices are powered by the auxiliary voltage and can wakeup on receiving CAN messages.
    • Implement real Sleep/Wake-Up handling. The EnergyBus Controller (EBC) command the network wide Sleep. The typical Display (HMI) power button send (only) a sleep request to the EBC.

EnergyBus Controller

    • Create a system design with the maximum components. The EBC must support this maximal network.
    • Provide non-volatile memory on EnergyBus Controller (EBC) hardware

It is recommended to have some non-volatile memory (EEPROM, EEPROM emulation, …) on the EBC hardware to store identity information of the connection components. This will increase the start-up of the network inside the vehicle significantly.

    • Detect connection of an EnergyBus service tool in the EBC

An EnergyBus service tool according to the CiA 454 specification reports itself by sending heartbeat of the node-ID 125. The EBC should recognize this and should e.g. prevent the Motor Controller (MCU) from powering. The bike shouldn’t move when a service tool is connected or do SDO transfers.

All ‘slave’ components: battery, display, manufacturer-specific devices, …

    • Use dynamic node-Ids as required by the specification CiA 454

The EnergyBus specification CiA 454 requires the use of dynamic node-IDs assigned by the EBC at startup. Using fixed node-IDs might work in the beginning with some other devices, but it will cause compatibility problems in the long term.

    • Support a dynamic instance offset

Using a dynamic instance offset (write-able object 0x6000:xx), the EBC can assign a different global instance number to the device and thus multiple devices of the same type, will be supported. It always only starts with 1 battery or 1 HMI, but mostly there will be more in the future.

Bootloader

According to the EnergyBus specification the usage of a boot-loader to update the firmware in the field is recommended. In addition to that it is recommended to implement some checks in the bootloader that it does not start a wrong application but with valid CRC, that has been flashed by accident.

EnergyBus – The CANopen-based communication standard for LEVs and E-Bikes

Why EnergyBus?

The LEV market is currently characterized by numerous proprietary solutions for the communication between components and with chargers. Vendors of e-bikes cannot use components from different manufacturers due to a missing compatibility. On the contrary many e-bike manufacturers and customers wish to have replaceable components with different feature sets and the possibility to charge the e-bike or pedelec at public charging stations without the need to bring an own charger.
The EnergyBus e.V. association with currently around 70 member companies has dedicated itself to these targets. The objective of the association is to develop and to promote the EnergyBus standard. First successful results have been reached. In the national cycle traffic plan the German government has committed to develop a non-proprietary LEV charging infrastructure by 2020 and the international standardization within ISO and IEC has been started and pilot projects with public EnergyBus charging stations are running.
The EnergyBus connectors
Besides the communication between the components special connectors for EnergyBus devices have been developed by EnergyBus e.V. as well.
Properties of the EnergyBus connector:

    Voltage up to 48V (power line)
    Current up to 50A
    2 pins for power (Powerline)
    2 pins for 12V auxiliary voltage (for passive devices and to wake up deeply-discharged batteries)
    2 pins for CAN communication
    magnetic reverse polarity protection
    unintended pulling out without damage is possible

Continue reading “EnergyBus – The CANopen-based communication standard for LEVs and E-Bikes”