Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

auto-register unknown charging stations? #55

Closed
goekay opened this issue Apr 11, 2018 · 7 comments
Closed

auto-register unknown charging stations? #55

goekay opened this issue Apr 11, 2018 · 7 comments

Comments

@goekay
Copy link
Member

goekay commented Apr 11, 2018

off-topic but it is being discussed in ChargeTimeEU/Java-OCA-OCPP#37

i can see the value of such feature, but it is highly dangerous to accept/register unknown stations. therefore, i was thinking maybe to add a new flag to the main.properties and the user of steve can make the decision and steve can act accordingly. but first i want to collect opinions from the community. @victormunoz @V2G-UK what do you think?

@goRaspy
Copy link

goRaspy commented Apr 11, 2018

Hi,
I still didn't find time to play with steve 1.6 as I would like.
I did some quick test with a Schneider smart wallbox (1.6 JSON) and it seems to work like a charm.
Many thanks to the community and specially to you @goekay .

Convening the question, I think like you.
Auto register of charging stations could be very dangerous. I already succeeded a sort of DOS attack (hikari pool error) on steve 1.5 with many "abusive chargepoints" (https://github.com/chargegrid/abusive-charge-point). A first solution may be not to store in DB data sent by "not registered" charge points. Unfortunately it still may create a potential gate for attacks by "BootNotification" (maybe DOS or SQL injection).

But if it is an option, why not. We can imagine to run two steve in parallel and switch cs from "pool" to production server by OCPP "change configuration" (for charging stations which support it).

@V2G-UK
Copy link

V2G-UK commented Apr 11, 2018

I guess if it's an option with a warning in the docs, and NOT the default, then one shouldn't complain.

However here is an overview of how Plug&Charge is supposed to work:

https://pdfs.semanticscholar.org/2a46/10cab21e28bbeec8467712cf2e9218507c58.pdf

It's not as simple as a previously unregistered charging station issuing a boot notification!

The overhead needed for public charging can be reduced when it comes to private or semi-public charging. Each local environment, be it a private parking garage or a garage or parking lot of a company with its own EV feet, needs a unique so-called private operator root certificate. Each EVSE (wall-box or charging station) in this local environment will then be equipped with an SECC certificate which is signed by the private operator root certificate – previously created by the EVSE manufacturer – specifically created for this local environment. The respective EVs which are supposed to charge at this local environment need the private operator root certificate to be installed as well in order to check at TLS connection creation whether the SECC certificate is in fact derived from the private operator root certificate.

@csamsel
Copy link
Contributor

csamsel commented Apr 11, 2018

I might be wrong, but ISO/IEC 15118 is still far away - It's also not in OCPP (yet), IIRC it's slated for 2.0

@goekay
Copy link
Member Author

goekay commented Apr 12, 2018

@V2G-UK i agree, this will be for sure an opt-in feature. regarding your other point: if in the near future PKI-based or certificate-based trust mechanisms are employed, then this feature becomes more important, because no-one with invalid certificate can communicate with steve anyways. in this case, the hurdle of manually registering charge points is unnecessary.

@goekay goekay closed this as completed in 78a781f Apr 12, 2018
@V2G-UK
Copy link

V2G-UK commented Apr 13, 2018

Christian - My apologies for the somewhat off topic diversion, but nevertheless:

FYI I sit on the ISO/IEC committees that are standardising 15118 Ed. 2 and IEC 63110, the "successor" to OCPP 2.0 if you will. Should you guys wish to provide some input into the process you may want to take a look at this?

http://www.V2G.co.uk/2018/04/iec-63110-project-team-2-kicks-off/

Jim

@goekay
Copy link
Member Author

goekay commented Apr 17, 2018

(somewhat off-topic but since @goRaspy mentioned the issues with "abusive-charge-point"...)

@goRaspy steve should not cause any problems when testing with abusive-charge-point anymore (after aba72d0). the problem was a really special case due the impl of abusive-charge-point and is not likely to occur in production.

we tested it successfully on a 2013 macbook pro with a local mysql instance (and default hikari pool config as in the repo) using up to 100 stations each with 50 connectors while also reducing the message sending time interval from 3 to 1 seconds to produce more load.

@gabriel1lima
Copy link

Hi,
I still didn't find time to play with steve 1.6 as I would like.
I did some quick test with a Schneider smart wallbox (1.6 JSON) and it seems to work like a charm.
Many thanks to the community and specially to you @goekay .

@goRaspy
Could you describe your test with Schneider's Smart Wallbox (1.6 JSON) model? The company I work for is considering using Steve with this Schneider charger model. If you can, send me something in this email: gabriel.lima.rds@gmail.com. Or if you prefer, speak right here. Thank you very much!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants