[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ocpp] "Not Authorized" Reason
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).
However, it would be wrong, and misleading to have such a field being named “StopReason” in the IdTagInfo structure as a way to communicate why a transaction was never started in the first place.
It would be even more confusing if a field called StopReason was a strict enumeration on StopTransaction.req messages, but a free text field on Authorize.conf . There is a clear distinction between the two cases, as is implied by the origin of the values (CP vs CS).
Further, I think that such a field should be named generically (e.g. “AuthorizeResponse”), rather than “negatively” (e.g. RefusalMessage”).
By so doing, it can also be used on “successful” authorization to give relevant supplementary warnings, notices, or other information: e.g.: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
Sent: 14 November 2016 08:22
To: Robert de Leeuw; ocpp@lists.oasis-open.org
Subject: RE: [ocpp] OCPP Not Authorized Reason
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
Verzonden: zondag 13 november 2016 18:21
Aan: ocpp@lists.oasis-open.org
Onderwerp: [ocpp] OCPP Not Authorized Reason
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:
- 1: Add more statuses to AuthorizationStatus
- Pros: simple, only extend the enumeration, Charge Point can implement messages that fit the display.
- Cons: how do we know we have all the possible reasons (Not enough pre-paid amount, Fast Charging not allowed?)
- 2: Add a extra optional string field: StopReason to IdTagInfo.
- Pros: everything possible reason can be given.
- Cons: Central System needs to know display size of the Charge Point. How about non ascii-character sets, use UTF-8?. Central System might need to know the language if the user is unknown, and has select a language on the Charge Point.
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,
Robert de Leeuw
IHomerHoge Ham 85
5104 JC Dongen
John F. Kennedylaan 3
5555 XC Valkenswaard
T: +31 6 2857 2123
E: robert.de.leeuw@ihomer.nl
An timpeallacht? - Smaoinigh air sula bpriontáileann tú an r-phost seo.
Please consider the Environment before printing this email.* ** *** ** * ** *** ** * ** *** ** *
Tá an t-eolas sa ríomhphost seo agus in aon chomhad a ghabhann leis rúnda agus ceaptha le haghaidh úsáide an té nó an aonáin ar seoladh chuige iad agus na húsáide sin amháin.
Is tuairimí nó dearcthaí an údair amháin aon tuairimí nó dearcthaí ann, agus ní gá gurb ionann iad agus tuairimí nó dearcthaí ESB.
Má bhfuair tú an ríomhphost seo trí earráid, ar mhiste leat é sin a chur in iúl don seoltóir.
Scanann ESB ríomhphoist agus ceangaltáin le haghaidh víreas, ach ní ráthaíonn sé go bhfuil ceachtar díobh saor ó víreas agus ní glacann dliteanas ar bith as aon damáiste de dhroim víreas.
https://www.esb.ie/contact
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.
Any views or opinions presented are solely those of the author, and do not necessarily represent those of ESB.
If you have received this email in error please notify the sender.
Although ESB scans e-mail and attachments for viruses, it does not guarantee that either is virus-free and accepts no liability for any damage sustained as a result of viruses.
https://www.esb.ie/contact* ** *** ** * ** *** ** * ** *** ** *
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]