Topology

Supported Topologies

OCPI started as a bilateral protocol, for peer-to-peer communication. Soon parties started to use OCPI via Hubs, but OCPI 2.1.1 and earlier were not designed for that. OCPI 2.2 introduced a solution for this: message routing.

OCPI 2.2 introduced Platforms that connect via OCPI instead of CPO and eMSP, more on this in: EV Charging Market Roles

Peer-to-peer

The simplest topology is a bilateral connection: peer-to-peer between two platforms, and in the most simple version each platform only has 1 role.

peer-to-peer topology example
Figure 1. peer-to-peer topology example

Multiple peer-to-peer connections

A more real-world topology where multiple parties connect their platforms and each platform only has 1 role. (Not every party necessarily connects with all the other parties with the other role).

Multiple peer-to-peer topology example
Figure 2. Multiple peer-to-peer topology example

Peer-to-peer multiple the same roles

Some parties provide for example CPO or eMSP services for other companies. So the platform hosts multiple parties with the same role. This topology is a bilateral connection: peer-to-peer between two platforms, and both platforms can have multiple roles.

peer-to-peer with multiple roles topology example
Figure 3. peer-to-peer with multiple roles topology example

Peer-to-peer dual roles

Some parties have dual roles, most of the companies are CPO and eMSP. This topology is a bilateral connection: peer-to-peer between two platforms, and both platforms have the CPO and the eMSP roles.

peer-to-peer with both CPO and eMSP roles topology example
Figure 4. peer-to-peer with both CPO and eMSP roles topology example

Peer-to-peer mixed roles

Some parties have dual roles, or provide them to other parties and then connect to other companies that do the same. This topology is a bilateral connection: peer-to-peer between two platforms, and both platforms have multiple different and also the same roles.

peer-to-peer with mixed roles topology example
Figure 5. peer-to-peer with mixed roles topology example

Multiple peer-to-peer

More a real-world topology when OCPI is used between market parties without a hub, all parties are platforms with multiple roles.

Disadvantage of this: requires a lot of connections between platforms to be setup, tested and maintained.

peer-to-peer with mixed roles topology example
Figure 6. peer-to-peer with mixed roles topology example

Platforms via Hub

This topology has all Platforms only connect via a Hub, all communication goes via the Hub.

Platforms connected via a Hub topology example
Figure 7. Platforms connected via a Hub topology example

Platforms via Hub and direct

Not all Platforms will only communicate via a Hub. There might be different reasons for Platforms to still have peer-to-peer connections. The Hub might not yet support new functionality. The Platforms use a custom module for some new project, which is not supported by the Hub. etc.

Platforms connected via a Hub and directly topology example
Figure 8. Platforms connected via a Hub and directly topology example