Roaming system for charging station networks

Abstract

An apparatus for managing roaming for electric vehicle charging by a source charging station management system is provided. The apparatus may enable roaming between the source charging station management system and one or more target charging station management systems, wherein the roaming is configured to be performed based on an OCPP protocol.

Description

ROAMING SYSTEM FOR CHARGING STATION NETWORKSTECHNICAL FIELD

[0001] Various example embodiments generally relate to the field of electric vehicle charging. Some example embodiments relate to an OCPP-based roaming system.BACKGROUND

[0002] Charging stations may be used to charge electric vehicles (EVs). Charging stations may be connected to a charging station management system (CSMS), for example, using a standard open charge point protocol (OCPP). Companies managing EV user information may be called mobility service providers (MSPs). Commercial charging stations can require authorization, such as through RFID tokens or mobile applications, to invoice users for charging. Roaming services for electric vehicle charging may allow users to charge their electric vehicles outside their provider’s network with one account. As EVs and EV charging is becoming more popular, there is also increasing amount of different CSMS systems and MSP systems in the market. The need to integrate these together through roaming is continuously growing.SUMMARY

[0003] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0004] Example embodiments of the present disclosure enable to implement roaming services between networks for electric vehicle charging using the OCPP protocol. Further, an apparatus performing the OCPP based roaming services is configured with an associated message routing logic, authorization procedures, and custom roaming configurations for different charging stations. This and other benefits may be achieved by the features of the independent claims. Furtherexample embodiments are provided in the dependent claims, the description, and the drawings.

[0005] According to a first aspect, an apparatus is disclosed. The apparatus may be for a source CSMS system. The source CSMS may be for electric vehicle charging roaming management. The electric vehicle charging roaming management may be performed between the source CSMS and one or more target CSMSs, each of which may manage different charging stations. The apparatus may comprise: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: store a list of target charging station management systems, target CSMSs, for roaming in electric vehicle charging, the list of target CSMSs comprising a unique identifier of each target CSMS and OCPP endpoint information of each target CSMS; store a list of available roaming connections for charging stations managed by a source charging station management system, source CSMS, the list comprising a unique identifier of each of the charging stations and an indication if a roaming connection to one or more target CSMSs is configured to be allowed for the respective charging station; detect an incoming open charge point protocol, OCPP, connection from a charging station to the source CSMS; check, from the list of available roaming connections, if a roaming connection is allowed to be opened by the source CSMS to one or more target CSMS for the charging station in response to the detected OCPP connection; open an OCPP connection to the one or more target CSMSs for roaming using the unique identifier of the charging station when the roaming connection is allowed to be opened for the charging station based on the list of roaming connections; detect a message is received by the source CSMS from the charging station; determine, based on one or more forwarding rules associated with a type of the received message, if the message is to be forwarded to at least one of the one or more target CSMS or processed by the source CSMS; and at least one of forward the message to the at least one of the one or more target CSMS via the respective OCPP connection or cause the message to be processed by the source CSMS based on the determination.

[0006] According to an example embodiment of the first aspect, the apparatus is further caused to determine if the response message is related to a request messagecreated by the source CSMS or by the one or more target CSMSs; cause the response message to be processed by the source CSMS based on the one or more forwarding rules when it is determined that the request message was created by the source CSMS; and forward the response message to be processed by at least one of the target CSMSs via the respective OCPP connection for roaming based on the one or more forwarding rules when it is determined that the at least one target CSMS created the request message.

[0007] According to an example embodiment of the first aspect, wherein the received message comprises at least one of a heartbeat message, an authorize request, a boot notification, a diagnostics status notification, a firmware status notification, meter values, a reset request, a message for start of charging transaction, a status notification, or a message for a stop of charging transaction.

[0008] According to an example embodiment of the first aspect, the apparatus is caused to detect that the received message comprises a boot notification; determine, based on the one or more forwarding rules, to forward the boot notification to the one or more target CSMSs; receive a response from the one or more target CSMSs via the respective OCPP connection in response to the forwarded boot notification; and send, to the one or more target CSMSs via the respective OCPP connection, an OCPP message configured for data transfer, wherein the OCPP message comprises additional point-of-interest data not included in the boot notification.

[0009] According to an example embodiment of the first aspect, the additional point-of-interest data is configurable and comprises at least one of the following: a name of the charging station; coordinates of the charging station; an address of the charging station; a location category of the charging station; or opening hours of the charging station.

[0010] According to an example embodiment of the first aspect, the list of target CSMSs further comprises an indication of an authentication method the respective target CSMS is configured to use for connection authentication, and the apparatus is further caused to: perform authorization of the charging station which opened the OCPP connection with the source CSMS based on an authorization methodconfigured for the source CSMS; and when opening the OCPP connection to the one or more target CSMSs for the charging station, perform authentication of the charging station based on the authentication method configured to be used by the respective target CSMS.

[0011] According to an example embodiment of the first aspect, the apparatus is further caused to: detect that the received message comprises an OCPP message for authorization of a user; check, based on information stored at the source CSMS, if authorization of the user is rejected or accepted by the source CSMS; when authorization of the user is rejected by the source CSMS, forward the OCPP message for authorization of the user to the one or more target CSMSs with the opened OCPP connection for the charging station; monitor if any of the one or more target CSMSs responds via the respective OCPP connection with an accepted authorization of the user based on the forwarded message; respond, to the charging station via the OCPP connection opened with the source CSMS, with one of an accepted authorization of the user based on an accepted authorization by one of the source CSMS or the target CSMS, or with a rejected authorization when the authorization of the user is rejected by both the source CSMS and the one or more target CSMSs.

[0012] According to an example embodiment of the first aspect, the apparatus is caused to: detect that the received message is an OCPP message related to a start of a charging transaction at the charging station; determine if a remote start request associated with the charging station was received from a target CSMS before the message, wherein both the remote start request and the received message comprise a same identifier of a user; when it is determined that the remote start request was received before the message from the target CSMS, forward the received message to be processed for authorization by the respective target CSMS based on the one or more forwarding rules; when it is determined that the remote start request was not received from any of the one or more target CSMSs, proceed to process the message for authorization by the source CSMS.

[0013] According to an example embodiment of the first aspect, the apparatus is caused to: detect that the received message is an OCPP message related to a stop of the charging transaction; check if the charging transaction was authorized by thesource CSMS or by one of the one or more target CSMSs; based on the determination, one of process the received message by the source CSMS or forward the received message to be processed by the one of the one or more target CSMSs; detect when a response created by the respective target CSMS is received via the OCPP connection in response to the forwarded message; send, to the charging station via the OCPP connection opened with the source CSMS, a response confirming that the stop of the charging transaction has being processed based on a response created by one of the source CSMS or the target CSMS.

[0014] According to an example embodiment of the first aspect, the apparatus is caused to: update a charge detail record of the charging transaction with information about which target CSMS authorized the start of the respective charging transaction; combine information about charging transactions for each of the one or more target CSMSs based on charge detail records linked with a respective target CSMS; and transmit the combined information linked with the respective target CSMS to each of the one or more target CSMSs.

[0015] According to an example embodiment of the first aspect, the apparatus is caused to: detect that the received message is an OCPP message related to a diagnostics status of the charging station; determine if the diagnostics status of the charging station was requested by the source CSMS or one of the target CSMSs; based on the determination, one of process the received message by the source CSMS or forward the received message to be processed by the one or more target CSMS based on the one or more forwarding rules; detect when a response created by the one or more target CSMSs is received via the respective OCPP connection in response to the forwarded message; and send, to the charging station via the OCPP connection opened with the source CSMS, a response created by one of the source CSMS or the one or more target CSMSs based on the processed message.

[0016] According to an example embodiment of the first aspect, caused to: detect that the received message is an OCPP message related to a firmware update; determine if the firmware update was requested by the source CSMS or the one or more target CSMSs; based on the determination, one of process the received message by the source CSMS or forward the received message to be processed by the one or more target CSMS according to the one or more forwarding rules; detectwhen a response created by the one or more target CSMSs is received via the respective OCPP connection in response to the forwarded message; and send, to the charging station via the OCPP connection opened with the source CSMS, a response based on the processed message by one of the source CSMS or the one or more target CSMS.

[0017] According to an example embodiment of the first aspect, the apparatus comprises the source CSMS.

[0018] According to a second aspect, a method carried out by a computing device is disclosed. The method may comprise: storing a list of target charging station management systems, target CSMSs, for roaming in electric vehicle charging, the list of target CSMSs comprising a unique identifier of each target CSMS and OCPP endpoint information of each target CSMS; storing a list of available roaming connections for charging stations managed by a source charging station management system, source CSMS, the list comprising a unique identifier of each of the charging stations and an indication if a roaming connection to one or more target CSMSs is configured to be allowed for the respective charging station; detecting an incoming open charge point protocol, OCPP, connection from a charging station to the source CSMS; check, from the list of available roaming connections, if a roaming connection is allowed to be opened by the source CSMS to one or more target CSMS for the charging station in response to the detected OCPP connection; opening an OCPP connection to the one or more target CSMSs for roaming using the unique identifier of the charging station when the roaming connection is allowed to be opened for the charging station based on the list of roaming connections; detecting a message is received by the source CSMS from the charging station; determine, based on one or more forwarding rules associated with a type of the received message, if the message is to be forwarded to at least one of the one or more target CSMS or processed by the source CSMS; and at least one of forwarding the message to the at least one of the one or more target CSMS via the respective OCPP connection or causing the message to be processed by the source CSMS based on the determination.

[0019] According to a third aspect, a computer program, a computer program product, or a (non-transitory) computer-readable medium is disclosed. Thecomputer program, computer program product, or (non-transitory) computer- readable medium may comprise instructions, which when executed by an apparatus, cause the apparatus at least to perform the method according to the second, fourth, sixth, eighth, tenth, twelfth, or fourteenth aspect, or any example embodiment(s) thereof, as provided in the description and / or the claims.

[0020] Example embodiments of the present disclosure can thus provide apparatuses, methods, computer programs, computer program products, or computer readable media for improving various aspects of roaming between charging networks. Any example embodiment may be combined with one or more other example embodiments. These and other aspects of the present disclosure will be apparent from the example embodiment(s) described below. According to some aspects, there is provided the subject matter of the independent claims. Some further aspects are defined in the dependent claims.DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings, which are included to provide a further understanding of the example embodiments and constitute a part of this specification, illustrate example embodiments and, together with the description, help to explain the example embodiments. In the drawings:

[0022] FIG. 1 illustrates an example of a roaming architecture with two charging networks;

[0023] FIG. 2 illustrates an example configuration for charging station data communication between charging networks;

[0024] FIG. 3 illustrates an example configuration for an authorization process between charging networks;

[0025] FIG. 4 illustrates an example configuration for charging control between charging networks in case of remote start;

[0026] FIG. 5 illustrate an example of configuration for CDR data communication between charging networks;

[0027] FIG. 6 illustrates an example configuration for CDR data related communication between charging networks;

[0028] FIG. 7 illustrates an example of a WebSocket duplication procedure;

[0029] FIG. 8 illustrates an example configuration for performing connection authentication;

[0030] FIG. 9 illustrates an example of message exchange between charging networks in a OCPP based roaming network;

[0031] FIG. 10 illustrates an example of a forwarding rule for an authorization message;

[0032] FIG. 11 illustrates an example of a forwarding rule for a message with updated data;

[0033] FIG. 12 illustrates an example of a forwarding rule for charging transaction start related message;

[0034] FIG. 13 illustrate example of a procedure for forwarding request messages in an EV roaming network;

[0035] FIG. 14 illustrates an example of a process of forwarding responses to messages;

[0036] FIG. 15 illustrates an example of charging station data transfer in a roaming network for electric vehicle charging;

[0037] FIG. 16 illustrates an example of a data model for one or more roaming processes;

[0038] FIG. 17 illustrates an example of a process to create invoices in a roaming network;

[0039] FIG. 18 illustrates an example of an apparatus configured to practice one or more example embodiments; and

[0040] FIG. 19 illustrates an example of a method for OCPP based roaming.

[0041] Like references are used to designate like parts in the accompanying drawings.DETAILED DESCRIPTION

[0042] Reference will now be made in detail to example embodiments, examples of which are illustrated in the accompanying drawings. The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description setsforth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

[0043] Charging stations may be used to charge electric vehicles (EV). Charging stations may be connected to a charging station management system (CSMS) using a standard open charge point protocol (OCPP). A company that manages stations with a CSMS may be called a charging point owner (CPO) or charging station owner (CSO). People who use and charge EVs are called EV users, or simply users. Companies managing EV user information may be called mobility service providers (MSPs), and an IT (information technology) system that may be used to manage this user information can be called an MSP system. Some charging stations may be configured to perform authorization of users before the user is allowed to use the charging station. The authorization may be used, for example, to invoice users for charging. Authorization may be performed, for example, using radio frequency identification (RFID) tokens and / or mobile applications.

[0044] Authorization information can be handled by an IT system. An IT system may comprise, for example, a computing device storing information related for user authorization and instructions for performing authorization operations based on said information. In one example, such IT system may be a CSMS. Authorization information may be handled in different ways. In one example, the CSMS itself can also act as an MSP system, and the CSMS has authorization information (such as a list of RFID tokens) in the system. In another example, CSMS systems can be connected to other external MSP systems. The external MSP system may manage authorization information outside the CSMS. When CSMS system and MSP system are two different IT systems, information exchange can be referred to as “roaming” between the systems. Roaming in electric vehicle charging, or EV roaming, may allow users to charge their electric vehicles outside their provider’s (e.g., MPS) charging network with one account. From user perspective, EV roaming allows the user to charge at any charging station open for roaming by using a single method of authentication or payment. Similar how mobile phone users can make calls or access the internet while roaming on different networks, EV roaming enables users to charge their electric vehicles at different charging networks using a single RFIDcard or mobile application. EV roaming may be also referred to as eRoaming, roaming in electric mobility, or roaming for electric vehicle charging.

[0045] Different roaming systems and technical roaming protocols may be used in EV roaming. One example is open intercharge protocol (OICP). In OICP, different CSMS systems and MSP systems may be connected to a central hub, which then may facilitate the communication between the CSMS and MSP systems. Another example is open charge point interface (OCPI). OCPI is a roaming protocol that may be used in peer-to-peer connections between CSMS systems and MSP systems, which may enable communication without a separate roaming hub between the systems.

[0046] OCPP is a protocol where a charging station and a CSMS can send JSON formatted data to each other through a WebSocket connection. WebSocket is a communication protocol that may provide a simultaneous two-way communication channel over a single transmission control protocol (TCP) connection. The CSMS may act as a WebSocket server, and the charging station as a WebSocket client. A WebSocket server may be also referred to as an OCPP server. A WebSocket client may be also referred to as an OCPP client. The client (e.g., charging station) may open a new WebSocket connection to the server (e.g., CSMS). After the connection is open, both parties may send messages to each other. OCPP may define the format and contents of these messages.

[0047] One example of how authorization with OCPP may work is as follows. A user may want to start charging and the user identifies at the charging station using, for example, an RFID token. The user presents the RFID token to a RFID reader of the charging station. The RFID token may be also referred to as an RFID tag, or an ID token in OCPP. The ID token may consist of numbers and / or letters (e.g., idToken=AlB2C3D4). The charging station sends an OCPP command for authorization comprising the RFID token to the CSMS. The CSMS may store information about the user such as a username and an identifier of the user in a database (e.g., User=Alice, idToken=AlB2C3D4). The CSMS may check if the RFID token is found from the database of the CSMS system, and responds “Accepted” or “Rejected” back to the charging station. If the CSMS responded “Accepted”, charging can start at the charging station.

[0048] When EV roaming is used, the ID token authorization may be done from an external MSP system. For example, a user may present an RFID token to the charging station. The charging station may send an OCPP command for authorization with the RFID token to the CSMS. The CSMS may send a request to one or more MSP systems to authorize the RFID token (e.g., idToken=AlB2C3D4), using some roaming protocol (for example OCPI or OICP). For example, a first MSP system may store user information of Alice, linked to idToken=AlB2C3D4, and Bob, linked to idToken=AABBCCDD. A second MSP system may store user information of Cecil, linked to idToken=DlA2D4H2. The MSP responds ’’Accepted” or ’’Rejected” back to the CSMS. If one of the MPS systems responded ’’Accepted”, then the CSMS also gives ’’Accepted” response back to the charging station. If the charging station received ’’Accepted” response, charging can start at the charging station. In this example, the first MSP system would respond “Accepted” because the received RFID token can be found from the user information stored at the first MSP system.

[0049] Some roaming protocols may assume that CSMS and MSP systems are different and separate IT systems with separate roles. However, roaming may be also done between systems that both have a CSMS module and an MSP module. Moreover, as EVs and EV charging is becoming more popular, the amount of different CSMS systems and MSP systems is increasing. When combining many different CSMS and MSP systems, and many different roaming protocols and protocol versions, there may be hundreds of different combinations that CSMS and MPS systems should support so that roaming with the specific roaming protocols would work. Even if two systems may be using the same roaming protocol and roaming protocol version, there can be some small differences in the roaming protocol implementation, which requires technical development work when new roaming connections are created. For these reasons, implementing roaming with current roaming protocol technologies may be slow and expensive.

[0050] An objective of this disclosure is to enable roaming between two systems of a charging network without using roaming hubs or roaming protocols, such as OCPI or OICP.

[0051] Creating and maintaining many different roaming connections and different technical protocols between CPOs and MPSs may be time consuming and expensive for companies developing CSMS and MSP systems. As more companies enter the market, the problem with roaming is growing due to increasing complexity of different protocols, protocol versions, and protocol implementations. At the same time, many companies may be implementing an OCPP protocol, which has less variety than roaming protocols. Charging stations may be connected to a CSMS system with OCPP. Platforms may have both a CSMS module and an MSP module in the same system, so there may be readily implemented support for OCPP.

[0052] FIG. 1 illustrates an example of charging networks 100 forming an OCPP based roaming architecture. The charging networks 100 may comprise a plurality of charging stations 118. The charging stations 118 are used by users 120. The charging networks 100 may further comprise at least one target system 102 and a source system 104. A target system may be also referred to as a target CSMS. A source system may be also referred to as a source CSMS. Each charging network may thus comprise a CSMS system (e.g., a source CSMS or a target CSMS) configured to manage charging stations connected to it. A source CSMS and a target CSMS are different CSMS systems storing at least partly different information from each other. For example, the different CSMS systems may be configured to manage operations of different charging stations and / or store information of different users. A source CSMS may be also referred to as a first CSMS and a target CSMS as a second CSMS. A CSMS system may comprise communication means and a computing device, such as a server device. A user may have an account for charging at charging stations connected to the target system 102 or the source system 104. Some of the users 120 may have an account only in the target system 102, but want to use charging stations 118 connected to the source system 104.

[0053] When a user has an account in a target system or a source system, the respective system stores user information associated with the user including an identifier of the user used for authorization. The user information may be stored at an MSP module of the respective system. The target system 102 may comprise an MSP module 116 storing accounts of users 120 registered at the target system 102. The source system 104 may comprise an MSP module 112 storing accounts of users120 registered at the source system 104. The target system 102 may further comprise a CSMS module 114 configured to manage charging stations 118 linked with the target system 102. The source system 104 may comprise a CSMS module 110 configured to manage charging stations 118 linked with the source system 104. For example, a CSMS module may store charging station information of the linked charging stations and be able to communicate with the charging stations, for example, via an established WebSocket connection.

[0054] Both the source system 104 and the target system 102 may act as OCPP servers towards the charging stations 118. The charging stations 118 may be configured to act as OCPP clients. The source system 104 may be configured with a feature that enables the source system 104 to act also as an OCPP client 108. Thus, the source system 104 may “pretend” to be a charging station, towards the target system 102. The target system 102 may not need to be configured with any new features to operate with the source system 104. The users who have an account at the source system 104 can continue using the charging stations of the source system 104. Users who have an account in the target system 102 can use charging stations both at the target system 102 and the source system 104. Hence, there is a working roaming connection between the target system 102 and the source system 104.

[0055] The technology used for roaming may be configured to fulfil one or more requirements. On a high level the requirements can be divided to the following categories:

[0056] A first category comprises charging station data: Target system 102 may need information which charging stations 118 of the source system 104 are available to it (e.g., connected to the target system 102 via the source system 104), and are thus available for charging to users of the target system 102. FIG. 2 illustrates an example configuration for charging station data communication between charging networks. For example, the source system 104 may be configured to inform at 200 the target system 102 about static and / or dynamic charging station data related to charging stations 118 connected with the source system 104 and having a roaming connection with the target system 102 via the source system 104. Here, the roaming connection may refer to an OCPP connection (e.g., WebSocket connection) established by the source system 104 to the target system 102 based onan identifier of a charging station connected to the source system 104. The static and dynamic charging station data may be referred to as station data.

[0057] The dynamic charging station data may comprise real-time operative status of the charging stations, such as which charging stations are available, which charging stations are in use (e.g., actively charging), which charging stations are faulted etc. The dynamic charging station data may comprise, for example, dynamic POI (point-of-interest) data.

[0058] Optionally, the target system 102 may also receive the static charging station data from the source system 104, such as static POI data (e.g., address, geocoordinates, accessibility, etc.) of the charging stations 118.

[0059] A second category comprises authorization and charging control: The source system 104 may need to authorize locally started transactions (such as RFID authorization) from the target system 102. Further, the target system 102 may need to be able to do remote start and stop (for example, when mobile applications are used) to charging stations of the source system 104.

[0060] FIG. 3 illustrates an example configuration for an authorization process between charging networks. When a user 120 authenticates himself / herself at a charging station 118, for example, by using RFID tag 300 or different ’’plug and charge” -technologies, the charging station 118 may send at 302 an OCPP authorize request to the source system 104. The authorize request may include the so called ”ID token” which is used to identify a user. However, the ID token is one example, and any user identifier according to current or future OCPP standards may be used.

[0061] After receiving the OCPP authorize request from the charging station 118, the source system 104 may first try to authorize charging based on user information stored at the source system 104. For example, the source system 104 may comprise an ID token storage including account information of users of the source system 104. This may be done by checking if the ID token belongs to any user account of the source system 104.

[0062] If the ID token was not found from the source system 104, the source system 104 may be configured to try authorizing the same ID token from the target system 102. At 304, the source system 104 transmits the ID token to the target system 102 through roaming authorization, e.g., via the roaming connection. Afterreceiving the ID token from the source system 104, the target system 102 may check from user information stored at the target system 102 if the ID token belongs to any user of the target system 102. For example, the target system 102 may comprise an ID token storage including account information of users of the target system 102.

[0063] FIG. 4 illustrates an example configuration for charging control between charging networks in case of remote start. When a user 120, who has an account in the target system 102, wants to start or stop charging at a charging station 118 of the source system 104 from a mobile application 404, the mobile application 404 can send a (remote) start / stop request first to the target system 102, at 406.

[0064] The target system 102 may be configured to forward the start / stop request to the source system 104, at 402. Thereafter, the source system 104 can send the start / stop request to the correct charging station 118, at 400. The charging station 118 may then start or stop charging transaction according to standard OCPP functionality.

[0065] A third category may comprise CDR (charge detail record) information: Target system 102 may need to get CDR data from the source system 104. The CDR data may comprise, for example, information about when a charging transaction started, when it ended, and how much energy was used.

[0066] FIG. 5 illustrates an example configuration for CDR data communication between charging networks. A charging station 118 and the source system 104 may exchange CDR data related information via OCPP messages at 500. The CDR data may comprise at least information about when charging ends (e.g., an end time of a charging transaction). In one example, the CDR data may comprise an identity of a charging station 118, start time of charging at the charging station, stop time of charging at the charging station, used energy for charging, and an identifier (e.g., ID token) of the user who charged. The CDR data may further comprise data updates (such as updated energy readings) during charging. The source system 104 may be configured to transmit the CDR data received from the charging station 118 to the target system 102, at 502. The target system 102 may be configured to store, at 504, the CDR data. The target system 102 may then use the stored CDR data to invoice the users 120, at 506.

[0067] A fourth category may comprise B2B (business-to-business) billing information: An operator of the source system may need to be able to get information to invoice operators of the target systems for the charging that users of the target system have been doing at charging stations of the source system.

[0068] FIG. 6 illustrates an example configuration for CDR data related communication between charging networks. The CDR data may be related, for example, to B2B billing data. The source system 104 (e.g., source system with CSMS module and MSP module ”A”) may need to be able to invoice target systems 102A, 102B (e.g., a first target system with CSMS module and MSP module “B” and a second target system with CSMS module and MSP module “C”) for the charging transactions their users 120 have made at charging stations 118A, 118B of the source system 104. Users 120 may pay for charging to the operator of the target system 102A and / or 102B. The operator of the source system 104 may then invoice the charging transactions from the operator of the target system 102A, 102B based on data transmitted via OCPP based roaming connections between the source system 104 and the target systems 102A, 102B at 600. In other words, the source system 104 may be configured to determine which charging transaction is associated with which target system, if any.

[0069] In order to do this, the source system 104 may need to keep track about which individual charging transaction was authorized by which system (e.g., the source system 104 or one of the target systems 102A, 102B), so that the source system 104 may then have all the required information to do invoicing from the target systems 102A, 102B. For example, the source system 104 may have obtained, from the charging station 118A, information (e.g., CDR data) that a user with ID 1 has charged 7.52 kWh, a user with ID 4 has charged 27.98 kWh and a user with ID 5 has charged 20.70 kWh. The source system 104 ma have also received, from the charging station 118B, information that a user with ID 2 has charged 10.50 kWh and that a user with ID 3 has charged 5.29 kWh. The source system 104 may then determine, based on the which source / target system performed authorization of the ID of the respective user, that charges of the user with ID 1 should be invoiced by the operator of the source system 104, charges of the users with ID 2 and ID 5 should be invoiced from the operator of the target system 102A and charges of theusers with ID 3 and ID 4 should be charged from the operator of the target system 102B. When the source system 104 then wants to invoice a certain target system for their charging transactions, the source system 104 may simply sum up all the charging transactions based on the stored information. In addition to invoicing, the stored data may be also used for other purposes, such as statistics.

[0070] A CSMS system can communicate with the charging stations either directly, or through another system, using the OCPP protocol. For example, the target system 102 may not need to know or care that some charging stations are connecting through the source system 104. From a perspective of the target system 102, all charging stations communicate with the same OCPP protocol. Users with an account in the target system 102 can use charging stations linked to the target system 102 and to the source system 104.

[0071] FIG. 7 illustrates an example of a WebSocket duplication procedure. A CSMS system, such as source system 104, may be configured with WebSocket duplication rules. After the WebSocket duplication is working, OCPP message routing rules may be implemented. This may enable, for example, a target system, such as target system 102, to receive boot notification, status notification messages, among other messages, from charging stations 118 of the source system 104. As a result, the target system 102 is able to know which charging stations 118 are connected to it, and what is the status of the charging stations 118.

[0072] As an example, the source system 104 that wants to provide one or more charging stations for roaming, may have a list of roaming systems it can use, such as a target system 102A and a target system 102B. Each of the target systems 102 A, 102B may have the following parameters configured in the source system 104: a unique identifier (e.g., target system “B”) and OCPP endpoint information, such as an OCPP endpoint URL (uniform resource locator).

[0073] In general, each charging station in the source system 104 can be configured to be open to roaming systems. Each charging station may have a unique identifier, for example, according to the OCPP standard. In FIG. 7, the unique identifier of a first charging station 118A may be “ABC” and the unique identifier of a second charging station 118B may be “DEF”. The source system 104 may configure charging stations to be open to certain target systems. For example, inFIF. 7, the first charging station 118A may be opened by the source system 104 to roaming with the target system 102A and the target system 102B, but the second charging station 118B is not opened for roaming with any target system. The source system 104 may store a list of roaming system configurations 704.

[0074] When charging stations 118A, 118B are connected to the source system 104, the charging stations 118A, 118B may open a normal WebSocket connection to the source system 104. The WebSocket connections may be opened, for example, according to OCPP. In other words, the charging stations 118A, 118B may be OCPP clients towards the source system 104 acting as the OCPP server 106.

[0075] Once the source system 104 receives the incoming WebSocket connection (e.g., WebSocket connection with identifier “ABC” 700 and WebSocket connection with identifier “DEF” 702) from the charging station(s) 118A, 118B, the source system 104 may check from the roaming configuration if the respective charging station is open to one or more target systems. If yes, the source system 104, now acting as OCPP client 108, can open a new WebSocket connection to the target system(s) (e.g., target system 102A and target system 102B acting as the OCPP server 106) linked with the identifier of the charging station (e.g., “ABC”) with the same identifier that the source system 104 got from the charging station (e.g., the WebSocket “ABC” 700). As a result, from the perspective of the target systems 102A and 102B a normal (OCPP) charging station is connecting to them, and the target systems 102A, 102B may not need to know or care that there is a source system 104 in between. Therefore, there may be no need for separate roaming protocols. After the WebSocket connection is opened towards the target system 102 A and 102B, the target systems 102 A, 102B are ready to receive any standard OCPP messages from the charging station 118A, through the source system 104. If the charging station 118A closes WebSocket connection to the source system 104, then the source system 104 may also close the WebSocket connection to the target systems 102 A and 102B.

[0076] With the above WebSocket connection procedure, a source system may open a WebSocket connection to all roaming target systems for each charging station that is open to roaming. Hence, there is communication channel(s) open tosend and receive OCPP messages between the source system and the roaming target systems.

[0077] For full roaming functionality, messaging between the source system and the target systems can be implemented as illustrated in FIG. 8. In general, OCPP standard may provide different ways for a CSMS to authenticate charging stations, such as password based basic authentication and client certificate-based authentication. In order for the authentication to work in roaming with different systems, the source system may need to configure authentication method to each target system at a database 802, when different target systems support different authentication methods. The source system 104 may then include the configured authentication method to the WebSocket connection according to the OCPP.

[0078] For example, charging stations 118 may use some authentication method with the source system 104, such as client certificate based authentication. One target system, such as target system 102A, may be using basic authentication, with an authentication password “XXYY”. One target system, such as target system 102B, is not using any method for authentication.

[0079] When a charging station 118 opens a WebSocket connection to the source system 104, the source system 104 may perform normal authentication configured to it, e.g., the client certificate based authentication according to OCPP, at 800. Thereafter, when the source system 104 opens WebSocket connection for the charging station 118 to the target system 102A, the source system 104 may use the basic authentication with the password “XXYY”. Further, when the source system 104 opens the WebSocket connection to the target system 102B, the source system 104 does not use any authentications, according to the configuration of the target system 102B. Hence, it is possible to separate the authentication method that the charging station uses with the source system from the authentication method the source system uses with the target system(s) when opening a connection (e.g., WebSocket connection), since different target systems may support different authentication options.

[0080] FIG. 9 illustrates an example of message exchange between charging networks in a OCPP based roaming network. The roaming network comprises aplurality of charging networks configured to allow opening roaming connections between each other.

[0081] An original request message may either come from a charging station 118 or from a target system, e.g. from a target system 102 A or target system 102B. In FIG. 9, the charging station 118 has transmitted a request message 900, such as a heartbeat request, and either a source system 104 or target system(s) 102A, 102B transmits a response message 902 to the request message 900, depending on the situation.

[0082] There are different message types in OCPP protocol. When the OCPP is used for roaming, an additional logic may be needed in the source system to determine which messages to forward for the target systems and in which case.

[0083] For example, the OCPP messages from the charging stations can be divided to two categories:

[0084] Always forward - message from a charging station is sent to all target systems linked with the charging station. Response to the charging station is created by the source system. For example, boot notifications, heartbeat messages, meter value messages and status notifications may be configured to be always forwarded to the linked target systems.

[0085] Decision process - a separate process is performed to decide whether a message from a charging station is forwarded to one or more of the linked target systems or not. Response can be created by one of the target systems. For example, messages related to a start or a stop of a charging transaction, messages related to authorization, and notification messages related to diagnostics statuses and firmware statuses can be configured to be processed to determine to which target systems, if any, the message needs to be forwarded to.

[0086] The configurations for forwarding of messages may be dynamically changed based on different use cases.

[0087] FIG. 10 illustrates an example of a forwarding rule for an authorization message. Authorization information may be received in several messages in OCPP, such as in messages related to authorization requests or charging transaction events.

[0088] At operation 1000, a charging station may send one of the authorization messages to a source system, e.g., source system 104.

[0089] At operation 1002, the source system may check from its own local database if the authorization information included in the authorization message (e.g., ID token associated with a user) is authorized.

[0090] At operation 1004, the source system determines if the authorization information is found from the local database. If yes, the source system can determine to use a response generated by the source system, at operation 1006. Thereafter, at operation 1008, the source system may respond to the charging station with the determined response to allow the user to use the charging station.

[0091] If the authorization information is not found from the local database of the source system, the source system can be configured to check, at operation 1010, which target system(s) are configured for the charging station for roaming.

[0092] At operation 1012, the source system may forward the authorization message received from the charging station at 1000 to the target system(s) configured for the charging station.

[0093] At operation 1014, the source system monitors if any of the target system(s) responds with an accepted authorization to the forwarded authorization message. If not, the source system may send a response to the charging station indicating that the authorization was rejected, at operation 1018. Hence, charging will not be started for the user at the charging station. If one of the target systems responds to the forwarded message with an accepted authorization, the source system determines, at operation 1016, to use the response received from the target system as the response to be transmitted to the charging station.

[0094] At operation 1008, the source system sends the response determined at 1006 or 1016 to the charging station. Because the authorization was accepted by the source system or the target system, the user can then start charging at the charging station.

[0095] FIG. 11 illustrates an example of a forwarding rule for a message with updated data. For example, a charging station may send information to a source system about a status of a diagnostics upload, a firmware update and / or a charging transaction. Status updates of diagnostics upload may be transmitted in an OCPP message, such as DiagnosticsStatusNotification or LogStatusNotification. Status updates of firmware updates may be transmitted in an OCPP message, such asFirmwareStatusNotification. Status updates of charging transaction events may be transmitted in an OCPP message, such as StopTransaction or TransactionEvent.

[0096] At operation 1100, the charging station may send a message with updated information to the source system. In one example, the message may comprise one of the diagnostics status messages, a firmware status message or a message indicating that a charging transaction has stopped.

[0097] At operation 1102, the source system may check if the message was requested by the source system. For example, in case of diagnostics status message, the source system may check if the source system requested the respective diagnostics upload. For example, in case of a firmware status message, the source system may check if the source system was the entity that requested a respective firmware update. For example, in case the message indicates that the charging transaction has stopped, the source system may check if it authorized a message for starting the charging transaction.

[0098] At operation 1104, the source system determines if the message received form the charging station was requested by the source system itself.

[0099] At operation 1106, if the source system determined that the message was requested by itself, the source system may determine to process the message and create a response to the charging station.

[0100] At operation 1110, if the source system determined that the message was not requested by the source system, the source system may check which target system requested the message, e.g., requested the diagnostics upload, the firmware update or authorized the start of charging transaction.

[0101] At operation 1112, the source system may forward the message received from the charging station to the correct target system for which the message was directed to.

[0102] At operation 1114, the target system may receive the forwarded message. The target system processes the message and created a response to the charging station.

[0103] At operation 1108, the source system sends the response created by the source system (at 1106) or the target system (at 1114) to the charging station. Depending on the content of the message received from the charging station, theresponse may comprise, for example, an acknowledgment of the status update or a confirmation that the charging transaction stop have been processed. For example, a standard (charging) transaction stop message in OCPP protocol may include information needed for charge detail records, such as charging duration and used energy. Hence, with the disclosed forwarding rule, a correct target system receives the CDR information to be stored for later use.

[0104] FIG. 12 illustrates an example of a forwarding rule for charging transaction start related message. The message may be an OCPP message that a charging station uses to inform a CSMS, such as a source system, that the charging station wants to start a new charging transaction. The OCPP message may be, for example, a StartTransaction or TransactionEvent messsage.

[0105] At operation 1200, the charging station may send the message for a charging transaction start to the source system. The message may include an identifier of a user who wants to start charging at the charging station. The identifier may be, for example, an ID token.

[0106] At operation 1202, the source system checks if there has been a remote start request with the same identifier as included in the message received at 1200. If the source system determines, at operation 1204, that there has been remote start request with the same identifier, the source system may be configured to forward the message to the system that created the remote start request. The system may be either the source system or a target system. If the source system determines, at operation 1204, there has not been a remote start request with the same identifier, the source system may continue with authorization of the message, at operation 1210.

[0107] If the message was forwarded to the target system at operation 1206, the source system may check, at operation 1208, a response from the target system that processed the message.

[0108] If the source system decided to continue with authorization of the message at operation 1210, the source system may perform the authorization message process as described in FIG. 10 at operation 1212.

[0109] After the operation 1212 or operation 1206, the source system may monitor if any target system has responded with an accepted authorization, at operation1214. If it is determined at 1214 that the authorization is being accepted, the source system may send the response to the charging station at operation 1218. Thereafter, the charging transaction can start at the charging station. If it is determined at 1214 that the authorization was rejected, the source system sends a response to the charging station indicating that the charging transaction was rejected, at operation 1216, and the charging transaction is not started at the charging station.

[0110] FIG. 13 illustrates an example of a procedure for forwarding request messages in an EV roaming network. An original request message can either come from a charging station 118, from a source system 104 (e.g., comprising CSMS and MSP “A”) or from a target system. The target system may be, for example, a target system 102A with CSMS and MSP “B” or a target system 102B with CSMS and MSP “C”. In other words, the source system 104 and the target systems 102 A and 102B are different systems configured to manage different charging stations and / or user information. FIG. 13 illustrates a scenario, where the target system 102B makes a request and the charging station gives a response to the request.

[0111] For example, the target system 102B may send a reset request 1300 for the charging station. The reset request 1300 may be first received by the source system 104. The source system 104 may then check if the target system 102B is configured for roaming for the charging station 118A. For example, the source system 104 may have created a list of roaming system configurations 704 as described in FIG. 7, and check from the list if the target system 102B is associated with the charging station 118A. If the target system 102B is configured for roaming with the charging station 118A, the source system 104 may forward the reset request 1300 to the charging station 118 A. The charging station 118 A can then respond to the reset request, and send the reset response 1302 to the source system 104 from which the reset request 1300 was received by the charging station 118A. The source system 104 may then check from which target system 102 A, 102B the reset request 1300 was initially received from, and forward the reset response 1302 to that target system.

[0112] If the reset request was initially created by the source system, the response received from the charging station would be processed by the source system itself, and not forwarded to a target system. The process of forwarding responses to messages in illustrated in more detail in FIG. 14. A goal of the process is that aresponse message from a charging system is forwarded to the same system that created an associated request message. If the request message was created by a source system, the message is not forwarded by processed by the source system.

[0113] First, a request message for a charging station is created either by a source system, at operation 1400 (start of process A), or by a target system, at operation 1402 (start of process B).

[0114] When the request message for the charging station is created by the target system, the request message is sent to the charging station via the source system. For example, at operation 1404, the target system may send the request message to a WebSocket connection that points to the source system.

[0115] When the request message is initially created by the source system, the source system sends the request message to the charging station as usual, at operation 1406.

[0116] The charging station then processes the received request message and creates a response to the request message, at operation 1408.

[0117] At operation 1410, the source system receives the response from the charging station. Thereafter, at operation 1412, the source system check which system created the initial request message (e.g., the source system at operation 1400 or the target system at operation 1402).

[0118] At operation 1414, the source system determines whether or not the initial request message was created by the source system. If yes, the source system decides to process the response itself, at operation 1422. If not, the source system forwards the response to the target system which created the initial request message, at operation 1416. When the response is received by the target system, the target system processes the response, at operation 1418.

[0119] The process may then end at operation 1420, and as a result, the response from the charging station is being processed by the same system which created the request message.

[0120] FIG. 15 illustrates an example of charging station data transfer in a roaming network for electric vehicle charging. As mentioned earlier, target systems may need different static POI data from a charging station. Part of this data can beincluded in standard OCPP messages. For other parts of the data, a special implementation of an OCPP message for data transfer can be used.

[0121] For example, a charging station may be powered on at operation 1500, and the charging station opens a WebSocket connection with a source system. When the source system then opens a new WebSocket connection to the target system(s) configured for roaming for the charging station, the respective target system obtains an identity of the charging station as a part of the WebSocket URL the source system opens, as described in FIG. 7.

[0122] Thereafter, at operation 1502, the charging station may send a notification message to the source system. The notification message may be one of standard OCPP messages, such as a boot notification. The source system may then check at operation 1504, if any target system is configured for roaming for the charging station. At operation 1506, the source system forwards the boot notification to the configured target system(s) (e.g., as described in FIG. 9), and waits for a response. The boot notification may comprise basic charging station information, such as a vendor and / or a model of the charging station.

[0123] However, some standard OCPP messages may not include other POI information, such as coordinates, address, facilities, and the like. Therefore, the source system may be configured to store the POI information, including at least one of the following: name coordinates (e.g., longitude and altitude) address category (e.g., restaurant, shopping, parking); and / or opening hours.

[0124] At operation 1508, the source system may be configured to send the stored POI data to the target system(s) after the response to the boot notification is received from the target system(s). Hence, when the process ends at 1510, it may be ensured that the target system(s) connected to the charging station (e.g., via the WebSocket connection) have up to date POI data. The stored POI data may be sent in an OCPP message configured with custom contents (e.g., DataTransfer-message with messageDataType “POIData”).

[0125] FIG. 16 illustrates an example of a data model for one or more roaming processes. A source system 104 may have zero or more charging stations 118 connected to it. The source system 104 may also have a roaming connection to zero or more target systems 102. Charging stations 118 may have zero or more CDRs 1600 stored and / or created by the charging stations 118. Each CDR 1600 (or a charging transaction associated with the CDR) can be authorized by a target system 102 or by the source system 104. Each CDR 1600 may comprise data associated to a single charging transaction, including information of at least one of a start time, an end time, an amount of charged energy (kWh), and / or which system authorized the charging transaction. Based on the data model, the source system 104 can conclude which system (target or source) authorized a single charging transaction, and the source system 104 is able to keep track of, and for example invoice, relevant charging transactions from the target systems 102.

[0126] FIG. 17 illustrates an example of a process to create invoices in a roaming network. The process enables a source system to keep track of charging transactions and create invoices for correct target systems.

[0127] At operation 1700, a new charging transaction is requested to be started at a charging station.

[0128] At operation 1702, a message for charging transaction start is received by the source system from the charging station, and the message is processed as described in FIG. 12.

[0129] At operation 1704, the source system determines if the new charging transaction is started based on whether a response to the message indicated an acceptance or rejection of the request to start the charging transaction. If the new charging transaction was not started (e.g. authorization rejected), the process may end at operation 1706. Because no new charging transaction was started, there is no need to gather billing information for the charging transaction. If the new charging transaction was started (e.g., authorization accepted), the source system may check at operation 1708 if the charging transaction was authorized by one of the target systems. If not, e.g., the source system authorized the charging transaction, the process may end at operation 1710. Because the source system authorized the charging transaction, there is no need to invoice the target systems.

[0130] If the charging transaction was authorized by one of the target systems, the source system may be configured update, at operation 1712, a CDR record associated with the charging transaction with information about which target system authorized the respective charging transaction.

[0131] At operation 1714, the source system may sum up all CDRs of each target system. For example, the source system may be configured to gather the CRDs at a certain date of a month, such as at each end date of a month, or within a certain interval, such as for the past thirty days, after each thirty days, depending on configuration.

[0132] At operation 1716, the source system may create invoices for all the target systems based on the summed up CDRs. At operation 1718, the source system may invoice each target system based on the respective CDR records.

[0133] FIG. 18 illustrates an example of an apparatus configured to practice one or more example embodiments. Apparatus 1800 may comprise a device such a server, a network device, a computing device, or in general any apparatus configured to implement functionality described herein. In one example, apparatus 1800 comprises a CSMS system. Apparatus 1800 may comprise at least one processor 1802. The at least one processor 1802 may comprise, for example, one or more of various processing devices, such as for example a co-processor, a microprocessor, a controller, a digital signal processor (DSP), a processing circuitry with or without an accompanying DSP, or various other processing devices including integrated circuits such as, for example, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a microcontroller unit (MCU), a hardware accelerator, a special-purpose computer chip, or the like.

[0134] Apparatus 1800 may further comprise at least one memory 1804. The memory 1804 may be configured to store, for example, computer program code or the like, for example operating system software and application software. Memory 1804 may comprise one or more volatile memory devices, one or more non-volatile memory devices, and / or a combination thereof. For example, the memory may be embodied as magnetic storage devices (such as hard disk drives, magnetic tapes, etc.), optical magnetic storage devices, or semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash ROM,RAM (random access memory), etc.). Memory 204 is provided as an example of a (non-transitory) computer readable medium. The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0135] Apparatus 1800 may further comprise a communication interface 1808 configured to enable apparatus 1800 to transmit and / or receive information. Communication interface 1808 may comprise, for example, a communication interface between a target system and a source system, as described herein. Communication interface may further comprise a communication interface between a management system (e.g., a target system, a source system, or the like) and one or more charging stations or other client devices (e.g., mobile devices of users). Communication interface 1808 may comprise one or more radio transmitters or receivers, which may be coupled to one or more antennas or apparatus 1800, or be configured to be coupled to one or more antennas external to apparatus 1800.

[0136] Apparatus 1800 may further comprise other components and / or functions such as a user interface 1810 comprising at least one input device and / or at least one output device. The input device may take various forms such a keyboard, a touch screen, or one or more embedded control buttons. The output device may for example comprise a display, a speaker, or the like. Apparatus 1800 may be configured to, for example, receive instructions and parameters from a user via the user interface 1810.

[0137] When apparatus 1800 is configured to implement some functionality, some component and / or components of apparatus 1800, such as for example the at least one processor 1802 and / or the at least one memory 1804, may be configured to implement this functionality. Furthermore, when the at least one processor 1802 is configured to implement some functionality, this functionality may be implemented using program code 1806 comprised, for example, in the at least one memory 1804.

[0138] The functionality described herein may be performed, at least in part, by one or more computer program product components such as software components. According to an example embodiment, apparatus 1800 comprises a processor or processor circuitry, such as for example a microcontroller, configured by theprogram code 1806, when executed, to execute the embodiments of the operations and functionality described herein. Program code 1806 is provided as an example of instructions which, when executed by the at least one processor 1802, cause performance of apparatus 1800.

[0139] Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), applicationspecific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), complex programmable logic devices (CPLDs), graphics processing units (GPUs), or the like.

[0140] Apparatus 1800 may be configured to perform, or cause performance of, method(s) described herein or comprise means for performing method(s) described herein. In one example, the means comprises the at least one processor 1802, the at least one memory 1804 including instructions (e.g., program code 1806) configured to, when executed by the at least one processor 1802, cause apparatus 1800 to perform the method(s). In general, computer program instructions may be executed on means providing generic processing functions. Such means may be embedded for example in a personal computer, a smart phone, a network device, or the like. The method(s) may be thus computer-implemented, for example, based on algorithm(s) executable by the generic processing functions, an example of which is the at least one processor 1802. The means may comprise transmission or reception means, for example one or more radio transmitters or receivers, which may be coupled or be configured to be coupled to one or more antennas. Apparatus 1800 may comprise, for example, a network device, for example, an access node, an access point, a base station, or a central / distributed unit thereof. Although apparatus 1800 is illustrated as a single device, it is appreciated that, wherever applicable, functions of apparatus 1800 may be distributed to a plurality of devices.

[0141] FIG. 19 illustrates an example of a method 1900 for OCPP based roaming. Method 1900 may be performed by a system, such as source system 104, or by a control apparatus configured to control the functioning thereof, when installed therein.

[0142] At operation 1902, the method may comprise storing a list of target charging station management systems, target CSMSs, for roaming in electric vehicle charging, the list of target CSMSs comprising a unique identifier of each target CSMS and OCPP endpoint information of each target CSMS.

[0143] At operation 1904, the method may comprise storing a list of available roaming connections for charging stations managed by a source CSMS, the list comprising a unique identifier of each of the charging stations and an indication if a roaming connection to one or more target CSMSs is configured to be allowed for the respective charging station.

[0144] At operation 1906, the method may comprise detecting an incoming open charge point protocol, OCPP, connection from a charging station to the source CSMS.

[0145] At operation 1908, the method may comprise checking, from the list of available roaming connections, if a roaming connection is allowed to be opened by the source CSMS to one or more target CSMS for the charging station in response to the detected OCPP connection.

[0146] At operation 1910, the method may comprise opening an OCPP connection to the one or more target CSMSs using the unique identifier of the charging station when the roaming connection is allowed to be opened for the charging station based on the list of roaming connections.

[0147] At operation 1912, the method may comprise detecting a message is received by the source CSMS from the charging station.

[0148] At operation 1914, the method may comprise determining, based on one or more forwarding rules associated with a type of the received message, if the message is to be forwarded to at least one of the one or more target CSMS or processed by the source CSMS.

[0149] At operation 1916, the method may comprise at least one of forwarding the message to the at least one of the one or more target CSMS via the respective OCPP connection or causing the message to be processed by the source CSMS based on the determination.

[0150] Further features of the methods directly result for example from functionality of a source system 104, or a target system 102, as describedthroughout the description, claims, and drawings, and are therefore not repeated here. An apparatus, for example a computing device, may be configured to perform or cause performance of any aspect of the method(s) described herein. Further, a computer program, a computer program product, or a (non-transitory) computer- readable medium may comprise instructions for causing, when executed by an apparatus, the apparatus to perform any aspect of the method(s) described herein. Further, an apparatus may comprise means for performing any aspect of the method(s) described herein. According to an example embodiment, the means comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform any aspect of the method(s).

[0151] Any range or device value given herein may be extended or altered without losing the effect sought. Also, any embodiment may be combined with another embodiment unless explicitly disallowed.

[0152] Although the subject matter has been described in language specific to structural features and / or acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as examples of implementing the claims and other equivalent features and acts are intended to be within the scope of the claims.

[0153] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. It will further be understood that reference to 'an' item may refer to one or more of those items.

[0154] The steps or operations of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. Additionally, individual blocks may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of any of the example embodiments described above may be combined with aspects of any of the other example embodiments described to form further example embodiments without losing the effect sought.

[0155] The term 'comprising' is used herein to mean including the method, blocks, or elements identified, but that such blocks or elements do not comprise an exclusive list and a method or apparatus may contain additional blocks or elements.

[0156] As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0157] Although subjects may be referred to as ‘first’ or ‘second’ subjects, this does not necessarily indicate any order or importance of the subjects. Instead, such attributes may be used solely for the purpose of making a difference between subjects.

[0158] As used in this application, the term ‘circuitry’ may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable) :(i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term in this application, including in any claims.

[0159] As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0160] It will be understood that the above description is given by way of example only and that various modifications may be made by those skilled in the art. The above specification, examples and data provide a complete description of the structure and use of exemplary embodiments. Although various embodiments have been described above with a certain degree of particularity, or with reference to one or more individual embodiments, those skilled in the art could make numerous alterations to the disclosed embodiments without departing from scope of this specification.

Claims

CLAIMS1. An apparatus for a source charging station management system of electric vehicle charging roaming management, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: store a list of target charging station management systems, target CSMSs, for roaming in electric vehicle charging, the list of target CSMSs comprising a unique identifier of each target CSMS and OCPP endpoint information of each target CSMS; store a list of available roaming connections for charging stations managed by the source charging station management system, source CSMS, the list comprising a unique identifier of each of the charging stations and an indication if a roaming connection to one or more target CSMSs is configured to be allowed for the respective charging station; detect an incoming open charge point protocol, OCPP, connection from a charging station to the source CSMS; check, from the list of available roaming connections, if a roaming connection is allowed to be opened by the source CSMS to one or more target CSMS for the charging station in response to the detected OCPP connection; open an OCPP connection to the one or more target CSMSs for roaming using the unique identifier of the charging station when the roaming connection is allowed to be opened for the charging station based on the list of roaming connections; detect a message is received by the source CSMS from the charging station; determine, based on one or more forwarding rules associated with a type of the received message, if the message is to be forwarded to at least one of the one or more target CSMS or processed by the source CSMS; and at least one of forward the message to the at least one of the one or more target CSMS via the respective OCPP connection or cause the message to be processed by the source CSMS based on the determination.

2. The apparatus of claim 1, further caused to: detect that the received message is a response message; determine if the response message is related to a request message created by the source CSMS or by the one or more target CSMSs; cause the response message to be processed by the source CSMS based on the one or more forwarding rules when it is determined that the request message was created by the source CSMS; and forward the response message to be processed by at least one of the target CSMSs via the respective OCPP connection for roaming based on the one or more forwarding rules when it is determined that the at least one target CSMS created the request message.

3. The apparatus of any preceding claim, wherein the received message comprises at least one of a heartbeat message, an authorize request, a boot notification, a diagnostics status notification, a firmware status notification, meter values, a reset request, a message for start of charging transaction, a status notification, or a message for a stop of charging transaction.

4. The apparatus of any preceding claim, further caused to: detect that the received message comprises a boot notification; determine, based on the one or more forwarding rules, to forward the boot notification to the one or more target CSMSs; receive a response from the one or more target CSMSs via the respective OCPP connection in response to the forwarded boot notification; and send, to the one or more target CSMSs via the respective OCPP connection, an OCPP message configured for data transfer, wherein the OCPP message comprises additional point-of-interest data not included in the boot notification.

5. The apparatus of claim 4, wherein the additional point-of-interest data is configurable and comprises at least one of the following:a name of the charging station; coordinates of the charging station; an address of the charging station; a location category of the charging station; or opening hours of the charging station.

6. The apparatus of any preceding claim, wherein the list of target CSMSs further comprises an indication of an authentication method the respective target CSMS is configured to use for connection authentication, and the apparatus is further caused to: perform authorization of the charging station which opened the OCPP connection with the source CSMS based on an authorization method configured for the source CSMS; and when opening the OCPP connection to the one or more target CSMSs for the charging station, perform authentication of the charging station based on the authentication method configured to be used by the respective target CSMS.

7. The apparatus of any preceding claim, further caused to: detect that the received message comprises an OCPP message for authorization of a user; check, based on information stored at the source CSMS, if authorization of the user is rejected or accepted by the source CSMS; when authorization of the user is rejected by the source CSMS, forward the OCPP message for authorization of the user to the one or more target CSMSs with the opened OCPP connection for the charging station; monitor if any of the one or more target CSMSs responds via the respective OCPP connection with an accepted authorization of the user based on the forwarded message; respond, to the charging station via the OCPP connection opened with the source CSMS, with one of an accepted authorization of the user based on an accepted authorization by one of the source CSMS or the target CSMS, or with arejected authorization when the authorization of the user is rejected by both the source CSMS and the one or more target CSMSs.

8. The apparatus of claim 7, caused to: detect that the received message is an OCPP message related to a start of a charging transaction at the charging station; determine if a remote start request associated with the charging station was received from a target CSMS before the message, wherein both the remote start request and the received message comprise a same identifier of a user; when it is determined that the remote start request was received before the message from the target CSMS, forward the received message to be processed for authorization by the respective target CSMS based on the one or more forwarding rules; when it is determined that the remote start request was not received from any of the one or more target CSMSs, proceed to process the message for authorization by the source CSMS.

9. The apparatus of claim 8, caused to: detect that the received message is an OCPP message related to a stop of the charging transaction; check if the charging transaction was authorized by the source CSMS or by one of the one or more target CSMSs; based on the determination, one of process the received message by the source CSMS or forward the received message to be processed by the one of the one or more target CSMSs; detect when a response created by the respective target CSMS is received via the OCPP connection in response to the forwarded message; send, to the charging station via the OCPP connection opened with the source CSMS, a response confirming that the stop of the charging transaction has being processed based on a response created by one of the source CSMS or the target CSMS.

10. The apparatus of any of claims 8 or 9, further caused to: update a charge detail record of the charging transaction with information about which target CSMS authorized the start of the respective charging transaction; combine information about charging transactions for each of the one or more target CSMSs based on charge detail records linked with a respective target CSMS; and transmit the combined information linked with the respective target CSMS to each of the one or more target CSMSs.

11. The apparatus of any preceding claims, further caused to: detect that the received message is an OCPP message related to a diagnostics status of the charging station; determine if the diagnostics status of the charging station was requested by the source CSMS or one of the target CSMSs; based on the determination, one of process the received message by the source CSMS or forward the received message to be processed by the one or more target CSMS based on the one or more forwarding rules; detect when a response created by the one or more target CSMSs is received via the respective OCPP connection in response to the forwarded message; and send, to the charging station via the OCPP connection opened with the source CSMS, a response created by one of the source CSMS or the one or more target CSMSs based on the processed message.

12. The apparatus of any preceding claim, further caused to: detect that the received message is an OCPP message related to a firmware update; determine if the firmware update was requested by the source CSMS or the one or more target CSMSs; based on the determination, one of cause the received message to be processed by the source CSMS or forward the received message to be processed by the one or more target CSMS according to the one or more forwarding rules;detect when a response created by the one or more target CSMSs is received via the respective OCPP connection in response to the forwarded message; and send, to the charging station via the OCPP connection opened with the source CSMS, a response based on the processed message by one of the source CSMS or the one or more target CSMS.

13. The apparatus of any preceding claim, wherein the apparatus comprises the source CSMS.

14. A method carried out by a computing device, comprising: storing a list of target charging station management systems, target CSMSs, for roaming of electric vehicle charging, the list of target CSMSs comprising a unique identifier of each target CSMS and OCPP endpoint information of each target CSMS; storing a list of available roaming connections for charging stations managed by a source charging station management system, source CSMS, the list comprising a unique identifier of each of the charging stations and an indication if a roaming connection to one or more target CSMSs is configured to be allowed for the respective charging station; detecting an incoming open charge point protocol, OCPP, connection from a charging station to the source CSMS; checking, from the list of available roaming connections, if a roaming connection is allowed to be opened by the source CSMS to one or more target CSMS for the charging station in response to the detected OCPP connection; opening an OCPP connection to the one or more target CSMSs using the unique identifier of the charging station when the roaming connection is allowed to be opened for the charging station based on the list of roaming connections; detecting a message is received by the source CSMS from the charging station; and determining, based on one or more forwarding rules associated with a type of the received message, if the message is to be forwarded to at least one of the one or more target CSMS or processed by the source CSMS;at least one of forwarding the message to the at least one of the one or more target CSMS via the respective OCPP connection or causing the message to be processed by the source CSMS based on the determination.

Images