RFC: Enhanced Data Model For Equipment/Location Information

[webprofusion-chrisc]

Proposal

As the world of EV charging has moved from pilot projects to growing international standards the need to grow and mature Open Charge Map has also developed. We're now at a point where we need to plan our next round of big changes to be able to accurately and efficiently capture, maintain and distribute the important details about the worlds EV charging infrastructure.

We've seen equipment and vehicles become more sophisticated and charging networks grow, merge or become obsolete. Charging stations have gone from being basic power delivery machines to multi-headed, networked, smart units often servicing multiple bays.

With that in mind, OCM needs to look at the information we currently capture and maintain and look forward to how we think it should be organised and managed in the future.

For a given location we currently (Mid-2015) store the following information:

* Address Details (Location Title, Address, Latitude & Longitude, Access Comments)
* A single associated Network Operator ID
* Number of Bays/Stations
* A single associated Data Provider (usually Open Charge Map but info may be imported from an external source)
* A Data Provider Reference (if imported)

Equipment Details:

This proposal and discussion broadly covers the need for a new (non-breaking change) design to capture equipment details in a way which more accurately reflects the real world and will allow for greater data accuracy.The aim of this is to then be able to show clearer information about available equipment at locations.

Suggested Changes

Network Operator - Standard Equipment

Versioned preset equipment configurations which users can select from a list after selecting the Country & network operator. This enables easier addition of locations where equipment is generally of the same specification. In addition the resulting UI could allow for further customisation on a per-location basis.

Related Operators

Establish relationships between network operators so that if an RFID card from one operator will work with another (and perhaps vice-versa) then that can be centrally documented and all associated charging stations will reflect that automatically.

Charging Stations vs ConnectionInfo

Currently a location may have one or more ConnectionInfo entries which details a connector type, power level etc. The proposal is to allow these to be grouped into a physical station (of which there may be several at the site), which in turn can service one or more parking bays.

A station may allow a single or multiple connections to be in use at any one time.

A station may have a distinct geographic location and access instructions at the common site (shared with other stations) .

Each station will be associated with a Network Operator (who controls access and may in turn do equipment maintenance or may outsource maintenance to one or more parties). How would we represent situations where the network operator is a corporation but the branding for the network is local (local government initiative etc.)?

The number of bays present at a given station needs to be clear, as does the number of available stations and their ability to share connections with multiple cars simultaneously
.
The OCM-ID of a location will point to one or more stations at a single common site (Point Of Interest [POI]), multiple network operators and equipment types may be present at the site.

The POI may be a composite of imported data which has since been edited.In this case multiple data providers are responsible and each provider and their associated license details needs to be identified.

OCM can currently hold external metadata about a site (this includes data attribution, POI types) - we would like to develop this more so that sites can be tagged with metadata such as the Hotel, Secure Access, Restaurant, Toilets etc.

As a related project, our current default API JSON output consists of monolithic objects for Data Provider, Country, Connection Type etc. Instead these should consists purely of reference ID's which related to our Core Reference Data (DataProviders, ConnectionTypes etc). This will greatly reduce the default API results payload size.

This proposal will be updated as we arrive at decisions.

[zymurgic]

Sometimes relatedoperators are unofficial and are on a per-charging station basis. It is not unknown for a charge station manufacturer to have a preferred charging network that they used for testing, and hard-code in a range of card numbers to the charging station code. Then the charging station is deployed, and the debug option isn't turned off, leaving it handily also accepting cards from a network other than officially defined. To be honest, these are fairly rare and could be documented in the description of each charging station.

Regarding connector types, we probably should differentiate between a socketed Mennekes Type 2 outlet (as used in most European public fast chargers), and a tethered type 2 vehicle plug, tethered type 2 vehicle plugs are often used by home chargers for convenience, and on public AC rapid chargers, where carrying a heavy high current capable cable around is inconvenient. If you have a type 1 (J1172) to type 2 (Mennekes) cable, you can't plug into the tethered chargers - because the geometry is subtly different, and there would be too many resistors in the cable.

[zymurgic]

Actually, I have just thought of an issue on related operators, I'll use some examples that are common in the UK.

Chargemaster make charge stations.
Chargemaster also run a backoffice system, and have end user accounts, with the offering known as "Polar Network".
Source London, and Source East are regional charge schemes, they run a backoffice system, and have end user accounts.
Councils and other organisations buy posts, which may, or may not be from Chargemaster, and register them with a regional charging scheme, to allow users to use the posts.

So, to use a Chargemaster manufactured charging station in much of London, you are supposed to use Source London cards, but you can also use a Polar Network Card. You're supposed to also be able to use Source East - but in practice, this roaming isn't very reliable.
To use an Elektromotive-manufactured charging station in much of London, you're supposed to use Source London cards, and a Polar Network card will not do. Because of quirks in commissioning, a Charge your Car card may unofficially work on the Elektromotive post.

As such, we may need to have default related operators - so by default a Source London managed post should accept Source London and Source East cards, but be able to override it on a per-charging station basis - and in some cases, on a per-outlet basis - some dual-outlet charging station designs have two entirely separate systems in the same cabinet - these have multiple unique identifers.

[solarpete]

My answer for question "How would we represent situations where the network operator is a corporation but the branding for the network is local (local government initiative etc.)?" would be to use the corporation operating it as a network operator, since the access method will depend on this operator. In case the branding makes it hard to identify which station is described, this kind of information could be added to the Notes field.

I agree with the need to differentiate between number of stations and number of bays, since these numbers can be different (if both of them are considered useful, e.g. I am not sure the number of bays is an important information).

[webprofusion-chrisc]

Updated to include reference to need for multiple composite data providers.

[solarpete]

I have a suggestion regarding the quality of data about station's availability:

Problem: When I add/edit information about a station and it's equipment, I am never sure whether to say in the operational status fields. The reason is that unless the status is updated automatically I can never be sure whether the station is still operable since the last time I was there. However entering "unknown" does not feel right either, since it does not differentiate between the station I update just based on other publicly accessible data and between station that I personally saw operable some time ago... Also it is hard to know how other users of OCM's data feel about the meaning of the statuses.

Proposed solution:

1. Display the date when the station's Operational Status was last updated along with the status itself.
2. Add a field for editors to add the date when this information was last known to be accurate.

Ad. 1.: This should enable each user to see how old the data actually is and he can make independent decision using this data. E.g. when planning a trip with a tight schedule he may prefer stations with only a few weeks old status to stations with months old statuses. But when just roaming this may not be a concern at all and he may trust older data as well.
Ad 2.: This will enable the editors who did not have time to update the status (or provide check-in) right away to add it later with correct date of acquiry without fear that what their knowledge is actually older than what is already in database.

Note: Data quality report already does partly indicate the quality of status update. While I really like the idea, there is a limitation to it: the logic how it works is not known. E.g. how old does the update have to be to claim the data is reliable/unreliable?