If you have followed the previous steps in this tutorial you should now have the following things ready for making your connection to the Open Charging Network:

• A backend service that has an OCN-ready API and Signing service

• An OCN Identity

• The OCN Identity of your selected OCN Node, and a registration token (TOKEN_A in OCPI Terms)

Follow the steps listed below to connect to your OCN Node

1. Get the Public URL of your selected OCN Node

2. Get OCN Node versions and endpoints

3. Ensure OCN Node can access our versions and endpoints

4. Credentials handshake

1. Get the Public URL of your selected OCN node from the OCN Registry

There are three methods of interacting with the OCN Registry:

1. CLI

2. Typescript Library

3. Java Library

Using the CLI

If you are using the Command Line Interface provided in the OCN Registry Repository on GitHub, you can check the Public URL of your selected OCN Node by doing this:

ocn-registry get-node 0xEada1b2521115e07578DBD9595B52359E9900104

Where 0xEada1b2521115e07578DBD9595B52359E9900104 is the operator's public address.

Using the Typescript Library

You can find documentation on how to install and use the library here.

The Public URL could look something like this: https://test-node.emobilify.com

Please visit the OCN Registry Repository for further details about this step.

Once connected to the registry, you can use the getNode method to return the operator's public URL:

     /**
     * Get a registry node listing for a given operator.
     * @param operator Ethereum address of the operator.
     * @returns the domain name/url if listing exists.
     */
    public async getNode(operator: string): Promise<string | undefined> {
        this.verifyAddress(operator)
        const node = await this.registry.getNode(operator)
        return node || undefined
    }

source

Using the Java Library

Use the documentation provided here to connect to the OCN Registry using the Java library.

2. Get OCN Node versions and endpoints

We will first send a GET request to the OCN Node’s versions endpoint, using the TOKEN_A we received from the faucet. Note that curl requests can be imported into e.g. Postman or Insomnia if desired.

curl https://test-node.emobilify.com/ocpi/versions -H 'Authorization: Token {{TOKEN_A}}'

You should see a JSON response with OCPI status code 1000. The response data will tell you that version 2.2 can be found at https://test-node.emobilify.com/ocpi/2.2.

Do the same for this endpoint:

curl https://test-node.emobilify.com/ocpi/2.2 -H 'Authorization: Token {{TOKEN_A}}'

You should see a long list of OCPI version 2.2 endpoints implemented by the OCN Node. You will want to save these endpoints for future reference in your application’s database.

For now though, we just need one endpoint. Find the endpoint URL for the module identifier “credentials”. This will be the one we use to connect to the node:

{
  "identifier": "credentials",
  "role": "SENDER",
  "url": "https://test-node.emobilify.com/ocpi/2.2/credentials"
}

3. Ensure OCN Node can access our versions and endpoints

During the credentials handshake, the OCN Node will attempt to request our own versions and endpoints, just as we did before in Step 2.

The OCN Node needs to know where to contact us in case there is a message from another party that needs to be routed to us. It can also help to filter requests, in the case that we have not implemented a specific OCPI module that another party is requesting from us.

If you have not already done so, we can spin up a quick server and execite a node script that will display our versions and endpoints as follows (note: requires NodeJS, Express and UUID):

const express = require("express")
const uuid = require("uuid")

const app = express()

const PUBLIC_URL = "https://service.msp.com"
const TOKEN_B = uuid.v4()
console.log("Auth TOKEN_B = " + TOKEN_B)


const authorize = (req, res, next) => {
	if (req.headers.authorization !== `Token ${TOKEN_B}`) {
		return res.status(401).send({
			status_code: 2001,
			status_message: "Unauthorized",
			timestamp: new Date()
		})
	}
	next()
} 


app.get("/ocpi/versions", authorize, async (_, res) => {
	res.send({
		status_code: 1000,
		data: {
			versions: [{
				version: "2.2",
				url: `${PUBLIC_URL}/ocpi/2.2`
			}]
		},
		timestamp: new Date()
	})
})


app.get("/ocpi/2.2", authorize, async (_, res) => {
	res.send({
		status_code: 1000,
		data: {
			version: "2.2",
			endpoints: [
				/* {
					identifier: "locations",
					role: "RECEIVER",
					url: `${PUBLIC_URL}/ocpi/2.2/receiver/locations`
				} */
			]
		},
		timestamp: new Date()
	})
})


app.listen(3000, () => { console.log("Started on port 3000") })

This will create an authorization token that the OCN Node should use to access our own endpoints. It is logged on start. Be sure to make a note of the authorization token as we will need it later.

Note also the PUBLIC_IP. We want the OCN Node to be able to access these endpoints from the outside, so we should make sure that the server is reachable via the public IP we set.

4. Credentials handshake

Now we are ready to connect to the OCN Node.

The credentials request is detailed below. Make sure to replace the variables TOKEN_A, TOKEN_B and PUBLIC_IP, PARTY_ID and COUNTRY_CODE where described:

• TOKEN_A should match the one generated for you by the faucet

• TOKEN_B should match the authorization token that you have created

• PUBLIC_IP should point to your publicly accessible web service

• PARTY_ID and COUNTRY_CODE refer to the same OCPI credentials that you used when generating the registration token and entering details to the OCN Registry

curl https://test-node.emobilify.com/ocpi/2.2/credentials \
  -H 'Authorization: Token {{TOKEN_A}}' \
  -H 'Content-Type: application/json' \
  -d '{
    "token": "{{TOKEN_B}}",
    "url": "{{PUBLIC_IP}}/ocpi/versions",
    "roles": [{
      "party_id": "{{PARTY_ID}",
      "country_code": "{{COUNTRY_CODE}}",
      "role": "EMSP",
      "business_details": {
        "name": "Tutorial MSP"
      }
    }]
  }'

If the request is successful, you should see a response with OCPI status code 1000 and the OCN Node’s credentials returned in the body.

Now that we have connected to the Open Charging Network we can make use of OCPI to find point of interest data, issue remote commands at charge points and authorize RFID cards of any other OCPI party that is connected to the network.

Overview

The most common use case of the Open Charging Network describes an eMobility Service Provider (eMSP) or Charge Point Operator (CPO) connecting their backend service to an OCN Node. An OCN node provides an entry point into the system, so a party must connect to an OCN node in order to participate in the network.

Follow these steps in order to successfully connect your own backend service.

1. Make your backend service OCN-ready (implement the OCPI 2.2 API and OCN Signature)

2. Select an OCN Node and enter details in OCN Registry

3. Manage your White- and Blacklist

4. Connect your service to an OCN Node

*Note that not only MSPs and CPOs can use the Open Charging Network, but these are the most common roles.

An OCN Service Provider develops and provides OCN services that can be used by CPOs, eMSPs and other parties to improve their charging services - such as contracting, billing, payment systems etc.

The OCN Service is - similar to any other OCPI role - an OCN Party. We make this distinction from other "Services" that might only require customers to send OCPI messages (including custom OCPI modules) directly.

Offer your OCN Service

To offer your OCN Service via the OCN Service Interface, make sure the following prerequisites are met:

Now you are ready to publish your OCN Service on the OCN Registry.

Set Service Permissions

An OCN Service is an OCPI party that requires additional permissions from their customers. Such permissions could include the forwarding of session or charge detail record data, for example in a payment service.

Once a customer/user has agreed to the Service's permissions, the OCN Node tied to the customer will automate any such required permissions, lessening the cost of integration with a service.

To be granted the aforementioned permissions, you must then list your OCN Service and the permissions required in a separate smart contract, entitled "Permissions". Thereafter, a user can make their agreement explicit in the same smart contract. Learn more on how to list your OCN Service on our .

You can find a full list of currently implemented OCN Permissions .

The Open Charging Network allows you to exchange OCPI messages with anybody on the network with just one single OCPI connection, regardless of the OCN Node that you or your counterpart are connected to.

There are some cases in which you want to restrict the list of parties that can communicate with you. For this, the OCN Node provides you with a white- and blacklisting module, called OCN Rules.

Note: This service is an optional feature that needs to be enabled in your own OCN Node or by your OCN Node Operator.

Example: add party to blacklist

• You can find a documentation of how you can use this service on the under OcnRules module.

• See the source code for the OCN node Rules service .

Being part of the Open Charging Network requires participants to set up and manage a self-sovereign identity (OCN Identity).

A 'self-sovereign identity’ is an identity where an individual maintains control over their own credentials, as opposed to having them stored in a centralized server by a third-party. A user's self-sovereign identity could, for example, be partially derived from their cryptocurrency wallet address, which the user maintains control of at all times.

Secure identities are critical for the automated routing of OCPI-messages, and for being able to use applications on top of the Open Charging Network.

Below are details on how to complete the steps necessary to create your OCN identity:

1. (not required for node operators)

1. Select and register your country_code and party_id

* This step is NOT required for OCN Node Operators

Your unique identity on the Open Charging Network is based on an compliant name constructed from a country_code (e.g. “CH”) and party_id (e.g. “SNC”).

Today, in many countries, national registries exist to ensure uniqueness of IDs. Please refer to the OCPI documentation for further information both on the Provider and Operator abbreviation as well as for a list of existing authorities: .

Note that currently not all countries have a national registry. To see a list of countries that currently have a national registry,

2. Create a private/public key pair

A public-private key pair is generated programmatically by a wallet through a cryptographic algorithm. The algorithm produces a private key and a corresponding public key. The public key can be exposed and shared with others (it is used to identify participants in the OCN Registry smart contract), but the private key should not be shared with anyone. The algorithm used to generate the key-pair makes it virtually impossible for any outsider to guess your private key.

3. Register and Manage your OCN Identity with the OCN Registry

As a neutral platform, the Energy Web Foundation holds the administration key to this smart contract. The initial implementation requires a centralized authority to have administration rights (e.g. for updates). As the governance of the OCN Registry is a crucial piece to ensure openness of the Open Charging Network, Energy Web Foundation will further develop this governance together with the community (e.g. enable decentralized administration).

3.1 Gather Required Information

The required information varies according to your role within the network and whether you are running a node or not.

You will need to determine your party's role. The most common roles are "CPO" (Charge Point Operator) and "MSP" (Mobility Service Provider).

3.2 Fund your Ethereum-Compatible Wallet

3.3 Create, read, update and delete your OCN Identity

4. Store your private key safely - and don’t lose it

If you have any issues with your OCN Identity, please reach out to us.

In order for your backend service to be OCN-ready, it must:

1. Implement the OCPI 2.2 API, the shared communication protocol for the OCN

2. Implement the OCN Notary in order to sign and verify OCN messages

1. Implement the OCPI 2.2 API

The OCPI protocol is the common communication protocol for the OCN. Each OCN node implements the OCPI 2.2 API (see, for example, the Kotlin implementation of the OCPI 2.2 API for the OCN node here), and every backend-service that communicates with an OCN node must also implement the OCPI 2.2 API.

Using the OCN Bridge

Using the OCN Bridge is an alternative to implementing the full OCPI 2.2 API in your backend service. The OCN Bridge provides an OCPI interface using pluggable backend APIs. You can instantiate an instance of the Bridge, which will proxy your requests and responses with other OCN parties.

In addition to the OCPI 2.2 implementation, the OCN Bridge also provides services to interact with an OCN node (i.e. register with a node, get connection status to a node) and the OCN Registry.

Examples:

public async getNodeInfo(nodeURL: string): Promise<INodeInfo> {
    const res = await fetch(new URL("/ocn/registry/node-info", nodeURL).href)
    return res.json()
}

You can view documentation on how to to implement the OCN Bridge here.

The OCN Bridge simplifies the implementation of the OCPI interface, but it is not required to use in your backend service. Note that the OCN Bridge can only be implemented in JavaScript environments.

2. Implement the OCN Notary

The OCN Notary is a package that enables the verification of OCN signature, which are used to sign and verify OCN requests using public/private key-pairs.

OCN Signatures

Taking a cue from the blockchain community, we have developed a message signing and verifying system for the Open Charging Network.

Under the hood it uses the Elliptic Curve Digital Signature Algorithm (ECDSA) as implemented by Ethereum. The signature itself holds a JSON Object containing all the necessary data for the recipient to verify the data it is receiving.

Not only do requests need to be signed, but responses too.

Signing Requests

For requests, the signature is appended to the outgoing OCPI 2.2 headers:

Authorization: Token 0ea32164-515f-418b-8bef-39f3817ea090

X-Request-ID: 71d62c5b-5017-493e-be00-3f5ad4e34fff

X-Correlation-ID: 9881b6f7-63aa-40d2-b9c2-d6daa69c11fb

OCPI-From-Country-Code: CH OCPI-From-Party-Id:

MSP OCPI-To-Country-Code: CH OCPI-To-Party-Id:

CPO OCN-Signature: eyJmaWVsZHMiOlsiJFsnaGVhZGVycyddWyd4L (truncated)...

Signing Responses

For responses, the signature is appended to the outgoing OCPI 2.2 JSON response body:

{

"status_code": 1000,

"data": { "result": "ACCEPTED" },

"timestamp": "2020-03-02T12:48:33.005Z",

"ocn_signature": "eyJmaWVsZHMiOlsiJFsnaGVhZGVycyddWyd4L (truncated)..."

}

The idea is that the recipient can use this signature to verify that the message has been signed correctly and has not been modified by an unauthorized party.

What do we mean by unauthorized?

For the OCN to function properly, there are cases where an intermediary (i.e. an OCN node) needs to modify the request/response. Such an example would be the response_url in the JSON body of requests made to the receiver interface of the OCPI commands module. As the recipient does not have access to the response_url defined by the sender, the OCN Node must modify the value. In an OCN signature, this is known as “stashing”. The signature object contains the history of rewrites, with the previous signature being stashed by the party modifying the data. When a recipient then verifies a signature, the rewrites are also verified.

Let’s take a closer look at what the signature actually is:

interface Signature {

val fields: Array val hash: String

val rsv: String

val signatory: String

val rewrites: Array

}

interface Rewrite {

val rewrittenFields: Map<String, Any?>

val hash: String

val rsv: String

val signatory: String

}

The signature itself contains everything needed to verify the most-recent version of the sent data, i.e. by the sender or OCN node depending on whether any values needed to be modified. Provided is a list of jsonpath fields which can be used to recreate the message as signed by the sender, with the original order of values preserved. The values are hashed using keccak-256, as implemented by Ethereum. The resultant hash is actually the message which is signed. The RSV is the signature, produced by ECDSA using an Ethereum wallet’s private key. The signatory refers to the address of the wallet that was used to sign the message.

The list of rewrites contains an object containing the previous hash, rsv and signatory. It also allows the original message to be recreated by storing the fields which have been rewritten. For example, a commands receiver request might have the following rewrite by the OCN node:

1Rewrite( 2 rewrittenFields = mapOf("$['body']['response_url']" to "https://emsp.net/ocpi/2.2/sender/commands/START_SESSION/acfbb8d2-bd49-4837-97e2-d2c38f6bae55"), 3 hash = "0x1ce93f156bc5b3a5c26c5f2499db7bfa2b38c37fd32616fc6487175b86f41eb2", 4 rsv = "0x16e8b9c4e44f4646235fca85a594b5a31057930676d338d111ae985a4f0d9d4214705a0a2ae18c4dfd014581e96eb4625137a937853d4b2d17a0f3a22750f6ac1c", 5 signatory = "0x25e4fca0a0e5107d06d71ed78f687827208d5ff9" 6)

The Signatory

Of course, the signatory of both the OCN Signature and its rewrites should be independently validated. The verification of the signature only tells us that the message was signed by the signatory provided. The signatory itself could be any Ethereum wallet address. The address of both the original sender and their OCN node can be found in the OCN Registry[link to repo].

Now that we know how the signature functions, how do we actually use it? Enter the OCN Notary.

Implementing the OCN Notary

The OCN Notary implements the above Signature and Rewrite interfaces. It can deserialize an incoming OCN Signature and verify its contents. It can be used to sign an OCPI request, and likewise to stash/rewrite values in a request.

Currently the Notary library is available as an NPM package and as a Maven package for languages targeting the JVM. See the OCN Notary repository to find more information for each package.

OCN Network v1.0 Open API 3.0 Specs

You can find the API specification document in the OCN Node repository, here: Open API 3.0 specs

Using this specification, it is possible to generate client code and test implementations. For more information, see https://swagger.io/docs/specification/about/.

Note that this document was generated using unmodified source code in the master branch. As such, certain features of the specification format might be missing, such as examples for HTTP requests and responses.

In order to connect a service to the OCN, you must choose which OCN node you want to connect to, and know the node's public wallet address. You will then request a registration token (Token_A) from your selected node.

1. Select a node

In order to connect a service to the Open Charging Network, you must decide which OCN Node you want to connect to.

Test Network

To view public nodes available on the public test network and their wallet address, see "Develop on the Test Network".

Production Network

To view public nodes available on the public test network and their wallet address, see "Develop on the Production Network".

2. Request a Token

Once you select a node operator that you want to connect to, you must:

1. Know the OCN Identity (wallet address) of that OCN Node Operator (from Step One above).

2. Request a registration token (TOKEN_A in OCPI terms). Note that this token is only temporary and will become invalid once the registration is complete.

3. Enter Node details in OCN Registry

After you have the public address of your public node and your registration token, you are now ready to create / update your OCN Identity on the OCN Registry. Follow the steps provided here: Create and manage an OCN Identity

If an OCN user wants to make use a particular OCN Service, it has to agree on to the Service's permissions. The OCN Node tied to the customer will automate any such required permissions, lessening the cost of integration with a service

To make use of an OCN OCN Service via the OCN Service Interface, make sure the following pre-requisites are met

1. You have an OCN Identity

2. Your backend is connected to the OCN

3. Your preferred OCN Service is connected to the OCN

You are now ready to give the OCN Service its required permissions.

Learn more about how to do that on our OCN Registry repository.

Overview

The OCN Service Interface enables third-party services (such as billing, settlement, location data enrichment) to offer their products to the OCPI community by accessing communication between two OCPI parties on the Open Charging Network without the need for endless API development work.

This is done using OCN Permissions, and requires no additional integration work to be done by the OCPI parties.

It reduces the cost for integration work beyond the EV roaming use-case, helping everyone involved climbing the API mountain of Electric Vehicle charging.

We consider this as crucial to a seamless mass-consumer experience and an efficient EV charging value-chain.

Get Started

As an OCN Service Provider

Learn how to connect your OCN Service to the OCN and to define what OCPI-based information your service needs from OCN Parties / Service Users (OCN Permissions).

As an OCN Party / Service User

Learn how to sign up for an OCN Service by agreeing to OCN Permissions.

Demo

The development of the Open Charging Network is steered by community needs with the non-profit Energy Web Foundation curating the development.

For this purpose, transparency about the current feature set is required, which the following OCN maturity model (inspired by ) shall provide. The maturity model and the roadmap of the Open Charging Network development is discussed quarterly during the Share&Charge Foundation and Tech Call.

The maturity model is based on different categories (columns):

• Messaging: How messages between OCN Parties are transmitted and secured

• Service interfaces: Interfaces that can be used by OCN Parties to connect their services to the OCN

• Connection & Community: Tools for the community to test and use the OCN

Maturity is indicated with different-sized black boxes or a heart:

Planned: Requirements are getting defined

Minimal: First implementations are tested

Viable: Can be used in production

Lovable: Functionality set is complete and used by community

A reference to the open source repositories is provided in parenthesis after the feature description.

Overview

The Open Charging Network (OCN) is a decentralized eRoaming hub.

Using the , the OCN provides the network for communication between , , and other industry players involved in EV charging services.

The primary purpose of the OCN is to make technical connection between these EV charging industry players as simple and secure as possible, without creating technical and commercial lock-in effects.

The two primary actors are eMobility Service Provider (eMSP) and Charge Point Operator.

• eMobility Service Providers (eMSPs) provide EV drivers with network access to electric vehicle charge points, typically through software applications and platforms. Their primary end-user is the EV driver.

• Charge Point Operators (CPOs) install and manage the physical charge point operation infrastructure and the network operations that allow for EV-charging. Their primary end-users are e-MSPs, who in turn make these charge points available to EV drivers through their products and services.

The OCN is made up of a distributed network of server nodes running the . These nodes share a registry that stores network participant data, which exists as a that is deployed on the .

Below you will find an overview of OCN functionality and technical components, as well as how to using the OCN.

OCN Use Cases

• Authorization

• Reservation

• Tariff Information

• Billing Stating Charge Point Information

• Real-time charge point status information

• Real-time charge session information

• Charge Detail Record (CDR) information

• Remote start/stop

• Smart charging

• Calibration law (eichrect) support

• Platform monitoring

Implementing the Open Charge Point Interface Protocol

These actors implement the OCPI on their back-end IT infrastructure.

OCPI Hub Concept

This allows end-users to, for example, locate and use EV chargers that are managed by one CPO, even if they are using an application created by a different CPO or eMSP. It provides a broader network of access to services and charge points that are critical for eRoaming.

The OCPI is broken down into modules that provide the protocol's core functionality, which includes:

1. Bilateral (peer-to-peer) and multilateral communication

2. Real-time information about charge point locations, availability and pricing

3. Exchange of data related to charging services (i.e. Charging Data Records)

4. Mobile access to Charge Points

The OCN as a Decentralized Solution

The OCN performs the role of communication hub as described by the OCPI 2.2, meaning OCN nodes handle the communication and message routing between relevant parties (CPOs, eMSPs, service providers).

The primary difference between the OCN and traditional hub networks is that the OCN is an open and decentralized network:

1. There is no centralized server that participants must connect to in order to use the network. The OCN is comprised of a distributed network of server nodes, and anyone is able to run or connect their service to a node. Nodes are responsible for brokering messages between parties.

OCN Nodes

A node consists of a message broker, blockchain wallet, and connection to an Energy Web Chain node. The network of nodes together constructs the Open Charging Network.

Anyone can run a node if they choose, or connect to a node remotely.

The OCN Registry

A participant is identified in the Registry by their public key, which is mapped to the public url of the OCN node that they are registered with:

Users can interact with the Registry smart contract to fetch, set or update their registered node or their party information.

Benefits of a Decentralized Network

Most implementations of OCPI are centralized applications, where a third-party platform provides the 'hub' network connection between multiple eMSPs and CPOs that enable actors to send and receive information.

This approach brings certain advantages and convenience, but also creates commercial and technical limitations:

• Participant identities are siloed within a network, creating a lock-in effect to that specific network

• Network service providers can choose to not provide particular services on a proprietary platform, creating commercial restraints for the network's users

• Centralized networks are typically less resilient and scalable than decentralized networks

• Participation can be restrictive due to cost or commercial agreements

A decentralized, open source architecture provides a solution for some of these challenges:

• Network participant identities are accessible to anyone on the network through a public, shared registry, reducing network and user silos.

Getting Started

OCN Technical Components

OCN Node

Provides an entry point to the network, which enables communication with other eRoaming parties using the Open Charge Point Interface 2.2.

OCN Bridge

A pluggable OCPI API interface for eRoaming parties with no OCPI API.

OCN Registry

The shared address, identity and permissions system of the OCN.

Utilities to securely verify and sign OCN messages using public/private cryptographic key-pairs.

Currently targeting JavaScript and JVM only.

OCN Tools

Common tools for aiding development of applications built on top of the OCN.

The Public Test Network is the pre-production test network of the Open Charging Network.

It should be used to test services and features in a robust quality assurance environment. To develop on the test network, you can connect to an OCN test node and the OCN Registry that is deployed on the Volta Test Network. See more details on this below:

OCN Registry on Volta Test Network

The Volta Test Network is the pre-production test network (testnet) of the Energy Web Chain. It is the blockchain equivalent of a test server or test environment in traditional software development.

The for the test network can be found on Volta under the following public key: 0xd57595D5FA1F94725C426739C449b15D92758D55.

You can view transactions and the log history for this contract on the Volta Block Explorer . If you're unfamiliar with the Block Explorer, you can read more .

Connect your Service to an OCN Test Node

The Public Test Network of the Open Charging Network provides you with some public test OCN Nodes that you can use for testing the features of the Open Charging Network.

The following test OCN test nodes are currently known to Energy Web Foundation:

Run a Node in a Test Environment

The Public Test Network should give you the option to test your OCN Node operation in a QA environment.

Testing Tools

The Open Charging Network provides mock OCPI parties for exchanging simple OCPI requests over the Public Test Network.

One Mock CPO and one Mock eMSP are available on the Public Test Network (i.e. registered in the Registry contract that is deployed on the Volta Testnet)

Overview

The Open Charging Network is a decentralized implementation of the hub concept. Unlike traditional, centralized hub architecture, the OCN does not rely on a centralized server - the network is made up of a distributed network of server nodes. Anybody can run an OCN node.

Why Run a Node?

There are several benefits to running your own node of the network.

• From an individual perspective, running a node makes you less dependent on external service providers

• From a network perspective, the Open Charging Network becomes more reliable the more nodes that are running

The following steps below help you to successfully set up and run your own OCN Node:

1. Setup and Configuration

Before running a node and connecting it to a local, test or production environment, it is recommended to become acquainted with how the network operates first.

2. Administration of Node and Connected Parties

After you have set up and configured your OCN Node, you can now set up administration and access restrictions, and allow others to access your node using the OCN Node APIs.

Outside of the full OCPI v2.2 API, OCN Nodes provide additional features, such as the custom OCPI module, OcnRules, as well as ways for admins to restrict use and users to query the OCN Registry.

3. Keep your OCN Node up to date

Every OCN Node is a crucial part of the overall Open Charging Network. As soon as you run your own node, you are responsible for keeping it up to date. This helps to keep the Open Charging Network efficient and secure.

The Energy Web Foundation is steering the development of all Open Charging Network Open Source components, and will release regular updates.

Monthly Developer Community Calls are being hosted to align the development of all Open Charging Network software components.

Anyone is invited to jointly discuss current status of development, upcoming releases, development contributions from the community, and other related topics.

Calls will take place every second Tuesday of the month via the video conferencing platform Zoom. The call will be recorded and published on this page.

Join the call via Zoom:

• Join Zoom Meeting https://us02web.zoom.us/j/81939801778?pwd=N3RzSHF2dEVBNXhWVE10OVZIUzcwUT09

• Meeting ID: 819 3980 1778

• Passcode: 009142

Dial by your location

Recordings of previous calls:

13.04.2021 - Watch recording on Youtube

09.03.2021 - Watch recording on Youtube

09.02.2021 - Watch recording on Youtube

12.01.2021 - Watch recording on Youtube

08.12.2020 - Watch recording on Youtube

10.11.2020 - Watch recording on Youtube

13.10.2020 - Watch recording on Youtube

08.09.2020 - Watch recording on Youtube

11.08.2020 - Watch recording on Youtube

The Production Network is the live network of the Open Charging Network. Services and features should only be used in a production network after performing robust quality assurance environment.

OCN Registry on Energy Web Main Network

The Energy Web Main Network (mainnet) is the production network of the Energy Web Chain.

The OCN Registry for the main network can be found under the following public key: 0x184aeD70F2aaB0Cd1FC62261C1170560cBfd0776

You can view transactions and the log history for this contract on the Block Explorer here. If you're unfamiliar with the Block Explorer, you can read more here.

Connect your Service to an OCN Production Node

Follow the steps outlined in the "Connect your Service to an OCN Node" in order to connect your service to one of the nodes listed below.

The following test OCN production network nodes are currently known to Energy Web Foundation:

• eMobilify GmbH with OCN-Identity 0x34F160573b96D3Db5928Ae804D7d99DdD0aF222c Reach out to eMobilify GmbH via info@emobilify.com to get connected.

• eMobility Easy with OCN-Identity 0x79d2D88A1F668296c96150139366ff507eFeD618 Reach out to eMobility East via info@emobility-east.de to get connected.

Follow the steps outlined in the "Connect your Service to an OCN Node" in order to connect your service to one of the nodes listed above.

Run a Node in a Production Environment

For the running of a production node, we advise that a few extra steps are taken. These include configuring HTTPS, enabling message signing, and running against a relational database.

You can see all OCN node configuration settings here.

1. Configure HTTPS

Running the OCN Node in production mode (by default or with the configuration setting ocn.node.dev=false) will require HTTPS. On startup in this mode, the OCN Node will look to see if HTTPS is enabled and properly working. If not, the node will shutdown.

We recommend using an Nginx reverse proxy and Let’s Encrypt certificate, but other solutions are not discouraged.

2. Enable Message Signing

This feature allows recipients to verify the integrity of the data they are receiving. When the configuration setting ocn.node.signatures=true, request senders should include an OCN-Signature header that all entities that the request passes through (i.e. OCN Nodes and the recipient) sign to verify that the data has not been modified without consent. Likewise, for responses, an ”ocn_signature” property should be placed in the JSON response body by the recipient.

Read more about OCN signatures here.

In some cases an OCN Node will need to modify data (typically to make URLs work for recipients). The signature can be modified by an OCN Node, but they must state the properties that they changed, and sign any new data. More information about message signing and verification can be found here.

By default message signing is turned on, but it can also be set with ocn.node.signatures=true if it is not.

3. Configure a Database

The default dev properties configuration file only connects to an in-memory database, for ease of quickly testing the OCN Node. When running a Node on the test or production environment, a database should be set up to persist data across restarts. The example application.prod.properties file provided with the OCN Node provides the configuration necessary to use PostgreSQL.

4. Configure Load Balancing

If necessary, the OCN Node can be load balanced. To do so, the nodes operating under the load balancer should have the same configuration:

ocn.node.url = https://balancer.server.net
ocn.node.privatekey = 0x...45d1
ocn.node.apikey = supersecretkey

The operator should also list the load balancer as the domain name using the same private key in the registry listing:

ocn-registry set-node https://balancer.server.net --signer 0x...45d1

Legal Setup of eRoaming via the OCN

The OCN allows you to have simple, cost-efficient and secure technical connections to other EV charging players like Charge Point Operators and eMobility Service Providers. To run your EV charging service in production, you may need to enter into different legal relationships.

You might want to consider establishing the following agreements when setting up your charging service:

Service Level Agreement (SLA) with Your OCN Node Operator

The OCN Node is responsible for your technical connection to other parties on the OCN. If you are not running your own OCN Node, but using the OCN Node of a third party (OCN Node Operator), you might want to sign a Service Level Agreement (SLA) with the OCN Node Operator. The agreement should make sure the OCN Node is hosted properly and has a high uptime.

eRoaming Agreement with Other Players on the OCN

Engaging with other parties on the Open Charging Network (like charge points or electric vehicles) requires in many cases a formal legal relationship between you and your counter party. An eRoaming Agreement stipulates the terms and conditions for the eRoaming connections between you and your counter party.

The Open Charging Network is a community project by and for the Electric Vehicle Charging community. Its mission is to provide the EV Charging industry players an open, secure and decentralized network for digital interoperability. This is why the core components are developed open source under the Apache license Version 2.0.

The development of the Open Charging Network is driven and steered by the non-profit Energy We Foundation. Many users and community members are contributing to it in the form of feedback, raised issues, pull requests and dedicated working groups. This article should provide you with some guidance on how you can contribute to this project.

Version Management

The production-ready version of every Open Charging Network component can be found in its MASTER BRANCH

Development of each component can be found in its DEVELOP BRANCH. Pull requests should therefore generally derive from the develop branch, which will be eventually merged into the master branch to coincide with the release of a new version.

Bare in mind that new features that are big enough may warrant their own feature branch so that multiple contributors can work on them before being merged into the development branch.

Maturity Model, Feature Roadmap and Releases

• The current state of development is made transparent with a maturity model, which describes the current and planned feature set: Maturity Model, Feature Roadmap and Releases.

• Monthly Developer Community Calls are being hosted to align the development of all software components. Anyone is invited to join. Learn more about it here.

Community support

If you need support in using or contributing to the Open Charging Network, use our Stack Overflow tag.

Reporting bugs and contribute with coding

Issues are raised, described and prioritized in our repositories on GitHub.

You can contribute fixes to bugs or new features by sending pull requests via the GitHub repository. Using the GitHub UI, a pull request can be initiated from a branch in a fork of repository.

Before we can include your contributions to the Open Charging Network code, you need to give us permission. As the author of any creative work (including source code, or documentation), you control the copyright for that work. Energy Web Foundation Foundation can’t legally use your contribution unless you allow us to.

To manage this process, we use a mechanism called a Developer Certificate of Origin (DCO) popularized by The Linux Foundation. The DCO is a legally binding statement that asserts that you are the creator of your contribution, and that you license the work under the Apache License Version 2.0.

Please take the following steps so that we can include your work:

1. Each source file must include the following header:

Copyright 2020 Your Name or Organization>

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

2. Each commit must include your sign-off

Your sign-off certifies that you are either the author of the contribution or have the right to submit it under the Apache 2.0 license used by the Share&Charge project. The sign-off is done by adding the following line to your source code:

Signed-off-by: John Doe <john.doe@example.com>

You must use your real name. Pseudonyms or anonymous contributions are not allowed.

If you set your user.name and user.email as part of your Git configuration, you can sign your commit automatically with git commit -s.

More tips on how to sign-off your work with Git can be found on this website: DITA Open Toolkit

The full text of the DCO is:

Developer's Certificate of Origin 1.1
 
By making a contribution to this project, I certify that:
 
(a) The contribution was created in whole or in part by me and I
     have the right to submit it under the open source license
     indicated in the file; or
 
(b) The contribution is based upon previous work that, to the best
     of my knowledge, is covered under an appropriate open source
     license and I have the right under that license to submit that
     work with modifications, whether created in whole or in part
     by me, under the same open source license (unless I am
     permitted to submit under a different license), as indicated
     in the file; or
 
(c) The contribution was provided directly to me by some other
     person who certified (a), (b) or (c) and I have not modified
     it.
 
(d) I understand and agree that this project and the contribution
     are public and that a record of the contribution (including all
     personal information I submit with it, including my sign-off) is
     maintained indefinitely and may be redistributed consistent with
     this project or the open source license(s) involved.

The EV Dashboard is an application which aggregates OCPI data (via the OCN) and Blockchain data for both EVs and charge points. It also facilitate the request and issuance process for credentials relating to a flexibility market.

The dashboard client is available on Github at https://github.com/energywebfoundation/ev-dashboard-client