Some implementation hints for EnergyBus in light-electric vehicles such as e-bikes:
- 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.
- 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.
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.