[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ocpp] "Not Authorized" Reason
|
Hi Robert, You have a good point here. The Authorize response from the Central System only states the validity and parent id of the card. It is up to the
charge point to use that information to determine if starting/stopping of a transaction is allowed. So, the charge point might report that a card is not a member of the group of the card that started the current transaction or not in the group for which the
charge point is reserverd, but this is concluded by the charge point and not the Central System. Regards, -Franc Van: ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org]
Namens Robert de Leeuw Hi Brendan, (all) Patrick Rademakers always told me the rule: "The Central System should never assume to know the state of a Charge Point". NotInGroup: How can the Central System know with 100% certainty that another ID (from another group) is Charging? There is not even an EVSE_ID/ConnectorId in the Authorize request, so with multiple connectors the Central System cannot know for which connector the Authorize request is. Even with 1 reader per EVSE. With only 1 connector on a Charge Point? What if the Charge Point just got back online? And there are still StopTransaction messages in the queue? OCPP 1.6 states: "In the event that a Charge Point has transaction-related messages queued to be sent to the Central System, new messages that are not transaction-related MAY be delivered immediately without waiting for the queue to be emptied. It is therefore allowed to send, for example, an Authorize request or a Notifications request before the transaction-related message queue has been emptied, so that customers are not kept waiting and urgent
notifications are not delayed." Scenario: Charge Point is offline, a couple of drivers have charged there EV while the Charge Point was offline. EV Driver A arrives, parks his card, swipes his card (it is in the cache, so charging is started. Driver A stops charging and
takes his EV en goes home. EV Driver B parks his EV next to the Charge point. Swipes his card, Charge Point just got back online, the authorize request is send before the queue is emptied. What if the Central System thinks a transaction for another user with a different ParentID is still ongoing, and then says: Sorry dude, I wont accept your card because somebody else is charging here... that would be so wrong... The driver would not be able to Charge. The Central System should say: Accepted! In case the EVSE is still in use, the Charge Point should determine that another driver is charging and the Charge Point itself should show a message like: "Not authorized to stop this transaction". It should not come from the Central System. Reservation Same goes for reservation... The Charge Point (as in 1.5 and 1.6) should determine that a driver cannot charge because somebody else has a reservation. "(Commanded) Unavailable" The Charge Point should never send an Authorize request. If there is a problem with the Charge Point that prevents Charging, the Charge Point should go to "Faulted", or an EVSE should go to "Faulted"
if it is an EVSE only problem. In the State Faulted, the Charge Point cannot charge, so it should NOT send an Authorize request. What would happen if we would allow a Charge Point to ask the Central System if it is allowed to charge? Charge Point is off-line, ID is in the Cache, Charge Point starts charging... hope not! If we want to show a specific message on the display of a Charge Point that is faulted? We should use the Message proposal being discussed... Scenario: "This situation is quite common in practice, on multi-standard chargers, where one protocol controller (e.g. CHAdeMO) is faulty, but the other (e.g. high power AC) is working fine. It also happens on chargers where all connectors/EVSEs are of the same type: often the operator is aware (usually through a report from a previous attempted use) that there is a physical/mechanical/electrical
fault, or safety issue, that only affects one connector/EVSE, and that the charge point cannot itself detect by its own inbuilt self-monitoring , or will only manifest itself later in the charging session start sequence, in a way that would be more confusing
to the user." This Charge Point should be set to
Unavailable. And I think any OCPP 1.x Charge Point with a display that is set to Unavailable
will already show an appropriate message on the Display: something like "Unavailable for charging"... Do we want an authorized to be send in this situation so a message in the correct language can be shown??? I don't known... Are there more people in favor of adding both option 1 and 2? More values for the enum and an optional message to the user?
Kind regards, Hoge Ham 85 5104 JC Dongen John F. Kennedylaan 3 5555 XC Valkenswaard
2016-11-15 10:46 GMT+01:00 Brendan McMahon <Brendan.McMahon@esb.ie>: Hi Robert, (folks), See inline responses below. Best Regards,
Brendan McMahon | Systems Architect | ESB ecars | T:
+353 1 702 6708 /
+353 87 662 2150 | www.esb.ie
From: Robert
de Leeuw [mailto:robert.de.leeuw@ihomer.nl]
Hi Brendan, Again, StopReason was a typo, should have been: NotAuthorizedReason, again, sorry for that. Do you propose to add both? More possible values for: AuthorizationStatus, and an optional text field "NotAuthorizedReason" or "AuthorizeResponse"
BMcM: Yes – both should be supported.
“Simple” charge points may have no visual display, or only support hard coded notifications on a very limited character mode display, and will use only the AuthorizationStatus
enumeration value to determine whether to proceed of display either a single rejection message, or one of a fixed set by messages per rejection enumeration value.
“Smarter” charge points may display a more specific and or additional message, either on “Accepted” or, more importantly, on a rejection status value, often in order
to try to reduce the annoyance of the driver. I don't see how the central system can return the status: "NotInGroup". Can you explain a bit more? BMcM:
If no LocalList is supported/enabled,
AND ( All connectors (EVSEs actually) are in use on a charge point and someone presents a card,
OR the charge point has one RFID reader per connector/EVSE (we have ones like this) and someone presents a card to the reader of an occupied connector/EVSE
)
AND the card is not the “starting card”
THEN the attempt to stop the transaction must be refused, and can be accompanied by a suitable (hard-coded if necessary) message: “Card is not authorized to stop this
session”
This case is distinct from the (putative) “LawEnforcement” CR extension case, which has a (new) distinct AuthorizationStatus enumeration value to also allow a case
specific message to be shown, if required. "Reserved"? OCPP 1.6 states: "If the parent idTag in the reservation has a value (it is optional), then in order to determine the parent idTag that is associated with an incoming idTag, the Charge Point MAY look it up in its Local Authorization List or Authorization Cache. If it is not found in the Local Authorization List or Authorization Cache, then the Charge Point SHALL send an Authorize.req for the incoming idTag to the Central System. The Authorize.conf response contains the parent-id." So when should a Central system return an AuthorizationStatus: Reserved?
BMcM: The “Reserved” AuthorizationStatus enumeration value is a negative/refusal response, to be used to enable a charge point to explicitly indicate to drivers (other
than the “reservee”) why they cannot charge: the connector/EVSE is now reserved for someone else, who has not yet arrived. Same goes for "(Commanded) Unavailable" Charge Point is unavailble, it should even do an Authorize request...
BMcM: In OCPP 2.0 “commanded unavailability” (via ChangeAvailability) can be at connector or EVSE level, in addition to overall.
It also happens on chargers where all connectors/EVSEs are of the same type: often the operator is aware (usually through a report from a previous attempted use) that
there is a physical/mechanical/electrical fault, or safety issue, that only affects one connector/EVSE, and that the charge point cannot itself detect by its own inbuilt self-monitoring , or will only manifest itself later in the charging session start sequence,
in a way that would be more confusing to the user.
Once again, this is to allow a sensible specific message to be given to the user. This is especially important on charge points with one card reader per connector/EVSE,
or one reader per (e.g. 2/4 way) cluster of connectors/EVSEs, as a suitable message (“This socket/connector is out of service; please try another, if free”) can direct them to try a different reader/connector/EVSE, rather
Kind regards, Hoge Ham 85 5104 JC Dongen John F. Kennedylaan 3 5555 XC Valkenswaard
2016-11-14 15:29 GMT+01:00 Brendan McMahon <Brendan.McMahon@esb.ie>: Hi Franc, Robert, (folks), I strongly agree with Franc that it would be wrong to have a field called StopReason
in the IdTagInfo structure as a way to communicate why a transaction was never started in the first place. To support all plausible business models and associated use cases, I think that there needs
to be BOTH: ·
Appropriate extra values for the AuthorizationStatus enumeration: e.g.:
o
Reserved – all working not currently in use are (soon to be) reserved to other drivers.
o
(Commanded) Unavailable – e.g. maintenance visit immediately pending
o
OutOfCredit (Central)
o
ContractMismatch – Contract does not allow use of (requested/implied) charging type/speed [at this time] ·
Provision for the Central System to return a (possibly driver language-localized) custom message (suitably formatted, based on the known display characteristics).
o
“You’re account credit will allows only <X> {minutes/hours/kWh} of charging”
o
This charging site closes at 10PM
o
This {charge point | charging site} will be unavailable tomorrow <from> - <to> [due to <reason>] ·
Separately, some thought ought to be given to similar mechanisms in regard to Authorize responses to (attempts to) stop an ongoing transaction:
o
AuthorizationStatus (additional:)
§
NotInGroup (groupIdTag, a.k.a parentIdTag in OCPP 1.6)
§
AcceptedLawEnforcement
o
AuthorizeResponse text (examples)
§
Account credit overdrawn: no further charging possible until topped-up.
§
charge point/site unavailability notices Best Regards,
Brendan McMahon | Systems Architect | ESB ecars | T:
+353 1 702 6708 /
+353 87 662 2150 | www.esb.ie
From:
ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org]
On Behalf Of Buve, Franc Hi Robert, I am in favour of extending the AuthorizationStatus enumeration. A StopReason is something
very different from a reason for not authorizing. I also got the impression that StopReason is a free format text field, which would make automated processing impossible. We can add some fairly generic statuses to AuthorizationStatus to deal with the ‘not
enough funds’ and ‘fast charging not allowed’ and similar cases. I propose the following additions: ·
NoCredit – e.g. when pre-paid card is empty ·
SubscriptionMismatch – e.g. when using a valid card on a type of charger that is not supported by your subscription Regards, -Franc Van:
ocpp@lists.oasis-open.org [mailto:ocpp@lists.oasis-open.org]
Namens Robert de Leeuw Hi All, There was a request for more information in the IdTagInfo class to be able to give more feedback to the EV Driver about the reason why the authorization has failed. Use Case: An EV Driver swipes his card, the Charge Point asks the Central System if the card is allowed to charge. Computer says NO.... If a Charge Point has a display you want to show a reason to the EV driver why he/she is not allowed to Charge. In OCPP 1.6 there are already a couple of different statuses, but these are limited. See: - 7.27. IdTagInfo on page 98 - 7.2. AuthorizationStatus on page 85 Currently we have the following statuses: Accepted Identifier is allowed for charging. Blocked Identifier has been blocked. Not allowed for charging. Expired Identifier has expired. Not allowed for charging. Invalid Identifier is unknown. Not allowed for charging. ConcurrentTx Identifier is already involved in another transaction and multiple transactions are not allowed. (Only relevant for a StartTransaction.req.) I see 2 possible solutions:
I tend to lean to option 1... All this UTF-8 and display size stuff makes a more complex solution.... But on the other hand, we might need to go into that for messages anyway.... Do you guys see a good reason why we should or should not go for one of these options?
Kind regards, Hoge Ham 85 5104 JC Dongen John F. Kennedylaan 3 5555 XC Valkenswaard
* ** *** ** * ** *** ** * ** *** ** *
* ** *** ** * ** *** ** * ** *** ** *
* ** *** ** * ** *** ** * ** *** ** *
* ** *** ** * ** *** ** * ** *** ** * |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]