[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ocpp] "Not Authorized" Reason
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]