EVerest charging stack¶
Introduction to EVerest¶
EVerest is an open-source modular framework designed to create a comprehensive software stack for electric vehicle (EV) charging.
The modular software architecture promotes flexibility and customization, allowing users to configure specific charging scenarios using interchangeable modules. This architecture is integrated and coordinated using MQTT (Message Queuing Telemetry Transport). EVerest aims to standardize and simplify the development of EV charging infrastructure, making it easier for developers and companies to implement robust and scalable charging solutions. The project includes support for various protocols like ISO 15118, OCPP, and IEC 61851, ensuring broad compatibility and future-proofing of the charging systems.
For more information, visit the EVerest GitHub repository.
Basic configuration¶
In order to test EVerest, you need to build it either natively on host Linux machine or integrate it into a firmware suitable for a specific target platform using Yocto. To build it natively, follow the instructions found in the main EVerest repository “everest-core”. Additionally, there is a quickstart guide to EVerest, which presents the different EVerest tools, build instructions, and a dive into simulating EVerest.
For Yocto, EVerest offers “meta-everest”; a Yocto meta layer that can be used to integrate the EVerest charging stack into a platform-specific firmware image. chargebyte utilizes this layer to produce firmware images suitable for Charge Control C. Detailed instructions on how to integrate EVerest into a Charge Control C firmware image can be found on GitHub.
For setting up a use case with EVerest, such as basic PWM charging, a YAML configuration file is needed. Various example configurations, including those for software-in-the-loop tests, can be found in the “config” folder of the everest-core repository. Below is an example configuration file provided by chargebyte in its images:
#
# This example configuration can be used as bare minimum starting point:
# no support for plug lock, no additional peripherals (RFID, meter...)
#
active_modules:
api:
module: API
connections:
evse_manager:
- module_id: connector
implementation_id: evse
tarragon_bsp:
module: CbTarragonDriver
config_module:
contactor_1_feedback_type: none
relay_2_name: none
tarragon_dig_in_ref:
module: CbTarragonDIs
connector:
module: EvseManager
config_module:
connector_id: 1
has_ventilation: false
disable_authentication: true
connections:
bsp:
- module_id: tarragon_bsp
implementation_id: evse_board_support
energy_manager:
module: EnergyManager
connections:
energy_trunk:
- module_id: grid_connection_point
implementation_id: energy_grid
grid_connection_point:
module: EnergyNode
config_module:
fuse_limit_A: 16
phase_count: 3
connections:
energy_consumer:
- module_id: connector
implementation_id: energy_grid
The use case described in this configuration file includes the following:
IEC 61851 / AC basic charging
Single connector with a fixed cable
CP state D is rejected
1 contactor for 3 phase
No phase switching
The modules CbTarragonDriver and CbTarragonDIs are part of the Hardware Abstraction Layer (HAL)
used to integrate Charge Control C with EVerest. This will be explained in the next section.
Required modules for Charge Control C¶
As seen from the previous configuration file, some modules are required in order to use EVerest with Charge Control C.
EvseManager (view on GitHub)
The main module in a charging infrastructure EVerest setup. It manages a single EVSE (i.e., one connector for charging a car) and may control multiple connectors under some circumstances. It handles charging logic (basic charging and HLC), gathers all relevant data for the charging session, such as energy delivered during the session, and provides control over the charging port/session. For more information about its capabilities, refer to the module documentation.
EnergyManager (view on GitHub)
This module is the global Energy Manager for all EVSE/Charging stations in a building.
CbTarragonDriver (view on GitHub)
This is the Hardware Abstraction Layer (HAL) for Charge Control C in EVerest. It implements
the evse_board_support
interface, enabling communication with the EvseManager and control of the board. The EVerest community
often refers to these HAL modules as BSPs, such as MicroMegaWattBSP and PhyVersoBSP. This module is
essential for controlling the Charge Control C. The term “Tarragon” in CbTarragonDriver refers to
the Charge Control C hardware platform.
CbTarragonDIs (view on GitHub)
The Charge Control C is equipped with multiple digital inputs (For more information, refer to section Digital Input).
The module CbTarragonDIs is used for setting the reference PWM for these DIs. The reference PWM
sets the threshold voltage for all 12V digital inputs, which is essential for their operation.
The use of this module is optional and depends on the EVSE requirements where the Charge Control C is integrated.
CbSystem (view on GitHub)
This module is an adaptation of the “System”
module in EVerest. It implements the “system”
interface and, like the System module, is responsible for performing system-wide operations but
tailored for chargebyte’s hardware platforms. The use of this module depends on the specific use case,
such as if OCPP is required. In such cases, the CbSystem module is responsible for executing
commands from OCPP e.g. UpdateFirmware.
CbTarragonPlugLock (view on GitHub)
This module is not mandatory for an EVSE setup using Charge Control C in EVerest. However, if EVerest
is configured for an AC supply equipment with a socket connector, the module CbTarragonPlugLock
can be utilized. This module is a driver for plug lock control and implements
connector_lock interface.
It is designed to support all types of plug locks on connector X9 of the Charge Control C. Check
section X9 / X10 - Locking Motor to understand how to connect the locking motor to the Charge Control C.
Further reading¶
For more information on getting started with EVerest, including an overview of the necessary tools and instructions on writing your own modules, please refer to the official EVerest documentation.
EVerest consists of multiple repositories, such as “everest-core” and “libocpp”. Each repository has its own documentation detailing its specific role within EVerest. It should be noted that Pionix GmbH and the EVerest community maintain all repositories that are a part of the EVerest GitHub organization. Only the EVerest modules that chargebyte implemented and that are located in “everest-chargebyte” are maintained by chargebyte.
For interesting discussions and solutions to common problems, visit the EVerest community’s Zulip channels.
For support and issues related to the EVerest modules developed by chargebyte, refer to section X for instructions on how to report problems and insights on contribution.