Auth

This module implements the authentication handling for the EVerest. It is responsible for providing authorization to the connected evse managers. In addition to that, it handles the reservation management.

Handwritten Documentation

This module handles incoming authorization and reservation requests.

The task of the module is to receive tokens from token providers, validate them and assign them to EvseManagers. It is responsible for providing authorization to EvseManagers and for stopping transactions at the EvseManagers if a token or parent id token is presented to stop a transaction. In addition, the module is responsible for managing all reservations and matching them with incoming tokens.

The module contains the logic to select a connector for incoming tokens (e.g. by waiting for a car plug in, user interface, random selection, etc.). Currently two selection algorithms are implemented and described in Selection Algorithm.

The following flow diagram describes how an incoming token is handled by the module.

Note

The processing of each authorization request and the respective validation runs in an individual thread. This allows the parallel processing of authorization requests.

Integration in EVerest

This module provides implementations for the reservation and the auth interfaces.

It requires connections to module(s) implementing the token_provider, token_validator and evse_manager interfaces.

The following diagram shows how it integrates with other EVerest modules.

The module connections of the evse_manager requirement must be connected in the correct order in the EVerest config file, i.e. the module representing the EVSE with evse id 1 must listed first, EVSE with evse id 2 second and so on.

Selection Algorithm

The selection algorithm contains the logic to select one connector for an incoming token. The algorithm can be specified within the module config using the key selection_algorithm. In case the charging station has only one connector, the selection of a connector is pretty straight-forward because there is only one that is available. The selection algorithm becomes relevant in case the Auth module manages authorization requests for multiple connectors.

Three options for the selection are available:

• PlugEvents

• FindFirst

• UserInput

PlugEvents

The following flow chart describes how a connector is selected using the PlugEvents algorithm.

Note

In case a user authorizes first and no EV is connected to the charger to initiate a SessionStarted event the processing thread waits for a SessionStarted event to select the respective connector. A Plug-In timeout may occur, which will require a subsequent initiation of authorization to start a charging session.

FindFirst

The FindFirst selection method simply selects the first available connector that has no active transaction. This method attempts to select a connector immediately.

UserInput

Not yet implemented.

Plug&Charge Authorization

Please see the Plug&Charge configuration guide for further information about the Plug&Charge integration in EVerest.

Auto-Generated Reference

Module Configuration

selection_algorithm: string <optional>

default: “FindFirst”

The selection algorithm contains the logic to select one connector for an incoming token. In case the charging station has only one connector, the selection of a connector is pretty straight-forward because there is only one that is available. The selection algorithm becomes relevant in case the Auth module manages authorization requests for multiple connectors. The following values can be set: PlugEvents: Selection of connector is based on EV Plug In events FindFirst: Simply selects the first available connector that has no active transaction UserInput: Placeholder, not yet implemented

connection_timeout: integer <required>

Defines how many seconds an authorization is valid before it is discarded. Defines how many seconds a user can provide authorization after the plug in of a car

master_pass_group_id: string <optional>

default: “”

IdTokens that have this id as groupId belong to the Master Pass Group. Meaning they can stop any ongoing transaction, but cannot start transactions. This can, for example, be used by law enforcement personal to stop any ongoing transaction when an EV has to be towed away. If left empty, master_pass_group_id is not used.

prioritize_authorization_over_stopping_transaction: boolean <optional>

default: True

Boolean value to describe the handling of parent id tokens.

If true, a new token will be preferably used for authorization of a new connector if a connector is available. It will not be used to finish a transaction using its parent_id_token. parent_id_token will only be used to finish transaction if no connector is available for authorization anymore.

If false, a new token will be used to finish a transaction if the parent_id_token of a present transaction matches the parent_id_token of the provided_token. Authorization to available connectors will only be provided if no transaction can be stopped using the given parent_id_token

ignore_connector_faults: boolean <optional>

default: False

Boolean value to describe the handling of faults on connectors.

If true, faults reported on connectors are ignored, i.e. they can still be authorized. This should be disabled in most use cases, but e.g. in free charging applications it may be useful to allow a charging session in the following case: A connector e.g. has an overtemperature fault that at some point will clear once it is cooled down. A car is plugged in before the error is cleared. The user would expect that the charging starts once it is cooled down. When this option is set to false, it will not be authorized on plug in as the connector is in fault state and it will never recover until the car is replugged. If it is set to true, the authorization happens on the faulty connector and charging will start once the fault is cleared.

If false, faulty connectors are treated as not available and will not be authorized. This is a good setting for e.g. public chargers.

plug_in_timeout_enabled: boolean <optional>

default: False

This parameter is only used if the charging station has multiple EVSEs managed by this Auth module.

Controls the authorization-timeout behavior after a plug-in event. When enabled, an internal timer is started immediately after an EV is detected as plugged in. During the time defined by connection_timeout, the user must present a valid authorization token.

If no valid token is received within the specified connection_timeout, the authorization attempt is considered as timed out and a re-plug by the user is required to start a new authorization process.

This setting is particularly useful for charging stations with multiple EVSEs and a shared, non-EVSE-specific authorization interface (e.g., a single RFID reader). It prevents authorization tokens from being incorrectly associated with an EVSE where an EV is plugged in but has not been authorized, by ensuring that expired or ambiguous plug-ins are not considered for EVSE assignments for future authorization attempts.

Provides

main: auth

This implements the auth interface for EVerest

reservation: reservation

This implements the reservation interface for EVerest.

Requirements

token_provider: auth_token_provider 1..128

token_validator: auth_token_validator 1..128

evse_manager: evse_manager 1..128

kvs: kvs 0..1

Metadata

Authors

Piet Gömpel

License

https://opensource.org/licenses/Apache-2.0