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”. Additionally, there is a Getting Started with EVerest guide which presents the different EVerest tools, build instructions, and first steps with 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 chargebyte hardware platforms. Detailed instructions on how to integrate EVerest into a chargebyte firmware image can be found on GitHub.

For setting up a use case with EVerest, such as basic setups for AC or DC 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 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
      evse_energy_sink:
        - module_id: grid_connection_point
          implementation_id: external_limits
      error_history:
        - module_id: error_history
          implementation_id: error_history
  rpc_api:
    module: RpcApi
    connections:
      evse_manager:
        - module_id: connector
          implementation_id: evse
      evse_energy_sink:
        - module_id: grid_connection_point
          implementation_id: external_limits
      charger_information:
        - module_id: charger_info
          implementation_id: main
  charger_info:
    module: ChargerInfo
    config_module:
      firmware_version_file: /usr/share/secc/VERSION
    connections:
      kvs:
        - module_id: kvs
          implementation_id: main
  kvs:
    module: YamlStore
    config_module:
      file: /etc/everest/charger_info.yaml
  bsp:
    module: CbTarragonDriver
    config_module:
      contactor_1_feedback_type: none
  tarragon_dig_in_ref:
    module: CbTarragonDIs
  connector:
    module: EvseManager
    mapping:
      module:
        evse: 1
    config_module:
      connector_id: 1
      has_ventilation: false
      disable_authentication: true
    connections:
      bsp:
        - module_id: 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
    mapping:
      module:
        evse: 1
    config_module:
      fuse_limit_A: 16
      phase_count: 3
    connections:
      energy_consumer:
        - module_id: connector
          implementation_id: energy_grid
  error_history:
    module: ErrorHistory
    config_implementation:
      error_history:
        database_path: /tmp/error_history.db

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
Energy management via JSON-RPC API and CB Energy

An overview of the EVerest modules that are defined within a configuration file is shown in the next section.

Overview of EVerest modules¶

As seen from the previous configuration file, some modules are required in order to use EVerest. Which modules are required is highly dependent on the use case you want to release. The following is a list of modules that are part of the chargebyte EVerest charging software:

This list is not complete and focuses mainly on modules that are particularly relevant for chargebyte systems, including chargebyte-specific modules. A complete list of the open source EVerest modules is available in the EVerest module reference.

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.

EvseV2G (view on GitHub)

This module implements DIN 70121 and the ISO 15118-2 charging protocols. For more information about its capabilities and configuration, refer to the module documentation.

Evse15118D20 (view on GitHub)

This module implements ISO 15118-20 charging protocol. For more information about its capabilities and configuration, refer to the module documentation.

IsoMux (view on GitHub)

This module is currently required to support DIN 70121, ISO 15118-2, and ISO 15118-20 at the same time. In the future, the IsoMux module is expected to become unnecessary once all protocols are provided by a single module.

EnergyManager (view on GitHub)

This module is the global Energy Manager for all EVSE/Charging stations in a building.

API (view on GitHub)

This module is not mandatory for a simple EVSE setup in EVerest. However, the module API is responsible for providing a simple MQTT based API to EVerest internals. Please note that this module is deprecated. For new integrations, the RpcApi module and the EVerest interface-specific stable-API modules are recommended.

RpcApi (view on GitHub)

This module is not mandatory for a simple EVSE setup in EVerest, but it is required by the CB Energy Management System Introduction CB Energy service. This module provides a standardized interface for external applications to interact with an EVerest-based charge point. It uses JSON-RPC over WebSocket to allow clients to perform various operations, such as starting or stopping a charging session, retrieving status information, and configuring settings.

ErrorHistory (view on GitHub)

This module is not mandatory for an EVSE setup in EVerest. This module is responsible for storing EVerest error events in a database file. The location of the database file can be defined via a configuration parameter.

ChargerInfo (view on GitHub)

This module provides a charger information interface, backed by simple key-value storage interface. With the optional dependency to another charger information node, it is possible to chain multiple sources of information. The module uses a YAML file to read charger information like manufacturer, model, serial number, firmware version, etc.. This file is located in /etc/everest/charger_info.yaml by default.

YamlStore (view on GitHub)

This module provides a read-only key-value store interface, backed by a simple YAML file. This module is used by the ChargerInfo module to read charger information from a YAML file.

DummyTokenProvider (view on GitHub)

This module is used for automatically providing an authorization token, instead of requiring e.g. an actual RFID reader. It listens to the AuthRequired event from evse_manager module and then publishes one token.

DummyTokenValidator (view on GitHub)

This module always returns the same configured token validation result for every token. The validation result is a configuration key in the manifest of the module.

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.

OCPP (view on GitHub)

This module implements and integrates OCPP 1.6 support within EVerest. For configuration details, please refer to the OCPP 1.6 tutorial.

OCPP201 (view on GitHub)

This module implements and integrates OCPP 2.0.1 support within EVerest. For configuration details, please refer to the OCPP 2.0.1 and 2.1 tutorial.

AuthListValidator

This module validates if an incoming token exists in a predefined list of authorized tokens.

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.

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.

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.

Energy Management: 3 phase / 1 phase switching¶

During AC charging, it is sometimes desired to charge with less than 4.2 kW (= 6 A * 230 V * 3 phases), e.g. for solar charging setups. EVerest comes with built-in support for such setups and can dynamically switch the count of phases provided to the car. It only requires a corresponding hardware setup and support in the used hardware abstractation layer.

The Charge Control C is equipped with two independent onboard relays. This makes this hardware platform ideal for setting up such a phase count switching setup. Also the BSP driver CbTarragonDriver (aka HAL) for this platform gained support for this.

A phase count switching setup always consists of two contactors which are controlled by the charging stack more or less independently. There exist three different kinds of hardware setups which are different in the physical wiring:

serial setup type: In this setup type both contactors are wired in ‘series’: while the primary contactor switches all phases, the secondary contactor only switches the phases 2 and 3. However, it is also required that all phases appear simultaneously on the car side, not one after another. To achieve this, from the software perspective, the secondary contactor is switched on first, but switched off last. In contrast to the primary contactor: this one is switched on last, but switched off first. This ensures - in combination with the physical setup - a homogeneous view of the grid from the car side. Thus the charger appears to be a single-phase only or a three-phase charger.

Fig. 16: Example wiring with two contactors ‘in series’, both with auxiliary contacts for feedback generation. Note, that both contactors must be rated for 400 V in this setup.¶
simultaneous setup type: In this setup type both contactors are wired ‘in parallel’: while the primary contactor switches neutral and one phase, the secondary contactor switches the phases 2 and 3. As mentioned above, it is required that all phases appear simultaneously on the car side, not one after another. To achieve this, from the software perspective, this mode ensures this by using the Linux kernel’s GPIO features. However, it also requires that the underlying GPIOs are located in the same GPIO bank of the CPU. Fortunately, this is the case for the Charge Control C platform.

Fig. 17: Example wiring with two contactors in a ‘simultaneous’ setup, both with auxiliary contacts for feedback generation. Note, that both contactors must be rated for 400 V in this setup.¶

Note

The IEC standard requires a physical/mechanical all-pole disconnect in emergency situations. So using this wiring mode is only permitted when this requirement is satisfied, e.g. with RCD type B or EV.
mutual setup type: In this setup type, two different contactors are used ‘in parallel’. However, it is important that only one contactor can be active at a time, i.e. they exclude each other mutually. This is ensured by the software implementation, but should already be enforced in hardware, e.g. by using the auxiliary contacts as shown in Fig. 18:. This setup allows the use of a single 400 V-rated contactor in combination with a (cheaper) 230 V-rated one.

Fig. 18: Example wiring with two contactors in ‘mutual’ setup. The primary contactor must be rated for 400 V, the secondary contactor can be rated for 230 V only.¶

As mentioned, the CbTarragonDriver module is the relevant hardware abstraction layer for EVerest for the Charge Control C platform. The module must know which wiring type is used in the charger and offers the configuration parameter switch_3ph1ph_wiring for this which can take the following strings:

none (default): No phase-count switching is supported - only R1/S1 is used to switch on/off a single contactor.
serial: Phase-count switching support is enabled using the serial wiring as described above: R1/S1 switches the primary contactor (for N + L1-3), R2/S2 is attached to the secondary contactor (for L2 + L3).
simultaneous: Phase-count switching support is enabled using the simultaneous wiring as described above: R1/S1 switches the primary contactor (for N + L1), R2/S2 is attached to the secondary contactor (for L2 + L3).
mutual: Phase-count switching support is enabled using the mutual wiring as described above. R1/S1 is wired to the three-phase contactor (for N + L1-3), R2/S2 is wired to the single-phase contactor (for N + Lx).

Snippet of an EVerest configuration file which fits the configuration for Fig. 18::

...
bsp:
  module: CbTarragonDriver
  config_module:
    contactor_1_feedback_type: no
    contactor_2_feedback_type: no
    switch_3ph1ph_wiring: mutual
    connector_type: IEC62196Type2Socket
...

Note

Older chargebyte configurations shipped with a CbTarragonDriver module parameter relay_2_name set to value none. This was part of an older approach and should not be used that way. Remove it when it is still present, so that the default value is applied automatically.

However, enabling support for phase-count switching in the BSP module is not sufficient. The EVerest configuration must include a module of type ‘EnergyManager’ which is linked to an ‘EnergyNode’, which in turn must be properly linked to the ‘EvseManager’ module. This ‘EnergyManger’ has also a configuration switch switch_3ph1ph_while_charging_mode which controls the phase-count switching in general:

Never: Do not use 1 phase / 3 phase switching even if supported by the BSP.
Oneway: Only switch from 3 phase to 1 phase if power is not enough, but never switch back to 3 phase for a session.
Both: Switch in both directions, i.e. from 3 phase to 1 phase and back to 3 phase if available power changes.

The EnergyManager module has also additional configuration options to allow fine-tuning of the behavior, but all ship with reasonable default values and thus are not explained in detail here. A description of all these parameters can be found in the EnergyManager manifest.

And also the ‘EvseManager’ module allows fine-tuning the switching process with two configuration parameters:

switch_3ph1ph_delay_s: This takes an integer and defines, how many seconds the charging stack waits between the switching process. In combination with Charge Control C, this value should be at least 11 seconds since the onboard relays are enforced to only switch on every 10 seconds, using this exact value or less generates a warning but does not result in faster switching.
switch_3ph1ph_cp_state: Allows to configure the CP state used during phase count switching. The default value of ‘X1’ should work with all cars and thus it’s recommended to leave it on this default value.

The full description of all these parameters can be found in the EvseManager manifest.

Note

Phase count switching is only possible in basic charging mode.

EVerest Charging Stack¶

Introduction to EVerest¶

Basic Configuration¶

Overview of EVerest modules¶

Energy Management: 3 phase / 1 phase switching¶

Further Reading¶

Table of Contents

Previous topic

Next topic