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

Electric vehicle charge points #60

Closed
2 of 4 tasks
thehenster opened this issue Jul 10, 2018 · 19 comments
Closed
2 of 4 tasks

Electric vehicle charge points #60

thehenster opened this issue Jul 10, 2018 · 19 comments

Comments

@thehenster
Copy link

Electric vehicle charge points

Title

A bulk dataset to represent electric vehicle charge points - such as position, power, and connector types available.

Category

  • Data
  • Document
  • Technical
  • Other Suggestions

Challenge Owner

Henry Turner working on behalf of the Office of Low Emission Vehicles (OLEV), which is part of the Department for Transport (DfT), and the National Chargepoint Registry (NCR).

Short Description

Charge points are represented by a collection of static data such as it's position, the power available, the connector types it has, the cost to use it, or any parking restrictions in force in the relevant parking bay. In additional to this there is a collection of live/dynamic data about whether it is in use or not.

Currently the charge point operators generally publish the data in proprietary formats. Mostly we expect this is because of the lack of communication, but in some cases operators offer features that others do not. For example, one operator does not offer live/dynamic data, another does, and another offers live/dynamic data about whether it is in use or not and future reservations.

There is an existing service called the NCR http://www.national-charge-point-registry.uk/.

The more complete and consistent the dataset the more useful it will be to it's users (see below).

User Need

Electric vehicle owners need to charge their car while away from home or are without a charging facility at home. Drivers won't use the dataset directly, but there are quite a few consumers of the data that provide mapping and routing software.

Charge point operators need to publish the availability of their charge points to attract business.

Researchers who are planning infrastructure or doing product development.

Expected Benefits

OLEV's goal is to promote low emission vehicles in the UK to reduce pollution and reliance on a finite fuel source. One of their areas of focus is how to recharge electric vehicles which is a blocker to their adoption.

A measurable outcome would be an increased number of charge points published. Another measurable outcome would be richer data such as live/dynamic data.

Functional Needs

  • Machine readable
  • The electric vehicle market is still evolving so some potential to adapt to change
  • Different formats for users with varying technical ability - geojson, kml, csv, xml? etc.
  • Some data is considered commercially valuable so most attributes may have to be optional
  • Static data changes infrequently while the live/dynamic data changes frequently - there might be performance benefits to breaking the data up across multiple endpoints

OCPI (Open Charge Point Interface)

It seems OCPI is gaining some traction elsewhere in Europe (The Netherlands and Germany). A decent chunk of OCPI seems to be related to interoperability and roaming between charge point networks, which is probably outside the scope of the NCR, it does contain some endpoints for geographical information (locations in their terminology) and live/dynamic data (sessions in their terminology). Potentially promising but it seems lacking in license information and ownership, which we are attempting to investigate. Any guidance around evaluating it or how to proceed would be valuable.

The document itself: https://github.com/ocpi/ocpi

An example from the locations endpoint: https://github.com/ocpi/Samples/blob/master/ocpi/chargepoints.md

@edent
Copy link
Contributor

edent commented Jul 11, 2018

Thanks Henry, this looks like a good idea.

The PDF version of the standard is at https://github.com/ocpi/ocpi/releases/download/2.1.1/OCPI_2.1.1.pdf

Seems well defined, and uses ISO8601, HTTP, and other common standards.

@thehenster do you know which government departments, local councils, or other bodies would make use of this?

@Lawrence-G let's start the regular process.

@thehenster
Copy link
Author

do you know which government departments, local councils, or other bodies would make use of this?

I'm trying to arrange a conversation with the current governance of the project at the moment. So far I just know some companies that are using it - EVBox, New Motion, and Elaad. I'll post back if I discover any public bodies.

@PeterParslow
Copy link

Ordnance Survey takes the National Charge Point Registry data & includes it in our OS Open Map - Local (https://os.uk/business-and-government/products/os-open-map-local.html). We output it in XML (as one of the data choices), "shape" (beloved of GIS people), and as a raster image. Our XML output includes charging method, voltage, and a free text string giving the 'type' of charger.

I expect we would continue to use OffLEV's service aggregating this data.

Possibly relevant open standard found by targeted googling: https://www.iso.org/standard/69693.html (UK is represented on the 'committee' for that).

@chris-little
Copy link

chris-little commented Jul 17, 2018

Battery performance is temperature dependent. Perhaps an option would be to record the temperature of the charging session as well as its time and duration. This may give or improve insight into battery performance, with weather dependency, driver behavior ("fill it up" vs "just enough to get me home").
I am not advocating a weather station at each charging point (one lives in hope! ;-). The vehicle will probably know the temperature of its battery, which is the relevant measure.

@tommorris
Copy link

OpenStreetMap now contains the locations of over 18,000 electric vehicle charging points. Some documentation of this is contained on the OSM Wiki. The OSM community has managed to produce a lightweight ontological 'tagging' scheme for charging points providing multiple socket interfaces with different voltages, as well as providing space for further information covering acceptable vehicle types, whether a fee is payable for parking, charging (or both), and how that fee can be paid (credit/debit card? via an app? etc.), as well as what authentication process is used to start charging (SMS verification, tapping an NFC receiver, etc.)

Looking at a number of tagged charge points in London, there's a variety of data, ranging from merely an assertion that a charge point exists through to a number which specify the number of cars that can be charged simultaneously, and what charging standards are in use. The Taginfo system from OpenStreetMap shows the kind of data used in combination with amenity=charging_station.

One important potential use case for this kind of data is the provision of open source, open data satellite navigation systems to enable satnav users to get to the nearest compatible charging point, just as they currently do with petrol stations. It would be good if the data sharing that goes on with this does not get locked in to proprietary systems provided either by manufacturers, or specific to particular countries or regions.

@thehenster
Copy link
Author

@PeterParslow Thank you! We hadn't heard that NCR data was being used in OS OpenMap Local. It's difficult to find out who uses the data. Because it's open it's users are often anonymous.

@chris-little Thanks for the feedback. Some companies are experimenting with putting telematics devices in cars which feedback recharging efficiency. Maybe an alternative would be to combine existing weather station data and charge point location data to get a rough idea of the conditions at a charge point.

@tommorris I've never contributed to OSM and so don't know much about it's inner workings. The tagging scheme looks like a good start, but charge point data can be complicated. The NCR struggles to represent it accurately. Is all data in the OSM added via community contributions? Are there examples out of there of "official" data sources being integrated?

@gcameo
Copy link

gcameo commented Nov 8, 2018

I have implemented a large chunk of the OCPI specification myself as part of an EV Interoperability work I am doing. The specification is actually very matured and very well documented and I am happy to contribute to a public reference implementation.

OCPI could be considered as the answer to this consultation by Energy UK: https://www.energy-uk.org.uk/publication.html?task=file.download&id=6576

Lastly the big charging point manufacturers are now adopting OCPI too
https://www.current-news.co.uk/news/chargepoint-and-evbox-pursuing-open-access-for-ev-charging-calling-for-uk-competitors-to-follow-suit

@GavinSummerson
Copy link

@Lawrence-G @edent is this still open? We are currently working on a cross Catapult project (Future Cities, Transport Systems, Digital & Energy Systems) looking at the user experience for EVs and what supporting digital infrastructure is needed to address challenges with the user experience including standards.

@edent
Copy link
Contributor

edent commented Nov 23, 2018

Yes - we are waiting for more comments and to see how OLEV want to take this forward. If you (Cities Catapult) want to take ownership of it, that would be great.

@GavinSummerson
Copy link

Ok great, that's a yes, we would be interested to speak to OLEV and i think the results of our work on this will be useful to inform future direction. The project is looking at scenarios and what technology interventions could solve this which may need different types of data exchange.

@thehenster
Copy link
Author

I have now stopped working on that bit of NCR discovery work, but I have just sent an email to the product owner of the project at OLEV with a link to this challenge/issue. Hopefully something will come of it.

@gcameo
Copy link

gcameo commented Dec 15, 2018

@thehenster Did anything come out of it?

Given this:
https://www.gov.uk/government/news/government-funded-electric-car-chargepoints-to-be-smart-by-july-2019
Do you know what technical specifications for "smartness" will be?

@thehenster
Copy link
Author

I didn't hear from them I'm afraid.

That article is the first I've heard of the requirement for 'smart' technology in OLEV funded charge points from July 2019. From the text I suspect they're talking about demand shifting, which is where a charge point can be remotely instructed to try and start charges outside of demand peaks. It could mean vehicle to grid (V2G) - but I doubt it considering everyone is still publishing feasibility studies for it.

@GavinSummerson
Copy link

Here is a link to the technical specification that is being used to define the information sharing protocol for smart charging that links to gaining grant funding for installing home or workplace EV charging: https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/772457/electric-vehicle-chargepoint-scheme-technical-spec-july-2019.pdf This references The Open Charge Point Protocol (OCPP) version 1.6 (or above), or an equivalent. Let me know if you have an opinion on this. I am meeting with Gemserve in the next couple of weeks and others to get a bit more intel on how smart charging standards are evolving.

Here is also a link to the work that we are doing on this subject if anyone is interested in feeding into this. https://futurecities.catapult.org.uk/project/electric-vehicles-delivering-an-excellent-user-experience/.

@thehenster
Copy link
Author

It's looks as though, in this case of the Electric Vehicle Homecharge Scheme, smart means demand shifting - which means being able to communicate with the charge point to control/limit/schedule the power output.

OCPP can manage demand shifting. The SetChargingProfile operation allows the operator to send a "charging profile" to a charge point, which is a blob of stuff that can include a power limit and a schedule. It can be set before a charge or during a charge. Of course, for that to actually work the charge point needs a modem, an operator who has a backend that supports setting charging profiles, and the information for when/what level of shifting is required (eg. a static schedule of around 6pm in the week, or a dynamic schedule supplied by somewhere in electricity distribution).

The forecasting and commnication of that dynamic schedule is where Open Smart Charging Protocol (OSCP) comes in: http://cired.net/publications/cired2015/papers/CIRED2015_0106_final.pdf .. but that spec isn't talking about that (yet).

@GavinSummerson
Copy link

@thehenster Henry, would be good to talk to you in person about this challenge, if you don’t mind getting in touch gsummerson@futurecities.catapult.org.uk so I could set up a call in the first instance…..

@thehenster
Copy link
Author

I try to promote a federated OCPI-flavoured model these days.

https://ocpi-register.github.io/ocpi-register/

@RokeJulianLockhart
Copy link

RokeJulianLockhart commented Mar 14, 2021

Charge points are represented by a collection of static data such as it's position, the power available, the connector types it has, the cost to use it, or any parking restrictions in force in the relevant parking bay. In additional to this there is a collection of live/dynamic data about whether it is in use or not.

its, not it's.

@DidacFB-CDDO
Copy link

Closing this challenge down due to a lack of activity since 2021.

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

10 participants