OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ocpp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] (OCPP-96) Investigate how we can support 4 tier charge points, and if this is needed.

    [ https://issues.oasis-open.org/browse/OCPP-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64608#comment-64608 ] 

Franc Buve commented on OCPP-96:

Summary of current status:
Hi Kor,

I have discussed the request to extend the Device Model with a 4th tier with Brendan and Robert. I summarized your points as follows:

1.	A charging pool may be used to define a cluster/group of charge points involved in smart charging
2.	A charging pool may collect parking place availability for the group, e.g. in a parking garage
3.	A charging pool may have opening times that need to be registered and published
4.	A charging pool can be used to reserve a spot for charging without identifying a specific charge point.

After some e-mail discussion we came to the conclusion that we don’t see the need for a 4th tier. However, we want to make sure that we are not missing some (implicit) requirement for this. Therefore, Brendan suggested to forward his points to you and request your comments.

This is the response of Brendan:
My main problem with this debate around Kor’s request is that it is still unclear to me why (and how) he feels it to be feasible/desirable/optimal to create a new “4th level” that floats “above” (I think of it as “Tier 0”) the three tiers defined in the OCPP 2.0 device model without the basic premise that the thing called a “charge point” is at the “top” of the 3-tier hierarchy, and is the thing that a Central System talks to directly.

There seem to be (only?) four possible physical/logical  implementation topologies:

1.	The “plaza-controller” is “the charge point”.
a.	It acts as a proxy-ing (mini) Central System to manage lower level controllers, mapping/translating EVSE numbers of the lower charge points, while replicating relevant common DM settings down to the “actual” charge points. 
b.	The “plaza-controller” is the only charge point, but has (multiple) logical/physical extension User Interface “nodes” (e.g. if the plaza is large). 
Such nodes’ UI elements (Token Reader, Display, etc.) may be modelled to exist on a keyed/array basis at the Charge Point level of the DM, or may be (nominally) associated with specific EVSEs (while controlling access to that one (or multiple) EVSEs.
2.	The “plaza-controller” exists logically “above” a set of (independent) charge points, but not as a Central System proxy. 
In that case, the question is: how are whatever number of justified “Tier-0 common variables” that exist  to be shared/propagated/synchronized/visible between the tier-1 charge points ? :
a.	By the Central System reading/setting/duplicating multiple copies of Variables across  two tiers?
This not only creates processing overhead at the CS and unnecessary bandwidth use, but worse, it makes the whole operation of the plaza likely absolutely dependent on the reliability of the comms links and the availability of the Central System as a pair of “single points of failure”.
b.	By some local “out-of-band” mechanism(e.g. local LAN), using some unspecified/proprietary protocol.
To me, options 1a/b  are “obviously” preferable to options 2a/b, but maybe I am missing something.

It is interesting to note that there is at least one company “out there” already that is claiming to offer the “1a” topology for a top-level standalone payment card terminal pod/post, “controlling”

I suggest that you put this directly to Kor, and get his point by point responses, in case there is some (other) requirement that has not been stated, or we are just seeing things form our own point of view.
Can you, please, comment on Brendan’s points above?

You brought up a very valid point with the requirement to reserve a spot in a charging pool without specifying a specific EVSE. Robert commented that this is currently  not supported by the ReserveNow command and I raised an issue in JIRA (OCPP-120) to enhance the specification to support this feature. This does, however, not require a 4th tier in the Device Model.


> Investigate how we can support 4 tier charge points, and if this is needed.	
> ----------------------------------------------------------------------------
>                 Key: OCPP-96
>                 URL: https://issues.oasis-open.org/browse/OCPP-96
>             Project: OASIS OCPP Electric Vehicle Charging Equipment Data Exchange TC
>          Issue Type: Task
>         Environment: New ideas (OCA list)	
>            Reporter: Jonel Timbergen
>            Assignee: Franc Buve
>            Priority: Trivial
> Investigate how we can support 4 tier charge points, and if this is needed.	

This message was sent by Atlassian JIRA

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]