From: Mark Webb-Johnson <mark@webb-johnson.net>
Message-Id: <8C0D2DD0-86ED-4329-AB0A-7ACD17AFE9C7@webb-johnson.net>
Date: Wed, 11 Dec 2013 21:32:46 +0800
To: OVMS Developers <ovmsdev@lists.teslaclub.hk>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
Subject: [Ovmsdev] Sharing Data Publicly - Public Charges
Precedence: list
Reply-To: OVMS Developers <ovmsdev@lists.teslaclub.hk>
Content-Type: multipart/mixed; boundary="===============2650495201468599346=="
Sender: ovmsdev-bounces@lists.teslaclub.hk
Errors-To: ovmsdev-bounces@lists.teslaclub.hk


--===============2650495201468599346==
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_F39DD869-FE8D-4B83-AB52-E764C1904063"


--Apple-Mail=_F39DD869-FE8D-4B83-AB52-E764C1904063
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


I=92ve 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 =91open=92 way. Do with it =
as you will. Perhaps creative commons, or something similar.

Vehicle Firmware Changes

Specific messages for =93Charge Start=94 and =93Charge Completed=94 =
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 =91last=92 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=92s 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 =91charge started=92 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 =91charge completed=92 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 =91Jimbo=92.

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=92s Apps to ask him about this charge.

Within seconds of the charge starting, the user=92s 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 =93Always share charging information for this =
location=94 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=92s 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=92s 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).


--Apple-Mail=_F39DD869-FE8D-4B83-AB52-E764C1904063
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div><br></div><div>I=92ve 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.</div><div><br></div><div>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.</div><div><br></div><div><div>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.</div></div><div><br></div><div>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.</div><div><br></div><div>Thanks, =
Mark.</div><div><br></div><div><font size=3D"4"><b><u>Sharing Public =
Charge Data</u></b></font></div><div><br></div><div><u><font =
size=3D"4"><b>The Problem</b></font></u></div><div><br></div><div>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.</div><div><br></div><div><u><font =
size=3D"4"><b>Pre-Requisites</b></font></u></div><div><br></div><div>Parti=
cipating 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.</div><div><br></div><div><u><font =
size=3D"4"><b>Licensing</b></font></u></div><div><br></div><div>The data =
produced should be licensed in some =91open=92 way. Do with it as you =
will. Perhaps creative commons, or something =
similar.</div><div><br></div><div><u><font size=3D"4"><b>Vehicle =
Firmware Changes</b></font></u></div><div><br></div><div>Specific =
messages for =93Charge Start=94 and =93Charge Completed=94 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 =91last=92 charge is required, and the normal historical data =
interface can be used.</div><div><br></div><div><u><font size=3D"4"><b>App=
 Changes</b></font></u></div><div><br></div><div>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.</div><div><br></div><div>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:</div><div>&nbsp; a) Always shared charging information for this =
location</div><div>&nbsp; b) Share just this once charging information =
for this location</div><div>&nbsp; c) Do not share this one charging =
session for this location.</div><div>&nbsp; d) Never share charging =
information for this location</div><div><br></div><div>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).</div><div><br></div><div>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:</div><div>&nbsp; a) Charge was successful, but interrupted by =
the user</div><div>&nbsp; b) Charge was unsuccessful, due to a problem =
with the charging station</div><div>&nbsp; c) Charge was unsuccessful, =
but not a problem of the charging station.</div><div><br></div><div>The =
user=92s response must be returned to the server =
appropriately.</div><div><br></div><div>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.</div><div><br></div><div><u><font size=3D"4"><b>Server =
Changes</b></font></u></div><div><br></div><div>The servers will =
maintain opt-in status for each vehicle in the system, and if opted-in, =
the nickname / anonymous handle for the =
vehicle.</div><div><br></div><div>The servers will maintain a historical =
list of charging locations for each vehicle in the system. Each location =
record would have:</div><div>&nbsp; a) Latitude, Longitude =
(geofenced).</div><div>&nbsp; b) Sharing flag (pending user, just this =
once, always, not this once, or never).</div><div>&nbsp; c) Charging =
information (date/time charge started, etc).</div><div>&nbsp; d) Date =
and result of last charge here.</div><div><br></div><div>When the server =
receives a =91charge started=92 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.</div><div><br></div><div>If there =
is no matching record found, a new record would be created (sharing =
flag: pending user).</div><div><br></div><div>When the server receives a =
=91charge completed=92 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.</div><div><br></div><div>If the sharing =
flag indicates that the charging information should be shared, the =
server would publish the charging session information =
appropriately.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div><div><u><font =
size=3D"4"><b>Partners</b></font></u></div><div><div><br></div><div>Partne=
rs 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.</div><div><br></div><div>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.</div><div><br></div></div></div><div><u><font =
size=3D"4"><b>Overview (start to =
finish)</b></font></u></div><div><br></div><div>An OVMS user opts in to =
the service. He uses the nickname =91Jimbo=92.</div><div><br></div><div>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=92s Apps to ask him about this =
charge.</div><div><br></div><div>Within seconds of the charge starting, =
the user=92s 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 =93Always =
share charging information for this location=94 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.</div><div><br></div><div>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).</div><div><br></div><div>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=92s Apps asking him about the =
cause of this interruption?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Partners not using PUSH notifications can =
retrieve all this information at a later date by a simple HTTP PULL =
request.</div><div><br></div><div><u><font size=3D"4"><b>Further =
work</b></font></u></div><div><br></div><div>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.</div><div><br></div><div>For =
example:</div><div><br></div><div>* Pictures of new charging =
locations.</div><div>* Information for new charging =
locations.</div><div>* Charging station information.</div><div>* Showing =
current usage of a particular station in the Apps.</div><div>* and so =
much more</div><div><br></div><div><u><font size=3D"4"><b>Privacy =
Issues</b></font></u></div><div><br></div><div>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=92s 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.</div><div><br></div><div>Perhaps a one-way hash could be used =
for storing locations, but we would have to find one that also worked =
with geofenced lookups.</div><div><br></div><div><font =
size=3D"4"><b><u>Conclusions</u></b></font></div><div><br></div><div>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).</div><div><br></div></body></html>=

--Apple-Mail=_F39DD869-FE8D-4B83-AB52-E764C1904063--

--===============2650495201468599346==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============2650495201468599346==--