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 is an example configuration for free DC charging
#
active_modules:
  api:
    module: API
    connections:
      evse_manager:
        - module_id: connector
          implementation_id: evse
      error_history:
        - module_id: error_history
          implementation_id: error_history
      evse_energy_sink:
        - module_id: grid_connection_point
          implementation_id: external_limits
  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: CbChargeSOMDriver
  connector:
    module: EvseManager
    mapping:
      module:
        evse: 1
    config_module:
      connector_id: 1
      charge_mode: DC
      evse_id: DE*CHB*E123456*1
      evse_id_din: 49A80737A45678
      session_logging: true
      session_logging_path: /tmp/everest-logs
      session_logging_xml: false
    connections:
      bsp:
        - module_id: bsp
          implementation_id: evse_board_support
      slac:
        - module_id: slac
          implementation_id: main
      powersupply_DC:
        - module_id: powersupply_dc
          implementation_id: main
      powermeter_car_side:
        - module_id: powersupply_dc
          implementation_id: powermeter
      imd:
        - module_id: imd
          implementation_id: main
      hlc:
        - module_id: iso15118_charger
          implementation_id: charger
  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
  iso15118_charger:
    module: EvseV2G
    config_module:
      device: eth1
    connections:
      security:
        - module_id: evse_security
          implementation_id: main
  evse_security:
    module: EvseSecurity
    config_module:
      private_key_password: "123456"
  slac:
    module: EvseSlac
    config_implementation:
      main:
        device: eth1
  auth:
    module: Auth
    config_module:
      connection_timeout: 10
      prioritize_authorization_over_stopping_transaction: true
      selection_algorithm: PlugEvents
    connections:
      token_provider:
        - module_id: token_provider
          implementation_id: main
      token_validator:
        - module_id: token_validator
          implementation_id: main
      evse_manager:
        - module_id: connector
          implementation_id: evse
      kvs:
        - module_id: persistent_store
          implementation_id: main
  persistent_store:
    module: PersistentStore
    config_module:
      sqlite_db_file_path: /var/lib/everest/everest_persistent_store.db
  powersupply_dc:
    module: DCSupplySimulator
  imd:
    module: IMDSimulator
  token_provider:
    module: DummyTokenProvider
    config_implementation:
      main:
        timeout: 10
        token: DEADBEEF
        type: RFID
    connections:
      evse:
        - module_id: connector
          implementation_id: evse
  token_validator:
    module: DummyTokenValidator
    config_implementation:
      main:
        sleep: 0.25
        validation_reason: Token seems valid
        validation_result: Accepted

The use case described in this configuration file includes the following:

  • DC charging mode

  • No TLS (Transport Layer Security) enabled for HLC (High Level Communication)

  • 3-phase, 16 A fuse limit

  • Simulation of the IMD (Insulation Monitoring Device)

  • Simulation of the DC Supply Device

  • Energy management via JSON-RPC API

An overview of the EVerest modules 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.

DCSupplySimulator (view on GitHub)

This module simulates a DC power supply device.

CbChargeSOMDriver (view on GitHub)

This is the Hardware Abstraction Layer (HAL) for the Charge SOM 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 SOM.

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 is maintained as a monorepo in “everest”. This repository contains the different EVerest modules and related components like “libocpp”. It should be noted that Pionix GmbH and the EVerest community maintain the EVerest repository. 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, please check the Troubleshooting section of the documentation first. If you can’t find the answer, please don’t hesitate to contact chargebyte’s support team (Contact).