[Ovmsdev] Sharing Data Publicly - Public Charges

[Tom Saxton]

Mark,

This is a wonderful idea, Mark. Your energy at pursuing an expanding array
of OVMS projects is inspiring. This one is particularly interesting to me.
What you propose is awesome, making reporting charging station experiences
both rich and more automated than any other process I've heard about.

In 2011, I conducted a survey of public charging sites, both to learn about
the current state of predominately taxpayer-funded charging networks and
also to explore the types of information that could be gathered for a more
effective charging station map. I've attached a brief summary of the
results. There's a lot more information and graphs available on the Plug In
America web site.

http://www.pluginamerica.org/evi-survey/
http://www.pluginamerica.org/evi-survey/EVI_Study_120225_EVS26_Paper.pdf
http://www.pluginamerica.org/evi-survey/EVI_Study_120502_EVS26_Poster.pdf

I suggest adding a couple of things:

1. Gather the charging voltage and current. It drives me crazy that the
various charging maps don't tell me the station voltage. The difference
between 208V and 240V is significant, even more so when some stations'
voltage sags well below the nominal circuit voltage under load. I've seen
stations ranging from just over 240V down to 187V. I really want that
information when I'm choosing between stations or planning charge times.
With OVMS, we can gather voltage and current info from the cars that expose
that data on the CAN bus.

2. Sometimes when you go to a site to charge, you're completely unable to
charge. I'd like a way to report that failure. The Plug In America survey
found the top reasons for not being able to charge were:
1. All available stations non-functional.
2. All station in use.
3. One or more stations ICEd.
4. Stations could not be found.
5. No public access to site.
Item 4 is actually a big problem when someone puts stations in a giant
parking garage with no directional signage to help driver's find them.

3. Text to help others location difficult-to-find stations.

4. To make this into a sustainable business, you could sell ads for
individual charging stations. I'd love to get a message like "Mention you're
charging at 3rd and Main to get 10% off at the Valley Cafe just a half block
east on 3rd Ave."

Of course as a newly-minted public charging station operator (on behalf of a
Tesla owner co-op), I'd like a piece of that action at my charging station
but I don't think there's a good argument that I'm entitled to such, and
managing that could be a pain. Perhaps there's a model where station
operators use the OVMS network as a platform for selling ads. I've suggested
this idea to ChargePoint and Blink, but they don't seem to be interested.

As a Plug In America guy, I'm always on the lookout for business models that
make public charging a sustainable business.

   Tom

From:  Mark Webb-Johnson <mark at webb-johnson.net>
Reply-To:  OVMS Developers <ovmsdev at lists.teslaclub.hk>
Date:  Wednesday, December 11, 2013 at 5:32 AM
To:  OVMS Developers <ovmsdev at lists.teslaclub.hk>
Subject:  [Ovmsdev] Sharing Data Publicly - Public Charges


I¹ve always been interested in the possible uses of OVMS for the greater
good of the EV community, and to assist with the widespread adoption of
Electric Vehicles. The anonymised Tesla Roadster charging records we
provided to Tom Saxton for his work on a Charge Time Predictor for these
cars showed how beautifully such information sharing can work.

One big target for me has always been the sharing of information on public
charge stations. Most of these systems are walled gardens at the moment
(either for the charge station network or for the vehicle manufacturers),
and there seems to be very little sharing going on. Chargepoint know when
you start to charge, when you finish, the result (completed successfully or
interrupted), volts, amps, etc - but not SOC% or which vehicle was actually
being charged (just the owner). Leaf Carwings presumably knows where you
charged, and the result, per vehicle, but has no way of sharing that with
charging station networks. You can use Recargo to find a charging station,
but have to manually go in and enter the charge result (if you want to
feed-back positive/negative reviews to Recargo for the benefit of other
users). The end result is a wallet full of charging network membership
cards, RFID tags, and a cellphone full of Apps for all the different
networks. Over time this will resolve itself, but for the moment it is a
mess.

Open Charge Map goes a long way towards opening the charging station
information, but the information seems to be flowing out of OCM to others,
but not necessarily the other way.

Well, it turns out that for OVMS at least, we have a possible solution. A
solution that can be both charging network and vehicle agnostic (at least
for the vehicles supported). The rest of this eMail outlines my ideas for
how this could be implemented. Think of it as an old-fashioned Request For
Comments, and let me have your feedback.

Thanks, Mark.

Sharing Public Charge Data

The Problem

To allow OVMS users to automatically and simply share their usage of public
charging stations. The information shared would be openly available to
charging networks, charge station databases, apps, researchers, and other
interested parties.

Pre-Requisites

Participating users would be required to have OVMS installed in their
vehicle, and for the vehicle to be supported in as much as it can provide to
the server indication of location, charge start, and charge completion
events. Users would also require a cellphone app for authorisation and
control of the sharing of their data.

Licensing

The data produced should be licensed in some Œopen¹ way. Do with it as you
will. Perhaps creative commons, or something similar.

Vehicle Firmware Changes

Specific messages for ³Charge Start² and ³Charge Completed² should be
created and sent to the server at the appropriate times. Control of this can
be in the common vehicle.{h,c} code, and is not hard to implement. Only the
Œlast¹ charge is required, and the normal historical data interface can be
used.

App Changes

The Apps (Android and iOS) would require a mechanism for the user to opt-in
to the scheme, and for that opt-in to be either anonymous or with a
user-defined nickname. The opt-in is per-vehicle and the default is for all
vehicles to be opted out. When the App connects to the server, it will
inform the server as to the opt-in status.

The Apps will occasionally receive push notification messages from the
server, at the start of a charge. Those messages will lead to a dialog for
the user to confirm what he would like to do with the current charge:
  a) Always shared charging information for this location
  b) Share just this once charging information for this location
  c) Do not share this one charging session for this location.
  d) Never share charging information for this location

If the choice is made to share, additional information can be provided (such
as the charging post number, comments, etc). It would be nice to include
information from Open Charge Map at this point (such as the name of the
charging station, and validation of the charging point number), but we will
need to verify licensing and other considerations (such as whether this
would be acceptable / desirable to Open Charge Map).

The Apps will occasionally receive push notification messages from the
server, when charges are aborted. Those messages will lead to a dialog for
the user to confirm the reason for the abort:
  a) Charge was successful, but interrupted by the user
  b) Charge was unsuccessful, due to a problem with the charging station
  c) Charge was unsuccessful, but not a problem of the charging station.

The user¹s response must be returned to the server appropriately.

The Apps, when connected to the server, can also receive a list of charging
records that have not yet been responded to. A dialog should be presented to
the user for each such location.

Server Changes

The servers will maintain opt-in status for each vehicle in the system, and
if opted-in, the nickname / anonymous handle for the vehicle.

The servers will maintain a historical list of charging locations for each
vehicle in the system. Each location record would have:
  a) Latitude, Longitude (geofenced).
  b) Sharing flag (pending user, just this once, always, not this once, or
never).
  c) Charging information (date/time charge started, etc).
  d) Date and result of last charge here.

When the server receives a Œcharge started¹ message from the vehicle, it
would look up the geofenced location in the database, for the vehicle, and
use the sharing flag to determine what to do.

If there is no matching record found, a new record would be created (sharing
flag: pending user).

When the server receives a Œcharge completed¹ message from the vehicle, it
would look up the geofenced location in the database, for the vehicle, and
use the sharing flag to determine what to do.

If the sharing flag indicates that the charging information should be
shared, the server would publish the charging session information
appropriately.

If the server receives an indication from the car that a charge has been
aborted, it will have to PUSH notify the user - but also ask the user for
confirmation of the reason why the charge was interrupted.

When the server receives a user decision message from an App (either before
or after charge completion), it should update the charging location record
appropriately. This may also result in the publishing of the charging
session information.

The server will maintain a database of partners, and their API access keys.
This database should allow for PUSH messages (via HTTP) to the partner. If
PUSH is enabled, every time a charging session is updated (either started or
completed), the server will connect to each partner (in randomised order)
and send them the information for recent charges. The server will also
provide an API to allow partners to PULL messages past a certain date/time
stamp (to allow for periodic synchronisation).

Partners

Partners would just have to subscribe to the system (signing up with a user
account and being given an API key). They would have to agree to the license
terms, but other than that there would be no restrictions to partnership.

Partners can choose to either retrieve updates via PUSH (they provide a
server URL to receive the data), PULL (they periodically poll the OVMS
server for updated data), or a combination of both.

Overview (start to finish)

An OVMS user opts in to the service. He uses the nickname ŒJimbo¹.

He arrives at a public charging station and plugs in. The OVMS module in his
car detects the charge has started and informs the server. The server looks
up the vehicle charging locations and finds that the vehicle has never
charged here before, so sends a PUSH notification to the user¹s Apps to ask
him about this charge.

Within seconds of the charge starting, the user¹s cellphone beeps and he
sees an OVMS notification. He clicks on it and is taken a dialog asking him
about the charge he has just started. This is a public charge station, so he
just clicks ³Always share charging information for this location² and turns
off his phone. The App sends a notification to the server, and the server
updates its records to never both the user about this location again. The
server also updates all partners (via PUSH notification) that a charge has
started at this location.

Partners can use this information to record statistics on charge station
usage, or even as a rudimentary indication of if the charging station is in
use (at least by an OVMS user).

After a few hours of charging, a breaker trips and the charge is
interrupted. The OVMS module in his car detected the abort and informs the
server. The server looks up the vehicle charging location, and if sharing is
enabled for this location sends a PUSH notification to the user¹s Apps
asking him about the cause of this interruption?

The user returns to his car and finds the problem. He responds to the dialog
in his OVMS App to let the system know that the charge was interrupted by a
problem of the charging station. The server receives the response, updates
its records, and updates all partners (via PUSH notification) that a charge
has been interrupted at this location.

Partners can use this information to record statistics on charge station
failure rates, as well as updating that the charge station is no longer in
use.

Partners not using PUSH notifications can retrieve all this information at a
later date by a simple HTTP PULL request.

Further work

There are many extensions possible to this system, but I would first of all
like to concentrate on getting a basic implementation designed and
implemented, and some partnerships in place.

For example:

* Pictures of new charging locations.
* Information for new charging locations.
* Charging station information.
* Showing current usage of a particular station in the Apps.
* and so much more

Privacy Issues

The biggest privacy issue is that the server would have to record the
locations of charging stations that the user has requested not be shared.
For example, someone¹s home. We could avoid this by not recording these, but
that would not be optimal as the system would then have to ask the user
whether he wanted to share, each and every time they charged at that
location (rather than just once, the first time). As this information is not
actually shared, it is not a true privacy issue - but should the security of
the server be compromised, that data could be exposed.

Perhaps a one-way hash could be used for storing locations, but we would
have to find one that also worked with geofenced lookups.

Conclusions

The above is not hard. In particular, the vehicle firmware changes are
trivial (it could even be done without any vehicle firmware changes, by
looking at the S and D messages coming back from the cars). The server code
is not difficult at all. The largest amount of work would be in the Apps (in
particular, handling the PUSH notifications and user dialogs).

_______________________________________________ OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20131211/07c42658/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 120815-results.pdf
Type: application/pdf
Size: 83051 bytes
Desc: not available
URL: <http://lists.teslaclub.hk/pipermail/ovmsdev/attachments/20131211/07c42658/attachment-0001.pdf>