-
-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
12 changed files
with
193 additions
and
0 deletions.
There are no files selected for viewing
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
{ | ||
"label": "Introduction", | ||
"collapsible": true, | ||
"collapsed": true | ||
} |
35 changes: 35 additions & 0 deletions
35
site/docs/protocols/ochp/ochp/introduction/clearing-house.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,35 @@ | ||
--- | ||
sidebar_position: 2 | ||
--- | ||
# Clearing House | ||
|
||
The basic idea of a Clearing House is to enable the connected partners | ||
to roam with each other. The goal of roaming is that EV users can | ||
easily charge their electric vehicle on every charging station of | ||
different EVSE operators. With roaming support, provided by the Clearing | ||
House, the complexity of relationships can be reduced: from many-to-many | ||
bilateral partner connection towards a one-to-many connection between | ||
the Clearing House and the partners. The figure illustrates the overall | ||
system overview of all partners with their systems and the clearing | ||
house system with the EV user as service consumer. | ||
|
||
![Figure Global System Overview](../../media/global-system-overview.png "Global System Overview") | ||
|
||
A different view to the implementation of the described role model gives | ||
figure below. The clearing house provides here a central | ||
connection between the operator layer — where the charging stations are | ||
located — and the provider layer — where the users are. Direct | ||
connections of two roaming partners on the same layer are not necessary. | ||
Each partner operates a single connection to the clearing house from | ||
through which they get connected to multiple partners on the other | ||
layers. | ||
Some of the partners might take two or more roles on different layers. | ||
For each of their roles a connection to the clearing house is necessary | ||
to connect to other roaming partners. The internal data connection | ||
between the distinct roles of one single partner might or might not be | ||
routed through the clearing house. | ||
For the sake of simplification only two layers are shown in this figure. | ||
The same principles apply to the navigation service layer. Also other | ||
additional clearing houses could exist in this model. | ||
|
||
![Figure Layer model of clearing house connections](../../media/ClearingHouseLayerModel.png "Layer model of clearing house connections") |
22 changes: 22 additions & 0 deletions
22
...otocols/ochp/ochp/introduction/functional-principles-of-an-ev-clearing-house.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,22 @@ | ||
--- | ||
sidebar_position: 3 | ||
--- | ||
# Functional principles of an EV Clearing House | ||
|
||
As an intermediate between two independent roaming partners, a clearing | ||
house serves to simplify and unify the data connection. There are few | ||
main principles, the business logic of a clearing house for electric | ||
mobility should follow. Those basic rules are: | ||
|
||
* *Transparency* The existence of a clearing house should be | ||
completely transparent for the EV user. The roaming connection | ||
between an operator and a provider may or may not be routed through | ||
a clearing house. | ||
* *Independence* Roaming connections between two roaming partners and | ||
their business models or tariffs should not be influenced by the | ||
logic of the clearing house. | ||
* *Anonymity* The clearing house should require as little private | ||
user data as possible. | ||
|
||
OCHP supports those basic principles and aims to be capable to any | ||
business model following them. |
39 changes: 39 additions & 0 deletions
39
site/docs/protocols/ochp/ochp/introduction/ochpdirect-extension.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
--- | ||
sidebar_position: 4 | ||
--- | ||
# OCHPdirect Extension | ||
|
||
Starting with Protocol Version 1.3, OCHP offers the possibility to | ||
open a _direct_ communication between two roaming partners. The | ||
following figure illustrates the additional data path. | ||
|
||
![Figure OCHP direct Basic Overview](../../media/OCHPdirectBasicOverview.png "OCHP direct Basic Overview") | ||
|
||
The direct communication between operators and providers allows the | ||
implementation of fundamental new use cases between two roaming | ||
partners. Those use cases are: | ||
|
||
* **Remote Start:** A user starts a charging process at an operator‘s | ||
charge pole by using a provider‘s app. They are starting the process | ||
from a – of the operator's point of view – remote service. | ||
* **Remote Stop:** A user stops a charging process at an operator‘s | ||
charge pole by using a provider‘s app (that was remotely started). | ||
* **Live Info:** A user requests information about a charging process | ||
at an operator’s charge pole by using a provider’s app (from which | ||
the process was started). | ||
* **Charge Event:** A user gets informed by a provider’s app about | ||
status changes of a charging process at an operator’s charge pole, | ||
even if it wasn't started remotely. | ||
* **Remote Control:** A user controls a charging process at an | ||
operator‘s charge pole that was not remotely started by using a | ||
provider‘s app. | ||
* **Remote Action:** A user triggers advanced and not charging process | ||
related actions at a charge point or charging station of an operator. | ||
|
||
## Definition of OCHP direct | ||
|
||
Being an extension to the pure OCHP, the messages and data types used | ||
for OCHPdirect are defined in a [seperate document](/docs/protocols/ochp/ochp_direct/intro). | ||
Within the current document, only the extension to OCHP is described. | ||
The complete description of the functionality and implementation of | ||
_OCHPdirect_ can be found in its seperate documentation. |
92 changes: 92 additions & 0 deletions
92
...docs/protocols/ochp/ochp/introduction/primary-stakeholders-electric-vehicles.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,92 @@ | ||
--- | ||
sidebar_position: 1 | ||
--- | ||
# Primary Stakeholders Electric Vehicles | ||
|
||
The purpose of the Open Clearing House Protocol is to connect market | ||
actors in the field of electric mobility charging infrastructure. The | ||
different relevant market roles are as shown in the market overview | ||
figure: | ||
|
||
* The *EV user* of the overall system - a human charging an electric | ||
car via the connected infrastructure, having a direct or indirect | ||
service contract with an EVSP. | ||
* The *EVSP* (Electric Vehicle Service Provider) - granting access to | ||
charging stations and thus offering services to the contracted EV | ||
user. The service offer is supported by the market roles EVSE | ||
Operator and NSP. | ||
* The *EVSE Operator* (Electric Vehicle Supply Equipment Operator) - | ||
operating charging stations. | ||
* The *NSP* (Navigation Service Provider) - offering relevant | ||
navigation services to the EV user. | ||
* The *PSO* (Parking Spot Operator) - owning and/or operating the parking | ||
spots that allow access to the charging infrastructure owned/operated | ||
by the EVSE Operator. | ||
* The *Clearing House Operator* - running a software platform called | ||
Clearing House to enable data exchange between the market roles (2) | ||
to (4). | ||
|
||
In the context of a clearing house system the market roles (2) to (4) | ||
are referred as *partners*, the role (5) is called | ||
*administrator*. The role (1) is not explicitly known to the system. | ||
The role of a clearing house in terms of this document is to facilitate | ||
the exchange of roaming authorisations, charge point information and | ||
charge detail records between the market participants. Other clearing | ||
houses and local networks might serve the same purpose on a different | ||
scale/region or with different partners. The connection to other | ||
clearing houses is out of scope in the current state. The market roles | ||
are defined in the following section. One company however might fulfil | ||
one or more market roles. The contracts between each actor and the data | ||
routing are part of the clearing house's business logic and out of scope | ||
for this protocol description. | ||
|
||
![Figure EV charging infrastructure market overview](../../media/EV-charging-market-overview.png) | ||
|
||
## Electric Vehicle User (EV User) | ||
|
||
The EV user has a direct or indirect service contract with an EVSP who | ||
grants access to a specified charging infrastructure of one or more EVSE | ||
Operators. The EV users identify their selves via an access token issued | ||
by the EVSP. | ||
|
||
## Electric Vehicle Service Provider (EVSP) | ||
|
||
The EVSP operates as a contract party for the EV user. The EV Service | ||
Provider takes care of the EV user authentication and billing processes. | ||
The EV Service Provider provides the EV-customer authorization tokens | ||
(i.e. RFID-card, Certificates, ... ) that give authorisation to use | ||
the charging stations of contracted EVSE Operators. | ||
|
||
## Electric Vehicle Supply Equipment Operator (EVSE Operator) | ||
|
||
The EVSE operator operates as contract party for the EVSP. The charging | ||
stations (EVSE) of the EVSE operator are accessible by a specified set | ||
of EV users of the contracted EVSPs. The EVSP pays the EVSE operator for | ||
the charging services received by its contracted EV users. | ||
|
||
## Navigation Service Provider (NSP) | ||
|
||
The NSP offers service towards the EV user for searching, locating and | ||
routing to EVSEs of the contracted EVSE operators. It therefore may have | ||
contracts with EVSE operators or EVSPs. | ||
|
||
## Parking Spot Operator (PSO) | ||
|
||
The PSO offers multiple services to the Operator as well as the EV Driver and | ||
NSP. They offer access to a parking spot associated with an EVSE to the | ||
EV driver and sometimes the location for the EVSE to the EVSE-Op. Furthermore, | ||
they may operate services that allow detailed tracking of the occupation | ||
of single parking spots, thus enhancing Operator-data sent to an NSP. | ||
|
||
## Charging Session | ||
|
||
A charging session in the scope of this document is defined from the | ||
successful authorization of the user at the charge point. It is | ||
considered active until the successful authorized stop command was | ||
executed (first figure below) or the car was disconnected from the | ||
charge point manually (second figure below). This is considered a | ||
forced unauthorized ending. | ||
|
||
![Figure Example for an authorized end of a charging session](../../media/ChargingSessionDefinition-1.png) | ||
|
||
![Figure Example for a forced end of a charging session](../../media/ChargingSessionDefinition-2.png) |